Jak ustawić shmall, shmmax, shmmin itp. Ogólnie i dla postgresql

11

Użyłem dokumentacji z PostgreSQL, aby ustawić ją na przykład w tej konfiguracji:

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

ekstrakt sysctl.conf , obliczony przeze mnie:

kernel.shmall = 1079204
kernel.shmmax = 4420419584

Postgresql.conf inne niż domyślne , obliczone przeze mnie:

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

Czy to jest właściwe? Jeśli nie (lub niekoniecznie), w którym przypadku byłoby właściwe?

Zauważyliśmy miłe ulepszenia wydajności w tej konfiguracji, jak byś ją ulepszył?

Jak obliczyć parametry zarządzania pamięcią jądra?

Czy ktoś może wyjaśnić, jak naprawdę ustawić je od podstaw?

jpic
źródło
To wiele pytań i nie powiedziałeś nam, jaki jest twój obecny problem (jeśli występuje) ani jaki jest twój sposób użycia. Może warto zdobyć książkę o wydajności PostgreSQL.
hmallett
Mój problem polega na tym, że nie jestem przekonany, że dokonałem właściwych ustawień. Myślę, że opcje zarządzania pamięcią jądra nie są specyficzne dla PostgreSQL. Nie jestem też pewien, czy PostgreSQL jest najlepszym miejscem, aby porozmawiać o tych opcjach. Oczywiście, są one mocno wspomniane w dowolnym artykule na temat wydajności PostgreSQL, ale to są opcje Linuksa i nie mogę się doczekać, aby naprawdę zrozumieć, jak je dostroić w ogóle.
jpic

Odpowiedzi:

11

Odpowiedziałem na inne pytanie tutaj:

Git nie wypycha się z błędem „brak pamięci”

Nie odpowiadam tutaj na wszystkie twoje pytania, ale pytanie w twoim tytule:

Jak ustawić shmall, shmmax, shmmni itp. Ogólnie i dla postgresql

W przypadku niektórych dystrybucji jądra istnieją ustawienia, które uniemożliwiają jądrze przydzielenie maksymalnej pamięci do jednego procesu:

Ustaw parametry jądra

Zmodyfikuj /etc/sysctl.confplik, tak aby zawierał wiersze odpowiednie dla twojego systemu operacyjnego:

# 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

Jeśli twój proces przekroczy limity, jądro go zabije, pomimo maksymalnej zgłoszonej pamięci dostępnej w twoim systemie.

Uwaga: zachowaj ostrożność przy tych ustawieniach. Prawdopodobnie nie chcesz używać ustawień z tego przykładu, ponieważ ściągnąłem je z serwera w naszym środowisku.

Kilka dodatkowych uwag do wspomnienia:

Aby zaktualizować i przetestować ustawienia jądra za pomocą sysctl, użyj następujących poleceń:

Wyświetl aktualne ustawienia:

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

Wyłącz bezpieczny system Linux, edytując /etc/selinux/configplik, upewniając się, że flaga SELINUX jest ustawiona w następujący sposób.

SELINUX=disabled

Czy to jest właściwe? Jeśli nie (lub niekoniecznie), w którym przypadku byłoby właściwe?

Ustawienia jądra są zwykle ściślej określone w środowiskach centrów danych, gdy dostawcy usług internetowych nie chcą, aby proces jednego klienta przejmował wszystkie zasoby na wspólnym serwerze.

Zwykle nie trzeba ustawiać parametrów pamięci jądra, chyba że istnieje proces, który zostaje zabity przez jądro z powodu głodu zasobów.

W niektórych przypadkach postgres może także przydzielić więcej pamięci do określonych rozmiarów stron niż to, co jest dostępne we wspólnej pamięci:

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

Błędy, takie jak powyższy przykład, można rozwiązać, dostosowując ustawienia zasobów jądra. Zalecane ustawienia i metody określania ustawień zasobów opisano szczegółowo tutaj:

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

