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 velocidadTRUNCATE y, por supuesto, agrega escaneos de solo índice. Incluso los lanzamientos menores siempre deben seguirse; ver la política de versiones .
No hacer
No NO poner un espacio de tabla en un disco RAM u otro almacenamiento no duraderos .
Si pierde un espacio de tabla, toda la base de datos puede dañarse y ser difícil de usar sin un trabajo significativo. Esto tiene muy poca ventaja en comparación con solo usar UNLOGGEDtablas y tener mucha RAM para caché de todos modos.
Si realmente desea un sistema basado en ramdisk, initdbun clúster completamente nuevo en el ramdisk initdbincorporando 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 la prueba, puede configurar su servidor para una operación no duradera pero más rápida .
Este es uno de los únicos usos aceptables para la fsync=offconfiguración en PostgreSQL. Esta configuración casi le dice a PostgreSQL que no se moleste con las escrituras ordenadas o cualquiera de esas otras cosas desagradables de protección de integridad de datos y seguridad contra choques, lo que le da permiso para destruir completamente sus datos si pierde energía o tiene un bloqueo del sistema operativo.
Huelga decir que nunca debe habilitar la fsync=offproducción a menos que esté usando 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 se puede full_page_writesdesactivar, ya que ya no sirve de nada. Tenga cuidado fsync=offy full_page_writesaplique a nivel de clúster , de modo que afecten a todas las bases de datos en su instancia de PostgreSQL.
Para el uso de producción, posiblemente pueda usar synchronous_commit=offy establecer un commit_delay, ya que obtendrá muchos de los mismos beneficios que fsync=offsin el riesgo de corrupción de datos gigantes. 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 UNLOGGEDtablas en la página 9.1+ para evitar completamente 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 se registren, se debe configurar durante CREATE TABLE. Además de ser bueno para las pruebas, esto es útil si tiene tablas llenas de datos generados o sin importancia en una base de datos que de lo contrario contiene cosas que necesita para estar seguro.
Verifique sus registros y vea si recibe advertencias sobre demasiados puntos de control. Si es así, debe aumentar sus checkpoint_segments . También es posible que desee ajustar su checkpoint_completion_target para suavizar las escrituras.
Sintonice shared_bufferspara adaptarse a su carga de trabajo. Esto depende del sistema operativo, depende de lo que 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_buffersPostgreSQL 9.2 y versiones inferiores; 9.3 y superior cambió 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_mempara darles más RAM para jugar, etc. Tenga en cuenta que una work_memconfiguración demasiado alta puede causar problemas de falta de memoria porque es por tipo, no por conexión para que una consulta pueda tener muchos tipos anidados. Realmente solo tiene que aumentar work_memsi puede ver cómo se derraman tipos en el disco EXPLAINo si se registra con la log_temp_filesconfiguración (recomendado), pero un valor más alto también puede permitir que Pg elija planes más inteligentes.
Como dijo otro póster aquí, es aconsejable colocar el xlog y las tablas / índices principales en discos duros separados si es posible. Las particiones separadas son bastante inútiles, realmente quieres unidades separadas. Esta separación tiene mucho menos beneficio si está ejecutando fsync=offy casi ninguno si está utilizando UNLOGGEDtablas.
Finalmente, ajuste sus consultas. Asegúrese de que su random_page_costy seq_page_costrefleje el rendimiento de su sistema, asegúrese de que effective_cache_sizesea correcto, etc. Utilícelo EXPLAIN (BUFFERS, ANALYZE)para examinar planes de consulta individuales y encienda el auto_explainmódulo para informar todas las consultas lentas. A menudo puede mejorar drásticamente el rendimiento de las consultas simplemente creando un índice apropiado o ajustando los parámetros de costo.
AFAIK no hay forma de configurar una base de datos completa o un clúster como UNLOGGED. Sería interesante poder hacerlo. Considere preguntar en la lista de correo de PostgreSQL.
Ajuste del sistema operativo del host
También puede hacer algunos ajustes a nivel del sistema operativo. Lo principal que puede querer hacer es convencer al sistema operativo de que no vacíe las escrituras en el disco de forma agresiva, ya que realmente no le importa cuándo / si llegan al disco.
En Linux se puede controlar esto con el subsistema de memoria virtual 's dirty_*ajustes, como dirty_writeback_centisecs.
El único problema con el ajuste de la configuración de reescritura es demasiado flojo es que una descarga de algún otro programa puede hacer que también se vacíen todos los búferes acumulados de PostgreSQL, 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 algunas descargas 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.
Esta optimización realmente requiere jugar con la configuración para ver qué funciona mejor para su carga de trabajo.
En los núcleos más nuevos, es posible que desee asegurarse de que vm.zone_reclaim_modeesté configurado 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 gestión de PostgreSQL shared_buffers.
Consulta y ajuste de carga de trabajo
Estas son cosas que sí requieren cambios de código; Puede que no te convengan. Algunas son cosas que puede aplicar.
Si no está agrupando el trabajo en transacciones más grandes, comience. Muchas pequeñas transacciones son caras, por lo que debe agrupar las cosas siempre que sea posible y práctico. Si está utilizando la confirmación asincrónica, esto es menos importante, pero sigue siendo muy recomendable.
Siempre que sea posible, use 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 deslizar un montón de datos en una tabla temporal, manipulándola como sea necesario y luego haciendo una INSERT INTO ... SELECT ...copia para copiarla en la tabla final. Tenga en cuenta que las tablas temporales son por sesión; si su sesión finaliza o pierde su conexión, la tabla temporal desaparece y ninguna otra conexión puede ver el contenido de las tablas temporales de una sesión.
Si está usando PostgreSQL 9.1 o más reciente, puede usar UNLOGGEDtablas para datos que puede permitirse perder, como el estado de la sesión. Estos son visibles en diferentes sesiones y se conservan entre las conexiones. Se truncan si el servidor se cierra de manera sucia, 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 lo hagas DELETE FROM blah;. Usar en su TRUNCATE TABLE blah;lugar; es mucho más rápido cuando estás volcando todas las filas en una tabla. Trunca muchas tablas en una TRUNCATEllamada si puedes. Sin TRUNCATESembargo, hay una advertencia si estás haciendo muchas mesas pequeñas una y otra vez; ver: velocidad de truncamiento Postgresql
Si no tiene índices en claves foráneas, los DELETEs que involucren las claves primarias a las que hacen referencia esas claves foráneas serán horriblemente lentos. Asegúrese de crear dichos índices si alguna vez lo espera DELETEde las tablas referenciadas. No se requieren índices para TRUNCATE.
No cree índices que no necesita. Cada índice tiene un costo de mantenimiento. Intente utilizar un conjunto mínimo de índices y deje que los escaneos de índice de mapa de bits los combinen en lugar de mantener demasiados índices enormes y costosos de múltiples columnas. Cuando se requieren índices, primero intente llenar la tabla y luego cree índices al final.
Hardware
Tener suficiente RAM para contener toda la base de datos es una gran victoria si puede administrarlo.
Si no tiene suficiente RAM, cuanto más rápido sea el almacenamiento, mejor. Incluso un SSD barato hace una gran diferencia sobre el óxido giratorio. Sin embargo, no confíe en los SSD baratos para la producción, a menudo no son seguros y pueden comer sus 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.
Leyendo: