El kernel de Linux proporciona una amplia gama de opciones de configuraciĆ³n que pueden afectar el rendimiento. Se trata de obtener la configuraciĆ³n correcta para su aplicaciĆ³n y carga de trabajo. Como cualquier otra base de datos, PostgreSQL usa el kernel de Linux para una configuraciĆ³n Ć³ptima. Las configuraciones mal ajustadas pueden dar como resultado un bajo rendimiento. Por lo tanto, es importante que mida el rendimiento de la base de datos despuĆ©s de cada sesiĆ³n de ajuste para evitar la degradaciĆ³n del rendimiento. En una de mis publicaciones anteriores, "Ajuste de los parĆ”metros del kernel de Linux para la optimizaciĆ³n de PostgreSQL", describĆ algunos de los parĆ”metros del kernel de Linux mĆ”s Ćŗtiles y cĆ³mo pueden ayudarlo a mejorar el rendimiento de la base de datos. Ahora voy a compartir los resultados de mi prueba despuĆ©s de configurar grandes pĆ”ginas de Linux con una carga de trabajo PostgreSQL diferente. RealicĆ© un conjunto exhaustivo de pruebas para diferentes tamaƱos de carga de PostgreSQL y el nĆŗmero simultĆ”neo de clientes.
MƔquina de prueba
- Servidor Supermicro:
- CPU IntelĀ® XeonĀ® E5-2683 v3 @ 2.00GHz
- 2 enchufes / 28 nĆŗcleos / 56 hilos
- Memoria: 256 GB de RAM
- Almacenamiento: SAMSUNG SM863 1.9TB 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Ć© la configuraciĆ³n predeterminada del kernel sin ninguna optimizaciĆ³n / ajuste que no sea deshabilitar pĆ”ginas grandes transparentes (Transparent HugePages). Las pĆ”ginas grandes transparentes estĆ”n habilitadas de forma predeterminada y resaltan el tamaƱo de la pĆ”gina, que puede no recomendarse para la base de datos. Las bases de datos generalmente requieren pĆ”ginas grandes de tamaƱo fijo que no estĆ”n cubiertas por pĆ”ginas grandes transparentes. Por lo tanto, siempre se recomienda deshabilitar esta funciĆ³n y usar pĆ”ginas grandes clĆ”sicas de forma predeterminada.
ConfiguraciĆ³n de PostgreSQL
UtilicĆ© la configuraciĆ³n uniforme de PostgreSQL para todas las pruebas para registrar diferentes cargas de trabajo de PostgreSQL con diferentes configuraciones para grandes pĆ”ginas de Linux. AquĆ estĆ” la configuraciĆ³n de PostgreSQL utilizada para todas las pruebas:
postgresql.confshared_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
En las pruebas, el esquema de pruebas juega un papel importante. Todas las pruebas se realizan tres veces durante 30 minutos para cada ejecuciĆ³n. TomĆ© el promedio de estos tres indicadores. Las pruebas se realizaron utilizando la herramienta de prueba de rendimiento PostgreSQL
pgbench . pgbench funciona con un factor de escala, con un factor de escala de aproximadamente 16 MB de carga de trabajo.
PƔginas grandes (pƔginas enormes)
Linux, por defecto, usa pĆ”ginas de memoria 4K junto con pĆ”ginas grandes. BSD tiene Super pĆ”ginas, mientras que Windows tiene pĆ”ginas grandes. PostgreSQL solo admite pĆ”ginas grandes (Linux). En casos de alto uso de memoria, las pĆ”ginas pequeƱas reducen el rendimiento. Al instalar pĆ”ginas grandes, aumenta la memoria asignada para la aplicaciĆ³n y, en consecuencia, reduce los costos operativos que surgen durante la asignaciĆ³n / intercambio; es decir, aumenta la productividad con pĆ”ginas grandes.
AquĆ estĆ” la configuraciĆ³n para pĆ”ginas grandes cuando se utiliza un tamaƱo de pĆ”gina grande de 1 GB. Siempre puede obtener esta informaciĆ³n de / proc.
$ cat / proc / meminfo | grep -i enorme AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB
Para obtener mĆ”s informaciĆ³n sobre pĆ”ginas grandes, lea mi publicaciĆ³n de blog anterior.
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/Por lo general, las pƔginas grandes tienen 2 MB y 1 GB, por lo que tiene sentido usar 1 GB en lugar de los 2 MB mucho mƔs pequeƱos.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhugehttps://kerneltalks.com/services/what-is-huge-pages-in-linux/Resultados de la prueba
Esta prueba muestra el efecto general de varios tamaƱos de pĆ”ginas grandes. El primer conjunto de pruebas se creĆ³ con el tamaƱo de pĆ”gina predeterminado en Linux 4K sin incluir pĆ”ginas grandes. Tenga en cuenta que las pĆ”ginas enormes transparentes tambiĆ©n se deshabilitaron y permanecieron deshabilitadas durante todas estas pruebas.
Luego, el segundo conjunto de pruebas se realizĆ³ en pĆ”ginas grandes de 2 MB. Finalmente, el tercer conjunto de pruebas se ejecuta con pĆ”ginas grandes de 1 GB.
Todas estas pruebas se realizaron en PostgreSQL versiĆ³n 11. Los conjuntos incluyen una combinaciĆ³n de diferentes tamaƱos de la base de datos y los clientes. El siguiente grĆ”fico muestra los resultados comparativos de rendimiento para estas pruebas con TPS (transacciones por segundo) en el eje Y, el tamaƱo de la base de datos y el nĆŗmero de clientes por tamaƱo de base de datos en el eje X.
Se puede ver en el grĆ”fico anterior que la ganancia de rendimiento con pĆ”ginas grandes aumenta con el nĆŗmero de clientes y el tamaƱo de la base de datos, si el tamaƱo permanece en el bĆŗfer previamente asignado en la memoria compartida.
Esta prueba muestra TPS en comparaciĆ³n con el nĆŗmero de clientes. En este caso, el tamaƱo de la base de datos es de 48 GB. En el eje Y, tenemos TPS, y en el eje X, tenemos 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 que se establece en 64 GB.
Si las pƔginas grandes se configuran en 1 GB, cuantos mƔs clientes, mayor serƔ la ganancia relativa de rendimiento.
El siguiente grĆ”fico es el mismo que el anterior, excepto por el tamaƱo de la base de datos de 96 GB. Esto excede el tamaƱo del bĆŗfer compartido, que se establece en 64 GB.
La observaciĆ³n clave aquĆ es que el rendimiento con pĆ”ginas grandes de 1 GB aumenta a medida que aumenta el nĆŗmero de clientes y, en Ćŗltima instancia, proporciona mĆ”s rendimiento que las pĆ”ginas grandes de 2 MB o el tamaƱo de pĆ”gina estĆ”ndar de 4 KB.
Esta prueba muestra TPS dependiendo del tamaƱo de la base de datos. En este caso, el nĆŗmero de clientes conectados es 32. En el eje Y, tenemos TPS, y en el eje X - tamaƱos de base de datos.
Como se esperaba, cuando la base de datos va mƔs allƔ de las pƔginas grandes preasignadas, el rendimiento se reduce significativamente.
Resumen
Una de mis recomendaciones clave es que debemos desactivar Transparent HugePages. VerĆ” la mayor ganancia de rendimiento cuando la base de datos se coloca en un bĆŗfer compartido con pĆ”ginas grandes habilitadas. Elegir el tamaƱo de pĆ”ginas grandes requiere una pequeƱa cantidad de prueba y error, pero esto puede conducir a un aumento significativo en TPS cuando el tamaƱo de la base de datos es grande, pero sigue siendo lo suficientemente pequeƱo como para caber en un bĆŗfer compartido.