Digital Q.DataBase требует, чтобы операционная система предоставляла функции межпроцессного взаимодействия (IPC), в частности разделяемую память и семафоры. Unix-подобные системы обычно предоставляют «System V» IPC, «POSIX» IPC, или и то, и другое. Windows имеет собственную реализацию этого функционала, которая здесь не рассматривается.

По умолчанию Digital Q.DataBase выделяет незначительный объем разделяемой памяти System V, а также значительно больший объем анонимной mmap разделяемой памяти. В качестве альтернативы можно использовать одну большую область разделяемой памяти System V (см. shared_memory_type). Кроме того, при запуске сервера создается значительное количество семафоров (типа System V или POSIX). В настоящее время семафоры POSIX используются в системах Linux и FreeBSD, тогда как на других платформах применяются семафоры System V.

System V IPC функциональные возможности обычно ограничены общесистемными лимитами на выделение ресурсов. Если Digital Q.DataBase превышен один из этих лимитов, сервер откажется запускаться и выдаст информативное сообщение об ошибке с описанием проблемы и инструкциями по её устранению. (См. также Раздел 3.3.3.1.) Соответствующие параметры ядра называются одинаково в различных системах; Таблица 3.3.1 приведен общий обзор. Однако способы их настройки различаются. Ниже приведены рекомендации для некоторых платформ.

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

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

При использовании семафоров System V Digital Q.DataBase использует по одному семафору на каждое разрешенное соединение (max_connections), разрешенный рабочий процесс автоочистки (autovacuum_max_workers), разрешенный процесс передачи WAL (max_wal_senders) и разрешенный фоновый процесс (max_worker_processes), в наборах по 19 штук. Каждый такой набор будет также содержать 20-й семафор, в котором хранится ««магическое число»»для обнаружения конфликтов с наборами семафоров, используемыми другими приложениями. Максимальное количество семафоров в системе определяется параметром SEMMNS, значение которого должно быть не меньше значения max_connections плюс autovacuum_max_workers плюс max_wal_senders, плюс max_worker_processes, плюс один дополнительный на каждые 19 разрешенных соединений, включая рабочие процессы (см. формулу в Таблица 3.3.1). Параметр SEMMNI определяет лимит на количество наборов семафоров, которые могут одновременно существовать в системе. Следовательно, значение этого параметра должно быть не менее ceil((max_connections + autovacuum_max_workers + max_wal_senders + max_worker_processes + 7) / 19). Уменьшение числа допустимых соединений является временным решением при возникновении ошибок, которые обычно имеют неясную формулировку «No space left on device», возвращаемую функцией semget.

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

Различные другие параметры, связанные с «semaphore undo», такие как SEMMNU и SEMUME, не влияют на работу Digital Q.DataBase.

При использовании семафоров POSIX количество необходимых семафоров совпадает с количеством для семафоров System V, то есть требуется один семафор на каждое разрешенное соединение (max_connections), разрешенный рабочий процесс автоочистки (autovacuum_max_workers), разрешенный процесс передачи WAL (max_wal_senders) и разрешенный фоновый процесс (max_worker_processes). На платформах, где этот вариант является предпочтительным, отсутствуют специфические системные ограничения ядра на количество семафоров POSIX.

Если systemd используется, необходимо следить за тем, чтобы ресурсы IPC (включая разделяемую память) не были преждевременно удалены операционной системой. Это особенно важно при установке PostgreSQL из исходных кодов. Пользователи дистрибутивных пакетов PostgreSQL менее подвержены этой проблеме, так как postgres пользователь в таких случаях обычно создается как системный.

Параметр RemoveIPC в logind.conf определяет, следует ли удалять IPC-объекты при полном завершении сеанса пользователя. Данное правило не распространяется на системных пользователей. В стандартной конфигурации этот параметр по умолчанию включен systemd, однако в некоторых дистрибутивах операционных систем он может быть выключен по умолчанию.

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

WARNING:  could not remove shared memory segment "/PostgreSQL.1450751626": No such file or directory

Различные типы IPC-объектов (разделяемая память и семафоры, System V и POSIX) обрабатываются systemdнесколько иначе, поэтому можно заметить, что одни IPC-ресурсы не удаляются так же, как другие. Однако не рекомендуется полагаться на эти незначительные различия.

Параметр «выход пользователя из системы» может происходить в рамках регламентных работ или вручную, когда администратор входит в систему от имени postgres пользователя или аналогичным образом, поэтому в общем случае это сложно предотвратить.

Что такое «системный пользователь» определяется во время systemd компиляции на основе параметра SYS_UID_MAX параметр в /etc/login.defs.

В скриптах упаковки и развертывания следует предусмотреть создание postgres пользователя как системного с помощью команды useradd -r, adduser --system, или их аналогов.

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

RemoveIPC=no

в /etc/systemd/logind.conf или другом соответствующем конфигурационном файле.

В операционных системах типа Unix применяются различные виды ограничений ресурсов, которые могут влиять на работу вашего Digital Q.DataBase сервера. Особую важность представляют ограничения на количество процессов на пользователя, количество открытых файлов на процесс и объем памяти, доступный каждому процессу. Для каждого из этих параметров предусмотрен «hard» и «soft» лимит. Фактическое значение имеет мягкий лимит (soft limit), но он может быть изменен пользователем вплоть до жесткого лимита (hard limit). Жесткий лимит может быть изменен только суперпользователем root. Системный вызов setrlimit отвечает за установку данных параметров. Встроенная команда оболочки ulimit (в оболочках Bourne) или limit (csh) используется для управления ограничениями ресурсов из командной строки. В системах на базе BSD файл /etc/login.conf управляет различными ограничениями ресурсов, устанавливаемыми при входе в систему. Для получения подробных сведений см. документацию к операционной системе. К соответствующим параметрам относятся maxproc, openfiles, а также datasize. Например:

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

(-cur соответствует мягкому лимиту (soft limit). Добавьте суффикс -max для установки жесткого лимита (hard limit).)

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

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

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

С другой стороны, некоторые системы позволяют отдельным процессам открывать большое количество файлов; если это будут делать сразу несколько процессов, общесистемный лимит может быть легко превышен. Если это происходит и изменять системные ограничения ядра нежелательно, можно задать Digital Q.DataBase's max_files_per_process параметр конфигурации для ограничения количества одновременно открытых файлов.

Еще одним системным ограничением ядра, которое следует учитывать при обеспечении большого количества клиентских соединений, является максимальная длина очереди соединений через сокет. Если за очень короткий промежуток времени поступит больше запросов на соединение, чем предусмотрено лимитом, некоторые из них могут быть отклонены до того, как Digital Q.DataBase сервер успеет обработать эти запросы; в этом случае клиенты получат неинформативные ошибки сбоя соединения, такие как «Resource temporarily unavailable» или «Connection refused». На многих платформах лимит длины очереди по умолчанию составляет 128 . Для его увеличения следует настроить соответствующий параметр ядра через утилита sysctl, после чего перезагрузить Digital Q.DataBase сервер. Название этого параметра может различаться: net.core.somaxconn в Linux, kern.ipc.soacceptqueue в новых версиях FreeBSD, а также kern.ipc.somaxconn в macOS и других вариантах BSD.

Стандартный механизм работы с виртуальной памятью в Linux не является оптимальным для Digital Q.DataBase. Из-за особенностей реализации избыточного выделения памяти в ядре, оно может принудительно завершить процесс Digital Q.DataBase postmaster (управляющий процесс сервера), если запросы на выделение памяти со стороны Digital Q.DataBase или других процессов приведут к исчерпанию виртуальной памяти в системе.

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

Out of Memory: Killed process 12345 (postgres).

Это указывает на то, что postgres процесс был завершен из-за нехватки памяти. Хотя существующие подключения к базе данных продолжат работу в штатном режиме, новые подключения приниматься не будут. Для восстановления работы Digital Q.DataBase потребуется перезапустить.

Одним из способов решения данной проблемы является запуск Digital Q.DataBase на сервере, где другие процессы гарантированно не приведут к исчерпанию оперативной памяти. При ограниченном объеме памяти увеличение пространства подкачки операционной системы может помочь избежать данной проблемы, так как механизм OOM killer (out-of-memory) вызывается только при полном исчерпании физической памяти и раздела подкачки.

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

