Что такое shmmax on linux

Operating System

This blog is created for learning how to manage OS.

Pages

Wednesday, March 12, 2014

Linux Understanding SHMMAX and SHMALL Settings

Linux Understanding SHMMAX and SHMALL Settings

Shared memory and SHMMAX and SHMALL

Just to clarify a couple of definitions, I will go over some terminology. The term shared memory is a term used to describe a type of memory management in the Unix kernel. It is a memory region that can shared between different processes. Oracle uses this shared memory when using and implementing the SGA, which has to be visible to all database sessions. Using a shared memory model, this avoids creating duplicate copies of memory. So programs can eaily share data. These regions of memory, because they are shared need to have controls on who can access them and who can’t. A locking mechanism is required. This is where semaphores come into play. Basically, flags that are either on or off. If the memory is being used, the process turns on the flag and other processes have to wait until the semaphore is freed or the flag is turned off. So shared memory needs semaphores, they go hand in hand. I should probably mention that an application can access shared memory programatically through a set of POSIX C routines, common on most Unix like operating systems including Linux. The IPC or shared memory API’s have common IPC calls like shmget() and shmat() which allow the programmer to get a shared memory segment, or attach to a segment. There are many more. Now the kernel paramaters SHMMAX and SHMALL need to be defined now. SHMMAX is really just the maximum size of a single shared memory segment. It’s size is represented in bytes”. And SHMALL is the sum of all shared memory segments on the whole system. But it is measured in number of pages. Will leave it at that for now.
At times on very busy transactional databases, you can run out of semaphores. This seriously limits the performance of a database. You can look at your semaphores as follows:
Enough of a semaphore tangent. Linux being a type of Unix, there are 300 different ways of finding the value of a system paramaters. The traditional way is calling ipcs to list the shared memory limits:

