Encontró el siguiente error al leer de una tabla PG 10 con 10 subprocesos paralelos: -
ERROR: no se pudo cambiar el tamaño del segmento de memoria compartida "/PostgreSQL.1110214013" a 3158016 bytes: no queda espacio en el dispositivo
Parece ser el resultado de que K8 limite el tamaño máximo de /dev/shm/ a 64 MB. Establecer este valor da como resultado un valor superior a 64 MB.
Las tareas de Spark llevan a cabo lecturas paralelas y se dividen en función del valor hash de una columna de identificación. Me pregunto si las particiones desequilibradas podrían estar causando que una tarea en particular exceda el valor de postgres work_mem para el proceso que causa una escritura en el disco.
Estoy viendo un registro de errores correspondiente para cada uno de mis subprocesos, por lo que este cambio de tamaño del segmento de memoria compartida se produce varias veces (presumiblemente, los cambios de tamaño solicitados superan los 64 MB bloqueados)
He intentado subir work_mem de 4 MB a 32 MB, 64 MB y finalmente a 256 MB, pero he visto el error en cada etapa. A continuación se muestra el conjunto completo de configuraciones de PG que creo que se pueden modificar para evitar el uso problemático del disco:
Tengo una posible solución alternativa que implica montar un directorio en /dev/shm/ pero preferiría evitar esta solución ya que no podría limitar el tamaño al que podría crecer el directorio, idealmente encontraría una solución que funcione con los 64 MB.
Gracias.
Parece que (según esta explicación ) si desea evitar el problema y dejar /dev/shm limitado a 64 MB, deberá configurar shared_buffers en menos de 64 MB. Sin embargo, montar un volumen emptyDir en /dev/shm es probablemente la mejor opción si hay más memoria físicamente disponible para su nodo de Kubernetes.
Es cierto que a partir de Kubernetes 1.21 no puede restringir el tamaño del volumen emptyDir (a menos que tenga acceso para configurar puertas de características: la nueva puerta de características SizeMemoryBackedVolumes todavía está en alfa ), pero esto probablemente no importe para el uso de Postgres caso.
Si Postgres es la única aplicación que se ejecuta en el pod y configuró shared_buffers en alrededor del 25 % de la memoria disponiblesegún lo recomendado por la documentación de Postgres , el comportamiento actual de ofrecer hasta el 50 % de la memoria del nodo al volumen emptyDir antes del desalojo debería estar bien. Necesitaría activar algún error en Postgres para que consuma mucha más memoria que la configuración de shared_buffers .
Por lo tanto, es probable que la mejor solución establezca shared_buffers en ~25 % de la memoria de nodo disponible y luego monte un volumen emptyDir en /dev/shm .