El kernel de Linux proporciona una amplia gama de opciones de configuración que pueden afectar el rendimiento. Lo principal es elegir la configuración correcta para su aplicación y carga de trabajo. Como cualquier otra base de datos, PostgreSQL necesita un ajuste óptimo del kernel de Linux. La configuración incorrecta puede resultar en un bajo rendimiento. Es importante realizar un análisis comparativo del rendimiento de la base de datos después de cada sesión de ajuste. En una de mis publicaciones anteriores, titulada "Ajustar los parámetros del kernel de Linux para la optimización de PostgreSQL" , describí algunos de los parámetros más útiles del kernel de Linux y cómo ayudan a mejorar el rendimiento de la base de datos. Ahora compartiré los resultados de las pruebas comparativas después de configurar HugePages en Linux bajo varias cargas de PostgreSQL. Realicé un conjunto de pruebas completo bajo muchas cargas de trabajo PostgreSQL diferentes con un número diferente de clientes concurrentes.
PC en la que se realizó la prueba
- Servidor Supermicro:
- CPU Intel® Xeon® E5-2683 v3 @ 2.00 GHz
- 2 enchufes / 28 núcleos / 56 hilos
- Memoria: 256 GB de RAM
- Almacenamiento: SAMSUNG SM863 1.9 TB Enterprise SSD
- Sistema de archivos: ext4 / xfs
- SO: Ubuntu 16.04.4, kernel 4.13.0-36-generic
- PostgreSQL: versión 11
Configuración del kernel de Linux
Usé los parámetros predeterminados del núcleo sin ninguna optimización / ajuste, solo deshabilité Transparent HugePages. Esta tecnología está habilitada de manera predeterminada y asigna páginas de un tamaño que no se recomienda usar con bases de datos. En general, las bases de datos necesitan HugePages de un tamaño fijo, pero Transparent HugePages no puede proporcionarlas. Por lo tanto, siempre se recomienda desactivar esta función y, de forma predeterminada, instalar HugePages clásicos.
Configuración de PostgreSQL
Utilicé la misma configuración de PostgreSQL para todas las pruebas para registrar diferentes cargas de trabajo de PostgreSQL con diferentes configuraciones de Linux HugePages. Para todas las pruebas, se aplicaron las siguientes configuraciones de PostgreSQL:
shared_buffers = '64GB' work_mem = '1GB' random_page_cost = '1' maintenance_work_mem = '2GB' synchronous_commit = 'on' seq_page_cost = '1' max_wal_size = '100GB' checkpoint_timeout = '10min' synchronous_commit = 'on' checkpoint_completion_target = '0.9' autovacuum_vacuum_scale_factor = '0.4' effective_cache_size = '200GB' min_wal_size = '1GB' wal_compression = 'ON'
Esquema de prueba
El esquema de prueba juega un papel importante. Todas las pruebas se realizan tres veces, la duración de cada ejecución es de 30 minutos. Con base en los resultados de estas 3 pruebas, deduje el valor promedio. Las pruebas se llevaron a cabo utilizando la herramienta pgbench PostgreSQL; funciona con un factor de escala en incrementos de aproximadamente 16 MB de carga.
Enormes páginas
Por defecto, Linux usa páginas de memoria 4K, así como la tecnología HugePages. BSD usa tecnología Super Pages y Windows usa páginas grandes. PostgreSQL solo es compatible con la tecnología HugePages (Linux). En los casos en que la cantidad de memoria utilizada es grande, las páginas más pequeñas reducen el rendimiento. Con HugePages, aumenta la memoria asignada para la aplicación y, por lo tanto, reduce la "sobrecarga" que ocurre durante el proceso de asignación / intercambio. Por lo tanto, HugePages aumenta la productividad.
Aquí están las configuraciones para HugePages 1 GB de tamaño. Esta información está disponible en cualquier momento usando / proc.
AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB
Escribí más sobre HugePages en una publicación anterior.
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/
En general, HugePages tiene un tamaño de 2 MB y 1 GB, por lo que tiene sentido usar 1 GB.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge
https://kerneltalks.com/services/what-is-huge-pages-in-linux/
Resultados de la prueba
Esta prueba muestra el efecto general del uso de HugePages de varios tamaños. El primer conjunto de pruebas se creó con un tamaño de página de 4K, utilizado por defecto en Linux, y sin la activación de HugePages. Permítame recordarle: deshabilité la opción Transparent HugePages durante toda la duración de las pruebas.
Luego se realizó un segundo conjunto de pruebas para HugePages con un tamaño de 2 MB. Finalmente, se ejecutó un tercer conjunto de pruebas para HugePages de 1 GB.
Para todas las pruebas comparativas, se utilizó PostgreSQL DBMS 11. Los kits incluyen combinaciones de varios tamaños de bases de datos y varios clientes. El siguiente gráfico muestra los resultados de una comparación de rendimiento utilizando estas pruebas: TPS (número de transacciones por segundo), a lo largo del eje Y, y el tamaño de la base de datos y el número de clientes para una base de datos de cierto tamaño, a lo largo del eje X.
En el gráfico anterior, se puede ver que, a partir del uso de HugePages, la ganancia aumenta a medida que aumenta el número de clientes y el tamaño de la base de datos, siempre que este tamaño permanezca dentro del búfer compartido previamente asignado.
Esta prueba comparó TPS y la cantidad de clientes. En este caso, el tamaño de la base de datos es de 48 GB. El eje Y muestra TPS, y el eje X muestra el número de clientes conectados. El tamaño de la base de datos es lo suficientemente pequeño como para caber en un búfer compartido con un tamaño fijo de 64 GB.
Cuando HugePages tiene un tamaño de 1 GB, la ganancia de rendimiento comparativo aumenta con el número de clientes.
El siguiente gráfico es el mismo que el anterior, pero el tamaño de la base de datos es de 96 GB. Esto es más grande que el tamaño de búfer total fijo de 64 GB.
Lo principal a tener en cuenta aquí: el rendimiento con HugePages de 1 GB aumenta a medida que aumenta el número de clientes y, en última instancia, proporciona un mejor rendimiento que el uso de HugePages de 2 MB o páginas estándar de 4 KB.
Esta prueba muestra la relación de TPS al tamaño de la base de datos. En este caso, el número de clientes conectados es 32. En el eje Y, se muestra TPS, y en el eje X, tamaños de base de datos.
Como se esperaba, cuando el tamaño de la base de datos excede el tamaño de los HugePages previamente asignados, el rendimiento se reduce significativamente.
Conclusión
Una de mis principales recomendaciones es desactivar Transparent HugePages. Obtendrá el mayor aumento de rendimiento si la base de datos se coloca en un búfer compartido con HugePages habilitado. El tamaño óptimo de HugePages se determina por prueba y error, pero potencialmente este enfoque puede conducir a una ganancia significativa en TPS, cuando el tamaño de la base de datos es lo suficientemente grande, pero al mismo tiempo le permite encajar en un búfer común.