Cómo configurar shmall, shmmax, shmmin, etc ... en general y para postgresql

11

He usado la documentación de PostgreSQL para configurarla, por ejemplo, esta configuración:

>>> 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

Extracto de sysctl.conf , calculado por mí:

kernel.shmall = 1079204
kernel.shmmax = 4420419584

postgresql.conf no predeterminados , calculado por mí:

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

¿Es esto apropiado? Si no (o no necesariamente), ¿en qué caso sería apropiado?

Notamos buenas mejoras de rendimiento con esta configuración, ¿cómo la mejorarías?

¿Cómo calcular los parámetros de gestión de memoria del kernel?

¿Alguien puede explicar cómo realmente establecerlos desde cero?

jpic
fuente
Son muchas preguntas, y no nos ha dicho cuál es su problema actual (si lo hay) o cuál es su patrón de uso. Puede valer la pena obtener un libro sobre el rendimiento de PostgreSQL.
hmallett
Mi problema es que no estoy convencido de haber hecho la configuración correcta. Creo que las opciones de administración de memoria del kernel no son específicas de PostgreSQL y tampoco estoy seguro de que PostgreSQL sea el mejor lugar para hablar sobre estas opciones. Claro, se mencionan en gran medida en cualquier artículo sobre el rendimiento de PostgreSQL, pero esas son las opciones de Linux y espero comprender realmente cómo ajustarlas en general.
jpic

Respuestas:

11

Respondí esto para otra pregunta aquí:

Git no puede presionar con el error 'sin memoria'

No estoy respondiendo todas sus preguntas aquí, pero la pregunta en su título:

Cómo configurar shmall, shmmax, shmmni, etc. en general y para postgresql

Con algunas distribuciones de kernel, hay configuraciones que evitan que el kernel asigne memoria máxima a un solo proceso:

Establecer los parámetros del kernel

Modifique el /etc/sysctl.confarchivo para incluir las líneas apropiadas para su sistema operativo:

# 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

Si su proceso excede los límites, el núcleo matará el proceso a pesar de que la memoria máxima reportada esté disponible en su sistema.

Nota: tenga cuidado con esta configuración. Probablemente no desee utilizar la configuración en ese ejemplo, ya que la extraje de un servidor en nuestro entorno.

Algunas notas adicionales para mencionar:

Para actualizar y probar la configuración del kernel con sysctl, use los siguientes comandos:

Lista de configuraciones actuales:

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

Deshabilite Linux seguro editando el /etc/selinux/configarchivo, asegurándose de que el indicador SELINUX esté configurado de la siguiente manera.

SELINUX=disabled

¿Es esto apropiado? Si no (o no necesariamente), ¿en qué caso sería apropiado?

La configuración del kernel generalmente se define más estrictamente en entornos de centros de datos cuando los proveedores de ISP no desean que un solo proceso de cliente acapare todos los recursos en un servidor compartido.

Por lo general, no tiene que establecer los parámetros de memoria del núcleo a menos que tenga un proceso que el núcleo está matando debido a la falta de recursos.

En algunos casos, postgres también puede asignar más mem a tamaños de página específicos que los que están disponibles en la memoria compartida:

* 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!

Los errores como el ejemplo anterior se pueden resolver modificando la configuración de recursos del kernel. La configuración y los métodos recomendados, para determinar la configuración de los recursos, se describen en detalle aquí:

http://www.postgresql.org/docs/9.1/static/kernel-resources.html

Sin embargo, realmente no tiene que tocar esta configuración a menos que se encuentre con situaciones de inanición de recursos relacionadas con el proceso de postgres. Estas situaciones ocurren, con mayor frecuencia, en entornos compartidos o servidores con pocos recursos asignados a ellos.

¿Alguien puede explicar cómo realmente establecerlos desde cero?

En cuanto a la optimización de Postgres, debería leer esto:

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

Jason Huntley
fuente
1
"Nota: tenga cuidado con estas configuraciones. Probablemente no quiera usar las configuraciones en ese ejemplo ya que las extraje de un servidor en nuestro entorno". ¿Cómo debo calcularlos para mis entornos?
jpic
1
Hola jpic, actualicé para proporcionar más detalles sobre la configuración del kernel.
Jason Huntley
2

¡¡Oh!! Encuentro una herramienta maravillosa para calcular la configuración optimus mem de nuestro servidor postgresql aquí.

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

Pablo Luna
fuente
Esta herramienta no va a calcular la configuración óptima, le brinda un punto de partida para ajustar su servidor, ya que le brinda una respuesta basada principalmente en la configuración de su hardware. El tamaño de la base de datos, el número de consultas y los tamaños también son importantes para ajustar los parámetros de configuración.
EAmez
1

Esas configuraciones del núcleo son globales, no específicas del proceso, por lo que es apropiado establecerlas sysctl.conf.

mgorven
fuente
La pregunta es sobre la determinación de valores para los parámetros de gestión de memoria compartida del núcleo, el "cómo", no el "dónde" ... Gracias por el esfuerzo realizado en su respuesta.
jpic
Sí. allí donde es trivial. el cómo es su carne.
Henley Chiu
0

Bueno, depende de qué más se esté ejecutando en el servidor, si este es un servidor PostgreSQL puro, PostgreSQL es el lugar adecuado para buscar estas configuraciones.
Si está ejecutando otras aplicaciones / servicios que tienen necesidades específicas de memoria, entonces necesitará encontrar una configuración óptima entre estas diferentes aplicaciones.

Si está viendo un mayor rendimiento en la base de datos y no hay pérdida de rendimiento en otras aplicaciones, entonces no me preocuparía por esto.

En general, las bases de datos son las más sensibles a la configuración de la memoria, ya que probablemente también sean el cuello de botella en el rendimiento de la aplicación.

Sibster
fuente
¿Cómo "encontrar una configuración óptima entre estas diferentes aplicaciones"? No tengo un problema de rendimiento, estoy buscando la forma canónica de configurar los ajustes del kernel de memoria compartida, ¿cómo lo haría un verdadero profesional? Digamos que alguien maneja un servidor en ejecución con un puñado de servicios y le paga para establecer solo la configuración de administración de memoria, ¿qué haría?
jpic
No hay una regla de oro, solo mira lo que dice el vendedor y pruébalo. Si tiene varias aplicaciones ejecutándose en la misma máquina, intente optimizar para la aplicación que requiere más memoria, en la mayoría de los casos, la base de datos. Pero además de mirar las sugerencias de los proveedores y probarlas, no hay una única solución correcta
Sibster,
Sé que no hay una regla de oro. Esperaba que tal vez la recompensa motivara a alguien que realmente entiende esto a escribir algunas instrucciones. Pero creo que nadie realmente comprende esto después de todo, ya que nadie puede dar una explicación simple.
jpic