Можно изменить поведение ядра таким образом, чтобы оно не «overcommit» памяти. Хотя данная настройка не предотвратит OOM killer от вызова полностью, она значительно снизит вероятность этого и, следовательно, приведет к более стабильной работе системы. Это достигается путем выбора режима строгого резервирования памяти (overcommit) с помощью утилиты sysctl: утилита sysctl:

sysctl -w vm.overcommit_memory=2

или путем внесения соответствующей записи в /etc/sysctl.conf. Также может потребоваться изменить связанный параметр vm.overcommit_ratio. Для получения подробной информации см. файл документации ядра https://www.kernel.org/doc/Documentation/vm/overcommit-accounting.

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

echo -1000 > /proc/self/oom_score_adj

в Digital Q.DataBase скрипте запуска непосредственно перед вызовом postgres. Обратите внимание, что это действие должно выполняться от имени суперпользователя root, иначе оно не возымеет эффекта; поэтому проще всего использовать для этого скрипт запуска, принадлежащий root. В этом случае также следует задать следующие переменные окружения в скрипте запуска перед вызовом postgres:

export PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
export PG_OOM_ADJUST_VALUE=0

Данные настройки обеспечат работу дочерних процессов postmaster с обычным нулевым значением корректировки OOM, чтобы при необходимости OOM-киллер по-прежнему мог выбирать их в качестве цели. Можно использовать и другое значение для PG_OOM_ADJUST_VALUE если требуется, чтобы дочерние процессы выполнялись с иным значением корректировки OOM score. (PG_OOM_ADJUST_VALUE также можно опустить, в этом случае оно по умолчанию принимает значение ноль.) Если не установить PG_OOM_ADJUST_FILE, дочерние процессы будут выполняться с тем же значением корректировки OOM score, что и процесс postmaster, что нецелесообразно, так как основная цель заключается в обеспечении приоритетных настроек для postmaster.

Использование больших страниц снижает накладные расходы при работе с большими непрерывными блоками памяти, как это Digital Q.DataBase делает , особенно при использовании больших значений shared_buffers. Для использования этой функции в Digital Q.DataBase требуется ядро с CONFIG_HUGETLBFS=y и CONFIG_HUGETLB_PAGE=y. Также необходимо настроить операционную систему для предоставления достаточного количества больших страниц нужного размера. Параметр, вычисляемый во время выполнения, shared_memory_size_in_huge_pages сообщает количество необходимых больших страниц. Данный параметр можно просмотреть перед запуском сервера с помощью postgres команда вида:

$ postgres -D $PGDATA -C shared_memory_size_in_huge_pages
3170
$ grep ^Hugepagesize /proc/meminfo
Hugepagesize:       2048 kB
$ ls /sys/kernel/mm/hugepages
hugepages-1048576kB  hugepages-2048kB

В данном примере значение по умолчанию составляет 2 МБ, но можно также явно запросить использование страниц размером 2 МБ или 1 ГБ с помощью huge_page_size для адаптации количества страниц, вычисленного shared_memory_size_in_huge_pages. Хотя в данном примере требуется как минимум 3170 больших страниц (huge pages), будет целесообразно установить большее значение, если другим программам на сервере также требуются большие страницы. Установить данное значение можно с помощью команды:

# sysctl -w vm.nr_hugepages=3170

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

# echo 3170 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

Данные настройки также можно указать при загрузке системы, используя такие параметры ядра, как hugepagesz=2M hugepages=3170.

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

$ cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

Также может потребоваться предоставить пользователю операционной системы сервера баз данных разрешение на использование больших страниц путем настройки параметра vm.hugetlb_shm_group через утилита sysctl, и/или предоставить разрешение на блокировку памяти с помощью ulimit -l.

Поведение по умолчанию для больших страниц в Digital Q.DataBase заключается в их использовании при наличии такой возможности (с системным размером больших страниц по умолчанию) и переходе на обычные страницы в случае ошибки. Для принудительного использования больших страниц (huge pages) можно установить значение huge_pages в on в файле postgresql.conf. Обратите внимание, что при такой настройке Digital Q.DataBase не удастся запустить, если доступно недостаточное количество больших страниц.

Для получения подробного описания Linux функциональностью использования больших страниц (huge pages), ознакомьтесь с https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt.