Ajuste de Linux para mejorar el rendimiento de PostgreSQL. Iliá Kosmodemianski

Transcripción del informe de 2015 de Ilya Kosmodemyansky "Ajuste de Linux para mejorar el rendimiento de PostgreSQL"

Descargo de responsabilidad: Observo que este informe tiene fecha de noviembre de 2015; han pasado más de 4 años y ha pasado mucho tiempo. La versión 9.4 comentada en el informe ya no es compatible. En los últimos 4 años, ha habido 5 nuevos lanzamientos de PostgreSQL y 15 versiones del kernel de Linux. Si reescribe estos lugares, terminará con un informe diferente. Pero aquí hay un ajuste fundamental de Linux para PostgreSQL, que sigue siendo relevante hoy en día.

Mi nombre es Ilya Kosmodemyansky. Trabajo para la empresa PostgreSQL-Consulting. Y ahora hablaré un poco de qué hacer con Linux en relación a las bases de datos en general y PostgreSQL en particular, porque los principios son bastante similares.

¿Qué se discutirá? Si trabaja con PostgreSQL, entonces necesita ser administrador de UNIX hasta cierto punto. ¿Qué significa? Si comparamos Oracle y PostgreSQL, entonces en Oracle debe ser 80% administrador de base de datos DBA y 20% administrador de Linux.

PostgreSQL es un poco más difícil. Con PostgreSQL, necesitas tener una idea mucho mejor de cómo funciona Linux. Y al mismo tiempo, corre un poco detrás de la locomotora, porque últimamente todo se ha actualizado bastante bien. Y salen nuevos núcleos, aparecen nuevas funcionalidades, mejora el rendimiento, etc.

¿Por qué hablamos de Linux? No porque estemos en la conferencia de Linux Peter, sino porque en las condiciones modernas uno de los sistemas operativos más justificados para operar con bases de datos en general y con PostgreSQL en particular es Linux. Porque FreeBSD, lamentablemente, se está desarrollando en una dirección muy extraña. Y habrá problemas tanto con el rendimiento como con muchas otras cosas. El rendimiento de PostgreSQL en Windows es generalmente un tema duro aparte, que se basa en el hecho de que Windows no tiene una memoria compartida como UNIX, y PostgreSQL tiene que ver con este negocio, porque es un sistema multiproceso.

Y creo que los exóticos como Solaris interesan menos a todos, así que vamos.

Una distribución de Linux moderna tiene más de 1 opciones de syctl, dependiendo de cómo esté construido el kernel. Al mismo tiempo, si miramos diferentes tuercas, todavía puede haber muchas maneras de ajustar algo. Hay opciones de sistema de archivos sobre cómo montar. Si tiene preguntas sobre cómo comenzar: qué habilitar en el BIOS, cómo configurar el hardware, etc.

Este es un volumen muy grande, del que se puede hablar durante varios días, y no en un informe breve, pero ahora me centraré en cosas importantes, cómo evitar esos rastrillos que no le permitirán operar bien una base de datos en Linux si no los arreglas.. Y al mismo tiempo, un punto importante es que muchos parámetros predeterminados no están incluidos en la configuración correcta para la base de datos. Es decir, por defecto funcionará mal o no funcionará en absoluto.

¿Cuáles son los objetivos de ajuste tradicionales en Linux? Creo que como todos ustedes se ocupan de la administración de Linux, no es necesario explicar cuáles son los objetivos.

Puedes sintonizar:

• La CPU.
• Memoria.
• Almacenamiento.
• otro. Hablaremos de esto al final para tomar un refrigerio. Incluso, por ejemplo, ajustes como la política de ahorro de energía pueden afectar al rendimiento de una forma muy impredecible y poco agradable.

¿Cuáles son las características específicas de PostgreSQL y la base de datos en general? El problema es que no se puede modificar una tuerca en particular y ver que nuestro rendimiento ha mejorado mucho.

Sí, existen tales dispositivos, pero la base de datos es algo complicado. Ella interactúa con todos los recursos que tiene el servidor y prefiere interactuar al máximo. Si nos fijamos en las directrices actuales de Oracle sobre cómo utilizar un sistema operativo anfitrión, es como el chiste del astronauta mongol: alimenta al perro y no toques nada. Demos a la base de datos todos los recursos, la base de datos misma destruirá todo.

En principio, hasta cierto punto, la situación es exactamente la misma con PostgreSQL. La diferencia radica en el hecho de que la base tampoco puede tomar todos los recursos por sí misma, es decir, en algún lugar del nivel de Linux debes resolverlo todo por tu cuenta.