Or cat’ing the /proc/* data structures

Now, how do you configure SHMALL for an Oracle database

The logic behind finding the SHMALL value for your system

Working example

System memory 12GB
Linux Kernel 1GB
Memory for Oracle 11GB (System memory – Linux Kernel)
So we can assign SHMALL the value of 11GB. But… SHMALL is measured in memory pages not bytes. We need to divide the 11GB by the systems page size value. It’s almost always 4K which is the recommended size, but to be safe, you run the following command:
We have to convert the 11GB byte value into a page value because as I mentioned above, SHMALL is measured in page size. I don’t make the rules, sorry. I use bc, the unix calculator and I don’t need decimal places.

This is a tad conveluted, but easy math. Lets make this SHMALL kernel paramater permanent by adding it to the /etc/sysctl.conf file.

The logic behind finding the SHMMAX value for your system

If you read the release and install and configuration documentation for Oracle 11g, Oracle recommends you set shmmax to half of your physical memory or 4 GB less 1 byte. Choose whichever is lower. The interesting 4 GB less 1byte memory setting is based on the virtual memory addressing limitations of the 32 bit (x86) processors. All 64 bit processors can address much larger memory addresse space and is not limited like it’s 32 bit brethren. So much larger shared memory segments can be permitted and created and used.
When Oracle first starts up, after having read it’s configuration files it will know how much memory it needs for it’s assorted SGA’s. The best fit for an Oracle SGA shared memory segment is when the SGA fits into one shared memory segment. As I mentioned earlier, Oracle can use non-contiguous shared memory segments, but its not Oracle’s chosen memory model. Therefore by defenition, if the SGA is larger than the value of SHMMAX, then Oracle has to use one of the two other remaining shared memory models. Contiguous or non-contiguous memory segments.
I try to set the SHMMAX to the size of the largest SGA defined on your database server. If your system has 6 Oracle instances configured, 2 require 2 GB SGA’s, 2 require 1.5GB SGA’s and 2 require 1 GB SGA’s, you would set the SHMMAX to 2GB.
Edit your sysctl.conf and add the SHMMAX value to 2 GB in bytes
Or, as this is Unix and there are many ways of doing things, use sysctl -w argument=xyz which writes to the sysctl.conf file.
Now reload the parameters by asking sysctl politely to to reread it’s configuration
Now that you have configured shmmax and shmall, and all the other steps required to configure you system for Oracle, I will jump ahead very fast here and install Oracle and create a test db instance.
….
Create a test databse
etc…..

The last few steps have been exceedingly oversimplied, but the point here is to show the shared memory use. You will also see that user oracle has grabbed 154 semaphores. This isn’t a huge number, and in this case it’s only a test db instance so no real traffic.

Источник

Что такое shmmax on linux

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы изменённые таким образом параметры вступили в силу, требуется перезагрузить систему.

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

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

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

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

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

Обычно имеет смысл увеличить kern.ipc.semmni и kern.ipc.semmns , так как их значения по умолчанию в NetBSD слишком малы.

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

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

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

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

Обычно имеет смысл увеличить kern.seminfo.semmni и kern.seminfo.semmns , так как их значения по умолчанию в OpenBSD слишком малы.

В старых версиях OpenBSD вам потребуется пересобрать ядро, чтобы изменить параметры IPC. Также убедитесь, что в ядре включены параметры SYSVSHM и SYSVSEM (по умолчанию они включены). Следующие строки показывают, как установить различные параметры в файле конфигурации ядра: HP-UX

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

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

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

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

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

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

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

Заметьте, что в некоторых версиях 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 и задать значения следующими командами:

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

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

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

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

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

и перезагрузите систему. Solaris версии с 2.6 по 2.9 (Solaris 6 .. Solaris 9)

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

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

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

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

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

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

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

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

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

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

17.4.2. RemoveIPC в systemd

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

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

Обычно нежелательный эффект этого включённого параметра проявляется в том, что объекты семафоров, используемые сервером Postgres Pro , удаляются без видимых причин, что приводит к отказу сервера с сообщениями вида:

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

Событие « выхода пользователя из системы » может произойти при выполнении задачи обслуживания или если администратор войдёт под именем postgres , а затем выйдет, либо случится что-то подобное, так что предотвратить это довольно сложно.

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

Скрипт упаковывания и развёртывания сервера должен предусмотрительно создавать пользователя postgres как системного пользователя, используя команды useradd -r , adduser —system или равнозначные.

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

в /etc/systemd/logind.conf или другом подходящем файле конфигурации.

Внимание

Необходимо предпринять минимум одно из этих двух действий, иначе сервер Postgres Pro будет очень нестабильным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в скрипте запуска управляющего процесса непосредственно перед тем, как запускать postmaster. Заметьте, что делать это надо под именем root, иначе ничего не изменится; поэтому проще всего вставить эту команду в стартовый скрипт, принадлежащий пользователю root. Если вы делаете это, вы также должны установить в данном скрипте эти переменные окружения перед запуском главного процесса:

С такими параметрами дочерние процессы главного будут запускаться с обычной, нулевой поправкой очков OOM, так что при необходимости механизм OOM сможет уничтожать их. Вы можете задать и другое значение для PG_OOM_ADJUST_VALUE , если хотите, чтобы дочерние процессы исполнялись с другой поправкой OOM. ( PG_OOM_ADJUST_VALUE также можно опустить, в этом случае подразумевается нулевое значение.) Если вы не установите PG_OOM_ADJUST_FILE , дочерние процессы будут работать с той же поправкой очков OOM, которая задана для главного процесса, что неразумно, так всё это делается как раз для того, чтобы главный процесс оказался на особом положении.

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

Примечание

Некоторые дистрибутивы с ядрами 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.5. Огромные страницы в Linux

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

В данном случае 6490428 / 2048 даёт примерно 3169.154 , так что нам потребуется минимум 3170 огромных страниц, и мы можем задать это значение так:

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

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

Источник