Jednak tak naprawdę nie musisz dotykać tych ustawień, chyba że napotykasz sytuacje głodu zasobów związane z procesem postgresu. Sytuacje takie występują najczęściej w środowiskach współdzielonych lub serwerach z przydzielonymi niewielkimi zasobami.

Czy ktoś może wyjaśnić, jak naprawdę ustawić je od podstaw?

Jeśli chodzi o strojenie Postgres, powinieneś przeczytać to:

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

Jason Huntley
źródło
1
„Uwaga: zachowaj ostrożność przy tych ustawieniach. Prawdopodobnie nie chcesz używać ustawień w tym przykładzie, ponieważ ściągnąłem je z serwera w naszym środowisku”. Jak powinienem je obliczyć dla mojego środowiska?
jpic
1
Hej jpic, zaktualizowałem, aby podać więcej szczegółów dotyczących ustawień jądra.
Jason Huntley,
2

O!! Znajduję tutaj wspaniałe narzędzie do obliczania optymalnej konfiguracji mem naszego serwera postgresql.

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

Pablo Luna
źródło
To narzędzie nie ma na celu obliczenia konfiguracji Optimus, daje punkt wyjścia do dostrojenia serwera, ponieważ daje odpowiedź opartą głównie na ustawieniach sprzętowych. Rozmiar bazy danych, liczba zapytań i rozmiary są również ważne, aby dostroić parametry konfiguracji.
EAmez
1

Te konfiguracje jądra są globalne, a nie specyficzne dla procesu, dlatego należy je ustawić sysctl.conf.

mgorven
źródło
Pytanie dotyczy określenia wartości parametrów zarządzania pamięcią współużytkowaną jądra, „jak”, a nie „gdzie” ... Dziękujemy za wysiłek włożony w odpowiedź.
jpic
tak. tam gdzie jest trywialne. jakie jest jego mięso.
Henley Chiu
0

Zależy to od tego, co jeszcze działa na serwerze, jeśli jest to czysty serwer PostgreSQL, to PostgreSQL jest właściwym miejscem do szukania tych ustawień.
Jeśli korzystasz z innych aplikacji / usług, które mają określone potrzeby w zakresie pamięci, musisz znaleźć optymalne ustawienie między tymi różnymi aplikacjami.

Jeśli widzisz wzrost wydajności bazy danych i brak utraty wydajności w innych aplikacjach, nie martwiłbym się tym.

Zasadniczo bazy danych są najbardziej wrażliwe na ustawienia pamięci, ponieważ najprawdopodobniej są również wąskim gardłem w wydajności aplikacji, warto zoptymalizować system pod kątem bazy danych.

Sibster
źródło
Jak „znaleźć optymalne ustawienie między tymi różnymi aplikacjami”? Nie mam problemu z wydajnością, szukam kanonicznego sposobu konfiguracji ustawień jądra pamięci współużytkowanej, jak zrobiłby to prawdziwy profesjonalista? Powiedzmy, że ktoś obsługuje ci działający serwer z garstką usług i płaci Ci za ustawienie tylko ustawień zarządzania pamięcią, co byś zrobił?
jpic
Nie ma złotej zasady, wystarczy spojrzeć na to, co mówi sprzedawca, i przetestować. Jeśli na tym samym komputerze działa wiele aplikacji, spróbuj zoptymalizować aplikację pod kątem największej ilości pamięci, w większości przypadków DB. Ale oprócz spojrzenia na sugestie dostawców i przetestowanie ich nie ma jednego właściwego rozwiązania
Sibster
Wiem, że nie ma złotej zasady. Miałem nadzieję, że nagroda może zmotywować kogoś, kto w pełni to rozumie, do napisania wskazówek. Ale myślę, że nikt tak naprawdę nie rozumie tego w pełni - ponieważ nikt nie jest w stanie podać prostego wyjaśnienia.
jpic