As\u00ed que el enfoque correcto es desactivar NUMA por completo.<\/strong>, por ejemplo, al reiniciar. En la mayor\u00eda de los casos, las ganancias son tan significativas que no surge la pregunta de cu\u00e1l es la mejor opci\u00f3n. <\/p>\n<\/p>\n
Hay otra opci\u00f3n. La utilizamos m\u00e1s a menudo que la primera, porque cuando un cliente llega a nosotros en soporte, reiniciar el servidor es un gran asunto para \u00e9l. Su negocio est\u00e1 en funcionamiento. Y experimentan problemas debido a NUMA. Por eso intentamos desactivarlo de maneras menos invasivas que reiniciar, pero aqu\u00ed hay que tener cuidado, verificar que realmente se haya desactivado. Porque, como muestra la experiencia, desactivar NUMA para el proceso padre de PostgreSQL es bueno, pero no es necesariamente que eso funcione. Hay que verificar y asegurarse de que realmente se haya desactivado. <\/p>\n
<\/p>\n
Hay un buen post de Robert Haas. Es uno de los committers de PostgreSQL. Uno de los desarrolladores clave de todas las entra\u00f1as de bajo nivel. Y si sigues los enlaces de este post, encontrar\u00e1s varias historias coloridas sobre c\u00f3mo el NUMA complic\u00f3 la vida de las personas. Mira, estudia la lista de verificaci\u00f3n del administrador del sistema sobre lo que se debe configurar en el servidor para que nuestra base de datos funcione bien. Estas configuraciones deben ser registradas y verificadas, porque de lo contrario no ir\u00e1 muy bien. <\/p>\n
<\/p>\n
Quiero se\u00f1alar que esto se aplica a todas las configuraciones de las que voy a hablar. Pero com\u00fanmente, las bases de datos se configuran en modo master-slave para la redundancia. No olvides realizar estos ajustes en el slave, porque en un momento dado tendr\u00e1s una falla, y cambiar\u00e1s al slave, que se convertir\u00e1 en el master. <\/p>\n
<\/p>\n
En una situaci\u00f3n de emergencia, cuando todo est\u00e1 muy mal, tu tel\u00e9fono sonar\u00e1 constantemente y tu jefe aparecer\u00e1 con un garrote grande; no tendr\u00e1s tiempo para pensar en verificar. Y los resultados pueden ser bastante desastrosos.<\/p>\n
<\/p>\n
<\/p>\n
El siguiente punto es las huge pages. Es complicado probar las huge pages por separado, y tampoco tiene sentido hacerlo, aunque hay benchmarks que pueden hacerlo. Se encuentran f\u00e1cilmente en Google. <\/p>\n
<\/p>\n
\u00bfCu\u00e1l es el sentido? Tienes un servidor no muy caro, con mucha memoria RAM, por ejemplo, m\u00e1s de 30 GB. No utilizas huge pages. Esto significa que definitivamente hay sobrecarga en el uso de la memoria. Y esa sobrecarga no es nada agradable. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfPor qu\u00e9 es as\u00ed? \u00bfY qu\u00e9 est\u00e1 sucediendo? El sistema operativo asigna memoria en peque\u00f1os trozos. Es conveniente, as\u00ed se ha hecho hist\u00f3ricamente. Y si nos adentramos en los detalles, el sistema operativo debe traducir direcciones virtuales a f\u00edsicas. Y este proceso no es el m\u00e1s sencillo, por lo que el sistema operativo almacena el resultado de esta operaci\u00f3n en el Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
Y dado que el TLB es una cach\u00e9, en esta situaci\u00f3n surgen todos los problemas inherentes a las cach\u00e9s. En primer lugar, si tienes mucha memoria RAM y toda ella est\u00e1 asignada en peque\u00f1os trozos, entonces este b\u00fafer se vuelve muy grande. Y si la cach\u00e9 es grande, buscar a trav\u00e9s de ella es m\u00e1s lento. La sobrecarga es significativa y consume espacio, es decir, la memoria RAM est\u00e1 ocupada por algo que no es correcto. Eso es uno. <\/p>\n
<\/p>\n
Cuanto m\u00e1s crece la cach\u00e9 en esta situaci\u00f3n, mayor es la probabilidad de que tenga fallos de cach\u00e9. La eficiencia de esta cach\u00e9 cae r\u00e1pidamente a medida que aumenta su tama\u00f1o. Por ello, en los sistemas operativos se ide\u00f3 un enfoque simple. En Linux se ha utilizado desde hace tiempo. En FreeBSD, esto apareci\u00f3 no hace mucho. Pero estamos hablando de Linux. Se trata de huge pages.<\/p>\n
<\/p>\n
Es importante se\u00f1alar que la idea de huge pages fue impulsada inicialmente por comunidades que inclu\u00edan a Oracle e IBM, es decir, los fabricantes de bases de datos pensaron firmemente que esto ser\u00eda \u00fatil, incluso para bases de datos. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfY c\u00f3mo se integra esto con PostgreSQL? Primero, el n\u00facleo de Linux debe tener habilitadas las huge pages.<\/p>\n
<\/p>\n
En segundo lugar, deben indicarse expl\u00edcitamente mediante el par\u00e1metro sysctl \u2013 cu\u00e1ntas hay. Las cifras aqu\u00ed provienen de alg\u00fan viejo servidor. Puede calcular cu\u00e1ntos buffers compartidos tiene, para que las huge pages quepan dentro. <\/p>\n
<\/p>\n
Y si tiene todo el servidor dedicado a PostgreSQL, un buen punto de partida es asignar el 25 % de la memoria RAM a los buffers compartidos, o el 75 %, si est\u00e1 seguro de que su base de datos puede caber en esos 75 %. Este es el primer punto de partida. Y calcule, si tiene 256 GB de memoria RAM, entonces, por lo tanto, tendr\u00e1 64 GB de buffers compartidos. Calcule con un margen de seguridad \u2013 en qu\u00e9 debe estar establecido este n\u00famero.<\/p>\n
<\/p>\n
Hasta la versi\u00f3n 9.2 (si no me equivoco, desde la versi\u00f3n 8.2) era posible integrar PostgreSQL con huge pages mediante una biblioteca externa. Y esto siempre debe hacerse. Primero, necesita que el n\u00facleo pueda asignar huge pages correctamente. Y en segundo lugar, que la aplicaci\u00f3n que trabaja con ellas pueda utilizarlas. No se aprovechar\u00e1 por s\u00ed sola. Dado que PostgreSQL asign\u00f3 memoria al estilo de system 5, esto se pod\u00eda hacer con libhugetlbfs \u2014 este es el nombre completo de la biblioteca.<\/p>\n
<\/p>\n
En 9.3 se mejor\u00f3 el rendimiento de PostgreSQL en el manejo de la memoria y se abandon\u00f3 el m\u00e9todo de asignaci\u00f3n de memoria system 5. Todos estaban muy contentos, porque de lo contrario, al intentar iniciar dos instancias de PostgreSQL en una misma m\u00e1quina, te dice que no hay suficiente memoria compartida. Y menciona que hay que ajustar el sysctl. Y ese sysctl es tal que hay que reiniciar y dem\u00e1s. En general, todos se alegraron. Pero la asignaci\u00f3n de memoria mmap rompi\u00f3 el uso de huge pages. La mayor\u00eda de nuestros clientes utilizan grandes buffers compartidos. Y recomendamos encarecidamente no actualizar a 9.3, porque el overhead empezaba a contarse en buenos porcentajes.<\/p>\n
<\/p>\n
Sin embargo, la comunidad prest\u00f3 atenci\u00f3n a este problema y en 9.4 se trabaj\u00f3 muy bien en este aspecto. Y en 9.4 apareci\u00f3 un par\u00e1metro en postgresql.conf, donde puedes habilitar try, on u off.<\/p>\n
<\/p>\n
Try es el par\u00e1metro m\u00e1s seguro. Al iniciar PostgreSQL, cuando asigna memoria compartida, intenta tomar de huge pages esa memoria. Y si no tiene \u00e9xito, vuelve a la asignaci\u00f3n normal. Y si est\u00e1s en FreeBSD o Solaris, puedes usar try, siempre es seguro. <\/p>\n
<\/p>\n
Si est\u00e1 on, simplemente no se iniciar\u00e1 si no pudo asignar de huge pages. Aqu\u00ed ya depende de cada uno. Pero si tienes try, verifica que realmente se haya asignado lo necesario, porque hay mucho margen para el error. Actualmente, esta funcionalidad solo funciona en Linux.<\/p>\n
<\/p>\n
Una peque\u00f1a nota antes de avanzar. Transparent huge pages no se aplica a PostgreSQL por ahora. No puede utilizarlas de manera adecuada. Y en el caso de Transparent huge pages, para una carga de trabajo que necesita un gran bloque de memoria compartida, las ventajas solo se presentan en vol\u00famenes muy grandes. Si tienes terabytes de memoria, entonces esto puede tener importancia. Si hablamos de aplicaciones m\u00e1s comunes, donde tienes 32, 64, 128, 256 GB de memoria en la m\u00e1quina, entonces simplemente huge pages est\u00e1 bien, y desactivamos Transparent. <\/p>\n
<\/p>\n
<\/p>\n
Y la \u00faltima cosa relacionada con la memoria, que no est\u00e1 directamente vinculada al flujo de datos, puede arruinar mucho. Todo el ancho de banda se ve afectado seriamente si el servidor est\u00e1 constantemente haciendo swap. <\/p>\n
<\/p>\n
Y esto ser\u00e1 muy desagradable en varios momentos. Y el principal inconveniente radica en que en los n\u00facleos modernos el comportamiento es un poco diferente al de los n\u00facleos Linux m\u00e1s antiguos. Y esto es algo con lo que es bastante inc\u00f3modo lidiar, porque cuando hablamos de alguna operaci\u00f3n con swap, esto termina no siendo la llegada oportuna del OOM-killer. Y el OOM-killer que lleg\u00f3 tarde y elimin\u00f3 PostgreSQL es molesto. Todos, es decir, hasta el \u00faltimo usuario, se dar\u00e1n cuenta de esto. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfQu\u00e9 est\u00e1 pasando? Tienes una gran cantidad de memoria RAM, todo funciona bien. Pero por alguna raz\u00f3n, el servidor se queda atascado en swap y eso lo ralentiza. Podr\u00eda parecer que hay mucha memoria, pero esto ocurre. <\/p>\n
<\/p>\n
<\/p>\n
Antes recomend\u00e1bamos establecer vm.swappiness en cero, es decir, desactivar swap. Antes parec\u00eda que 32 GB de memoria RAM y los buffers compartidos correspondientes eran una cantidad enorme. La funci\u00f3n principal del swap es proporcionar un espacio donde enviar un n\u00facleo si fallamos. Y eso ya no se estaba cumpliendo. \u00bfY qu\u00e9 har\u00e1s luego con este n\u00facleo? Esa es ya una tarea en la que no est\u00e1 muy claro para qu\u00e9 sirve el swap, a\u00fan m\u00e1s de tal tama\u00f1o. <\/p>\n
<\/p>\n
Pero en los n\u00facleos modernos, es decir, en las versiones tres, el comportamiento ha cambiado. Y si ajustas swap a cero, es decir, lo apagas, tarde o temprano, incluso con una cierta cantidad de memoria RAM restante, el OOM-killer vendr\u00e1 a matar a los consumidores m\u00e1s intensivos. Porque \u00e9l considerar\u00e1 que con tal carga de trabajo nos queda un poco y vamos a fallar, es decir, no apu\u00f1alar el proceso del sistema, sino eliminar algo menos importante. Lo menos importante resultar\u00e1 ser el consumidor intensivo de memoria compartida, a saber, postmaster. Y despu\u00e9s de esto, ser\u00e1 un alivio si no tienes que restaurar la base de datos. <\/p>\n
<\/p>\n
Por lo tanto, ahora por defecto, si no me equivoco, la mayor\u00eda de las distribuciones utilizan alrededor de 6, es decir, en qu\u00e9 momento comenzamos a utilizar swap dependiendo de cu\u00e1nta memoria queda. Ahora recomendamos establecer vm.swappiness = 1, porque esto pr\u00e1cticamente lo apaga, pero evita los efectos de una llegada inesperada del OOM-killer que lo elimina todo.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
\u00bfQu\u00e9 sigue? Cuando hablamos del rendimiento de las bases de datos y poco a poco nos acercamos a los discos, todos empiezan a agarrarse la cabeza. Porque la verdad de que el disco es lento y la memoria es r\u00e1pida es algo que todos conocen desde peque\u00f1os. Y todos saben que en las bases de datos habr\u00e1 problemas con el rendimiento del disco.<\/p>\n
<\/p>\n
El principal problema con el rendimiento de PostgreSQL, relacionado con los picos de checkpoints, no surge porque el disco sea lento. M\u00e1s bien se debe a que el ancho de banda de la memoria y el disco no est\u00e1n equilibrados. Adem\u00e1s, pueden estar desbalanceados en diferentes lugares. PostgreSQL no est\u00e1 configurado, el SO no est\u00e1 configurado, el hardware no est\u00e1 configurado y el hardware es incorrecto. Y este problema no ocurre solo si todo se hace como debe ser, es decir, o no hay carga, o las configuraciones y el hardware est\u00e1n bien seleccionados. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfQu\u00e9 es esto y c\u00f3mo se ve? Normalmente, las personas que trabajan con PostgreSQL han pasado por esto varias veces. Lo explicar\u00e9. Como dije, PostgreSQL hace checkpoints peri\u00f3dicamente para volcar las p\u00e1ginas sucias de la memoria compartida al disco. Si tenemos un gran volumen de memoria compartida, el checkpoint comienza a afectar intensamente al disco porque vuelca estas p\u00e1ginas usando fsync. Llega al kernel buffer y se escribe en los discos mediante fsync. Y si el volumen de esto es grande, podemos observar un efecto desagradable, a saber, una utilizaci\u00f3n del disco muy alta.<\/p>\n
<\/p>\n
Aqu\u00ed tengo dos im\u00e1genes. Ahora explicar\u00e9 qu\u00e9 son. Son dos gr\u00e1ficos correlacionados en el tiempo. El primer gr\u00e1fico es la utilizaci\u00f3n del disco. Aqu\u00ed alcanza casi el 90% en ese momento. Si su base de datos cae con discos f\u00edsicos, con un controlador RAID y la utilizaci\u00f3n est\u00e1 al 90%, entonces son malas noticias. Esto significa que un poco m\u00e1s y llegar\u00e1 al 100% y la entrada\/salida se detendr\u00e1. <\/p>\n
<\/p>\n
Si tiene un arreglo de discos, la historia es un poco diferente. Ah\u00ed depende de c\u00f3mo est\u00e9 configurado, qu\u00e9 tipo de arreglo, etc. <\/p>\n
<\/p>\n
Y paralelamente aqu\u00ed se ha configurado un gr\u00e1fico de una vista interna de Postgres que indica c\u00f3mo se realiza el checkpoint. Y en color verde se muestra cu\u00e1ntos buffers, estas p\u00e1ginas sucias, llegaron en ese momento a este checkpoint para sincronizaci\u00f3n. Y esto es lo principal que se debe saber aqu\u00ed. Vemos que hay muchas p\u00e1ginas que llegaron y en alg\u00fan momento nos topamos con la placa, es decir, estuvimos escribiendo constantemente, aqu\u00ed claramente el sistema de discos est\u00e1 muy ocupado. Y nuestro checkpoint est\u00e1 afectando mucho al disco. En un escenario ideal, la situaci\u00f3n deber\u00eda verse, m\u00e1s bien, as\u00ed, es decir, aqu\u00ed hubo menos escritura. Y con la configuraci\u00f3n podemos arreglar esto para que siga as\u00ed. Es decir, la utilizaci\u00f3n es baja, pero en alg\u00fan lugar estamos escribiendo. <\/p>\n
<\/p>\n
\u00bfQu\u00e9 se debe hacer para resolver este problema? Si su IO se ha detenido en la base de datos, significa que todos los usuarios que vinieron a ejecutar sus consultas estar\u00e1n esperando. <\/p>\n
<\/p>\n
<\/p>\n
Si se observa desde el punto de vista de Linux, si ha tomado un buen hardware, lo ha configurado correctamente y ha ajustado adecuadamente PostgreSQL para que realice estos checkpoints con menos frecuencia, esparci\u00e9ndolos en el tiempo uno entre otro, entonces est\u00e1 utilizando los par\u00e1metros predeterminados de Debian. Para la mayor\u00eda de las distribuciones de Linux, esta es la situaci\u00f3n: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
\u00bfQu\u00e9 significa esto? A partir del n\u00facleo 2.6, apareci\u00f3 un demonio de flushing. Pgflush, dependiendo de cu\u00e1l se utilice, se encarga de la descarga en segundo plano de las p\u00e1ginas sucias del buffer del n\u00facleo y descarga, cuando sea necesario, las p\u00e1ginas sucias, cuando el flushing en segundo plano ya no es suficiente. <\/p>\n
<\/p>\n
\u00bfCu\u00e1ndo se activa el fondo? Cuando el 10 % de toda la memoria RAM en el servidor est\u00e1 ocupada por p\u00e1ginas sucias en el buffer del n\u00facleo, se llama a una funci\u00f3n especial de escritura en segundo plano. \u00bfPor qu\u00e9 es de fondo? Toma como par\u00e1metro cu\u00e1ntas p\u00e1ginas escribir. Y, por ejemplo, escribe N p\u00e1ginas. Y por un tiempo, esta cosa se duerme. Luego vuelve y escribe otra cantidad de p\u00e1ginas. <\/p>\n
<\/p>\n
Esta es una historia extremadamente simple. Aqu\u00ed la tarea es como con una piscina, cuando se vierte en un tubo y se llena en otro. Nuestro checkpoint ha llegado y si ha enviado pocas p\u00e1ginas sucias para descarga, gradualmente se dispersar\u00e1 todo esto cuidadosamente desde el buffer del n\u00facleo pgflush. <\/p>\n
<\/p>\n
Si siguen acumul\u00e1ndose esas p\u00e1ginas sucias, se acumulan hasta el 20%, despu\u00e9s de esto, la prioridad del sistema operativo es escribir todo esto en el disco, porque la alimentaci\u00f3n se cortar\u00e1, y estaremos en problemas. Perderemos esos datos, por ejemplo. <\/p>\n
<\/p>\n
\u00bfCu\u00e1l es el truco? El truco consiste en que estos par\u00e1metros en el mundo moderno, el 20% y el 10% de toda la memoria RAM disponible en la m\u00e1quina, son completamente monstruosos desde el punto de vista del rendimiento de cualquier sistema de disco que tengas.<\/strong> <\/p>\n<\/p>\n
Imagina que tienes 128 GB de memoria RAM. 12,8 GB llegan a tu sistema de disco. Y por mucho que tengas cach\u00e9 all\u00ed, o por mucho que tengas un arreglo, no soportar\u00e1n tanto. <\/p>\n
<\/p>\n
<\/p>\n
Por lo tanto, recomendamos configurar esos n\u00fameros desde la capacidad de tu controlador RAID.<\/strong> Aqu\u00ed hay una recomendaci\u00f3n para un controlador que tiene 512 MB de cach\u00e9. <\/p>\n<\/p>\n
Todo se considera de manera muy simple. Se puede establecer vm.dirty_background en bytes. Y esas configuraciones anulan las dos anteriores. O el ratio por defecto, o las activadas con bytes, funcionar\u00e1n las que tienen bytes. Pero dado que soy consultor DBA y trabajo con diferentes clientes, trato de ponerme a cubierto, as\u00ed que si en bytes, entonces en bytes. Nadie ha dado ninguna garant\u00eda de que un buen administrador no le agregue memoria al servidor, no lo reinicie, y el n\u00famero permanezca igual. Simplemente calculen esos n\u00fameros, para garantizar que todo quepa ah\u00ed. <\/p>\n
<\/p>\n
\u00bfQu\u00e9 sucede si no cabe? Se dice que se detiene efectivamente cualquier flushing, pero en realidad es una figura ret\u00f3rica. El sistema operativo tiene un gran problema: tiene muchas p\u00e1ginas sucias, por lo tanto se detiene efectivamente la IO que generan tus clientes, es decir, cuando una aplicaci\u00f3n env\u00eda una consulta SQL a la base, est\u00e1 en espera. Cualquier entrada\/salida en ella est\u00e1 en la prioridad m\u00e1s baja, porque la base est\u00e1 ocupada con el checkpoint. Y cu\u00e1ndo lo terminar\u00e1 es completamente incierto. Y cuando has alcanzado el flushing no de fondo, no background, significa que toda tu IO est\u00e1 ocupada con eso. Y mientras no termine, no podr\u00e1s hacer nada. <\/p>\n
<\/p>\n
Aqu\u00ed hay otros dos puntos importantes que est\u00e1n m\u00e1s all\u00e1 de este informe. Estas configuraciones deben coincidir con las configuraciones en postgresql.conf, es decir, las configuraciones de checkpoints. Y tu sistema de disco debe estar adecuadamente configurado. Si tienes cach\u00e9 en RAID, debe haber una bater\u00eda en \u00e9l.<\/strong> Las personas compran RAID con buen cach\u00e9 sin bater\u00eda. Si tienes SSD en RAID, deben ser de servidor, deben tener condensadores.<\/strong> Aqu\u00ed hay una lista de verificaci\u00f3n detallada. En este enlace est\u00e1 mi informe sobre c\u00f3mo configurar el rendimiento del disco en PostgreSQL. Ah\u00ed est\u00e1n todas estas listas de verificaci\u00f3n. <\/p>\n<\/p>\n
<\/p>\n
\u00bfQu\u00e9 m\u00e1s puede complicar la vida? Son dos par\u00e1metros. Son relativamente nuevos. Pueden estar habilitados por defecto en diferentes aplicaciones. Y pueden complicar la vida tanto como si est\u00e1n habilitados incorrectamente. <\/p>\n
<\/p>\n
<\/p>\n
Hay dos cosas relativamente nuevas. Ya aparecen en los n\u00facleos tres. Son sched_migration_cost en nanosegundos y sched_autogroup_enabled, que por defecto es uno. <\/p>\n
<\/p>\n
\u00bfY c\u00f3mo arruinan la vida? \u00bfQu\u00e9 es sched_migration_cost? El planificador de Linux puede migrar un proceso de una CPU a otra. Y para PostgreSQL, que ejecuta consultas, la migraci\u00f3n a otra CPU no tiene sentido. Desde la perspectiva del sistema operativo, cuando cambias entre ventanas de openoffice y terminal, puede que sea bueno, pero para la base de datos, esto es muy malo.<\/strong> Por lo tanto, una pol\u00edtica sensata es establecer el migration_cost en un valor grande, al menos en varios miles de nanosegundos.<\/strong> <\/p>\n<\/p>\n
\u00bfQu\u00e9 significar\u00e1 esto para el planificador? Considerar\u00e1 que durante ese tiempo este proceso todav\u00eda est\u00e1 caliente. Es decir, si tienes alguna transacci\u00f3n larga que est\u00e1 haciendo algo, el planificador lo entender\u00e1. Considerar\u00e1 que mientras no pase este tiempo de espera, no es necesario migrar este proceso a ning\u00fan lado. Si este proceso est\u00e1 haciendo algo, no se migrar\u00e1 a ning\u00fan otro lugar, terminar\u00e1 tranquilamente en la CPU que se le asign\u00f3. Y el resultado es excelente. <\/p>\n
<\/p>\n
El segundo punto es autogroup. Hay una buena idea para cargas de trabajo espec\u00edficas, que no tienen relaci\u00f3n con bases de datos modernas, que es agrupar procesos seg\u00fan el terminal virtual desde el cual fueron iniciados. Esto es conveniente para algunas tareas. En la pr\u00e1ctica, PostgreSQL es un sistema multiproceso con prefork que se inicia desde un solo terminal. Tendr\u00e1 un bloqueador de escritura, un checkpoint, y todas sus solicitudes de clientes se agrupar\u00e1n en un solo programador, en una sola CPU. Y estar\u00e1n all\u00ed esperando pac\u00edficamente a que se libere, interrumpi\u00e9ndose entre s\u00ed y ocup\u00e1ndolo por m\u00e1s tiempo. Esta es una situaci\u00f3n que no se necesita en caso de tal carga y, por lo tanto, debe desactivarse.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Mi colega Alex\u00e9i Lesovski realiz\u00f3 pruebas con un pgbench simple, donde aument\u00f3 en un orden el migration_cost y desactiv\u00f3 el autogroup. La diferencia en un hardware deficiente fue de casi un 10%.<\/strong>. Hay una discusi\u00f3n en la lista de correo de PostgreSQL donde la gente presenta resultados sobre c\u00f3mo tales cambios afectaron la velocidad de las consultas. influyeron en un 50%.<\/strong>. Hay muchas historias como estas.<\/p>\n<\/p>\n
<\/p>\n
Y por \u00faltimo, sobre la pol\u00edtica de ahorro de energ\u00eda. Es bueno que ahora se pueda usar Linux en una laptop. Y supuestamente consumir\u00e1 bien la bater\u00eda. Pero resulta que esto tambi\u00e9n puede ocurrir en un servidor. <\/p>\n
<\/p>\n
Adem\u00e1s, si alquila servidores a alg\u00fan proveedor de hosting, entonces los \"amables\" hosting<\/a> no se preocupan por que tenga un mejor rendimiento. Su tarea es asegurarse de que su hardware se utilice de manera m\u00e1s eficiente. Por lo tanto, pueden habilitar de forma predeterminada el modo de ahorro de energ\u00eda de laptop en el sistema operativo.<\/p>\n<\/p>\n
Si utiliza en un servidor con una base de datos bajo carga intensa esta opci\u00f3n, su elecci\u00f3n es acpi_cpufreq + performance. Incluso con ondemand ya habr\u00e1 problemas.<\/strong> <\/p>\n<\/p>\n
Intel_pstate es un controlador un poco diferente. Y ahora se prefiere este, ya que es m\u00e1s reciente y funciona mejor.<\/p>\n
<\/p>\n
Y, por lo tanto, el gobernador solo debe ser performance. Ondemand, powersave y todo lo dem\u00e1s no son para usted. <\/p>\n
<\/p>\n
Los resultados del explain analyze en PostgreSQL pueden diferir en varios \u00f3rdenes de magnitud si habilita powersave, porque pr\u00e1cticamente el CPU bajo su base de datos se programar\u00e1 de manera completamente impredecible.<\/p>\n
<\/p>\n
Estas configuraciones pueden estar habilitadas por defecto. \u00c9chale un vistazo detenidamente - verifica si est\u00e1n habilitadas por defecto. Esto puede ser realmente un gran problema. <\/p>\n
<\/p>\n
<\/p>\n
Y al final quer\u00eda agradecer a los chicos de nuestro equipo de DBA PosgreSQL-Consulting, en particular a Max Boguk y Alexey Lesovsky, quienes se enfrentan a desaf\u00edos diariamente en este tema. Y para nuestros clientes, nos esforzamos por hacer que todo funcione lo mejor posible. Aqu\u00ed es como con las instrucciones de seguridad a\u00e9rea. Todo est\u00e1 escrito con sangre. Cada uno de estos problemas fue descubierto durante alg\u00fan inconveniente. Con gusto los comparto con ustedes.<\/p>\n
<\/p>\n
Preguntas:<\/p>\n
<\/p>\n
\u00a1Gracias! Si, por ejemplo, una empresa quiere ahorrar y alojar la base de datos y la l\u00f3gica de la aplicaci\u00f3n en un mismo servidor, o si la empresa sigue la tendencia moderna de arquitecturas de microservicios, donde PostgreSQL se ejecuta en un contenedor. \u00bfCu\u00e1l es el truco? Sysctl afecta globalmente a todo el n\u00facleo. No he o\u00eddo que sysctl se virtualice de alguna manera para funcionar por separado en un contenedor. Solo hay cgroup y all\u00ed solo hay control parcial. \u00bfC\u00f3mo se puede vivir con esto? O si desea rendimiento, entonces ejecute PostgreSQL en un servidor f\u00edsico separado y aj\u00fastelo.<\/em><\/p>\n<\/p>\n
Respondimos a su pregunta de aproximadamente tres maneras. Si no se trata de un servidor f\u00edsico que se pueda ajustar, rel\u00e1jese, todo funcionar\u00e1 bien sin esa configuraci\u00f3n. Si tiene una carga tal que necesita hacer estas configuraciones, llegar\u00e1 a un servidor f\u00edsico antes que a estas configuraciones.<\/p>\n
<\/p>\n
\u00bfCu\u00e1l es el problema? Si es una m\u00e1quina virtual, es probable que tenga muchos problemas, por ejemplo, con el hecho de que la latencia del disco es bastante inconsistente en la mayor\u00eda de las m\u00e1quinas virtuales. Incluso si el ancho de banda de los discos es bueno, una transacci\u00f3n fallida en operaciones de entrada\/salida, que no afecta mucho al rendimiento promedio, que ocurre durante un checkpoint o al escribir en WAL, har\u00e1 que la base de datos sufra gravemente. Y notar\u00e1 esto antes de encontrarse con esos problemas. <\/p>\n
<\/p>\n
Si tiene NGINX en el mismo servidor, tambi\u00e9n tendr\u00e1 el mismo problema. Competir\u00e1 por la memoria compartida. Y no llegar\u00e1 a los problemas que se describen aqu\u00ed.<\/p>\n
<\/p>\n
Pero, por otro lado, algunos de estos par\u00e1metros seguir\u00e1n siendo relevantes para usted. Por ejemplo, con sysctl establecer dirty_ratio para que no sea tan extremo; de todos modos, esto ayudar\u00e1. De una forma u otra, tendr\u00e1 interacci\u00f3n con el disco. Y lo har\u00e1 de una manera incorrecta. Esos son en general los par\u00e1metros predeterminados que mostr\u00e9. Y en cualquier caso, es mejor cambiarlos. <\/p>\n
<\/p>\n
Y puede haber problemas con NUMA. VmWare, por ejemplo, funciona bien con NUMA con configuraciones totalmente opuestas. Y aqu\u00ed hay que elegir: \u00bfservidor f\u00edsico o no f\u00edsico? <\/p>\n
<\/p>\n
Tengo una pregunta relacionada con Amazon AWS. Ellos tienen im\u00e1genes preconfiguradas. Una de ellas se llama Amazon RDS. \u00bfHay alguna configuraci\u00f3n personalizada para su sistema operativo?<\/em><\/p>\n<\/p>\n
Hay configuraciones, pero son diferentes. Aqu\u00ed configuramos el sistema operativo desde el punto de vista de c\u00f3mo la base de datos utilizar\u00e1 esto. Y all\u00ed hay par\u00e1metros que determinan a d\u00f3nde vamos, como un tipo de shaping. Es decir, necesitamos tantos recursos, y ahora los consumiremos. Despu\u00e9s de esto, Amazon RDS incorpora esos recursos, y ah\u00ed la performance disminuye. Hay historias separadas de c\u00f3mo la gente comienza a jugar con esto. A veces con bastante \u00e9xito. Pero esto no tiene que ver con la configuraci\u00f3n del sistema operativo. Es como un hackeo en la nube. Esa es otra historia.<\/p>\n
<\/p>\n
\u00bfPor qu\u00e9 las Transparent huge pages no tienen efecto en comparaci\u00f3n con Huge TLB?<\/em><\/p>\n<\/p>\n
No lo tienen. Se puede explicar de muchas maneras. Pero en realidad simplemente no lo dan. \u00bfCu\u00e1l es la historia con PostgreSQL? Al iniciar, asigna un gran bloque de memoria compartida. Si son Transparent o no, no importa en absoluto. El hecho de que se asignen al inicio lo explica todo. Y si hay mucha memoria y es necesario reconstruir el segmento de shared_memory, entonces las Transparent huge pages ser\u00e1n relevantes. En PostgreSQL, simplemente se asigna un gran bloque al inicio y ya, no sucede nada especial despu\u00e9s de eso. Se puede usar, claro, pero hay una posibilidad de corrupci\u00f3n en shared_memory, cuando se reasigne algo. PostgreSQL no sabe nada de esto.<\/p>\n
Fuente: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2015 \u0433\u043e\u0434\u0430 \u0418\u043b\u044c\u0438 \u041a\u043e\u0441\u043c\u043e\u0434\u0435\u043c\u044c\u044f\u043d\u0441\u043a\u043e\u0433\u043e "Linux tuning to improve PostgreSQL performance" Disclaimer: \u0417\u0430\u043c\u0435\u0447\u0443 \u0447\u0442\u043e \u0434\u043e\u043a\u043b\u0430\u0434 \u044d\u0442\u043e\u0442 \u0434\u0430\u0442\u0438\u0440\u043e\u0432\u0430\u043d \u043d\u043e\u044f\u0431\u0440\u0435\u043c 2015 \u0433\u043e\u0434\u0430 \u2014 \u043f\u0440\u043e\u0448\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u0435 4 \u043b\u0435\u0442 \u0438 \u043f\u0440\u043e\u0448\u043b\u043e \u043c\u043d\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u043c\u0430\u044f \u0432 \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0432\u0435\u0440\u0441\u0438\u044f 9.4 \u0443\u0436\u0435 \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 4 \u0433\u043e\u0434\u0430 \u0432\u044b\u0448\u043b\u043e 5 \u043d\u043e\u0432\u044b\u0445 \u0440\u0435\u043b\u0438\u0437\u043e\u0432 PostgreSQL \u0432\u044b\u0448\u043b\u043e \u0438 15 \u0432\u0435\u0440\u0441\u0438\u0439 \u044f\u0434\u0440\u0430 Linux. \u0415\u0441\u043b\u0438 \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84083,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Ajustes](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n