Cara mengatur shmall, shmmax, shmmin, dll ... secara umum dan untuk postgresql


11

Saya telah menggunakan dokumentasi dari PostgreSQL untuk mengaturnya sebagai contoh konfigurasi ini:

>>> 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

ekstrak sysctl.conf , dihitung oleh saya:

kernel.shmall = 1079204
kernel.shmmax = 4420419584

postgresql.conf non default , dihitung oleh saya:

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

Apakah ini tepat? Jika tidak (atau tidak harus), dalam hal apa itu akan sesuai?

Kami mencatat peningkatan kinerja yang bagus dengan konfigurasi ini, bagaimana Anda memperbaikinya?

Bagaimana cara menghitung parameter manajemen memori kernel?

Adakah yang bisa menjelaskan bagaimana cara mengaturnya dari bawah ke atas?


Itu banyak pertanyaan, dan Anda belum memberi tahu kami apa masalah Anda saat ini (jika ada), atau apa pola penggunaan Anda. Mungkin layak mendapatkan buku tentang kinerja PostgreSQL.
hmallett

Masalah saya adalah saya tidak yakin bahwa saya membuat pengaturan yang benar. Saya pikir opsi manajemen memori kernel tidak spesifik untuk PostgreSQL dan saya juga tidak yakin bahwa PostgreSQL adalah pilihan terbaik untuk membicarakan opsi-opsi ini. Tentu, mereka banyak disebutkan dalam artikel apa pun tentang kinerja PostgreSQL, tapi itu opsi Linux dan saya berharap untuk benar-benar memahami cara menyetelnya secara umum.
jpic

Jawaban:


11

Saya menjawab ini untuk pertanyaan lain di sini:

Git gagal mendorong dengan kesalahan 'kehabisan memori'

Saya tidak menjawab semua pertanyaan Anda di sini, tetapi pertanyaan dalam judul Anda:

Cara mengatur shmall, shmmax, shmmni, dll ... secara umum dan untuk postgresql

Dengan beberapa distribusi kernel, ada pengaturan yang mencegah kernel dari alokasi memori maksimal ke satu proses:

Setel Parameter Kernel

Ubah /etc/sysctl.conffile untuk memasukkan baris yang sesuai dengan sistem operasi Anda:

# 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

Jika proses Anda melebihi batas, kernel akan mematikan proses meskipun memori maks yang dilaporkan tersedia di sistem Anda.

Catatan: hati-hati dengan pengaturan ini. Anda mungkin tidak ingin menggunakan pengaturan dalam contoh itu karena saya menariknya dari server di lingkungan kami.

Beberapa catatan tambahan untuk menyebutkan:

Untuk memperbarui dan menguji pengaturan kernel dengan sysctl, gunakan perintah berikut:

Daftar pengaturan saat ini:

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

Nonaktifkan linux aman dengan mengedit /etc/selinux/configfile, pastikan flag SELINUX diatur sebagai berikut.

SELINUX=disabled

Apakah ini tepat? Jika tidak (atau tidak harus), dalam hal apa itu akan sesuai?

Pengaturan kernel biasanya lebih ketat didefinisikan dalam lingkungan pusat data ketika penyedia ISP tidak ingin satu proses pelanggan memonopoli semua sumber daya pada server bersama.

Anda biasanya tidak perlu mengatur parameter memori kernel kecuali Anda memiliki proses yang terbunuh oleh kernel karena kelaparan sumber daya.

Dalam beberapa kasus, postgres juga dapat mengalokasikan lebih banyak memo ke ukuran halaman tertentu daripada yang tersedia di memo bersama:

* 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!

Kesalahan seperti contoh di atas, dapat diatasi dengan mengubah pengaturan sumber daya kernel Anda. Pengaturan dan metode yang direkomendasikan, untuk menentukan pengaturan sumber daya, dijelaskan secara rinci di sini:

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

Namun, Anda benar-benar tidak perlu menyentuh pengaturan ini kecuali Anda menghadapi situasi kelaparan sumber daya terkait dengan proses postgres. Situasi ini terjadi, paling sering, di lingkungan bersama atau server dengan sumber daya yang dialokasikan sedikit untuk mereka.

Adakah yang bisa menjelaskan bagaimana cara mengaturnya dari bawah ke atas?

Adapun penyetelan Postgres, Anda harus membaca ini:

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


1
"Catatan: hati-hati dengan pengaturan ini. Anda mungkin tidak ingin menggunakan pengaturan dalam contoh itu karena saya menarik mereka dari server di lingkungan kita." Bagaimana saya harus menghitungnya untuk lingkungan saya?
jpic

1
Hei jpic, saya memperbarui untuk memberikan detail lebih lanjut tentang pengaturan kernel.
Jason Huntley

2

Oh !! Saya menemukan alat yang bagus untuk menghitung konfigurasi mem dari server postgresql kami di sini.

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


Alat ini bukan untuk menghitung konfigurasi optimus, ini memberi Anda titik awal untuk menyempurnakan server Anda, karena memberi Anda jawaban terutama berdasarkan pengaturan perangkat keras Anda. Ukuran basis data, jumlah kueri dan ukuran juga penting untuk menyetel parameter konfigurasi.
EAmez

1

Konfigurasi kernel tersebut bersifat global, bukan spesifik untuk proses, jadi sangat tepat untuk mengaturnya sysctl.conf.


Pertanyaannya adalah tentang menentukan nilai untuk parameter manajemen memori kernel bersama, "bagaimana", bukan "di mana" ... Terima kasih atas upaya yang dimasukkan ke dalam jawaban Anda.
jpic

ya. ada tempat yang sepele. bagaimana dagingnya.
Henley Chiu

0

Yah itu tergantung apa lagi yang berjalan di server, jika ini adalah murni server PostgreSQL maka PostgreSQL adalah tempat yang tepat untuk mencari pengaturan ini.
Jika Anda menjalankan aplikasi / layanan lain yang memiliki kebutuhan memori spesifik maka Anda perlu menemukan pengaturan optimal antara berbagai aplikasi ini.

Jika Anda melihat peningkatan kinerja pada database, dan tidak ada kehilangan kinerja pada aplikasi lain maka saya tidak akan khawatir tentang hal ini.

Umumnya database adalah yang paling sensitif terhadap pengaturan memori, karena mereka juga kemungkinan besar merupakan hambatan pada kinerja aplikasi, masuk akal untuk mengoptimalkan sistem Anda untuk DB.


Bagaimana "menemukan pengaturan optimal antara berbagai aplikasi ini"? Saya tidak memiliki masalah kinerja, saya mencari cara kanonik untuk mengkonfigurasi pengaturan kernel memori bersama, bagaimana pro nyata melakukannya? Katakanlah seseorang menangani Anda server yang sedang berjalan dengan beberapa layanan dan membayar Anda untuk mengatur pengaturan manajemen memori saja, apa yang akan Anda lakukan?
jpic

Tidak ada aturan emas, Anda hanya melihat apa yang dikatakan vendor, dan mengujinya. Jika Anda memiliki beberapa aplikasi yang berjalan pada mesin yang sama, cobalah untuk mengoptimalkan untuk aplikasi yang paling intensif memori, dalam banyak kasus DB. Tapi selain melihat saran vendor dan mengujinya, tidak ada solusi yang tepat
Sibster

Saya tahu tidak ada aturan emas. Saya berharap mungkin hadiah itu akan memotivasi seseorang yang benar-benar memahami ini untuk menulis beberapa arahan. Tapi saya pikir tidak ada yang benar-benar sepenuhnya memahami hal ini - karena tidak ada yang bisa memberikan penjelasan sederhana.
jpic
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.