Gracias por los comentarios Raúl.
Tenemos un RAID10 en el servidor donde actualmente se graban los logs y
xlogs, una de las mejoras en IO es desviar los logs a otro disco, eso lo
tenemos en la lista de cambios ya.
Respecto a la redundancia de potencia, también la tenemos, no a ese
nivel pero sí con dos fuentes switch y UPS con generador.
Respecto al caché de disco, leí en algun lado buscando estos tips que
se recomienda configurar el postgres de acuerdo al buffer de disco
disponible, para mejor aprovechamiento del mismo, pero no recuerdo a qué
parámetro se refería.
Voy a seguir leyendo, y cualquier otra recomendación de configuración
será de gran utilidad.
saludos y gracias
Mario Sileone
El 13/05/2014 11:42 a.m., raul andrez gutierrez alejo escribió:
hola Mario.
yo administro una db que realiza 4millones de tranaciones por hora y
esta configura una SAN "rapida" de 50GB la partcion para los
pg_xlog(WAL) y en otra SAN mas lenta los pg_data, esta configurado el
pg_xlog "tan grandre" para poder almacenar sifiecientes WALs mientras se
sincroniza algun esclavo, no se que tipo de disco tenga, pero puedes
pensar en tener un SSD que tiene mejor rendimiento.
Tambien puede pensar en desactivar el uso de barrier en las particiones,
esto es algo arriesgado y solo se puede hacer si confia el 200% en su
unidad de respaldo de potencia(2 fuentes redundante conectadas cada una
a una UPS diferente y cada UPS en un "taco" electrico diferente), al
desactivar la barrier cuando se realiza un comit el SO retorna que ya se
escribio en disco duro el comit, pero en realiadad está en la cache del
disco duro, si una consulta lee este dato el disco retorna la
informacion, pero si hay una perdida de energia esa ultima informacion
menor a 1 o 2 segundos se puede perder lo cual puede generrar corrupcion
de datos.
http://www.postgresql.org/docs/9.0/static/wal-reliability.html
un parametro que puede mejorar el rendimiento del disco es desactivar
"enable_material" pero solo existe apartir de 9.0.
http://www.postgresql.org/docs/9.0/static/runtime-config-query.html
El 13 de mayo de 2014, 8:49, Mario Sileone <[email protected]
<mailto:[email protected]>> escribió:
Estimada lista:
Tenemos un servidor con una alta carga de Inserts y Updates
(mas de 5 millones diarios) y me gustaría saber si alguien ha tenido
experiencia en la optimización del WAL para bases de datos con
similar carga.
Trabajamos en un Servidor de 16 núcleos (2x8 si mal no
recuerdo) y 24 GB de RAM cn CentOS 6.
Tenemos tablas paticionadas por mes, donde se insertan
+2.000.000 de registros diarios y por supuesto, muchas consultas
entre fechas de estas tablas, sumado a post procesos que generan un
alto nivel de IO en el servidor.
Actualmente estamos en Postgres 8.4, y en breve pasaremos a
Postgres 9.2, pero mientras tanto necesitamos optimizar la carga
actual en 8.4.
Lo que no tengo claro es si, estiramos el tiempo de checkpoints
o límite de bloques, la escritura se hace completa de todos los
bloques o sólo las tuplas limpias (en caso de los updates) o si
modificar otras configuraciones como el bgwriter_, checkpoint_, etc.
podemos llegar a sacar un poco más de jugo a nuestro servidor actual.
Actualmente, la consulta pg_stat_bgwriter nos brinda esta información:
checkpoints_timed checkpoints_req buffers_checkpoint
buffers_clean maxwritten_clean buffers_backend buffers_alloc
259 40 6451702 40354 213 350116 4088648
Alguna sugerencia?
Desde ya muchas gracias y saludos
--
Mario Sileone
-
Enviado a la lista de correo pgsql-es-ayuda
([email protected] <mailto:[email protected]>__)
Para cambiar tu suscripción:
http://www.postgresql.org/__mailpref/pgsql-es-ayuda
<http://www.postgresql.org/mailpref/pgsql-es-ayuda>
--
Raul Andres Gutierrez Alejo
--
Mario Sileone
-
Enviado a la lista de correo pgsql-es-ayuda ([email protected])
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
