Slow Query Questions/es

Guía para Consultas Lentas

En una semana cualquiera, aproximadamente el 50% de las preguntas en el canal #postgresql de IRC y el 75% en pgsql-performance son solicitudes de ayuda con una consulta lenta. Sin embargo, es raro que el autor de la pregunta envíe información completa acerca de la consulta lenta, frustrando tanto al autor de la pregunta así como a los que tratan de ayudarlo.

Por lo tanto, antes de enviar "Mi consulta es lenta", por favor obtenga la información y siga las recomendaciones que se listan a continuación. Examine y publique, además, la información relevante de Guide to reporting problems.

Por favor envíe las preguntas relacionadas con el rendimiento a la lista de correo pgsql-performance después de leer los recursos disponibles en la categoría de rendimiento de la wiki, reunir la información pertinente (ver abajo) y después de pensar en el problema. Antes de pinchar "Enviar", lea su mensaje, intentando pensar como alguien que no sabe nada acerca de su configuración o aplicación, y verifique si su pregunta tiene sentido. Esto le ahorrará varias respuestas del tipo "no explica <tal cosa>" o "¿qué quiere decir con <tal cosa>?" antes de que alguien tenga suficiente información para ayudarle – poner un poco de su esfuerzo le permitirá obtener mejores respuestas, más rápido.

La información que usted necesita enviar

(Nota: publique esto en un sitio como [pgsql.privatepaste.com] y no directamente en el canal de IRC, si usted está pidiendo ayuda por IRC)

• Tabla y esquema de índice: Publicar las definiciones de todas las tablas y los índices de referencia en la consulta. Si la consulta toca vista o funciones, vamos a necesitar esas definiciones también.

• Metadatos de las tablas: además de la definición de las tablas, por favor publicar el número aproximado de filas de la tabla (s), además de cualquier cosa inusual en ella, como:
  • contiene objetos grandes (large objects)
  • tiene una gran proporción de valores nulos en varias columnas
  • recibe un gran número de UPDATEs o DELETEs con regularidad
  • está creciendo rápidamente
  • tiene muchos índices
  • usa triggers que pueden estar llamando otras funciones de la BD, o llama directamente a otras funciones

• EXPLAIN ANALYZE, no sólo EXPLAIN: EXPLAIN ANALYZE nos dice cómo la consulta se ha ejecutado en realidad, no sólo la forma en que se había previsto. Esta información es esencial en descubrir cómo el planificador utilizó un plan ineficiente, en lugar de cualquier otro. Si no se puede ejecutar un EXPLAIN ANALYZE porque nunca la consulta completa, dígalo. Aún mejor, pegar el resultado del EXPLAIN ANALYZE en explain.depesz.com y publique el enlace resultante. Nos encanta esto, porque hace los planes mucho más fácil de leer y estudiar.

• Versión PostgreSQL: por favor proporcione la versión exacta del servidor que está utilizando (SELECT version () es una manera fácil de conseguirlo). El comportamiento del planificador cambia en cada versión, así que es importante.

• Historia: fue esta consulta siempre lenta, o se ha hecho más lentamente con el tiempo? Si el plan de ejecución de la consulta que utilizó es diferente, ¿no tiene copias de los planes de consulta? ¿Ha cambiado algo en su base de datos otra acumulación de datos?

• Hardware: por favor enviar la información esencial sobre su plataforma de hardware. Si algún elemento de hardware es inusual, por favor incluya información detallada sobre el. Vea en Guide to reporting problems qué tipo de información sobre el hardware es útil.

• Configuración de Mantenimiento: ¿estás corriendo autovacuum? Si es así, ¿con qué parámetros? Si no, ¿estás haciendo VACUUM y/o ANALYZE? ¿Con qué frecuencia?

• Configuración del WAL: (para consultas que hacen escrituras) se ha cambiado la WAL a un disco diferente? ¿Ha cambiado la configuración?

• Configuración GUC: ¿qué configuración de base de datos de configuración ha cambiado? ¿Cuáles son sus valores? (Estas son cosas como "work_mem", "enable_seq_scan", etc.) Vea Server Configuration para una consulta útil que muestra los parámetros que fueron cambiados de sus valores por omisión, en una forma más fácil de leer que publicar extractos de su postgresql.conf.

Cosas para probar antes de escribir

Usted se ahorrará mucho tiempo si intenta las siguientes cosas antes de escribir su pregunta:

• Leer Using EXPLAIN si no lo ha hecho aún.
• ANALYZE a su base de datos para actualizar las estadísticas de la consulta.
• VACUUM a su base de datos para purgar si no está ya en ejecución Autovacuum.
• Compruebe las configuración principales de GUC para asegurarse de que se ajustan a los valores razonables (vea Tuning Your PostgreSQL Server para pistas adicionales):
  • shared_buffers debe ser de 10% a 25% de RAM disponible
  • effective_cache_size debe ser de 75% de RAM disponible
• Prueba cambiando Work_mem: aumentar la cantidad hasta 8MB, 32MB, 256MB, 1GB. ¿Hay alguna diferencia?
• Para las consultas de Insert/Update/Delete, también deberías probar la configuración que tiene su WAL:
  • Mueva pg_xlog a ​​un recurso de disco separado, si es posible
  • Aumentar checkpoint_segments a 16 o más (suponiendo que tiene espacio en disco)
  • Aumentar wal_buffers a 16MB
• Pruebe sus dispositivos de I/O: pruebe correr dd, bonnie++ u otras pruebas de velocidad de la unidad para ver si su problema de rendimiento no es simplemente basado en hardware. Por ejemplo, una configuración RAID-5 no tendrá inserciones y actualizaciones rápidas sin importar cómo se juega con sus consultas.