Genel olarak ve postgresql için shmall, shmmax, shmmin vb.


11

Ben kullandım PostgreSQL'den belgelere örneğin bu yapılandırma için ayarlamanız için:

>>> cat /proc/meminfo 
MemTotal:       16345480 kB
MemFree:         1770128 kB
Buffers:          382184 kB
Cached:         10432632 kB
SwapCached:            0 kB
Active:          9228324 kB
Inactive:        4621264 kB
Active(anon):    7019996 kB
Inactive(anon):   548528 kB
Active(file):    2208328 kB
Inactive(file):  4072736 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:              3432 kB
Writeback:             0 kB
AnonPages:       3034588 kB
Mapped:          4243720 kB
Shmem:           4533752 kB
Slab:             481728 kB
SReclaimable:     440712 kB
SUnreclaim:        41016 kB
KernelStack:        1776 kB
PageTables:        39208 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8172740 kB
Committed_AS:   14935216 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      399340 kB
VmallocChunk:   34359334908 kB
HardwareCorrupted:     0 kB
AnonHugePages:    456704 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       12288 kB
DirectMap2M:    16680960 kB

>>> ipcs -l          

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 4316816
max total shared memory (kbytes) = 4316816
min seg size (bytes) = 1

------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767

------ Messages Limits --------
max queues system wide = 31918
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

Benim tarafımdan hesaplanan sysctl.conf özütü :

kernel.shmall = 1079204
kernel.shmmax = 4420419584

postgresql.conf varsayılan olmayan , benim tarafımdan hesaplanan:

max_connections = 60            # (change requires restart)
shared_buffers = 4GB            # min 128kB
work_mem = 4MB              # min 64kB
wal_sync_method = open_sync     # the default is the first option
checkpoint_segments = 16        # in logfile segments, min 1, 16MB each
checkpoint_completion_target = 0.9  # checkpoint target duration, 0.0 - 1.0
effective_cache_size = 6GB

Bu uygun mu? Değilse (veya zorunlu olarak değil), bu durumda uygun olur mu?

Bu yapılandırmada güzel performans geliştirmelerine dikkat çektik, nasıl geliştirirdiniz?

Çekirdek bellek yönetimi parametreleri nasıl hesaplanır?

Bunları nasıl sıfırdan başlatacağınızı açıklayan var mı?


Bu çok soru ve bize mevcut probleminizin (eğer varsa) veya kullanım şeklinizin ne olduğunu söylemediniz. PostgreSQL performansı hakkında bir kitap edinmeye değer olabilir.
hmallett

Benim sorunum, doğru ayarları yaptığım konusunda ikna olmadığım. Çekirdek bellek yönetimi seçeneklerinin PostgreSQL'e özgü olmadığını düşünüyorum, ayrıca PostgreSQL'in bu seçenekler hakkında konuşmak için en iyi yer olduğundan emin değilim. Elbette, PostgreSQL performansı hakkında herhangi bir makalede yoğun bir şekilde bahsedildi, ancak bu Linux seçenekleri ve genel olarak nasıl ayarlanacağını gerçekten anlamak için sabırsızlanıyorum.
jpic

Yanıtlar:


11

Buraya başka bir soru için cevap verdim:

Git, 'bellek yetersiz' hatasıyla aktarılamıyor

Burada tüm sorularınızı cevaplamıyorum, ancak başlığınızdaki soru:

Genel olarak ve postgresql için shmall, shmmax, shmmni, vb nasıl ayarlanır?

Bazı çekirdek dağıtımlarında, çekirdeğin tek bir işleme maksimum bellek ayırmasını engelleyen ayarlar vardır:

Çekirdek Parametrelerini Ayarlama

Değiştir /etc/sysctl.confhatları işletim sistemine mülk içerecek şekilde dosyayı:

# Red Hat Enterprise Linux 3.0 and CentOS 3.x 
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmin = 1
kernel.shmseg = 10

# semaphores: 
semmsl, semmns, semopm, semmni kernel.sem = 250 32000 100 128
fs.file-max = 65536

# Red Hat Enterprise Linux 4.0 and CentOS 4.x 
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.shmall = 2097152

İşleminiz sınırları aşarsa, sisteminizde bildirilen maksimum bellek miktarına rağmen çekirdek işlemi öldürür.

Not: bu ayarlara dikkat edin. Ortamımızdaki bir sunucudan çektiğim için muhtemelen bu örnekteki ayarları kullanmak istemezsiniz.

Birkaç ek not:

Çekirdek ayarlarını sysctl ile güncellemek ve test etmek için aşağıdaki komutları kullanın:

Mevcut ayarları listele:

sysctl -A | grep shm
sysctl -w kernel.shmmax=<value> to write in sysctl.conf
sysctl -p /etc/sysctl.conf to read/reload the values from sysctl.conf

/etc/selinux/configSELINUX bayrağının aşağıdaki gibi ayarlandığından emin olarak dosyayı düzenleyerek güvenli linux'u devre dışı bırakın .

SELINUX=disabled

Bu uygun mu? Değilse (veya zorunlu olarak değil), bu durumda uygun olur mu?

Çekirdek ayarları genellikle, ISS sağlayıcıları paylaşılan bir sunucudaki tüm kaynakları dolaşan tek bir müşteri işlemi istemediğinde veri merkezi ortamlarında daha kesin olarak tanımlanır.

Kaynak açlığı nedeniyle çekirdek tarafından öldürülen bir işleminiz yoksa genellikle çekirdek bellek parametrelerini ayarlamanız gerekmez.

Bazı durumlarda postgres, belirli sayfa boyutlarına paylaşılan hafızada bulunanlardan daha fazla bellek ayırabilir:

* The PostgreSQL server failed to start. Please check the log output:
2011-11-04 05:06:26 UTC FATAL: could not create shared memory segment: Invalid
argument
2011-11-04 05:06:26 UTC DETAIL: Failed system call was shmget(key=5432001, size
=161849344, 03600).
2011-11-04 05:06:26 UTC HINT: This error usually means that PostgreSQL’s reques
t for a shared memory segment exceeded your kernel’s SHMMAX parameter. You can
either reduce the request size or reconfigure the kernel with larger SHMMAX. To
reduce the request size (currently 161849344 bytes), reduce PostgreSQL’s shared
_buffers parameter (currently 19200) and/or its max_connections parameter (curre
ntly 53).
If the request size is already small, it’s possible that it is less than
your kernel’s SHMMIN parameter, in which case raising the request size or recon
figuring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memo
ry configuration.
…fail!

Yukarıdaki örnek gibi hatalar, çekirdek kaynak ayarlarınızı değiştirerek çözülebilir. Kaynak ayarlarını belirlemek için önerilen ayarlar ve yöntemler burada ayrıntılı olarak açıklanmaktadır:

http://www.postgresql.org/docs/9.1/static/kernel-resources.html

Ancak, postgres işlemiyle ilgili kaynak açlık durumlarıyla karşılaşmadığınız sürece bu ayarlara dokunmanız gerekmez. Bu durumlar, çoğunlukla, paylaşılan ortamlarda veya kendilerine çok az kaynak ayrılmış sunucularda görülür.

Bunları nasıl sıfırdan başlatacağınızı açıklayan var mı?

Postgres ayarı için şunu okumalısınız:

http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server


1
"Not: bu ayarlara dikkat edin. Bu örnekteki ayarları muhtemelen ortamımızdaki bir sunucudan aldığım için kullanmak istemezsiniz." Onları çevrelerim için nasıl hesaplamalıyım?
jpic

1
Hey jpic, çekirdek ayarları hakkında daha ayrıntılı bilgi vermek için güncelledim.
Jason Huntley

2

Ah !! Burada postgresql sunucumuzun optimus mem yapılandırmasını hesaplamak için harika bir araç buluyorum.

http://pgtune.leopard.in.ua/


Bu araç, optimus yapılandırmasını hesaplamak üzere değildir, size temel olarak donanım ayarlarınıza dayalı bir yanıt verdiği için sunucunuzu ayarlamanız için bir başlangıç ​​noktası sağlar. Yapılandırma parametrelerini ayarlamak için veritabanı boyutu, sorgu sayısı ve boyutları da önemlidir.
EAmez

1

Bu çekirdek yapılandırmaları geneldir, işleme özgü değildir, bu nedenle bunları ayarlamak uygundur sysctl.conf.


Soru, çekirdek paylaşımlı bellek yönetimi parametreleri için değerlerin belirlenmesiyle ilgilidir, "nerede" değil, "nerede" ... Cevabınız için gösterdiğiniz çaba için teşekkürler.
jpic

Evet. önemsiz olan orada. eti nasıl.
Henley Chiu

0

Peki bu saf bir PostgreSQL sunucusu ise, o zaman PostgreSQL bu ayarları aramak için doğru yer başka ne sunucuda çalışıyor bağlıdır.
Belirli bellek gereksinimlerine sahip diğer uygulamaları / hizmetleri çalıştırıyorsanız, bu farklı uygulamalar arasında en uygun ayarı bulmanız gerekecektir.

Veritabanında artan bir performans ve diğer uygulamalarda performans kaybı görmüyorsanız, bu konuda endişelenmeyeceğim.

Genellikle veritabanları, bellek ayarlarına en duyarlıdır, çünkü büyük olasılıkla uygulama performansı üzerindeki darboğaz, DB için sisteminizi optimize etmek mantıklıdır.


"Bu farklı uygulamalar arasında en uygun ayarı nasıl bulurum?" Bir performans sorunum yok, paylaşılan bellek çekirdeği ayarlarını yapılandırmak için kanonik bir yol arıyorum, gerçek bir profesyonel nasıl yapardı? Birisinin size bir avuç hizmet ile çalışan bir sunucuyu yönettiğini ve sadece bellek yönetimi ayarlarını yapmanızı ödediğini varsayalım, ne yapardınız?
jpic

Altın bir kural yoktur, sadece satıcının söylediklerine bakın ve test edin. Aynı makinede çalışan birden fazla uygulamanız varsa, bellek yoğun uygulamaların çoğunu, çoğu durumda DB'yi optimize etmeye çalışın. Ancak bunları test eden satıcı önerilerine bakmanın yanı sıra, tek bir doğru çözüm yoktur
Sibster

Altın bir kural olmadığını biliyorum. Belki de ödülün bunu gerçekten anlayan birini bazı yönleri yazmaya motive edeceğini umuyordum. Ama bence kimse bunu tam olarak tam olarak anlayamıyor - çünkü kimse basit bir açıklama yapamıyor.
jpic
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.