PostgreSQL requiere que el sistema operativo proporcione características de comunicación entre procesos (IPC), específicamente memoria compartida y semáforos. Los sistemas derivados de Unix típicamente proporcionan IPC de “System V”, IPC de “POSIX”, o ambos. Windows tiene su propia implementación de estas características y no se discute aquí.

Por defecto, PostgreSQL asigna una cantidad muy pequeña de memoria compartida de System V, así como una cantidad mucho mayor de memoria compartida anónima mediante mmap. Alternativamente, se puede usar una única región grande de memoria compartida de System V (ver shared_memory_type). Además, al inicio del servidor se crea un número significativo de semáforos, que pueden ser de estilo System V o POSIX. Actualmente, se usan semáforos POSIX en sistemas Linux y FreeBSD, mientras que otras plataformas usan semáforos de System V.

Las características de IPC de System V están típicamente limitadas por límites de asignación en todo el sistema. Cuando PostgreSQL excede uno de estos límites, el servidor se negará a iniciar y debería dejar un mensaje de error instructivo que describa el problema y qué hacer al respecto. (Ver también Section 18.3.1). Los parámetros de kernel relevantes se nombran de manera consistente en diferentes sistemas; Table 18.1 da una descripción general. Los métodos para establecerlos, sin embargo, varían. A continuación se dan sugerencias para algunas plataformas.

PostgreSQL requiere unos pocos bytes de memoria compartida de System V (típicamente 48 bytes, en plataformas de 64 bits) por cada copia del servidor. En la mayoría de los sistemas operativos modernos, esta cantidad se puede asignar fácilmente. Sin embargo, si estás ejecutando muchas copias del servidor o si configuras explícitamente el servidor para usar grandes cantidades de memoria compartida de System V (ver shared_memory_type y dynamic_shared_memory_type), podría ser necesario incrementar SHMALL, que es la cantidad total de memoria compartida de System V en todo el sistema. Ten en cuenta que SHMALL se mide en páginas en lugar de bytes en muchos sistemas.

Es menos probable que cause problemas el tamaño mínimo para los segmentos de memoria compartida (SHMMIN), el cual debería ser a lo sumo aproximadamente 32 bytes para PostgreSQL (usualmente es solo 1). Es improbable que el número máximo de segmentos en todo el sistema (SHMMNI) o por proceso (SHMSEG) cause un problema a menos que tu sistema los tenga configurados a cero.

Cuando se usan semáforos de System V, PostgreSQL usa un semáforo por conexión permitida (max_connections), proceso trabajador de autovacuum permitido (autovacuum_worker_slots), proceso emisor de WAL permitido (max_wal_senders), proceso de fondo permitido (max_worker_processes), etc., en conjuntos de 16. El parámetro calculado en tiempo de ejecución num_os_semaphores reporta el número de semáforos requeridos. Este parámetro se puede ver antes de iniciar el servidor con un comando de postgres como:

$ postgres -D $PGDATA -C num_os_semaphores

Cada conjunto de 16 semáforos también contendrá un 17º semáforo que contiene un “número mágico”, para detectar colisiones con conjuntos de semáforos usados por otras aplicaciones. El número máximo de semáforos en el sistema se establece por SEMMNS, el cual consecuentemente debe ser al menos tan alto como num_os_semaphores más uno extra por cada conjunto de 16 semáforos requeridos (ver la fórmula en Table 18.1). El parámetro SEMMNI determina el límite en el número de conjuntos de semáforos que pueden existir en el sistema al mismo tiempo. Por lo tanto, este parámetro debe ser al menos ceil(num_os_semaphores / 16). Reducir el número de conexiones permitidas es una solución temporal para los fallos, que usualmente se expresan de manera confusa como “No space left on device”, provenientes de la función semget.

En algunos casos también podría ser necesario incrementar SEMMAP para que sea al menos del orden de SEMMNS. Si el sistema tiene este parámetro (muchos no lo tienen), este define el tamaño del mapa de recursos de semáforos, en el cual cada bloque contiguo de semáforos disponibles necesita una entrada. Cuando un conjunto de semáforos se libera, se añade a una entrada existente que sea adyacente al bloque liberado o se registra bajo una nueva entrada del mapa. Si el mapa está lleno, los semáforos liberados se pierden (hasta el reinicio). La fragmentación del espacio de semáforos podría con el tiempo llevar a tener menos semáforos disponibles de los que debería.

