ajuste postgresql para grandes cantidades de ram


29

Tengo dos servidores idénticos (en términos de hardware), ambos son instalaciones estándar de Windows Server 2008 R2, con un software mínimo instalado (básicamente mi código y cosas necesarias como jvm, etc.).

En un servidor, estoy ejecutando sql server 2005, en el segundo servidor postgresql 9.1. La diferencia en el rendimiento b / n de estos 2 servidores es asombrosa, es tan mala en postgresql que lamento mi discurso inicial "usemos postgresql en lugar de pagar la licencia del servidor sql" a mi jefe. Estamos hablando de diferencias de 30 segundos frente a 15 minutos para el mismo comando, y no es solo este comando, es cualquier consulta o comando que le arroje. Ambos tienen casi los mismos datos (los registros se insertaron en un orden diferente), y ambas bases de datos tienen exactamente la misma estructura / índices, etc.

Pero espero que sea solo una cuestión de ajuste de rendimiento. La cuestión es que el servidor sql está utilizando prácticamente los 32 gigas de ram en el servidor, mientras que postgresl no está usando nada, definitivamente menos que un concierto, aunque en realidad no lo he descubierto con todo detalle.

¿Cómo consigo postgresql para usar más de 20 gigas de ram? Estos servidores se construyeron específicamente para estas cosas de la base de datos, por lo que, en mi opinión, se desperdicia cualquier ram que no esté en uso por la base de datos y los procesos de soporte.


44
¿Cambiaste algo a la afinación inicial? Paso 1: SET effective_cache_size=18G;(la configuración predeterminada es extremadamente baja) Por cierto: suponiendo que se trata de una máquina de 64 bits (sin PTE)

1
Realmente no nos das lo suficiente para ayudar mucho. Aparte de "Es lento", no sabemos mucho sobre su conjunto de datos, cómo está accediendo a él, qué tipos de consultas generalmente se ejecutan lentamente, lo que ya ha hecho para ajustar (y posiblemente ajustar) su servidor. Diablos, en una máquina Linux con muchos núcleos y canales de memoria, puede obtener un rendimiento desagradable mucho antes de instalar postgresql. ¿Estás vinculado a CPU o IO? ¿Qué configuraciones no predeterminadas tienes ya? ¿Qué tipo de consultas son lentas?
Scott Marlowe

2
Postgres no "usa ram" de la forma en que habla de él. Se basa en la memoria caché de la página del sistema de archivos del sistema operativo para la mayor parte de su almacenamiento en caché, por lo que cuando observa el uso de ram en un sistema que ejecuta postgres, generalmente ve muchos GB en uso por los buffers / caché del sistema operativo y los procesos backend individuales de postgres usando solo unos pocos para unas pocas decenas de MB cada una.
dbenhur 01 de

1
Vea este enlace: tekadempiere.blogspot.ae/2014/09/… Y encuentre sus valores conf basados ​​en recursos desde aquí: pgtune.leopard.in.ua
Sajeev

pregunta relacionada, tal vez de interés: stackoverflow.com/questions/47311485/…
mountainclimber

Respuestas:


41

Hay muchas constantes ajustables, inicializadas a través de postgres.conf. Los más importantes son:

  • max_connections: el número de sesiones concurrentes
  • work_mem : la cantidad máxima de memoria que se utilizará para resultados intermedios, como tablas hash, y para ordenar
  • shared_buffers La cantidad de memoria dedicada al espacio de búfer 'anclado'.
  • effective_cache_size la cantidad de memoria supuestamente utilizada por los búferes LRU del sistema operativo.
  • random_page_cost : una estimación del costo relativo de las búsquedas de disco.

max_connectionsno debe establecerse más de lo necesario, las conexiones cuestan recursos incluso cuando están inactivas; en la mayoría de los casos, una conexión pasaría más tiempo esperando adentro que esperando afuera. (al precio de la concurrencia) Una buena fórmula de regla general es "número de husillos + número de procesadores + X"

work_memes complicado: se puede aplicar a cada subconsulta, por lo que una consulta con 5 HASHJOINSpuede costar 5 * work_mem. Y para el peor de los casos, también debe pensar en varias sesiones que consuman esta cantidad (nuevamente una razón para mantenerse max_connectionsbajo).

shared_buffersestá (en mi humilde opinión) sobrevalorado. Normalmente se recomienda configurarlo en aproximadamente 1/4 ... 1/2 de toda la memoria "libre" disponible, pero tiendo a mantenerlo bajo y configurarlo effective_cache_sizeen toda la memoria "libre" disponible.

random_page_costes el costo de una búsqueda + lectura en el disco. Es relativo a sequential_disk_cost, que es 1. El valor predeterminado (4) para random_page_costse establece demasiado alto para las máquinas modernas y el almacenamiento en red, normalmente se puede reducir a entre 2 y 1.x. Para los discos SSD, incluso puede configurarlo en 1.0, ya que la búsqueda es casi gratis en SSD.


