2ndQuadrant | PostgreSQL
Bases de Datos de Misión Crítica
  • Contacto
  • ES
    • EN
    • FR
    • IT
    • DE
    • PT
  • Soporte & Servicios
  • Descargas
    • Instaladores
      • Postgres Installer
      • 2UDA – Unified Data Analytics
    • Whitepapers
      • Caso de Negocio para Soporte PostgreSQL
      • Mejores Prácticas de Seguridad
    • Casos de Estudio
      • Migración de Bases de Datos
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
      • Ajustes de Rendimiento
        • BenchPrep
        • tastyworks
      • Clústeres de Bases de Datos Distribuidas
        • ClickUp
        • Agencia Espacial Europea (ESA)
        • Animal Logic
        • Telefónica del Sur
      • Actualizaciones de Bases de Datos
        • Instituto Alfred Wegener (AWI)
      • Soporte & Administración de Bases de Datos
        • Met Office
        • Agilis Systems
        • London & Partners
  • Centro de Aprendizaje Postgres
    • Webinars
      • Próximos Webinars
      • Biblioteca de Webinar
    • Whitepapers
      • Caso de Negocio para Soporte PostgreSQL
      • Mejores Prácticas de Seguridad
    • Blog
    • Formación
      • Catálogo de los Cursos
    • Casos de Estudio
      • Ajustes de Rendimiento
        • BenchPrep
        • tastyworks
      • Clústeres Distribuidos
        • ClickUp
        • Agencia Espacial Europea (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Administración de Bases de Datos
        • Agilis Systems
      • Formación Profesional
        • Met Office
        • London Partners
      • Actualizaciones de Bases de Datos
        • Instituto Alfred Wegener (AWI)
      • Migración de Bases de Datos
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
    • Libros
      • PostgreSQL 11 Administration Cookbook
      • PostgreSQL 10 Administration Cookbook
      • PostgreSQL High Availability Cookbook – 2a Edición
      • PostgreSQL 9 Administration Cookbook – 3a Edición
      • PostgreSQL Server Programming Cookbook – 2a Edición
      • PostgreSQL 9 Cookbook – Edición en Chino
    • Videos
    • PostgreSQL
      • PostgreSQL – La historia
      • ¿Quién usa PostgreSQL?
      • Preguntas Frecuentes sobre PostgreSQL
      • PostgreSQL VS MySQL
      • Caso de Negocio para PostgreSQL
      • Información de Seguridad
      • Documentación
  • Sobre nosotros
    • Sobre 2ndQuadrant
    • La Pasión de 2ndQuadrant por PostgreSQL
    • Noticias
    • Trabaje con Nosotros
  • Blog
  • Instaladores
  • Menú Menú
Usted está aquí: Inicio1 / Blog2 / PostgreSQL3 / Rendimiento OLTP desde PostgreSQL 8.3
Tomas Vondra

Rendimiento OLTP desde PostgreSQL 8.3

octubre 16, 2020/0 Comentarios/en PostgreSQL, Tomas' PlanetPostgreSQL /por Tomas Vondra

Hace un par de años (en el pgconf.eu 2014 en Madrid) presenté una charla titulada «Arqueología del rendimiento«. Mostraba el cambio en el rendimiento alcanzado con las recientes versiones de PostgreSQL. Di esa charla porque considero que una visión a largo plazo es algo interesante y puede ofrecernos ideas muy valiosas. Para los que, como yo, trabajamos con el código PostgreSQL, representa una guía muy útil para el desarrollo futuro, y puede ayudar a los usuarios de PostgreSQL a evaluar las actualizaciones.

Así que he decidido repetir este ejercicio y escribir un par de posts en este blog para analizar el rendimiento de varias versiones de PostgreSQL. En la charla de 2014 empecé con PostgreSQL 7.4, que en aquel momento tenía unos 10 años de vida, puesto que fue lanzado en el año 2003. Esta vez empezaré con PostgreSQL 8.3, que ya tiene unos 12 años.

Por qué no empezar de nuevo con PostgreSQL 7.4? Existen tres razones principales por las que quiero empezar con PostgreSQL 8.3. En primer lugar, por pereza en general. Cuanto más anticuada sea una versión, más difícil será compilar usando las actuales versiones de los compiladores, etc. En segundo lugar, realizar pruebas de rendimiento adecuadas requiere mucho tiempo, especialmente cuando se trabaja con grandes cantidades de datos, por lo que añadir una sola versión principal puede suponer fácilmente un par de días de tiempo de máquina. Simplemente no parecía valer la pena. Y por último, la versión 8.3 introdujo una serie de cambios importantes – mejoras del proceso de autovacuum (habilitado por defecto, procesos ayudantes concurrentes, …), búsqueda de texto completo integrada, puntos de control extendidos, etc. Así que, en mi opinión, tiene mucho sentido empezar con PostgreSQL 8.3. Y puesto que fue lanzado hace unos 12 años, esta comparación abarca un período de tiempo superior a la anterior.

He decidido realizar una prueba de rendimiento con tres tipos básicos de carga de trabajo: OLTP, analítica y búsqueda de texto completo. Creo que la OLTP y la analítica son opciones bastante obvias, ya que la mayoría de las aplicaciones son una combinación de estos dos tipos básicos. La búsqueda de texto completo me permite demostrar las mejoras en los tipos especiales de índices, utilizados también para indexar tipos de datos populares como JSONB, tipos utilizados por PostGIS, etc.

¿Por qué realizar una prueba de rendimiento?

¿Vale la pena el esfuerzo? Después de todo, durante la fase de desarrollo realizamos constantemente pruebas de rendimiento para comprobar la utilidad de alguna revisión o para evitar que se produzcan regresiones, ¿verdad? El problema es que normalmente se trata sólo de pruebas "parciales", en las que se comparan dos commits específicos con una selección muy limitada de cargas de trabajo que consideramos relevantes. Y eso tiene sentido. Simplemente no es posible realizar una serie completa de cargas de trabajo para cada commit.

De vez en cuando (por lo general poco después del lanzamiento de una nueva versión principal de PostgreSQL) los usuarios realizan pruebas para comparar la nueva versión con la anterior. Eso es bueno y, de hecho, les recomiendo que hagan este tipo de pruebas, (de tipo estándar o específicas para la aplicación que realicen). Pero es difícil combinar estos resultados con una visión a largo plazo, debido a que estas pruebas se realizan empleando distintos tipos de configuración, de equipos (por lo general uno más reciente para la versión más actual), y otros elementos. Así que es difícil emitir juicios bien definidos sobre los cambios generales.

Lo mismo ocurre con el rendimiento de la aplicación, que, por supuesto, constituye el "criterio de referencia definitivo". Sin embargo, es posible que los usuarios no realicen la actualización a todas las versiones principales (en ocasiones pueden saltarse un par de versiones, por ejemplo, de la 9.5 a la 12). Y cuando deciden actualizar, a menudo lo hacen en combinación con actualizaciones de hardware, o de otro tipo. Cabe mencionar también que con el paso del tiempo las aplicaciones evolucionan (nuevas características, mayor complejidad), la cantidad de datos y el número de usuarios simultáneos aumentan, etc.

Eso es precisamente lo que esta serie de blogs quiere presentar: tendencias a largo plazo en el rendimiento de PostgreSQL relativas a algunas cargas de trabajo básicas. Esto dará a nosotros, los desarrolladores, la agradable sensación de haber realizado un buen trabajo a lo largo de los años. Mostrará también a los usuarios que, aunque PostgreSQL es un producto bien desarrollado, sigue ofreciendo mejoras significativas en cada nueva versión principal.

Mi intención no es utilizar estos parámetros para comparar distintos sistemas de bases de datos, ni presentar resultados que se ajusten a alguna clasificación oficial (como la del TPC-H). Mi objetivo es simplemente educarme como desarrollador de PostgreSQL, tal vez identificar e investigar algunos problemas, y compartir con otros mis conclusiones.

¿Comparación ecuánime?

Pienso que ninguna comparación entre las versiones publicadas en los últimos 12 años puede ser totalmente ecuánime. La razón es que cada software, para un sistema de base de datos, se desarrolla en un contexto específico, como por ejemplo el hardware. Piensen en las máquinas utilizadas hace 12 años: ¿cuántos núcleos tenían, cuánta memoria RAM? ¿Qué tipo de almacenamiento utilizaban?

Un típico servidor de rango medio en el año 2008 contaba quizás con 8-12 núcleos, 16 GB de RAM y un RAID con un par de unidades SAS. En la actualidad, un típico servidor de rango medio puede contar con un par de docenas de núcleos, cientos de GB de RAM y almacenamiento SSD.

El desarrollo de software está organizado por prioridades: siempre habrá más tareas que tiempo disponible. Por eso, es necesario seleccionar las tareas que ofrezcan la mejor relación costo-beneficio para los usuarios (especialmente los que financian directa o indirectamente el proyecto). Además, en el año 2008 algunas optimizaciones probablemente aún no eran relevantes. Por ejemplo, la mayoría de las máquinas no contaban con cantidades extremas de RAM, por lo que la optimización para grandes buffers compartidos aún no valía la pena. Por otro lado, muchos de los cuellos de botella de la CPU fueron eclipsados por el I/O, ya que la mayoría de las máquinas empleaban unidades de disco duro para el almacenamiento de datos.

Nota: Por supuesto, ya en esa época había clientes que usaban máquinas de mayor desempeño. Algunos usaban la versión comunitaria de Postgres con varios ajustes, otros decidieron utilizar una de las distintas variantes (forks) de Postgres con capacidades adicionales (por ejemplo, paralelismo masivo, consultas distribuidas, uso de FPGA, etc.). Por supuesto, esto también contribuyó al desarrollo de la comunidad.

A lo largo de los años, a medida que las máquinas de mayor desempeño se hicieron más comunes, más usuarios pudieron permitirse equipos con grandes cantidades de memoria RAM y un alto número de núcleos, lo cual incrementó la relación costo-beneficio. Los cuellos de botella fueron analizados y solucionados, permitiendo un mejor rendimiento de las nuevas versiones.

Esto significa que una prueba de rendimiento como esta siempre es un poco parcial. Dependiendo de la configuración (hardware, software), favorecerá a la versión más antigua o a la más reciente. De todas formas, he intentado elegir los parámetros del hardware y de la configuración para que el resultado no sea tan negativo para las versiones más antiguas.

El punto que estoy tratando de explicar es que lo anterior no significa que las versiones más antiguas de PostgreSQL fueran pésimas. Así es como funciona el desarrollo de software. Se abordan los cuellos de botella que los usuarios pueden encontrar con los sistemas actuales, no los que podrían encontrar de aquí a 10 años.

Hardware

Prefiero realizar pruebas de rendimiento basadas en el hardware físico al cual tengo acceso directo. Entre otras cosas, esto me permite disponer de todos los detalles y controlarlos. Así que he utilizado la máquina en nuestra oficina. Aunque no es nada sofisticado, considero sea lo suficientemente adecuada para este propósito.

  • 2x E5-2620 v4 (16 núcleos, 32 hilos)
  • 64GB RAM
  • Intel Optane 900P 280GB NVMe SSD (data)
  • 3 x 7.2k SATA RAID0 (tablespace temporal)
  • kernel 5.6.15, ext4
  • gcc 9.2.0, clang 9.0.1
He utilizado también una segunda máquina – de menor desempeño -, con sólo 4 núcleos y 8 GB de RAM, que generalmente presenta las mismas mejoras y regresiones, aunque menos pronunciadas.

pgbench

Para la prueba de rendimiento de todas las versiones he utilizado la última edición del conocido pgbench (incluida en PostgreSQL 13). Esto descarta posibles distorsiones debidas a las optimizaciones aportadas a pgbench a lo largo del tiempo, permitiendo que los resultados sean más comparables. La prueba de rendimiento evalúa diferentes situaciones, variando una serie de parámetros, como los siguientes:

tamaño

  • pequeño – los datos caben en los buffers de memoria compartidos, presentando problemas de bloqueo, etc.
  • mediano – los datos exceden el tamaño de los buffers de memoria compartidos pero caben en la memoria RAM, normalmente están vinculados a la CPU (o posiblemente al I/O para las cargas de trabajo de lectura y escritura)
  • grande – los datos exceden el tamaño de la RAM, principalmente vinculados al I/O

modos

  • sólo lectura – pgbench -S
  • lectura-escritura – pgbench -N

cantidad de clientes

  • 1, 4, 8, 16, 32, 64, 128, 256
  • el número de procesos de pgbench (-j) se ajusta en consecuencia

Resultados

OK, veamos los resultados. Presentaré primero los resultados del almacenamiento NVMe, luego mostraré algunos resultados interesantes usando el almacenamiento SATA RAID.

NVMe SSD / sólo lectura

Para el conjunto de datos de tamaño pequeño (que cabe completamente en los buffers de memoria compartidos), los resultados de sólo lectura aparecen así:
resultados de pgbench / sólo lectura en un conjunto de datos pequeño (tamaño 100, de 1,6 GB)

pgbench results / read-only on small data set (scale 100, i.e. 1.6GB)

Es evidente un aumento significativo del rendimiento en la versión 9.2, que introdujo una serie de mejoras como, por ejemplo, la función fast-path para el bloqueo. El rendimiento para un único cliente en realidad se reduce levemente, pasando de 47k tps a unos 42k tps. Pero en el caso de un mayor número de clientes, la mejora en la versión 9.2 es más evidente.
resultados de pgbench / sólo lectura en un conjunto de datos mediano (tamaño1000, de 16 GB)

pgbench results / read-only on medium data set (scale 1000, i.e. 16GB)

En el caso del conjunto de datos de tamaño medio (cuyo volumen excede el de los buffers de memoria compartidos, y que no obstante cabe en la RAM) también parece haber cierta mejora en la versión 9,2, aunque no tan clara como la anterior, seguida de una mejora mucho más clara en la 9,5, debida probablemente al perfeccionamiento de la escalabilidad del bloqueo.
resultados de pgbench / sólo lectura en un conjunto de datos grande (tamaño10000, de 160 GB)

pgbench results / read-only on large data set (scale 10000, i.e. 160GB)

En el conjunto de datos de mayor tamaño, donde lo más importante es la capacidad de utilizar eficazmente el almacenamiento, también hay cierta aceleración, gracias, probablemente, a las mejoras introducidas con la versión 9.5.

NVMe SSD / lectura-escritura

Los resultados obtenidos en la modalidad de lectura-escritura también muestran algunas mejoras, aunque no tan pronunciadas. En el conjunto de datos de tamaño pequeño, los resultados se observan así:
resultados de pgbench / lectura-escritura en un conjunto de datos pequeño (tamaño 100, de 1,6 GB)

pgbench results / read-write on small data set (scale 100, i.e. 1.6GB)

Se trata de una modesta mejora de unos 52k a 75k tps con un número suficiente de clientes. Para el conjunto de datos de tamaño medio, la mejora es mucho más clara – entre 27k y 63k tps, es decir, el rendimiento es más del doble.
resultados de pgbench / lectura-escritura en un conjunto de datos mediano (tamaño1000, de 16 GB)

pgbench results / read-write on medium data set (scale 1000, i.e. 16GB)

Para el conjunto de datos de mayor tamaño también se observa una mejora general, aunque parece haber cierta regresión entre las versiones 9,5 y 11.
resultados de pgbench / lectura-escritura en un conjunto de datos grande (tamaño 10000, de 160 GB)

pgbench results / read-write on large data set (scale 10000, i.e. 160GB)

SATA RAID / sólo lectura

Para el almacenamiento SATA RAID, los resultados de sólo lectura no son tan favorables. Podemos ignorar los conjuntos de datos de tamaño pequeño y mediano, para los cuales el sistema de almacenamiento es irrelevante. Para el conjunto de datos de gran tamaño, el rendimiento es bastante elevado, aunque parece disminuir con el tiempo, especialmente desde la versión 9.6 de PostgreSQL. Desconozco la razón del problema (nada en las notas de la versión 9.6 se destaca claramente como elemento sospechoso), pero parece existir algún tipo de regresión.
resultados de pgbench con SATA RAID / sólo lectura en un conjunto de datos grande (tamaño 10000, de 160 GB)

pgbench results on SATA RAID / read-only on large data set (scale 10000, i.e. 160GB)

SATA RAID / lectura-escritura

Sin embargo, el comportamiento en la modalidad de lectura-escritura parece mucho más favorable. En el conjunto de datos de tamaño pequeño, el rendimiento incrementa de unas 600 tps a más de 6000 tps. Me atrevería a afirmar que esto se debe a las mejoras en el group commit en las versiones 9.1 y 9.2.
resultados de pgbench con SATA RAID / lectura-escritura en un conjunto de datos pequeño (tamaño 100, de 1.6 GB)

pgbench results on SATA RAID / read-write on small data set (scale 100, i.e. 1.6GB)

Para los de tamaño mediano y grande se observa una mejora similar, aunque inferior, ya que el almacenamiento necesita manejar también las peticiones del I/O para la lectura y escritura de los bloques de datos. En el caso del conjunto de tamaño mediano necesitamos únicamente realizar operaciones de escritura (ya que los datos caben en la memoria RAM). En cambio, en el caso del conjunto de gran tamaño, también necesitamos realizar operaciones de lectura, por lo que el rendimiento máximo se reduce aún más.
resultados de pgbench con SATA RAID / lectura-escritura en un conjunto de datos mediano (tamaño 1000, de 16 GB)

pgbench results on SATA RAID / read-write on medium data set (scale 1000, i.e. 16GB)

resultados de pgbench con SATA RAID / lectura-escritura en un conjunto de datos grande (tamaño 10000, de 160 GB)

pgbench results on SATA RAID / read-write on large data set (scale 10000, i.e. 160GB)

Conclusión y perspectiva futura

En resumen, para la configuración con almacenamiento NVMe los resultados parecen ser muy positivos. En la carga de trabajo de sólo lectura se observa un incremento moderado de la velocidad de ejecución en la versión 9.2 y un incremento significativo en la 9.5, gracias a las optimizaciones de la escalabilidad. En cambio, a lo largo del tiempo, en la carga de trabajo de lectura-escritura aplicada a múltiples versiones principales e intermedias, el rendimiento ha aumentado aproximadamente de dos veces. Sin embargo, las conclusiones de la prueba con la configuración SATA RAID son algo contradictorias. En el caso de la carga de trabajo de sólo lectura existe mucha variabilidad/fluctuación, y una posible regresión en la versión 9.6. Para la carga de trabajo de lectura-escritura, se registra un considerable aumento de la velocidad de ejecución en la versión 9.1, con un incremento repentino del rendimiento que pasa de 100 tps a 600 tps, aproximadamente.

¿Qué mejoras se introducirán en las futuras versiones de PostgreSQL? La verdad es que no tengo una idea muy clara de cuál será la próxima novedad importante, pero estoy seguro de que otros desarrolladores de PostgreSQL tendrán ideas geniales que harán las cosas más eficientes o permitirán aprovechar los recursos hardware disponibles. La revisión que mejora la escalabilidad en un sistema con muchas conexiones, o la que añade soporte para buffers WAL no volátiles son ejemplos de estas mejoras. Podríamos ser testigos de algunas mejoras radicales en el almacenamiento PostgreSQL (formato en disco más eficiente, uso de I/O directo, etc.), indexación, etc.

   
Etiquetas: benchmarking, performance, pgbench
Compartir esta entrada
  • Compartir en Facebook
  • Compartir en Twitter
  • Share on WhatsApp
  • Compartir en LinkedIn
/wp-content/uploads/2019/04/2ndQuadrant-Logo-e1554357894467.png 0 0 Tomas Vondra /wp-content/uploads/2019/04/2ndQuadrant-Logo-e1554357894467.png Tomas Vondra2020-10-16 14:52:532020-10-16 15:12:34Rendimiento OLTP desde PostgreSQL 8.3
0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Search

Get in touch with us!

Recent Posts

  • PG Phriday: 10 cosas que Postgres podría mejorar – Parte 3 noviembre 8, 2020
  • Búsqueda de texto completo desde PostgreSQL 8.3 noviembre 5, 2020
  • Webinar: Mejores prácticas para la carga masiva de datos en PostgreSQL [continuación] noviembre 4, 2020
  • Números aleatorios noviembre 4, 2020
  • ¿Qué partición de mi base de datos PostgreSQL contiene una fila determinada? noviembre 1, 2020

Featured External Blogs

Tomas Vondra's Blog

Our Bloggers

  • Simon Riggs
  • Alvaro Herrera
  • Andrew Dunstan
  • Craig Ringer
  • Francesco Canovai
  • Gabriele Bartolini
  • Giulio Calacoci
  • Ian Barwick
  • Marco Nenciarini
  • Mark Wong
  • Pavan Deolasee
  • Petr Jelinek
  • Shaun Thomas
  • Tomas Vondra
  • Umair Shahid

PostgreSQL Cloud

2ndQuadrant ANALYZE autoanalyze AutoVacuum benchmarking best practice bulk insert community data import data load EDB full text search GIN GIST indexes java JSON JSONB jsonpath mvcc OmniDB open source Partitioning partitions performance pgbench PG Phriday Pluggable Storage postgres PostgreSQL PostgreSql analyze postgresql vacuum prng pseudorandom number generators r2dbc RUM tableoid TPC-H TPCH Vacuum vacuuming VODKA webinars XID

  • Twitter
  • Linkedin
  • Facebook
  • Youtube
  • Mail

Soporte y Servicios

Soporte de producción 24/7

Soporte para desarrolladores

DBA remoto para PostgreSQL

Monitoreo para bases de datos PostgreSQL

Health Check para PostgreSQL

Ajustes de Rendimiento para PostgreSQL

Auditoría de seguridad para bases de datos

Actualice PostgreSQL

Evaluación de Migración hacia PostgreSQL

Migre desde Oracle

Productos

PostgreSQL de alta disponibilidad

BDR

2ndQPostgres

pglogical

repmgr

Barman

Postgres Cloud Manager

Firewall SQL

Postgres-XL

OmniDB

Postgres Installer

2UDA

Centro de Aprendizaje Postgres

PostgreSQL

Blog

Webinars

Libros

Videos

Formación

Casos de Estudio

Eventos

Sobre nosotros

Sobre 2ndQuadrant

¿Qué significa «2ndQuadrant»?

Noticias

Trabaje con nosotros

Nuestro equipo

© 2ndQuadrant Ltd. All rights reserved | Privacy Policy
  • Twitter
  • LinkedIn
  • Facebook
  • Youtube
  • Mail
VACUUM y ANALYZE en PostgreSQL – Consejos basados en las mejores prá... VACUUM y ANALYZE en PostgreSQL - Consejos basados en las mejores prácticas Cuándo implementar o actualizar a una nueva versión principal de PostgreSQL Cuándo implementar o actualizar a una nueva versión principal de PostgreS...
Desplazarse hacia arriba
×