Varios otros ajustes relacionados con “deshacer semáforos (semaphore undo)”, tales como SEMMNU y SEMUME, no afectan a PostgreSQL.

Cuando se usan semáforos POSIX, el número de semáforos necesarios es el mismo que para System V, es decir, un semáforo por conexión permitida (max_connections), proceso trabajador de autovacuum permitido (autovacuum_worker_slots), proceso emisor de WAL permitido (max_wal_senders), proceso de fondo permitido (max_worker_processes), etc. En las plataformas donde se prefiere esta opción, no hay un límite de kernel específico para el número de semáforos POSIX.

Si se está utilizando systemd, se debe tener cierto cuidado de que los recursos de IPC (incluyendo la memoria compartida) no sean eliminados prematuramente por el sistema operativo. Esto es especialmente preocupante cuando se instala PostgreSQL desde el código fuente. Los usuarios de paquetes de distribución de PostgreSQL tienen menos probabilidades de verse afectados, ya que el usuario postgres normalmente se crea entonces como un usuario del sistema.

La configuración RemoveIPC en logind.conf controla si los objetos IPC se eliminan cuando un usuario cierra la sesión por completo. Los usuarios del sistema están exentos. Esta configuración está activada por defecto en el systemd original, pero algunas distribuciones de sistemas operativos la desactivan por defecto.

Un efecto típico observado cuando esta configuración está activada es que los objetos de memoria compartida utilizados para la ejecución de consultas en paralelo se eliminan en momentos aparentemente aleatorios, lo que provoca errores y advertencias al intentar abrirlos y eliminarlos, como:

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

Los diferentes tipos de objetos IPC (memoria compartida frente a semáforos, System V frente a POSIX) son tratados de forma ligeramente diferente por systemd, por lo que uno podría observar que algunos recursos de IPC no se eliminan de la misma manera que otros. Pero no es recomendable confiar en estas sutiles diferencias.

El “cierre de sesión de un usuario” podría ocurrir como parte de un trabajo de mantenimiento o manualmente cuando un administrador inicia sesión como el usuario postgres o algo similar, por lo que es difícil de evitar en general.

Lo que constituye un “usuario del sistema” se determina en el momento de la compilación de systemd a partir de la configuración SYS_UID_MAX en /etc/login.defs.

Los scripts de empaquetado y despliegue deben tener cuidado de crear el usuario postgres como un usuario del sistema usando useradd -r, adduser --system, o equivalente.

Alternativamente, si la cuenta de usuario se creó incorrectamente o no se puede cambiar, se recomienda establecer:

RemoveIPC=no

en /etc/systemd/logind.conf u otro archivo de configuración apropiado.

Los sistemas operativos de tipo Unix imponen varios tipos de límites de recursos que podrían interferir con el funcionamiento de tu servidor PostgreSQL. De particular importancia son los límites en el número de procesos por usuario, el número de archivos abiertos por proceso y la cantidad de memoria disponible para cada proceso. Cada uno de estos tiene un límite “hard” (duro) y uno “soft” (blando). El límite soft es el que realmente cuenta, pero el usuario puede cambiarlo hasta llegar al límite hard. El límite hard solo lo puede cambiar el usuario root. La llamada al sistema setrlimit es responsable de establecer estos parámetros. El comando integrado de la shell ulimit (shells Bourne) o limit (csh) se utiliza para controlar los límites de recursos desde la línea de comandos. En sistemas derivados de BSD, el archivo /etc/login.conf controla los diversos límites de recursos establecidos durante el inicio de sesión. Consulta la documentación del sistema operativo para más detalles. Los parámetros relevantes son maxproc, openfiles y datasize. Por ejemplo:

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

(-cur es el límite soft. Añade -max para establecer el límite hard).

Los kernels también pueden tener límites en todo el sistema para algunos recursos.