¡Excelente! Nunca vi la importancia de efectividad_caché_size, siempre engañado solo con shared_buffers. Esto realmente hizo una gran diferencia. Ejecuté pgtune también y recomendó 20 GB de 96 para usar para shard_buffers, pero 64 GB para efectividad_caché_size. ¡Gracias!

1
FWIW, revisé estas y otras configuraciones sugeridas en los documentos de Postgres e hice un análisis para nuestro servidor .
mlissner

Muchas gracias por la respuesta. ¿Puedo preguntar cuál es la recomendada work_memcuando el max_connectionsvalor predeterminado es 100 y la RAM del servidor es de 32 GB (servidor postgres dedicado)? Sabía que necesitaba ajustar esto por mí mismo basado en consultas diarias. Me pregunto si puede decirme un valor de "respuesta única" (o un valor de punto de partida). ¿50 MB es demasiado grande? Muchas gracias.
sgon00

Depende de la actividad concurrente típica en su máquina. 100 sesiones que quieran 50M (además de sus 10..20M) cada una podría encajar. O tal vez no. Para tener una impresión, controle vmstat o top. Además: depende de su consulta (y las demás). Solo mira los planes.
wildplasser

@wildplasser muchas gracias por la rápida respuesta. Encontré un sitio web interesante pgtune.leopard.in.ua . Creo que usaré 40 MB como punto de partida a partir de su sugerencia y ajuste basado en eso. Aclamaciones.
sgon00

20

Considere usar pgtune para ayudarlo a ajustar la configuración de PostgreSQL. De PgFoundry:

pgtune toma el postgresql.conf predeterminado de Wimpy y expande el servidor de la base de datos para que sea tan potente como el hardware en el que se está implementando

La configuración predeterminada de PostgreSQL es muy conservadora y esa herramienta está destinada a ayudar con esta situación exacta. La documentación es una lectura ligera y el uso de la herramienta es bastante sencillo.

Tenga en cuenta que no es necesario utilizar las sugerencias exactas de pgtune. Jugar con su configuración y observar los cambios resultantes en el archivo conf le dará una mejor comprensión de la configuración de PostgreSQL y cómo ajustarla manualmente.


8
La última actualización de pgtune fue en 2009, hace 5 años y sigue contando. Me pregunto si todavía es válido para la serie 9.1-9.2-9.3.
sorin

9
pgtune ya está disponible en línea
Alfabravo

3

Si cada consulta o comando se ejecuta lentamente, sospecho que:

  • se conecta a la base de datos para cada consulta que ejecuta;
  • ha configurado algún tipo de método de autenticación, que no funciona y detiene sus consultas hasta que este método de autenticación en particular se agote.

¿Podría decirnos cuánto tiempo lleva ejecutar una consulta select version()? Si debe ser instantáneo (0,16 ms en mi estación de trabajo).


2

Si CADA consulta es mucho más lenta, algo está terriblemente mal con el servidor o algo así. En mi experiencia, cada db tiene algunas cosas en las que es mejor que la otra, pero pgsql en cuanto al rendimiento está fácilmente en el mismo ámbito que el servidor mssql.

Entonces, ¿en qué sistema operativo está ejecutando pgsql? Que hardware ¿Qué configuraciones has cambiado ya? ¿Qué tan grande es su conjunto de datos? ¿Cuál es un ejemplo de una consulta deficiente y la salida de explicar analizar (Ejecute su consulta de esta manera:

explicar analizar seleccionar ... resto de la consulta aquí ...;

Publique el resultado en http://explain.depesz.com/ y publique el enlace aquí.


1
Sí, cada consulta / comando se ejecuta lentamente, y sí "algo" está terriblemente mal, de ahí mi pregunta. El problema es que mssql está haciendo un uso completo de la memoria RAM disponible en el servidor (almacenamiento en caché tan pesado) mientras que psql no. Agradezco los comentarios y consejos, pero debe haber perdido la mayor parte de mi pregunta y el asunto en sí ... Solo quiero saber cómo obtener psql para hacer uso de la memoria RAM disponible; Actualmente
estoy

1
Usar tu RAM NO es el problema. Postgresql se basa en el sistema operativo para realizar la mayor parte del almacenamiento en caché. Por lo tanto, NO NECESITA usar toda la RAM. Nuevamente, perdiste la mayor parte de mi punto. Nos estás dando muy poco para ayudarte. Conduzco 5000 grupos de TPS postgresql para vivir. Puedes seguir mi consejo o seguir pensando que sabes cómo funciona pgsql y discutir.
Scott Marlowe,

@ user85116, escuche a Scott, ya tenemos un flujo de trabajo con MySQL que depende de la latencia súper, por lo que actualmente MySQL está utilizando 64 GB de RAM para hacer esas consultas rápidamente, mientras que lo mismo se puede lograr en 2G Postgres con solo vistas materializadas. El almacenamiento en caché de toda la base de datos en la RAM no resolverá su problema, solo lo hace menos visible. Si tiene los mismos problemas en la estructura de base de datos, Postgres no lo solucionará ni intentará ocultarlo.
kworr
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.