Postgres DISK IO muy alto. ¿Qué puedo hacer para reducirlo de inmediato?

Sé que los discos más rápidos de lo que estoy usando ayudarán, pero esto llevará más tiempo y estoy tratando de usar algunas medidas de emergencia para disminuir la E / S del disco. encima está reportando el uso de DSK en rojo casi constantemente. Esto es para postgres 8.3.

Mi configuración shared_buffers es de 24 MB, aunque el servidor tiene 16 GB de RAM que no se utilizan por completo. Lo primero que pensé fue darle a la base de datos tanta memoria RAM como pudiera, pero no estoy seguro de cómo hacerlo (este es un servidor de base de datos dedicado).

Es preferible cualquier solución que no requiera un reinicio, pero tomaré lo que pueda obtener en este momento.

¡Gracias!

La configuración de 24 MB de shared_buffers es el valor predeterminado conservador, yo diría que debe ser bastante más alto para una base de datos dedicada con 16 GB de RAM disponible. Pero sí, tendrá que reiniciar el servidor para cambiar su tamaño. http://wiki.postgresql.org/wiki/Performance_Optimization es un buen lugar para comenzar con las pautas de configuración de rendimiento. Establecer shared_buffers en 4GB o 6GB parecería más razonable.

Tenga en cuenta que en Linux necesita ajustar la configuración de kernel.shmmax sysctl (en /etc/sysctl.conf o simplemente escribiendo / proc / sys / kernel / shmmax) para asignar un bloque de esta memoria compartida. Si no lo hace, recibirá un error que especifica cuánto se solicitó, debe configurar kernel.shmmax por encima de eso.

Dado que tiene mucha memoria, también puede considerar configurar el work_mem predeterminado más alto, lo que hará que las cosas como ordenaciones y hashes (grupo / orden / distinto, etc.) tiendan a funcionar en la memoria en lugar de usar archivos temporales. No necesita reiniciar el servidor para hacer esto, solo actualice el archivo de configuración, vuelva a cargar el servicio y las nuevas sesiones obtendrán la nueva configuración. La memoria de trabajo predeterminada para una sesión es de 1 MB, puede calcular el máximo que se puede usar a la vez work_mem * max_client_connectionsy calcular el impacto que tendrá.

También debe aumentar el tamaño efectivo de caché para indicar al planificador que es probable que la capa FS del núcleo almacene en caché muchas páginas en la memoria fuera de los búferes compartidos de postgresql.

etc. etc. Espero que esto lo lleve a un buen comienzo.

Vuelva a montar los discos con noatime

Además de las sugerencias dadas aquí, es posible que también desee consultar la configuración de su autovacum. De manera predeterminada, se activará después de alrededor de 50 actualizaciones y si su base de datos está haciendo muchas actualizaciones / inserciones, esto puede desencadenar una cantidad innecesaria de declaraciones de vacío que generarán una gran cantidad de E / S.

En un sistema que está muy cerca del rendimiento máximo de E / S durante el funcionamiento normal, es posible que desee aumentar checkpoint_completion_target para reducir la carga de E / S desde los puntos de control . La desventaja de esto es que prolongar los puntos de control afecta el tiempo de recuperación, ya que será necesario mantener más segmentos de WAL para su posible uso en la recuperación

Ver más aquí .

Si el diskio del postgresql es muy alto, debe verificar las declaraciones en ejecución, especialmente para las declaraciones, hacer un "ordenar en disco" y establecer los índices adecuados.

Solo busque en Google "Postgresql Performance Tuning", encontrará suficientes pistas por dónde comenzar.