17.4. Управление ресурсами ядра

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

17.4.1. Разделяемая память и семафоры

Разделяемая память и семафоры в совокупности называются средствами межпроцессного взаимодействия (IPC) в стиле System V (к этим средствам также относятся очереди сообщений, но они не имеют отношения к PostgreSQL). За исключением Windows, где PostgreSQL использует собственную замену этих средств, эти средства необходимы для работы PostgreSQL.

Если эти механизмы полностью отсутствуют в системе, при запуске сервера обычно выдаётся ошибка Illegal system call (Неверный системный вызов). В этом случае единственный способ решить проблему — переконфигурировать ядро системы. Без них PostgreSQL просто не будет работать. Это довольно редкая ситуация, особенно с современными операционными системами.

Когда PostgreSQL превышает один из различных жёстких пределов IPC, сервер отказывается запускаться, но выдаёт полезное сообщение, говорящее об ошибке и о том, что с ней делать. (См. также Подраздел 17.3.1.) Соответствующие параметры ядра в разных системах называются аналогично (они перечислены в Таблице 17-1), но устанавливаются они по-разному. Ниже предлагаются способы их изменения для некоторых систем.

Замечание: PostgreSQL до версии 9.3 требовал для запуска сервера гораздо больший объём разделяемой памяти System V. Если вы используете более раннюю версию сервера, обратитесь к документации по вашей версии.

Таблица 17-1. Параметры IPC в стиле System V

ИмяОписаниеРазумные значения
SHMMAXМаксимальный размер сегмента разделяемой памяти (в байтах)не меньше 1 КБ (больше, если запускается много копий сервера)
SHMMINМинимальный размер сегмента разделяемой памяти (в байтах)1
SHMALLОбщий объём доступной разделяемой памяти (в байтах или страницах)если в байтах, то же, что и SHMMAX; если в страницах, то ceil(SHMMAX/PAGE_SIZE)
SHMSEGМаксимальное число сегментов разделяемой памяти для процессатребуется только 1 сегмент, но значение по умолчанию гораздо больше
SHMMNIМаксимальное число сегментов разделяемой памяти для всей системыкак SHMSEG плюс потребность других приложений
SEMMNIМаксимальное число идентификаторов семафоров (т. е., их наборов)как минимум ceil((max_connections + autovacuum_max_workers + 4) / 16)
SEMMNSМаксимальное число семафоров для всей системыceil((max_connections + autovacuum_max_workers + 4) / 16) * 17 плюс потребность для других приложений
SEMMSLМаксимальное число семафоров в наборене меньше 17
SEMMAPЧисло записей в карте семафоровсм. текст
SEMVMXМаксимальное значение семафоране меньше 1000 (по умолчанию оно обычно равно 32767; без необходимости менять его не следует)

PostgreSQL запрашивает небольшой блок разделяемой памяти System V (обычно 48 байт на 64-битной платформе) для каждой копии сервера. В большинстве современных операционных систем такой объём выделяется без проблем. Однако, если запускать много копий сервера, или разделяемую память System V занимают и другие приложения, может понадобиться увеличить значение SHMMAX, максимальный размер сегмента разделяемой памяти (в байтах), либо SHMALL, общий объём разделяемой памяти System V, доступный для всей системы. Заметьте, что SHMALL во многих системах задаётся в страницах, а не в байтах.

Менее вероятны проблемы с минимальным размером сегментов разделяемой памяти (SHMMIN), который для PostgreSQL не должен превышать примерно 32 байт (обычно это всего 1 байт). Максимальное число сегментов для всей системы (SHMMNI) или для одного процесса (SHMSEG) тоже обычно не влияет на работоспособность сервера, если только это число не равно нулю.

