Algunos consejos generales para aumentar el rendimiento
Como hemos dicho muchas veces, no existe siempre la solución perfecta para aumentar el rendimiento de nuestro sistema. Las bases de datos son sistemas dinámicos que se utilizan de diferentes maneras y contienen diferentes tipos de datos.
Una configuración que funciona bien con un sistema, no tiene porque hacerlo con otro y existen muchos factores que pueden afectar positiva y negativamente al rendimiento.
Pero existen diferentes técnicas que se pueden usar aisladas ó en conjunto que ayudan en muchos casos a mejorar el rendimiento. Aqui teneis una pequeña lista con algunos consejos generales que suelen ayudar en muchas ocasiones cuando se necesita mejorar el rendimiento. En esta lista no tendremos en cuanta las mejorias que se pueden obtener con el uso adecuado de SQL y normalización de los datos.
- Ejecutar VACUUM ANALYZE tan a menudo como sea necesario, Bien manualmente ó ajustanto autovacuum si es necesario
- Un sistema de discos de alto rendimiento suele ser más importante que la cantidad de memoria disponible y esta a su vez más importante que la CPU utilizada.
- Un servidor de bases de datos nunca tendra suficiente memoria. Cuanta más memoria, mejor.
- Cuanto más discos disponibles en RAID, mejor. Usar Tablespaces para organizar los datos.
- RAID 1+0 / 0+1 suele funcionar mejor que RAID 5.
- Saparar el registro de transacciones (ficheros WAL) del resto de datos, usar diferentes discos.
- Aumentar el valor de checkpoint_segments en sistemas con una alta concurrencia de actualizaciones de los datos (insert,update,delete)
- Discos SCSI y SAS som preferibles en servidores con un alto nivel de utilización
- Múltiples CPUs ayudan a ejecutar/realizar trabajos paralelos en nuestras bases de datos.
- Ejecutar CLUSTER cuando sea viable en tablas con una alto nivel de actualización de datos.
- Utilizar un servidor dedicado siempre que sea posible. Será más facil de configurar y ajustar para mejorar nuestro rendimiento.
- Al inicializar/poblar una nueva base de datos con una gran cantidad de datos:
- Usar COPY en vez de INSERT
- Remover los indices durante la restauración de los datos.
- Aumentar el valor de maintenance_work_mem
- Aumentar el valor de checkpoint_segments
- fsync=false !! No olvidar cambiar este valor a TRUE cuando termineis de restaurar los datos !!
- No olvidar ejecutar ANALYZE al termino de la restauración de los datos
Bueno, y hasta aqui los consejos generales, más adelante iremos profundizando en aspectos concretos que pueden afectar al rendimiento.
- 8163 lecturas
Inicio de sesión
PostgreSQL
 Contenidos distribuidos bajo la Licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.5 cuando no se especifique lo contrario © Copyright 2009-2011 PosgreSQL-es - Rafael Martinez - Condiciones de uso |
Comentarios
por que fsync=false?
Lun, 20/04/2009 - 15:29 — AnónimoEse parametro afecta a todas las transacciones en curso y es peligroso tenerlo en OFF. Al menos desde 8.3 existe synchronous_commit tiene el mismo efecto en rendimiento pero se setea a nivel de sesion y si el servidor por algun momento falla no existe el riesgo de corrupcion de datos.
http://www.postgresql.org/docs/current/static/runtime-config-wal.html
http://www.postgresql.org/docs/current/static/wal-async-commit.html
Re: por que fsync=false?
Lun, 20/04/2009 - 16:45 — ralfmMuy buena apreciación. Como tu comentas y yo recalco en el artículo, fsync = off es muy peligroso y no se deberia de utilizar en sistemas en producción.
El artículo dice que se puede utilizar solamente cuando estemos restaurando los datos. Yo lo he utilizado cuando he realizado actualizaciones mayores de PostgreSQL, durante la importación de grandes cantidades de datos y nadie tiene acceso a las bases de datos.
Con otras palabras, en entornos controlados, nunca en producción y sabiendo lo que se hace.
synchronous_commit, como tu dices, es la única opción viable si se tiene que utilizar en producción y podemos permitirnos el perder algunas transacciones (sin corrupción de datos). Pero solo está disponible a partir de la version 8.3.
No estaría mal hacer un test para ver el aumento de velocidad que se consigue con las diferentes opciones.
No estoy de acuerdo del todo en alguna cosa...
Sáb, 25/04/2009 - 20:08 — AnónimoPor experiencia en BBDD de alta concurrencia, es más importante la RAM que la velocidad real de los discos, sobre todo si la BBDD es principalmente lectura y no hay inserciones o updates masivos.
¿Por qué? Pues porque a más RAM, más cacheado por parte de sistema operativo. En un sistema QUAD XEON con una carga media de 60% de BBDD os puedo asegurar que con una buena cantidad de RAM las operaciones de I/O al disco duro, si no hay operaciones masivas de escritura, son mínimas una vez que el sistema lleva un rato operando y el sistema operativo ha cacheado adecuadamente.
Las operaciones de escritura puntuales, igualmente pueden amortiguarse enormemente con una controladora simple con un poco de caché (64,128MB).
Ahora, eso sí, si las inserciones son masivas, entonces los discos se notarán una auténtica barbaridad.
A modo de ejemplo, en el sistema que os comento se sustituyó un sistema de 3 discos SCSI antiguo en RAID5 (sí, RAID5 sucks!!!) por una cabina iSCSI de 8 discos en RAID1. El rendimiento en escritura se multiplicó por tres, y sin embargo la operativa en el día a día apenas se modificó. Una serie de procesos batch nocturos pasaron de tardar hora y media a apenas 30 minutos, donde había muchas inserciones y un VACUUM nocturno, y un matenimiento de reindexación semanal pasó a tardar solo 1 hora (antiguamente casi tres). Pero el rendimiento general en el día a día apenas se notó.
Así que mi consejo es, primero la RAM, luego los discos.
memoria vs. discos
Sáb, 25/04/2009 - 21:52 — rafaelmaGracias por la puntualización y el comentario de calidad.
En el caso que comentas, principalmente lectura y sin inserciones o updates masivos, tienes toda la razón. Otro parametro a tener en cuenta, del cual no das datos, es el tamaño de la base de datos. Si no es muy grande en comparación a la memoria disponible, no se notarán mucho mejores discos, como tu dices. Pero si es el tamaño de la base de datos es mucho mayor que la memoria que podamos conseguir, mejores discos serán más importantes que la memoria, incluso en bases del tipo que comentas (aunque esto tambien dependerá de como y que datos se lean)
En el artículo se dan consejos generales y se avisa que no existe la solución perfecta. Cada base de datos es un mundo y tu ejemplo ilustra perfectamente esto, gracias por demostralo.
"no hay una transaccion en curso"
Mié, 10/08/2011 - 13:55 — AnónimoHola Gente, les comento que tengo un problema con un sistema que funciona con un postgresql 8.4 bastante concurrente con ubuntu server 10.04 y de repente es como que se congela y queda encolados los select y a veces aparece un lock table y todo colgado, es como que el unlock no solto la tabla y se cuelga todo. alguien me puede ayudar con esto? muchas gracias
D martin
Como se remueven estos indices?
Mar, 12/07/2011 - 18:21 — AnónimoRemover los indices durante la restauración de los datos
Dudas sobre optimización.
Jue, 19/05/2011 - 20:30 — ygarbeyHOla!!
Leí el articulo y me pareció bastante interesante, yo estoy tratando de obtener el mejor rendimiento posible en mi servidor con PostgreSQL 8.3.Ya revise los parámetros de configuración que menciona aqui asi como el max_conectios, el shared_buffer y work_men.Quisiera saber cuáles otros debo tener en cuenta para lograr la optimización deseada. Igualmente veo que administra un grupo importante de bases de datos y quiero saber si cada servidor debe tener un pgdata particular o es posible tener uno que sea común para todos.
Agradeceré infinitamente su ayuda.Qdo al tanto.. Saludos
Rendimiento de Memoria
Mié, 05/05/2010 - 20:43 — AnónimoBuenos dias
Tenemos un servidor con doble procesamiento y 16 gb de memoria ram, corriendo el linux y el manejador es el postgre, pero siento que las aplicaciones estan demasiado lentas, existe alguna manera de saber si el servidor esta utilizando todos los recursos de hardware que tiene.
gracias pos su aoporte
Stored Procedures
Mar, 25/05/2010 - 23:44 — AnónimoHola que tal, el uso de los stored procedures pueden ayudar a mejorar el performance de una base de datos concurrida?
fsync=true, muy, pero muy malo si quieres una BD rápida
Sáb, 27/06/2009 - 00:48 — AnónimoSi estas utilizando "fsync = true", es por que tienes una base de datos que se podría decir que es de solo lectura y es donde da "casi" igual tener este parametro "false" o "true". Por el contrario, si tu base de datos realiza sentencias "UPDATE", "INSERT", "VACUUM FULL", de forma constante y quieres un rendimiento "Bueno o muy Bueno", es mejor que coloques este parametro en "false".
¿Por que?, bueno una manera rápida de explicarlo es:
fsync=true --> Ir a disco por cada transacción
fsync=false --> Ir a cache de disco y/o cache de memoria por cada transacción, e ir a disco realmente cuando yo lo desee (ya que esto lo configuras en los WAL del archivo postgresql.conf).
NOTA: Jamas los discos por muy rápido que sean se acercarán siquiera a la velocidad de la memoria RAM, salvo este tipo de productos que revolucionaran la forma de pensar (Fusion-io ioDrive, www.fusionio.com/)
Por supuesto que para tener "fsync = false" debes cumplir con ciertas cosas que te permitan dormir confiado si eres el administrador de la base de datos, entre ellas estan:
* Un hardware con redundancia (funte de poder, discos en RAID, UPS, etc) y ademas muy confiable.
* Un respaldo de tu base de datos realizado con frecuencia.
Pero si eres de los que tine muchos recursos, pues no te queda otra que dormir confiado y hasta soñar si puedes utilizar cosas como:
* PostgreSQL PITR
* cluster de tu BD (actvo-activo->multimaster, activo-pasivo->master-slave).
Enviar nuevo comentario