Как установить 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.
Гмаллетт

Моя проблема в том, что я не уверен, что сделал правильные настройки. Я думаю, что параметры управления памятью ядра не являются специфическими для 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

Это уместно? Если нет (или не обязательно), в каком случае это будет уместно?

Настройки ядра обычно более строго определены в средах центра обработки данных, когда поставщики услуг Интернета не хотят, чтобы один процесс клиента занимал все ресурсы на общем сервере.

Обычно вам не нужно устанавливать параметры памяти ядра, если у вас нет процесса, который убивает ядро ​​из-за нехватки ресурсов.

В некоторых случаях postgres также может выделять больше памяти для определенных размеров страниц, чем доступно в общей памяти:

* 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. Эти ситуации чаще всего встречаются в общих средах или на серверах с ограниченными ресурсами, выделенными для них.

Кто-нибудь может объяснить, как действительно установить их с нуля?

Что касается настройки Postgres, вы должны прочитать это:

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


1
«Примечание: будьте осторожны с этими настройками. Вы, вероятно, не хотите использовать настройки в этом примере, так как я извлек их с сервера в нашей среде». Как мне рассчитать их для моей среды?
Jpic

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

2

Ой!! Я нахожу замечательный инструмент для расчета конфигурации config нашего сервера postgresql.

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


Этот инструмент не предназначен для расчета конфигурации Optimus, он дает вам отправную точку для настройки вашего сервера, так как он дает вам ответ, основанный в основном на ваших аппаратных настройках. Размер базы данных, количество запросов и размеры также важны для настройки параметров конфигурации.
EAmez

1

Эти конфигурации ядра являются глобальными, а не специфичными для процесса, поэтому целесообразно установить их в sysctl.conf.


Вопрос в том, чтобы определить значения параметров управления общей памятью ядра, «как», а не «где» ... Спасибо за усилия, приложенные к вашему ответу.
Jpic

Ага. там где тривиально. как мясо это.
Хенли Чиу

0

Ну, это зависит от того, что еще работает на сервере, если это чистый сервер PostgreSQL, то PostgreSQL - правильное место для поиска этих настроек.
Если вы работаете с другими приложениями / службами, у которых есть определенные потребности в памяти, вам нужно будет найти оптимальную настройку между этими различными приложениями.

Если вы видите увеличение производительности в базе данных и отсутствие потери производительности в других приложениях, я бы не беспокоился об этом.

Как правило, базы данных наиболее чувствительны к настройкам памяти, поскольку они также, скорее всего, являются узким местом в производительности приложений, поэтому имеет смысл оптимизировать систему для работы с БД.


Как «найти оптимальную настройку между этими различными приложениями»? У меня нет проблем с производительностью, я ищу канонический способ настройки параметров ядра совместно используемой памяти, как бы это сделал настоящий профессионал? Скажем, кто-то обслуживает вас работающий сервер с несколькими службами и платит вам за установку только настроек управления памятью, что бы вы сделали?
JPP

Золотого правила не существует, просто посмотрите, что говорит продавец, и протестируйте его. Если у вас на одном компьютере запущено несколько приложений, попробуйте оптимизировать работу приложения с наибольшим объемом памяти, в большинстве случаев это БД. Но кроме рассмотрения предложений поставщиков и их тестирования, нет единственного правильного решения
Sibster

Я знаю, что нет золотого правила. Я надеялся, что щедрость побудит кого-то, кто на самом деле полностью понимает это, написать несколько указаний. Но я думаю, что в конце концов никто не понимает этого полностью - поскольку никто не может дать простое объяснение.
JPP
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.