PostgreSQL использует по одному семафору на одно разрешённое подключение (max_connections) и на рабочий процесс автоочистки (autovacuum_max_workers), в наборах по 16. В каждом таком наборе есть также 17-ый семафор, содержащий "магическое число", позволяющий обнаруживать коллизии с наборами семафоров других приложений. Максимальное число семафоров в системе задаётся параметром SEMMNS, который, следовательно, должен быть равен как минимум сумме max_connections и autovacuum_max_workers, плюс один дополнительный на каждые 16 семафоров подключений и рабочих процессов (см. формулу в Таблице 17-1). Параметр SEMMNI определяет максимальное число наборов семафоров, которые могут существовать в системе в один момент времени. Таким образом, этот параметр должен быть не меньше ceil((max_connections + autovacuum_max_workers + 4) / 16). В качестве временного решения проблем, которые вызваны этими ограничениями, но обычно сопровождаются некорректными сообщениями, например, "No space left on device" (На устройстве не осталось места) от функции semget, можно уменьшить число разрешённых соединений.

В некоторых случаях может потребоваться увеличить SEMMAP как минимум до уровня SEMMNS. Этот параметр определяет размер карты ресурсов семафоров, в которой выделяется запись для каждого непрерывного блока семафоров. Когда набор семафоров освобождается, эта запись либо добавляется к существующей соседней записи, либо регистрируется как новая запись в карте. Если карта переполняется, освобождаемые семафоры теряются (до перезагрузки). Таким образом, фрагментация пространства семафоров может со времени привести к уменьшению числа доступных семафоров.

Параметр SEMMSL, определяющий, сколько семафоров может быть в одном наборе, для PostgreSQL должен равняться как минимум 17.

Другие параметры, связанные с "аннулированием операций" с семафорами, например, SEMMNU и SEMUME, на работу PostgreSQL не влияют.

AIX

Как минимум с версии 5.1, для таких параметров, как SHMMAX, никакая дополнительная настройка не должна требоваться, так как система, похоже, позволяет использовать всю память в качестве разделяемой. Подобная конфигурация требуется обычно и для других баз данных, например, для DB/2.

Однако может понадобиться изменить глобальные параметры ulimit в /etc/security/limits, так как стандартные жёсткие ограничения на размер (fsize) и количество файлов (nofiles) могут быть недостаточно большими.

FreeBSD

Значения по умолчанию можно изменить, используя возможности sysctl или loader. С помощью sysctl можно задать следующие параметры:

# sysctl kern.ipc.shmall=32768
# sysctl kern.ipc.shmmax=134217728

Чтобы эти изменения сохранялись после перезагрузки, измените /etc/sysctl.conf.

Эти параметры, связанные с семафорами, sysctl менять не позволяет, но их можно задать в /boot/loader.conf:

kern.ipc.semmni=256
kern.ipc.semmns=512
kern.ipc.semmnu=256

Чтобы изменённые таким образом параметры вступили в силу, требуется перезагрузить систему. (Заметьте, что во FreeBSD нет параметра SEMMAP. В старых версиях значение для kern.ipc.semmap принималось, но игнорировалось; новые версии его не принимают.)

Возможно, вы захотите настроить ядро так, чтобы разделяемая память всегда находилась в ОЗУ и никогда не выгружалась в пространство подкачки. Это можно сделать, установив с помощью sysctl параметр kern.ipc.shm_use_phys.

Если вы используете «камеры» FreeBSD, включив в sysctl параметр security.jail.sysvipc_allowed, главные процессы postmaster, работающие в разных камерах, должны запускаться разными пользователями операционной системы. Это усиливает защиту, так как не позволяет обычным пользователям обращаться к разделяемой памяти или семафорам в разных камерах, и при этом способствует корректной работе кода очистки IPC в PostgreSQL. (Во FreeBSD 6.0 и более поздних версиях код очистки IPC не может корректно выявить процессы в других камерах, что не позволяет запускать процессы postmaster на одном порту в разных камерах.)

До версии 4.0 система FreeBSD работала так же, как сейчас OpenBSD (см. ниже).

NetBSD

В NetBSD, начиная с версии 5.0, параметры IPC можно изменить, воспользовавшись командой sysctl, например:

$ sysctl -w kern.ipc.shmmax=16777216

Чтобы эти параметры сохранялись после перезагрузки, измените /etc/sysctl.conf.

Возможно, вы захотите настроить ядро так, чтобы разделяемая память всегда находилась в ОЗУ и никогда не выгружалась в пространство подкачки. Это можно сделать, установив с помощью sysctl параметр kern.ipc.shm_use_phys.

До версии 5.0 система NetBSD работала так же, как сейчас OpenBSD (см. ниже), за исключением того, что параметры устанавливаются с указанием options, а не option.

OpenBSD

При компиляции ядра должны быть включены механизмы SYSVSHM и SYSVSEM. (По умолчанию они включены.) Максимальный размер разделяемой памяти определяется параметром SHMMAXPGS (в страницах). Ниже показан пример, как установить следующие параметры:

option        SYSVSHM
option        SHMMAXPGS=4096
option        SHMSEG=256

option        SYSVSEM
option        SEMMNI=256
option        SEMMNS=512
option        SEMMNU=256
option        SEMMAP=256

Возможно, вы захотите настроить ядро так, чтобы разделяемая память всегда находилась в ОЗУ и никогда не выгружалась в пространство подкачки. Это можно сделать, установив с помощью sysctl параметр kern.ipc.shm_use_phys.

HP-UX

Значения по умолчанию обычно вполне удовлетворяют средним потребностям. В HP-UX 10 параметр SEMMNS по умолчанию имеет значение 128, что может быть недостаточно для больших баз данных.

Параметры IPC можно установить в менеджере системного администрирования (System Administration Manager, SAM) в разделе Kernel Configuration (Настройка ядра)->Configurable Parameters (Настраиваемые параметры). Установив нужные параметры, выполните операцию Create A New Kernel (Создать ядро).

Linux

По умолчанию максимальный размер сегмента равен 32 МБ, а максимальный общий размер составляет 2097152 страниц. Страница почти всегда содержит 4096 байт, за исключением нестандартных конфигураций ядра с поддержкой "огромных страниц" (точно узнать размер страницы можно, выполнив getconf PAGE_SIZE).

Параметры размера разделяемой памяти можно изменить, воспользовавшись командой sysctl. Например, так можно выделить 16 ГБ для разделяемой памяти:

$ sysctl -w kernel.shmmax=17179869184
$ sysctl -w kernel.shmall=4194304

Чтобы сохранить эти изменения после перезагрузки, их также можно записать в файл /etc/sysctl.conf (это настоятельно рекомендуется).

В некоторых старых дистрибутивах может не оказаться программы sysctl, но те же изменения можно произвести, обратившись к файловой системе /proc:

$ echo 17179869184 >/proc/sys/kernel/shmmax
$ echo 4194304 >/proc/sys/kernel/shmall

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

OS X

Для настройки разделяемой памяти в OS X рекомендуется создать файл /etc/sysctl.conf и записать в него присвоения переменных следующим образом:

kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

Заметьте, что в некоторых версиях OS X, все пять параметров разделяемой памяти должны быть установлены в /etc/sysctl.conf, иначе их значения будут проигнорированы.

Имейте в виду, что последние версии OS X игнорируют попытки задать для SHMMAX значение, не кратное 4096.

SHMALL на этой платформе измеряется в страницах (по 4 КБ).

В старых версиях OS X, чтобы изменения параметров разделяемой памяти вступили в силу, требовалась перезагрузка. Начиная с версии 10.5, все параметры, кроме SHMMNI можно изменить «на лету», воспользовавшись командой sysctl. Но, тем не менее, лучше задавать выбранные вами значения в /etc/sysctl.conf, чтобы они сохранялись после перезагрузки.

Файл /etc/sysctl.conf обрабатывается, только начиная с OS X версии 10.3.9. Если вы используете предыдущий выпуск 10.3.x, необходимо отредактировать файл /etc/rc и задать значения следующими командами:

sysctl -w kern.sysv.shmmax
sysctl -w kern.sysv.shmmin
sysctl -w kern.sysv.shmmni
sysctl -w kern.sysv.shmseg
sysctl -w kern.sysv.shmall

Заметьте, что /etc/rc обычно заменяется при обновлении системы OS X, так что следует ожидать, что вам придётся повторять эти изменения после каждого обновления.

В OS X 10.2 и более ранних версиях вместо этого надо записать эти команды в файле /System/Library/StartupItems/SystemTuning/SystemTuning.

SCO OpenServer

В стандартной конфигурации размер одного сегмента разделяемой памяти имеет предел в 512 КБ. Чтобы увеличить этот предел, сначала перейдите в каталог /etc/conf/cf.d. Затем просмотрите текущее значение SHMMAX, выполнив:

./configure -y SHMMAX

Задайте новое значение SHMMAX, выполнив:

./configure SHMMAX=значение

Здесь значение — новый предел, который вы хотите установить (в байтах). Установив SHMMAX, пересоберите ядро:

./link_unix

и перезагрузите систему.

Solaris версии с 2.6 по 2.9 (Solaris 6 .. Solaris 9)

Соответствующие параметры можно изменить в /etc/system, например так:

set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256

set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32

Чтобы изменения вступили в силу, потребуется перегрузить систему. Информацию о разделяемой памяти в более старых версиях Solaris можно найти по ссылке http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html.

Solaris 2.10 (Solaris 10) и более поздние версии
OpenSolaris

В Solaris 10 и новее, а также в OpenSolaris, стандартные параметры разделяемой памяти и семафоров достаточно хороши для большинства применений PostgreSQL. По умолчанию Solaris теперь устанавливает в SHMMAX четверть объёма ОЗУ. Чтобы изменить этот параметр, воспользуйтесь возможностью задать параметр проекта, связанного с пользователем postgres. Например, выполните от имени root такую команду:

projadd -c "PostgreSQL DB User" -K "project.max-shm-memory=(privileged,8GB,deny)" -U postgres -G postgres user.postgres

Эта команда создаёт проект user.postgres и устанавливает максимальный объём разделяемой памяти для пользователя postgres равным 8 ГБ. Это изменение вступает в силу при следующем входе этого пользователя или при перезапуске PostgreSQL (не перезагрузке конфигурации). При этом подразумевается, что PostgreSQL выполняется пользователем postgres в группе postgres. Перезагружать систему после этой команды не нужно.

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

project.max-shm-ids=(priv,32768,deny)
project.max-sem-ids=(priv,4096,deny)
project.max-msg-ids=(priv,4096,deny)

Кроме того, если PostgreSQL у вас выполняется внутри зоны, может понадобиться также увеличить лимиты на использование ресурсов зоны. Получить дополнительную информацию о проектах и команде prctl можно в Руководстве системного администратора (System Administrator's Guide), «Главе 2: Проекты и задачи» (Chapter2: Projects and Tasks).

UnixWare

В UnixWare 7 максимальный размер сегментов разделяемой памяти равен 512 КБ в стандартной конфигурации. Чтобы просмотреть текущее значение SHMMAX, выполните:

/etc/conf/bin/idtune -g SHMMAX

В результате вы увидите текущее значение, значение по умолчанию, а также минимальные и максимальные значения. Чтобы задать новое значение SHMMAX, выполните:

/etc/conf/bin/idtune SHMMAX значение

Здесь значение — новый предел, который вы хотите установить (в байтах). Изменив значение SHMMAX, пересоберите ядро:

/etc/conf/bin/idbuild -B

и перегрузите систему.

17.4.2. Ограничения ресурсов

В Unix-подобных операционных системах существуют различные типы ограничений ресурсов, которые могут влиять на работу сервера PostgreSQL. Особенно важны ограничения на число процессов для пользователя, число открытых файлов и объём памяти для каждого процесса. Каждое из этих ограничений имеет "жёсткий" и "мягкий" предел. Мягкий предел действительно ограничивает использование ресурса, но пользователь может увеличить его значение до жёсткого предела. Изменить жёсткий предел может только пользователь root. За изменение этих параметров отвечает системный вызов setrlimit. Управлять этими ресурсами в командной строке позволяет встроенная команда ulimit (в оболочках Bourne) и limit (csh). В системах семейства BSD различными ограничениями ресурсов, устанавливаемыми при входе пользователя, управляет файл /etc/login.conf. За подробностями обратитесь к документации операционной системы. Для PostgreSQL интерес представляют параметры maxproc, openfiles и datasize. Они могут задаваться, например так:

default:\
...
        :datasize-cur=256M:\
        :maxproc-cur=256:\
        :openfiles-cur=256:\
...

(Здесь -cur обозначает мягкий предел. Чтобы задать жёсткий предел, нужно заменить это окончание на -max.)

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

  • В Linux максимальное число открытых файлов, которое поддерживает ядро, определяется в спецфайле /proc/sys/fs/file-max. Изменить этот предел можно, записав другое число в этот файл, либо добавив присваивание в файл /etc/sysctl.conf. Максимальное число файлов для одного процесса задаётся при компиляции ядра; за дополнительными сведения обратитесь к /usr/src/linux/Documentation/proc.txt.

Сервер PostgreSQL использует для обслуживания каждого подключения отдельный процесс, так что возможное число процессов должно быть не меньше числа разрешённых соединений плюс число процессов, требуемых для остальной системы. Это обычно не проблема, но когда в одной системе работает множество серверов, предел может быть достигнут.

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

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

17.4.3. Чрезмерное выделение памяти в Linux

В Linux 2.4 и новее механизм виртуальной памяти по умолчанию работает не оптимально для PostgreSQL. Вследствие того, что ядро выделяет память в чрезмерном объёме, оно может уничтожить главный управляющий процесс PostgreSQL (postmaster), если при выделении памяти процессу PostgreSQL или другому процессу виртуальная память будет исчерпана.

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

Out of Memory: Killed process 12345 (postgres).

Это сообщение говорит о том, что процесс postgres был уничтожен из-за нехватки памяти. Хотя существующие подключения к базе данных будут работать по-прежнему, новые подключения приниматься не будут. Чтобы восстановить работу сервера, PostgreSQL придётся перезапустить.

Один из способов обойти эту проблему — запускать PostgreSQL на компьютере, где никакие другие процессы не займут всю память. Если физической памяти недостаточно, решить проблему также можно, увеличив объём пространства подкачки, так как уничтожение процессов при нехватке памяти происходит только когда заканчивается и физическая память, и место в пространстве подкачки.

Если памяти не хватает по вине самого PostgreSQL, эту проблему можно решить, изменив конфигурацию сервера. В некоторых случаях может помочь уменьшение конфигурационных параметров, связанных с памятью, а именно shared_buffers и work_mem. В других случаях проблема может возникать, потому что разрешено слишком много подключений к самому серверу баз данных. Чаще всего в такой ситуации стоит уменьшить число подключений max_connections и организовать внешний пул соединений.

В Linux 2.6 и новее "чрезмерное выделение" памяти можно предотвратить, изменив поведение ядра. Хотя при этом OOM killer (уничтожение процессов при нехватке памяти) всё равно может вызываться, вероятность такого уничтожения значительно уменьшается, а значит поведение системы становится более стабильным. Для этого нужно включить режим строгого выделения памяти, воспользовавшись sysctl:

sysctl -w vm.overcommit_memory=2

либо поместив соответствующую запись в /etc/sysctl.conf. Возможно, вы также захотите изменить связанный параметр vm.overcommit_ratio. За подробностями обратитесь к документации ядра Documentation/vm/overcommit-accounting.

Другой подход, который можно применить (возможно, вместе с изменением vm.overcommit_memory), заключается в исключении процесса postmaster из числа возможных жертв при нехватке памяти. Для этого нужно задать для переменной oom_score_adj этого процесса значение -1000. Проще всего это можно сделать, выполнив

echo -1000 > /proc/self/oom_score_adj

в скрипте запуска управляющего процесса непосредственно перед тем, как запускать postmaster. Заметьте, что делать это надо под именем root, иначе ничего не изменится; поэтому проще всего вставить эту команду в скрипт, принадлежащий пользователю root. Применяя такой подход, также имеет смысл собрать PostgreSQL с ключом -DLINUX_OOM_SCORE_ADJ=0 в параметрах CPPFLAGS. При этом дочерние процессы postgres будут работать с обычным значением oom_score_adj, равным нулю, так что при необходимости система сможет уничтожать их.

В старых ядрах Linux /proc/self/oom_score_adj отсутствует, но та же функциональность может быть доступна через /proc/self/oom_adj. Эта переменная процесса работает так же, только значение, исключающее уничтожение процесса, равно -17, а не -1000. Соответствующий флаг сборки PostgreSQL устанавливается так: -DLINUX_OOM_ADJ=0.

Замечание: Некоторые дистрибутивы с ядрами Linux 2.4 содержат предварительную реализацию механизма sysctl overcommit, появившегося официально в 2.6. Однако, если установить для vm.overcommit_memory значение 2 в ядре 2.4, ситуация не улучшится, а только ухудшится. Прежде чем модифицировать этот параметр в ядре 2.4, рекомендуется проанализировать исходный код вашего ядра (см. функцию vm_enough_memory в файле mm/mmap.c) и убедиться, что ядро поддерживает именно нужный вам режим. Наличие файла документации overcommit-accounting не следует считать признаком того, что он действительно поддерживается. В случае сомнений, обратитесь к эксперту по ядру или поставщику вашей системы.

17.4.4. Огромные страницы в Linux

Использование огромных страниц снижает накладные расходы при работе с большими непрерывными блоками памяти, что характерно для PostgreSQL. Чтобы использовать эту возможность в PostgreSQL, ядро должно быть собрано с параметрами CONFIG_HUGETLBFS=y и CONFIG_HUGETLB_PAGE=y. Также вам нужно будет настроить системный параметр vm.nr_hugepages. Чтобы оценить, сколько огромных страниц потребуется для PostgreSQL, нужно запустить сервер без поддержки огромных страниц и посмотреть на значение VmPeak в файловой системе proc:

$ head -1 /path/to/data/directory/postmaster.pid
4170
$ grep ^VmPeak /proc/4170/status
VmPeak:  6490428 kB

6490428 / 2048 (размер страницы (PAGE_SIZE) в данном случае равен 2 МБ) — это приблизительно 3169.154 огромных страниц, так что потребуется не меньше 3170 огромных страниц:

$ sysctl -w vm.nr_hugepages=3170

Иногда ядро не может выделить запрошенное количество огромных страниц сразу, поэтому может потребоваться повторить эту команду или перезагрузить систему. Чтобы изменённый параметр сохранился после перезагрузки, не забудьте записать его в /etc/sysctl.conf.

По умолчанию PostgreSQL использует огромные страницы, когда считает это возможным, а в противном случае, переходит к обычным страницам. Чтобы задействовать огромные страницы принудительно, можно установить для huge_pages значение on. Заметьте, что в этом случае PostgreSQL не сможет запуститься, если не получит достаточного количества огромных страниц.

Более подробно о механизме огромных страниц в Linux можно узнать в документации ядра: https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt.