Primero, use siempre la última versión de PostgreSQL. Las mejoras de rendimiento siempre están llegando, por lo que probablemente esté perdiendo el tiempo si está ajustando una versión anterior. Por ejemplo, PostgreSQL 9.2 mejora significativamente la velocidad de TRUNCATE y, por supuesto, agrega escaneos de solo índice. Incluso los lanzamientos menores siempre deben seguirse; consulte la política de versiones.
No hacer
NO coloque un tablespace en un disco RAM o en otro almacenamiento no duradero.
Si pierde un espacio de tabla, toda la base de datos puede dañarse y ser difícil de usar sin un trabajo significativo. Hay muy pocas ventajas en esto en comparación con solo usar UNLOGGED tablas y tener mucha RAM para caché de todos modos.
Si realmente desea un sistema basado en ramdisk, initdb un clúster completamente nuevo en el ramdisk por initdb ing una nueva instancia de PostgreSQL en el ramdisk, por lo que tiene una instancia de PostgreSQL completamente desechable.
Configuración del servidor PostgreSQL
Al realizar pruebas, puede configurar su servidor para un funcionamiento no duradero pero más rápido.
Este es uno de los únicos usos aceptables para fsync=off configuración en PostgreSQL. Esta configuración básicamente le dice a PostgreSQL que no se moleste con las escrituras ordenadas o cualquier otra cosa desagradable de protección de integridad de datos y seguridad contra fallas, lo que le da permiso para destruir por completo sus datos si se queda sin energía o se bloquea el sistema operativo.
No hace falta decir que nunca debe habilitar fsync=off en producción a menos que esté utilizando Pg como una base de datos temporal para datos que puede volver a generar desde otro lugar. Si y solo si está haciendo para desactivar fsync, también puede activar full_page_writes apagado, ya que ya no sirve de nada entonces. Cuidado con que fsync=off y full_page_writes aplicar en el clúster nivel, por lo que afectan a todos bases de datos en su instancia de PostgreSQL.
Para uso en producción, posiblemente pueda usar synchronous_commit=off y establece un commit_delay , ya que obtendrá muchos de los mismos beneficios que fsync=off sin el riesgo gigante de corrupción de datos. Tiene una pequeña ventana de pérdida de datos recientes si habilita la confirmación asíncrona, pero eso es todo.
Si tiene la opción de alterar ligeramente el DDL, también puede usar UNLOGGED tablas en Pg 9.1+ para evitar por completo el registro de WAL y obtener un aumento de velocidad real a costa de que las tablas se borren si el servidor falla. No hay una opción de configuración para hacer que todas las tablas no estén registradas, debe establecerse durante CREATE TABLE . Además de ser bueno para realizar pruebas, esto es útil si tiene tablas llenas de datos generados o sin importancia en una base de datos que de otro modo contiene cosas que necesita para estar seguro.
Revise sus registros y vea si recibe advertencias sobre demasiados puntos de control. Si es así, debe aumentar su checkpoint_segments. También es posible que desee ajustar su checkpoint_completion_target para suavizar las escrituras.
Ajuste shared_buffers para adaptarse a su carga de trabajo. Esto depende del sistema operativo, depende de qué más esté sucediendo con su máquina y requiere algo de prueba y error. Los valores predeterminados son extremadamente conservadores. Es posible que deba aumentar el límite máximo de memoria compartida del sistema operativo si aumenta shared_buffers en PostgreSQL 9.2 y versiones anteriores; 9.3 y versiones posteriores cambiaron la forma en que usan la memoria compartida para evitar eso.
Si está utilizando solo un par de conexiones que hacen mucho trabajo, aumente work_mem para darles más RAM para jugar, ordenar, etc. Tenga cuidado con un work_mem demasiado alto la configuración puede causar problemas de falta de memoria porque es por clasificación, no por conexión, por lo que una consulta puede tener muchas clasificaciones anidadas. Tú solo realmente tiene que aumentar work_mem si puede ver los tipos que se derraman en el disco en EXPLAIN o registrado con log_temp_files (recomendado), pero un valor más alto también puede permitir que Pg elija planes más inteligentes.
Como dijo otro cartel aquí, es aconsejable colocar el xlog y las tablas/índices principales en discos duros separados si es posible. Las particiones separadas no tienen sentido, realmente quieres unidades separadas. Esta separación tiene mucho menos beneficio si está ejecutando con fsync=off y casi ninguno si está usando UNLOGGED mesas.
Por último, afina tus consultas. Asegúrate de que tu random_page_cost y seq_page_cost refleje el rendimiento de su sistema, asegúrese de que su effective_cache_size es correcto, etc. Use EXPLAIN (BUFFERS, ANALYZE) para examinar planes de consulta individuales y convertir el auto_explain Módulo activado para informar todas las consultas lentas. A menudo, puede mejorar drásticamente el rendimiento de las consultas simplemente creando un índice adecuado o modificando los parámetros de costo.
AFAIK, no hay forma de configurar una base de datos o un clúster completo como UNLOGGED . Sería interesante poder hacerlo. Considere preguntar en la lista de correo de PostgreSQL.
Ajuste del sistema operativo del host
También hay algunos ajustes que puede hacer a nivel del sistema operativo. Lo principal que puede querer hacer es convencer al sistema operativo de que no elimine las escrituras en el disco de forma agresiva, ya que realmente no le importa cuándo/si llegan al disco.
En Linux, puede controlar esto con el dirty_* del subsistema de memoria virtual configuraciones, como dirty_writeback_centisecs .
El único problema con el ajuste de la configuración de reescritura para que sea demasiado flojo es que un vaciado por algún otro programa puede hacer que todos los búferes acumulados de PostgreSQL también se vacíen, causando grandes paradas mientras todo se bloquea en las escrituras. Es posible que pueda aliviar esto ejecutando PostgreSQL en un sistema de archivos diferente, pero algunos vaciados pueden ser a nivel de dispositivo o a nivel de host completo, no a nivel de sistema de archivos, por lo que no puede confiar en eso.
Este ajuste realmente requiere jugar con la configuración para ver qué funciona mejor para su carga de trabajo.
En kernels más nuevos, es posible que desee asegurarse de que vm.zone_reclaim_mode se establece en cero, ya que puede causar graves problemas de rendimiento con los sistemas NUMA (la mayoría de los sistemas en estos días) debido a las interacciones con la forma en que PostgreSQL administra shared_buffers .
Ajuste de consultas y cargas de trabajo
Estas son cosas que SÍ requieren cambios de código; puede que no te convengan. Algunas son cosas que podrías aplicar.
Si no está agrupando el trabajo en transacciones más grandes, comience. Muchas transacciones pequeñas son costosas, por lo que debe procesar lotes siempre que sea posible y práctico hacerlo. Si está utilizando la confirmación asíncrona, esto es menos importante, pero aún así es muy recomendable.
Siempre que sea posible utilice tablas temporales. No generan tráfico WAL, por lo que son mucho más rápidos para inserciones y actualizaciones. A veces vale la pena introducir un montón de datos en una tabla temporal, manipularlos como sea necesario y luego hacer INSERT INTO ... SELECT ... para copiarlo en la tabla final. Tenga en cuenta que las tablas temporales son por sesión; si su sesión finaliza o pierde la conexión, la tabla temporal desaparece y ninguna otra conexión puede ver el contenido de la(s) tabla(s) temporal(es) de una sesión.
Si usa PostgreSQL 9.1 o posterior, puede usar UNLOGGED tablas para datos que puede permitirse perder, como el estado de la sesión. Estos son visibles en diferentes sesiones y se conservan entre conexiones. Se truncan si el servidor se apaga de manera incorrecta, por lo que no se pueden usar para nada que no se pueda volver a crear, pero son excelentes para cachés, vistas materializadas, tablas de estado, etc.
En general, no DELETE FROM blah; . Usa TRUNCATE TABLE blah; en cambio; es mucho más rápido cuando volcamos todas las filas de una tabla. Truncar muchas tablas en una TRUNCATE llama si puedes. Hay una advertencia si estás haciendo muchos TRUNCATES de mesas pequeñas una y otra vez, sin embargo; ver:Velocidad de truncamiento de Postgresql
Si no tiene índices en claves foráneas, DELETE Los correos electrónicos relacionados con las claves primarias a las que hacen referencia esas claves externas serán terriblemente lentos. Asegúrese de crear dichos índices si alguna vez espera DELETE de la(s) tabla(s) de referencia. No se requieren índices para TRUNCATE .
No cree índices que no necesite. Cada índice tiene un costo de mantenimiento. Intente usar un conjunto mínimo de índices y deje que los escaneos de índices de mapa de bits los combinen en lugar de mantener demasiados índices de varias columnas grandes y costosos. Cuando se requieran índices, intente llenar la tabla primero, luego cree índices al final.
Hardware
Tener suficiente RAM para almacenar toda la base de datos es una gran victoria si puede administrarla.
Si no tiene suficiente RAM, cuanto más rápido pueda obtener el almacenamiento, mejor. Incluso un SSD barato hace una gran diferencia sobre el óxido giratorio. Sin embargo, no confíes en los SSD baratos para la producción, ya que a menudo no son seguros contra fallas y pueden comerse tus datos.
Aprendizaje
El libro de Greg Smith, PostgreSQL 9.0 High Performance sigue siendo relevante a pesar de referirse a una versión algo más antigua. Debería ser una referencia útil.
Únase a la lista de correo general de PostgreSQL y sígala.
Lectura:
- Ajuste de su servidor PostgreSQL:wiki de PostgreSQL
- Número de conexiones a la base de datos:wiki de PostgreSQL