La idea principal no es elegir un solo objetivo y comenzar a ajustarlo, por ejemplo, memoria, CPU o algo así, sino analizar la carga de trabajo e intentar mejorar el rendimiento tanto como sea posible para que la carga que los buenos programadores crearon para nosotros, incluidos nuestros usuarios.

Aquí os dejo una imagen para explicar de qué se trata. Hay un búfer del sistema operativo Linux, hay memoria compartida y hay búferes compartidos de PostgreSQL. PostgreSQL, a diferencia de Oracle, funciona directamente solo a través del búfer del kernel, es decir, para que una página del disco ingrese a su memoria compartida, debe pasar por el búfer del kernel y regresar exactamente a la misma situación.

Los discos viven bajo este sistema. Lo dibujé como discos. De hecho, puede haber un controlador RAID, etc.

Y esta entrada-salida de una forma u otra ocurre a través de este caso.

PostgreSQL es una base de datos clásica. Está dentro de la página. Y toda la entrada y salida se produce con la ayuda de páginas. Levantamos bloques en la memoria por páginas. Y si no pasa nada, simplemente los leemos y luego, gradualmente, se hunden desde este caché, desde los búferes compartidos y regresan al disco.

Si reemplazamos algo en alguna parte, toda nuestra página se marca como sucia. Los marqué en azul aquí. Y esto significa que esta página debe estar sincronizada con el almacenamiento en bloque. Es decir, cuando lo ensuciamos, hicimos una entrada en WAL. Y en algún momento, se produjo un fenómeno llamado checkpoint. Y este registro registró información de que vino. Y esto significa que todas las páginas sucias que estaban aquí en ese momento en estos buffers compartidos se sincronizaron con el disco de almacenamiento usando fsync a través del buffer del kernel.

¿Para qué sirve? Si perdimos voltaje, entonces no llegamos a la situación de que se perdieran todos los datos. La memoria persistente, de la que todo el mundo nos habló, hasta ahora está en la teoría de las bases de datos: este es un futuro brillante por el que, por supuesto, nos esforzamos y nos gusta, pero hasta ahora todavía viven menos de 20 años. Y, por supuesto, todo esto hay que vigilarlo.

Y la tarea de maximizar el rendimiento es ajustar todas estas etapas para que todo vaya y venga rápidamente. La memoria compartida es básicamente una caché de páginas. En PostgreSQL, enviamos una solicitud de selección de algo, obtuvo estos datos del disco. Se metieron en buffers compartidos. En consecuencia, para que esto funcione mejor, debe haber mucha memoria.

Para que todo esto funcione bien y rápidamente, es necesario configurar correctamente el sistema operativo en todas las etapas. Y elige plancha equilibrada, porque si tienes un desequilibrio en algún lugar, entonces puedes ganar mucha memoria, pero te servirá a una velocidad insuficiente.

Repasemos cada uno de estos puntos.

Para que estas páginas avancen y retrocedan más rápido, debe lograr lo siguiente:

• Primero, necesitas trabajar más eficientemente con la memoria.
• En segundo lugar, esta transición debería ser más eficiente cuando las páginas de la memoria pasan al disco.
• Y en tercer lugar, debe haber buenos discos.

Si tiene 512 GB de RAM en el servidor y todo esto termina en un disco duro SATA sin caché, entonces todo el servidor de la base de datos se convierte no solo en una calabaza, sino en una calabaza con una interfaz SATA. Te toparás con él directamente. Y nada te salvará.

En cuanto al primer punto con la memoria, hay tres cosas que pueden complicarnos mucho la vida.

El primero es la NUMA. NUMA es algo que está hecho para mejorar el rendimiento. Dependiendo de la carga de trabajo, puedes optimizar diferentes cosas. Y en su nueva forma actual, no es muy bueno para aplicaciones como una base de datos que utiliza intensivamente buffers compartidos de caché de páginas.

En una palabra. ¿Cómo entender que algo anda mal con la NUMA? Tienes algún tipo de golpe desagradable, de repente alguna CPU se sobrecarga. Al mismo tiempo, analiza consultas en PostgreSQL y ve que no hay nada similar allí. Estas solicitudes no deberían consumir tanta CPU. Puedes atraparlo durante mucho tiempo. Es más fácil seguir los consejos correctos desde el principio sobre cómo configurar NUMA para PostgreSQL.

¿Qué pasa en realidad? NUMA significa Acceso a memoria no uniforme. ¿Cual es el punto? Tienes una CPU, al lado está su memoria local. Y estas interconexiones de memoria pueden extraer memoria de otras CPU.

Si tu corres numactl --hardware, entonces obtendrás una hoja tan grande. Entre otras cosas, habrá un campo de distancias. Habrá números: 10-20, algo así. Estos números no son más que el número de saltos para recoger esta memoria remota y usarla localmente. Básicamente una buena idea. Esto mejora bien el rendimiento en varias cargas de trabajo.

Ahora imagine que tiene una CPU que primero intenta usar su memoria local y luego intenta obtener otra memoria a través de la interconexión para algo. Y todo el caché de su página PostgreSQL llega a esta CPU; eso es todo, cuántos gigabytes hay. Siempre se obtiene el peor de los casos porque normalmente hay poca memoria en la CPU directamente en ese módulo. Y toda la memoria que se sirve pasa por estas interconexiones. Resulta lenta y tristemente. Y tienes un procesador que sirve a este nodo que está constantemente sobrecargado. Y el tiempo de acceso a esta memoria es malo, lento. Este es el tipo de situación que no desea si utiliza este caso para una base de datos.

Por tanto, una opción más correcta para la base de datos es que el sistema operativo Linux no sepa en absoluto lo que está pasando allí. Para que ella aborde la memoria como lo hace.

¿Porqué es eso? Parecería que debería ser al revés. Esto sucede por una simple razón: necesitamos mucha memoria para el caché de la página: decenas, cientos de gigabytes.

Y si asignamos todo esto y almacenamos en caché nuestros datos allí, entonces la ganancia del uso del caché será significativamente mayor que la ganancia de un acceso a la memoria tan astuto. Y de esta manera ganaremos incomparablemente en comparación con el hecho de que accederemos a la memoria de manera más eficiente usando NUMA.

Por lo tanto, hay dos enfoques en este momento, hasta que llegue un futuro brillante y la base de datos por sí misma no pueda determinar en qué CPU funciona y de dónde necesita extraer algo.

Por lo tanto, el enfoque correcto es desactivar NUMA por completo.por ejemplo, al reiniciar. En la mayoría de los casos, las ganancias están en tal orden que no hay ninguna duda sobre cuál es mejor.

Hay otra opción. Lo usamos con más frecuencia que el primero, porque cuando un cliente acude a nosotros en busca de soporte, reiniciar el servidor es todo un asunto para él. Tiene un negocio allí. Y experimentan problemas debido a la NUMA. Por lo tanto, intentamos desactivarlo de formas menos invasivas que reiniciar, pero aquí hay que tener cuidado de comprobar que esté desactivado. Porque, como muestra la experiencia, que deshabilitemos NUMA en el proceso principal de PostgreSQL, esto es bueno, pero no es en absoluto necesario que funcione. Necesitamos verificar y ver que ella realmente se apagó.

Hay una buena publicación de Robert Haas. Este es uno de los confirmadores de PostgreSQL. Uno de los desarrolladores clave de todos los menudillos de bajo nivel. Y si sigue los enlaces de esta publicación, describe varias historias coloridas sobre cómo la NUMA le hizo la vida difícil a la gente. Mire, estudie la lista de verificación del administrador del sistema sobre lo que se debe configurar en el servidor para que nuestra base de datos funcione bien. Estas configuraciones deben registrarse y verificarse, porque de lo contrario no serán muy buenas.

Llamo su atención sobre el hecho de que esto se aplica a todas las configuraciones de las que hablaré. Pero normalmente las bases de datos se ensamblan en modo maestro-esclavo para lograr tolerancia a fallas. No olvides hacer estos ajustes en el esclavo, porque un día tendrás un accidente y cambiarás al esclavo y éste se convertirá en el maestro.

En caso de emergencia, cuando todo está muy mal, tu teléfono suena constantemente y tu jefe viene corriendo con un gran garrote, no tendrás tiempo para pensar en comprobarlo. Y los resultados pueden ser muy desastrosos.

El siguiente momento son páginas enormes. Las páginas enormes son difíciles de probar por separado y esto no tiene sentido, aunque existen puntos de referencia que pueden hacerlo. Se buscan fácilmente en Google.

¿Cuál es el punto de? Tienes un servidor no muy caro que tiene mucha RAM, por ejemplo más de 30 GB. No estás utilizando páginas enormes. Esto significa que definitivamente tiene una sobrecarga en el uso de la memoria. Y esta sobrecarga está lejos de ser la más agradable.

¿Porqué es eso? ¿Y que esta pasando? El sistema operativo asigna memoria en pequeños fragmentos. Tan conveniente, tan históricamente. Y si entra en detalles, entonces el sistema operativo debe traducir direcciones virtuales en físicas. Y este proceso no es el más fácil, por lo que el sistema operativo almacena en caché el resultado de esta operación en el Translation Lookaside Buffer (TLB).

Y dado que TLB es un caché, en esta situación surgen todos los problemas inherentes al caché. En primer lugar, si tiene mucha RAM y está toda asignada en pequeños trozos, entonces este búfer se vuelve muy grande. Y si el caché es grande, será más lento buscarlo. La sobrecarga es saludable y ocupa espacio por sí sola, es decir, algo mal está consumiendo RAM. Esta vez.

Dos: cuanto más crece el caché en tal situación, más probable es que se produzcan errores de caché. Y la eficiencia de este caché cae rápidamente a medida que crece su tamaño. Entonces a los sistemas operativos se les ocurrió un enfoque simple. Linux lo ha estado usando durante mucho tiempo. Apareció en FreeBSD no hace mucho. Pero estamos hablando de Linux. Estas son páginas enormes.

Y aquí cabe señalar que las páginas enormes, como idea, fueron inicialmente impulsadas por comunidades entre las que se encontraban Oracle e IBM, es decir, los fabricantes de bases de datos pensaron mucho en el hecho de que esto sería útil, incluso para las bases de datos.

¿Y cómo hacerse amigo de PostgreSQL? Primero, se deben habilitar páginas grandes en el kernel de Linux.

En segundo lugar, deben especificarse explícitamente mediante el parámetro sysctl: cuántos hay. Los números aquí son de algún servidor antiguo. Puedes calcular aproximadamente cuántos buffers compartidos tienes para que quepan páginas enormes allí.

Y si tiene todo el servidor dedicado a PostgreSQL, entonces un buen punto de partida es asignar el 25% de la RAM para los buffers compartidos, o el 75% si está seguro de que su base de datos definitivamente cabe en ese 75%. Punto de partida primero. Y considere, si tiene 256 GB de RAM, entonces, en consecuencia, tendrá 64 GB de buffers fragmentados. Calcule aproximadamente con algo de margen: en qué debería establecer esta cifra.

Antes de la versión 9.2 (si no me equivoco, desde la versión 8.2), era posible hacerse amigo de páginas enormes de PostgreSQL utilizando una biblioteca de terceros. Y esto siempre debe hacerse. Primero, necesita que el kernel pueda asignar páginas grandes correctamente. Y, segundo, para que la aplicación que trabaja con ellos pueda utilizarlos. Simplemente no se usará de esa manera. Dado que PostgreSQL asignó memoria en el estilo del sistema 5, esto se podría hacer usando libhugetlbfs: este es el nombre completo de la biblioteca.

9.3 mejoró el rendimiento de la memoria PostgreSQL y eliminó el método de asignación de memoria del sistema 5. Todos estaban muy contentos porque, de lo contrario, intentas ejecutar dos instancias de PostgreSQL en la misma máquina y dice que no tengo suficiente memoria compartida. Y él dice que necesitas arreglar syctl. Y existe tal sysctl que aún es necesario reiniciar, etc. En general, todos quedaron encantados. Pero la asignación de memoria mmap se rompió al usar páginas enormes. La mayoría de nuestros clientes utilizan grandes buffers compartidos. Y recomendamos encarecidamente no cambiar a 9.3, porque allí los gastos generales comenzaron a calcularse en buenos porcentajes.

Pero, por otro lado, la comunidad llamó la atención sobre este problema y en 9.4 reelaboraron muy bien este evento. Y en 9.4, apareció un parámetro en postgresql.conf, en el que puedes activar o desactivar try.

Probar es la opción más segura. Cuando se inicia PostgreSQL, cuando asigna memoria compartida, intenta tomar esta memoria de páginas enormes. Y si no funciona, vuelve a la selección habitual. Y si tienes FreeBSD o Solaris, puedes intentarlo, siempre es seguro.

Si está activado, simplemente no se inicia si no se puede seleccionar entre páginas grandes. Aquí ya, para quién y qué es más lindo. Pero si lo intentas, comprueba que realmente tienes resaltado lo que necesitas, porque hay muchos espacios para un error. Actualmente, esta funcionalidad sólo funciona en Linux.

Una pequeña nota más antes de continuar. Las páginas enormes y transparentes aún no tratan sobre PostgreSQL. No puede usarlos normalmente. Y con páginas enormes transparentes para tal carga de trabajo, cuando se necesita una gran cantidad de memoria compartida, las ventajas solo vienen con volúmenes muy grandes. Si tiene terabytes de memoria, esto puede influir. Si hablamos de aplicaciones más cotidianas, cuando tienes 32, 64, 128, 256 GB de memoria en la máquina, entonces las páginas enormes habituales están bien y simplemente desactivamos Transparente.

Y lo último de la memoria no está directamente relacionado con el fruto, puede arruinar mucho la vida. Todo el rendimiento se verá muy afectado por el hecho de que el servidor cambia constantemente.

Y será muy desagradable en algunos momentos. Y el principal problema es que en los kernels modernos el comportamiento es ligeramente diferente al de los kernels de Linux más antiguos. Y esto, que es bastante desagradable de pisar, porque cuando hablamos de algún trabajo con swap, termina con la llegada inoportuna del OOM-killer. Y el asesino de OOM, que no llegó a tiempo y descartó a PostgreSQL, es desagradable. Todo el mundo lo sabrá, es decir, hasta el último usuario.

¿Lo que está sucediendo? Tienes una gran cantidad de RAM allí, todo funciona bien. Pero por alguna razón el servidor se bloquea en el intercambio y se ralentiza debido a esto. Parecería que hay mucha memoria, pero sucede.

Anteriormente, recomendábamos que vm.swappiness se estableciera en cero, es decir, deshabilitar el intercambio. Antes parecía que 32 GB de RAM y los correspondientes buffers compartidos era una cantidad enorme. El objetivo principal del swap es tener un lugar donde tirar una costra si nos caemos. Y no se ha hecho muy bien. ¿Y luego qué harás con esta corteza? Esta ya es una tarea de este tipo cuando no está muy claro por qué se necesita un intercambio, especialmente de tal tamaño.

Pero en las versiones más modernas, es decir, en las terceras versiones del kernel, el comportamiento ha cambiado. Y si configura el intercambio en cero, es decir, lo apaga, tarde o temprano, incluso cuando quede algo de RAM, un asesino de OOM vendrá a usted para matar a los consumidores más intensivos. Porque considerará que con tal carga de trabajo todavía nos queda un poquito y saltaremos, es decir, no mataremos el proceso del sistema, sino mataremos algo menos importante. Este menos importante será el gran consumidor de memoria compartida, es decir, el administrador de correo. Y después de eso será bueno si no es necesario restaurar la base.

Por lo tanto, ahora el valor predeterminado, hasta donde recuerdo, es la mayoría de las distribuciones alrededor de 6, es decir, en qué punto comenzar a usar el intercambio, dependiendo de cuánta memoria quede. Ahora recomendamos configurar vm.swappiness = 1, porque prácticamente lo apaga, pero no produce efectos como los de un OOM-killer inesperado que vino y acabó con todo.

¿Que sigue? Cuando hablamos del rendimiento de las bases de datos y poco a poco, somos como discos, todo el mundo empieza a agarrarse la cabeza. Porque la verdad de que el disco es lento y la memoria es rápida nos resulta familiar a todos desde la infancia. Y todo el mundo sabe que habrá problemas de rendimiento del disco en la base de datos.

El principal problema de rendimiento de PostgreSQL con los picos de los puntos de control no se debe a que el disco sea lento. Es más probable que esto se deba al hecho de que la memoria y el ancho de banda del disco no están equilibrados. Sin embargo, es posible que no estén equilibrados en diferentes lugares. PostgreSQL no está configurado, el sistema operativo no está configurado, el hardware no está configurado y el hardware es incorrecto. Y este problema no ocurre sólo si todo va como debería, es decir, no hay carga o la configuración y el hardware están bien elegidos.

¿Qué es y cómo se ve? Por lo general, las personas que trabajan con PostgreSQL se han involucrado en este negocio más de una vez. Lo explicaré. Como dije, PostgreSQL periódicamente realiza puntos de control para volcar páginas sucias en la memoria compartida al disco. Si tenemos una gran cantidad de memoria compartida, entonces el punto de control comienza a afectar intensamente al disco, porque fsync vuelca estas páginas. Llega al búfer del kernel y se escribe en el disco mediante fsync. Y si el volumen de este caso es grande, entonces podemos observar un efecto desagradable, es decir, una utilización muy grande de los discos.

Aquí tengo dos fotos. Ahora explicaré qué es. Estos son dos gráficos correlacionados en el tiempo. El primer gráfico es la utilización del disco. Aquí alcanza casi el 90% en este momento. Si tiene una base de datos con discos físicos, con un controlador RAID con una utilización inferior al 90 %, entonces esta es una mala noticia. Esto significa que vendrán un poco más y 100 y la entrada/salida se detendrá.

Si tiene una matriz de discos, la historia es ligeramente diferente. Ahí depende de cómo esté configurado, qué tipo de array, etc.

Y en paralelo se configura aquí un gráfico desde la vista interna de postgres, que cuenta cómo se produce el punto de control. Y el color verde aquí muestra cuántos buffers de estas páginas sucias llegaron en ese momento a este punto de control para la sincronización. Y esto es lo principal que hay que saber aquí. Vemos que tenemos muchas páginas aquí y en algún momento nos topamos con una tarifa, es decir, escribimos y escribimos, aquí el sistema de disco claramente está muy ocupado. Y nuestro punto de control tiene un efecto muy fuerte en el disco. Idealmente, la situación debería parecerse más a esto, es decir, que aquí tuviéramos menos antecedentes. Y podemos arreglarlo con ajustes para que siga así. Es decir, el reciclaje es pequeño, pero en alguna parte escribimos algo aquí.

¿Qué hay que hacer para superar este problema? Si detuvo IO en la base de datos, esto significa que todos los usuarios que vinieron a ejecutar sus solicitudes estarán esperando.

Si lo miras desde el punto de vista de Linux, si tomas un buen hardware, lo configuras correctamente, configuras PostgreSQL normalmente para que estos puntos de control sean menos frecuentes, los distribuyes en el tiempo entre sí, luego ingresas a los parámetros predeterminados de Debian. . Para la mayoría de las distribuciones de Linux, esta es la imagen: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

¿Qué significa? Desde el kernel 2.6, ha aparecido un demonio. Pdglush, dependiendo de quién usa qué, que se ocupa del fondo, eliminando páginas sucias del búfer del kernel y eliminando páginas sucias cuando es necesario, pase lo que pase, cuando el lanzamiento de fondo no ayuda.

¿Cuándo llegan los antecedentes? Cuando el 10% de la RAM total que hay en el servidor está ocupada por páginas sucias en el búfer del kernel, se llama a una función especial de trampa en segundo plano. ¿Por qué tiene antecedentes? Toma como parámetro cuántas páginas cancelar. Y, digamos, cancela N páginas. Y por un rato, esta cosa se queda dormida. Y luego regresa y escribe algunas páginas más.

Esta es una historia extremadamente simple. Aquí la tarea es como en una piscina, cuando se vierte por una tubería, se vierte por otra. Llegó nuestro punto de control y, si envió algunas páginas sucias para descartar, gradualmente desde el búfer del núcleo pgflush todo esto se resolverá perfectamente.

Si estas páginas sucias continúan acumulándose, se acumulan hasta un 20%, después de eso la prioridad del sistema operativo es escribir todo en el disco, porque se cortará la energía y todo irá mal para nosotros. Perderemos estos datos, por ejemplo.

¿Cuál es el truco? El truco es que estos parámetros en el mundo moderno del 20 al 10% de toda la RAM que hay en la máquina, son absolutamente monstruosos en términos del rendimiento de cualquier sistema de disco que tengas.

Imagina que tienes 128 GB de RAM. 12,8 GB llegan a su sistema de discos. Y no importa qué caché tengas allí, no importa qué matriz tengas allí, no resistirán tanto.

Por lo tanto, recomendamos que estos números se ajusten inmediatamente según las capacidades de su controlador RAID. Inmediatamente recomendé aquí un controlador que tenga 512 MB de caché.

Todo se considera muy simple. Puedes poner vm.dirty_background en bytes. Y estas configuraciones anulan las dos anteriores. O la relación es la predeterminada, o los que tienen bytes están activados, entonces funcionarán los que tienen bytes. Pero como soy consultor DBA y trabajo con diferentes clientes, trato de poner pajitas y por lo tanto, si en bytes, entonces en bytes. Nadie dio ninguna garantía de que un buen administrador no agregaría memoria al servidor, no lo reiniciaría y la cifra seguiría siendo la misma. Simplemente calcula estos números para que todo encaje allí con garantía.

¿Qué pasa si no encajas? He escrito que detiene efectivamente cualquier enrojecimiento, pero en realidad es una figura retórica. El sistema operativo tiene un gran problema: tiene muchas páginas sucias, por lo que la IO que generan sus clientes se detiene efectivamente, es decir, la aplicación vino a enviar una consulta SQL a la base de datos, está esperando. Cualquier E/S tiene la prioridad más baja, porque la base está ocupada por el punto de control. Y cuando termina es completamente incomprensible. Y cuando haya alcanzado el vaciado sin fondo, significa que todo su IO está ocupado por él. Y hasta que termine, no harás nada.

Hay dos puntos más importantes que están fuera del alcance de este informe. Estas configuraciones deben coincidir con las configuraciones en postgresql.conf, es decir, la configuración de los puntos de control. Y su sistema de disco debe estar configurado adecuadamente. Si tiene un caché en el RAID, entonces debe tener una batería. La gente compra RAID con buena caché sin batería. Si tiene un SSD en RAID, entonces deben ser de servidor, debe haber condensadores. Aquí está la lista de verificación ampliada. En este enlace está mi informe sobre cómo configurar el rendimiento del disco en PostgreSQL. Todas esas listas de verificación están ahí.

¿Qué más puede hacer la vida muy difícil? Éstas son dos opciones. Son relativamente nuevos. Por defecto, se pueden incluir en diferentes aplicaciones. Y también pueden complicar la vida si se encienden incorrectamente.

Hay dos piezas relativamente nuevas. Ya han aparecido en los terceros núcleos. Estos son sched_migration_cost en nanosegundos y sched_autogroup_enabled, que es uno por defecto.

¿Y cómo estropean la vida? ¿Qué es el costo_sched_migration_cost? El programador de Linux puede migrar un proceso de una CPU a otra. Y para PostgreSQL, que ejecuta consultas, migrar a otra CPU es completamente incomprensible por qué. Desde el punto de vista del sistema operativo, cuando cambias de ventana entre openoffice y terminal, esto puede estar bien, pero para la base de datos, es muy malo. Por lo tanto, una política razonable es establecer el costo_migración en algún valor grande, al menos unos pocos miles de nanosegundos.

¿Qué significará esto para el planificador? Se supondrá que durante este tiempo este proceso todavía está caliente. Es decir, si tiene algún tipo de transacción larga haciendo algo durante mucho tiempo, el programador lo entenderá. Supondrá que hasta que pase este tiempo de espera, no será necesario migrar este proceso a ninguna parte. Si al mismo tiempo el proceso hace algo, entonces no se migrará a ninguna parte, finalizará tranquilamente en la CPU que se le asignó. Y el resultado es excelente.

El segundo punto es el autogrupo. Existe una buena idea para cargas de trabajo específicas que no están relacionadas con bases de datos modernas: agrupar procesos según el terminal virtual desde el que se inician. Es conveniente para algunas tareas. En la práctica, PostgreSQL es un sistema multiproceso previo a la bifurcación que se ejecuta desde una única terminal. Tiene un escritor de bloqueo, un punto de control y todas las solicitudes de sus clientes están agrupadas en un programador, por CPU. Y esperarán juntos allí cuando esté libre, para interferir entre sí y mantenerlo ocupado por más tiempo. Esta es una historia que es completamente innecesaria en el caso de tal carga y, por lo tanto, debe desactivarse.

Mi colega Alexey Lesovsky hizo pruebas con un pgbench simple, donde aumentó el costo de migración en un orden de magnitud y desactivó el grupo automático. La diferencia en una pieza de hierro defectuosa resultó ser de casi el 10%.. Hay una discusión en la lista de correo de Postgres donde las personas informan resultados como cambios similares en la velocidad de consulta. influenciado 50%. Hay bastantes historias de este tipo.

Y por último, sobre la política de ahorro de energía. Es bueno que ahora se pueda usar Linux en una computadora portátil. Y supuestamente consumirá bien la batería. Pero de repente resulta que esto también puede suceder en el servidor.

Además, si alquila servidores de algún proveedor de alojamiento, a los "buenos" proveedores de alojamiento no les importa que usted tenga un mejor rendimiento. Su tarea es asegurarse de que su hierro se utilice de la manera más eficiente posible. Por lo tanto, de forma predeterminada, pueden activar el modo de ahorro de energía de la computadora portátil en el sistema operativo.

Si está utilizando esto en un servidor de base de datos muy cargado, entonces su elección es acpi_cpufreq + permormance. Incluso con el servicio bajo demanda, ya habrá problemas.

Intel_pstate es un controlador ligeramente diferente. Y ahora se da preferencia a éste, que a uno posterior y que funcione mejor.

Y, en consecuencia, el gobernador es sólo desempeño. Ondemand, powersave y todo lo demás: esto no se trata de usted.

Los resultados del análisis explicativo de PostgreSQL pueden diferir en varios órdenes de magnitud si habilita el ahorro de energía, porque en la práctica tendrá una pérdida de CPU en la base de datos de una manera completamente impredecible.

Estas cosas se pueden habilitar de forma predeterminada. Fíjate bien para ver si lo tienen habilitado por defecto. Esto puede ser un problema realmente grande.

Y al final, quería agradecer a los muchachos de nuestro equipo de DBA de PosgreSQL-Consulting, a saber, Max Boguk y Alexey Lesovsky, quienes todos los días llenan los obstáculos en este negocio. Y para nuestros clientes, intentamos hacer lo mejor, para que todo funcione para ellos. Es como con las instrucciones de seguridad de la aviación. Todo aquí está escrito con sangre. Cada una de estas nueces se descubre en el proceso de algún tipo de problema. Estoy feliz de compartirlos contigo.

Preguntas:

¡Gracias! Si, por ejemplo, una empresa quiere ahorrar dinero y alojar la base de datos y la lógica de la aplicación en el mismo servidor, o si la empresa sigue la tendencia de moda de las arquitecturas de microservicios en las que PostgreSQL se ejecuta en un contenedor. ¿Cuál es el punto de? Sysctl afecta globalmente a todo el kernel. No he oído que los sysctls estén de alguna manera virtualizados para que funcionen por separado en el contenedor. Sólo existe cgroup y sólo una parte de él tiene el control. ¿Cómo puedes vivir con esto? ¿O si desea rendimiento, ejecutar PostgreSQL en un servidor de hierro independiente y ajustarlo?

Hemos respondido a su pregunta de aproximadamente tres maneras. Si no estamos hablando de un servidor de hierro que se pueda configurar, etc., entonces relájate, todo funcionará bien sin estas configuraciones. Si tiene tal carga que necesita realizar estas configuraciones, llegará al servidor de hierro antes que estas configuraciones.

¿Cuál es el problema? Si se trata de una máquina virtual, lo más probable es que tenga muchos problemas, por ejemplo, con el hecho de que la mayoría de las máquinas virtuales tienen una latencia de disco bastante inconsistente. Incluso si el rendimiento del disco es bueno, entonces una sola transacción de E/S fallida que no afecte en gran medida el rendimiento promedio que ocurrió en el momento del punto de control o en el momento de escribir en WAL, entonces la base de datos sufrirá mucho por esto. Y lo notarás antes de encontrarte con estos problemas.

Si tienes NGINX en el mismo servidor, también tendrás el mismo problema. Luchará por la memoria compartida. Y no llegarás a los problemas que se describen aquí.

Pero, por otro lado, algunos de estos parámetros seguirán siendo relevantes para usted. Por ejemplo, con sysctl, configure dirty_ratio para que no sea tan loco; en cualquier caso, esto ayudará. De una forma u otra, tendrás interacción con el disco. Y estará mal. Este es generalmente el valor predeterminado de los parámetros que mostré. Y en cualquier caso, es mejor cambiarlos.

Y con la NUMA puede haber problemas. VmWare, por ejemplo, funciona bien con NUMA con exactamente la configuración opuesta. Y aquí tienes que elegir: un servidor de hierro o uno que no sea de hierro.

Tengo una pregunta relacionada con Amazon AWS. Tienen imágenes preconfiguradas. Uno de ellos se llama Amazon RDS. ¿Existe alguna configuración personalizada para su sistema operativo?

Hay configuraciones, pero son configuraciones diferentes. Aquí configuramos el sistema operativo en términos de cómo la base de datos utilizará este negocio. Y hay parámetros que determinan hacia dónde debemos ir ahora, tal configuración. Es decir, necesitamos tantos recursos que los consumiremos ahora. Después de eso, Amazon RDS fija estos recursos y el rendimiento cae allí. Hay historias separadas sobre cómo las personas comienzan a tener química con este asunto. A veces incluso con bastante éxito. Pero no tiene nada que ver con la configuración del sistema operativo. Es como hackear la nube. Es una historia diferente.

¿Por qué las páginas enormes transparentes no tienen ningún efecto en comparación con el TLB enorme?

No des. Esto se puede explicar de muchas maneras. Pero en realidad simplemente no lo dan. ¿Cuál es la historia de PostgreSQL? Al inicio, asigna una gran cantidad de memoria compartida. Si son transparentes o no al mismo tiempo, no importa en absoluto. El hecho de que destaquen al principio lo explica todo. Y si hay mucha memoria y necesita reconstruir el segmento de memoria compartida, entonces las páginas transparentes enormes serán relevantes. En PostgreSQL, simplemente se resalta al principio con una pieza enorme y listo, y luego no sucede nada especial allí. Por supuesto, puede usarlo, pero existe la posibilidad de que se produzca una interrupción de la memoria compartida cuando reasigna algo. PostgreSQL no sabe nada de esto.

Fuente: habr.com