Як встановити shmall, shmmax, shmmin тощо ... загалом і для postgresql


11

Я використовував документацію з PostgreSQL, щоб встановити її, наприклад, для цього конфігурації:

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

sysctl.conf екстракт , обчислений мною:

kernel.shmall = 1079204
kernel.shmmax = 4420419584

postgresql.conf не за замовчуванням , обчислений мною:

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

Чи підходить це? Якщо ні (чи не обов'язково), то в якому випадку це було б доречно?

Ми помітили приємні покращення продуктивності за допомогою цього конфігурації, як би ви його покращили?

Як обчислити параметри управління пам'яттю ядра?

Хтось може пояснити, як насправді їх встановити з нуля?


Це багато питань, і ви не сказали нам, що є вашою поточною проблемою (якщо вона є) чи якою є ваша схема використання. Можливо, варто придбати книгу про продуктивність PostgreSQL.
hmallett

Моя проблема полягає в тому, що я не переконаний, що я зробив правильні налаштування. Я думаю, що параметри управління пам’яттю ядра не є PostgreSQL, і я не впевнений, що PostgreSQL найкраще говорити про ці параметри. Звичайно, про них часто згадується в будь-якій статті про продуктивність PostgreSQL, але це варіанти Linux, і я з нетерпінням чекаю, коли я зрозумію, як їх налаштувати взагалі.
jpic

Відповіді:


11

Я відповів на це на ще одне запитання тут:

Git не вдається натиснути з помилкою "поза пам'яттю"

Я не відповідаю на всі ваші запитання тут, але на запитання у вашій назві:

Як встановити shmall, shmmax, shmmni тощо ... загалом і для postgresql

У деяких дистрибутивах ядра є параметри, які не дозволяють ядру виділяти максимум пам'яті в один процес:

Встановіть параметри ядра

Змініть /etc/sysctl.confфайл, щоб він включав рядки, відповідні вашій операційній системі:

# 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

Якщо ваш процес перевищує обмеження, ядро ​​знищить процес, незважаючи на те, що у вашій системі наявна максимальна пам'ять.

Примітка: будьте обережні з цими налаштуваннями. Напевно, ви не хочете використовувати налаштування в цьому прикладі, оскільки я витягнув їх із сервера в нашому середовищі.

Кілька додаткових зауважень:

Для оновлення та тестування параметрів ядра за допомогою sysctl використовуйте наступні команди:

Список поточних налаштувань:

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

Вимкніть захищений Linux, редагуючи /etc/selinux/configфайл, переконайтесь, що прапор SELINUX встановлений наступним чином.

SELINUX=disabled

Чи підходить це? Якщо ні (чи не обов'язково), то в якому випадку це було б доречно?

Налаштування ядра, як правило, більш суворо визначені в середовищах центру обробки даних, коли постачальники провайдерів не хочуть, щоб один клієнтський процес перебирав усі ресурси на спільний сервер.

Зазвичай вам не доведеться встановлювати параметри пам'яті ядра, якщо у вас немає процесу, який вбивається ядром через голодування ресурсів.

У деяких випадках постгреси також можуть виділяти більше пам’яті певним розмірам сторінки, ніж наявні у спільній пам’яті:

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

Помилки, як-от наведений вище приклад, можна вирішити, відкоригувавши налаштування ресурсу ядра. Рекомендовані параметри та методи визначення параметрів ресурсів тут детально описані:

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

Однак вам дійсно не потрібно торкатися цих налаштувань, якщо ви не стикаєтеся з ситуаціями голодування у ресурсах, пов’язаних із процесом постгреси. Ці ситуації трапляються, найчастіше, у спільних середовищах або серверах з невеликими ресурсами, що їм виділяються.

Хтось може пояснити, як насправді їх встановити з нуля?

Щодо налаштування Postgres, ви повинні прочитати це:

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


1
"Примітка. Будьте уважні з цими налаштуваннями. Напевно, ви не хочете використовувати налаштування в цьому прикладі, оскільки я витягнув їх із сервера в нашому середовищі." Як слід обчислити їх для мого середовища?
jpic

1
Привіт jpic, я оновив, щоб отримати більш детальну інформацію про налаштування ядра.
Джейсон Хантлі

2

Ох !! Тут я знаходжу чудовий інструмент для обчислення оптимальної конфігурації пам’яті нашого сервера postgresql.

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


Цей інструмент не збирається обчислювати оптимізовану конфігурацію, він дає вам вихідну точку для налаштування вашого сервера, оскільки він дає відповідь, в основному виходячи з налаштувань обладнання. Розмір бази даних, кількість запитів та розміри також важливі для налаштування параметрів конфігурації.
EAmez

1

Ці конфігурації ядра є глобальними, не специфічними для процесу, тому їх доцільно встановити sysctl.conf.


Питання полягає у визначенні значень параметрів управління пам'яттю спільного використання ядра, "як", а не "куди" ... Дякую за зусилля, вкладені у вашу відповідь.
jpic

так. там де банально. як це м'ясо.
Henley Chiu

0

Ну, це залежить від того, що ще працює на сервері, якщо це чистий PostgreSQL сервер, то PostgreSQL - це правильне місце для пошуку цих параметрів.
Якщо ви працюєте з іншими програмами / послугами, які мають певні потреби в пам'яті, вам потрібно буде знайти оптимальне налаштування між цими різними програмами.

Якщо ви бачите підвищення продуктивності в базі даних, а втрати продуктивності інших програм не втрачають, то я б не переймався цим.

Як правило, бази даних є найбільш чутливими до налаштувань пам’яті, оскільки вони, ймовірно, є вузьким місцем у продуктивності програми, має сенс оптимізувати вашу систему для БД.


Як "знайти оптимальне налаштування між цими різними програмами"? У мене немає проблеми з продуктивністю, я шукаю канонічний спосіб налаштування параметрів ядра спільної пам’яті, як би реально це зробити? Скажіть, що хтось обробляє вас із запущеним сервером з кількома послугами і платить вам, щоб встановити лише налаштування управління пам’яттю, що б ви зробили?
jpic

Золотого правила немає, ви просто подивіться, що говорить продавець, і протестуйте його. Якщо у вас є кілька додатків, що працюють на одній машині, спробуйте оптимізувати для програми, що займає найбільшу пам'ять, у більшості випадків БД. Але окрім перегляду пропозицій постачальників, які перевіряють їх, немає єдиного правильного рішення
Сібстер

Я знаю, що немає жодного золотого правила. Я сподівався, що, можливо, щедро мотивує того, хто насправді цілком розуміє це, написати певні вказівки. Але я думаю, що насправді ніхто не розуміє цього, адже ніхто не в змозі дати просте пояснення.
jpic
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.