El servidor PostgreSQL utiliza un proceso por conexión, por lo que deberías prever al menos tantos procesos como conexiones permitidas, además de lo que necesites para el resto de tu sistema. Esto usualmente no es un problema, pero si ejecutas varios servidores en una máquina, las cosas podrían ponerse difíciles.

El límite predeterminado de fábrica para archivos abiertos se establece a menudo en valores “socialmente amigables” que permiten la coexistencia de muchos usuarios en una máquina sin utilizar una fracción inapropiada de los recursos del sistema. Si ejecutas muchos servidores en una máquina, esto es quizás lo que deseas, pero en servidores dedicados podrías querer elevar este límite.

Por otro lado, algunos sistemas permiten a los procesos individuales abrir una gran cantidad de archivos; si más de unos pocos procesos lo hacen, el límite de todo el sistema se puede superar fácilmente. Si ves que esto sucede y no deseas alterar el límite de todo el sistema, puedes establecer el parámetro de configuración max_files_per_process de PostgreSQL para limitar el consumo de archivos abiertos.

Otro límite del kernel que puede ser de interés cuando se soporta un gran número de conexiones de clientes es la longitud máxima de la cola de conexiones de sockets. Si llegan más solicitudes de conexión que esa en un período muy corto, algunas podrían ser rechazadas antes de que el servidor PostgreSQL pueda atender las solicitudes, recibiendo esos clientes errores de fallo de conexión poco útiles tales como “Resource temporarily unavailable” o “Connection refused”. El límite de longitud de cola predeterminado es 128 en muchas plataformas. Para elevarlo, ajusta el parámetro de kernel apropiado a través de sysctl, luego reinicia el servidor PostgreSQL. El parámetro se nombra de diversas formas: net.core.somaxconn en Linux, kern.ipc.soacceptqueue en FreeBSD más nuevo, y kern.ipc.somaxconn en macOS y otras variantes de BSD.

El comportamiento por defecto de la memoria virtual en Linux no es óptimo para PostgreSQL. Debido a la forma en que el kernel implementa la sobreasignación de memoria, el kernel podría terminar el postmaster de PostgreSQL (el proceso de servidor supervisor) si las demandas de memoria de PostgreSQL o de otro proceso causan que el sistema se quede sin memoria virtual.

Si esto sucede, verás un mensaje del kernel parecido a este (consulta la documentación y configuración de tu sistema sobre dónde buscar dicho mensaje):

Out of Memory: Killed process 12345 (postgres).

Esto indica que el proceso postgres ha sido terminado debido a la presión de memoria. Aunque las conexiones de bases de datos existentes continuarán funcionando normalmente, no se aceptarán nuevas conexiones. Para recuperarse, será necesario reiniciar PostgreSQL.

Una forma de evitar este problema es ejecutar PostgreSQL en una máquina donde puedas estar seguro de que otros procesos no harán que la máquina se quede sin memoria. Si la memoria es escasa, aumentar el espacio de swap del sistema operativo puede ayudar a evitar el problema, porque el eliminador de falta de memoria (OOM killer) se invoca solo cuando la memoria física y el espacio de swap se agotan.

Si PostgreSQL mismo es la causa de que el sistema se quede sin memoria, puedes evitar el problema cambiando tu configuración. En algunos casos, puede ayudar reducir los parámetros de configuración relacionados con la memoria, particularmente shared_buffers, work_mem y hash_mem_multiplier. En otros casos, el problema puede ser causado por permitir demasiadas conexiones al propio servidor de bases de datos. En muchos casos, puede ser mejor reducir max_connections y en su lugar hacer uso de software externo de pool de conexiones (connection pooling).

Es posible modificar el comportamiento del kernel para que no “sobreasigne (overcommit)” memoria. Aunque esta configuración no evitará por completo que se invoque el OOM killer, reducirá significativamente las probabilidades y, por lo tanto, conducirá a un comportamiento del sistema más robusto. Esto se hace seleccionando el modo de sobreasignación estricto a través de sysctl:

sysctl -w vm.overcommit_memory=2

o colocando una entrada equivalente en /etc/sysctl.conf. También es posible que desees modificar la configuración relacionada vm.overcommit_ratio. Para más detalles, consulta el archivo de documentación del kernel https://www.kernel.org/doc/Documentation/vm/overcommit-accounting.

Otro enfoque, que se puede utilizar con o sin alterar vm.overcommit_memory, es establecer el valor específico de proceso de ajuste de puntuación OOM (OOM score adjustment) para el proceso postmaster en -1000, garantizando así que no será el objetivo del OOM killer. La forma más sencilla de hacer esto es ejecutar:

echo -1000 > /proc/self/oom_score_adj

en el script de inicio de PostgreSQL justo antes de invocar postgres. Ten en cuenta que esta acción debe realizarse como root, o de lo contrario no tendrá efecto; por lo tanto, un script de inicio propiedad de root es el lugar más fácil para hacerlo. Si haces esto, también deberías establecer estas variables de entorno en el script de inicio antes de invocar postgres:

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

Estos ajustes causarán que los procesos hijo del postmaster se ejecuten con el ajuste de puntuación OOM normal de cero, de modo que el OOM killer pueda seguir apuntando a ellos si es necesario. Podrías usar algún otro valor para PG_OOM_ADJUST_VALUE si deseas que los procesos hijo se ejecuten con algún otro ajuste de puntuación OOM. (PG_OOM_ADJUST_VALUE también se puede omitir, en cuyo caso toma por defecto el valor cero). Si no estableces PG_OOM_ADJUST_FILE, los procesos hijo se ejecutarán con el mismo ajuste de puntuación OOM que el postmaster, lo cual es imprudente ya que el objetivo principal es asegurar que el postmaster tenga una configuración preferencial.

El uso de páginas gigantes (huge pages) reduce la sobrecarga al usar grandes bloques contiguos de memoria, como hace PostgreSQL, particularmente cuando se usan valores grandes de shared_buffers. Para usar esta característica en PostgreSQL necesitas un kernel con CONFIG_HUGETLBFS=y y CONFIG_HUGETLB_PAGE=y. También tendrás que configurar el sistema operativo para proporcionar suficientes páginas gigantes del tamaño deseado. El parámetro calculado en tiempo de ejecución shared_memory_size_in_huge_pages reporta el número de páginas gigantes requeridas. Este parámetro se puede ver antes de iniciar el servidor con un comando de postgres como:

$ 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

En este ejemplo, el valor predeterminado es 2MB, pero también puedes solicitar explícitamente 2MB o 1GB con huge_page_size para adaptar el número de páginas calculadas por shared_memory_size_in_huge_pages. Aunque necesitamos al menos 3170 páginas gigantes en este ejemplo, una configuración mayor sería apropiada si otros programas en la máquina también necesitan páginas gigantes. Podemos establecer esto con:

# sysctl -w vm.nr_hugepages=3170

so that it is reapplied after reboots. For non-default huge page sizes, we can instead use:

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

También es posible proporcionar estas configuraciones en el momento del arranque usando parámetros del kernel tales como hugepagesz=2M hugepages=3170.

A veces el kernel no puede asignar el número de páginas gigantes deseado inmediatamente debido a la fragmentación, por lo que podría ser necesario repetir el comando o reiniciar. (Inmediatamente después de un reinicio, la mayor parte de la memoria de la máquina debería estar disponible para ser convertida en páginas gigantes). Para verificar la situación de la asignación de páginas gigantes para un tamaño dado, usa:

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

También puede ser necesario dar permiso al usuario de sistema operativo del servidor de bases de datos para usar páginas gigantes configurando vm.hugetlb_shm_group a través de sysctl, y/o dar permiso para bloquear memoria con ulimit -l.

El comportamiento predeterminado para las páginas gigantes en PostgreSQL es usarlas cuando sea posible, con el tamaño de página gigante predeterminado del sistema, y volver a las páginas normales en caso de fallo. Para forzar el uso de páginas gigantes, puedes establecer huge_pages a on en postgresql.conf. Ten en cuenta que con esta configuración, PostgreSQL fallará al iniciar si no hay suficientes páginas gigantes disponibles.

Para una descripción detallada de la característica de páginas gigantes de Linux, echa un vistazo a https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt.