Re: Optimización del WAL/BGWriter

Martín, gracias por tu respuesta.
Si, he encontrado muchos posibles problemas, y estoy analizando todo
con vmstat,iostat, consultando la escritura con pg_bg_writer y revisando
los log_checkpoint, que al parecer están correctos.
En base a lo recopilado comenzaré a testear cambios, la consulta pasaba
por si existía algo muy obvio que no he tenido en consideración, pero
viendo la cantidad de factores que afectan, y basándome en unos escritos
de Gregory Smith muy interesantes veremos como avanza todo.

Saludos y gracias

Mario.

El 13/05/2014 06:08 p.m., Martín Marqués escribió:
> Hola Mario,
>
> El *problema* que describís no es simple, y dar con una solución
> requiere más investigación. Hay que ver exactamente que es lo que esta
> pasando cuando se está escribiendo a disco y donde están los problemas
> de E/S.
>
> Podés tener problemas de configuración de PostgreSQL, o de
> configuración del Linux, o algún bloqueo, o simplemente que tu HW no
> pueda con la tarea que se le esta encomendando (u otras opciones que
> ahora no se me ocurren).
>
> BTW, si actualizas, deberías pensar en 9.3 así tenés más dulces. ;)
>
> Saludos,
>
>
> El día 13 de mayo de 2014, 12:02, Mario Sileone <msileone(at)gmail(dot)com> escribió:
>> 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 <msileone(at)gmail(dot)com
>>> <mailto:msileone(at)gmail(dot)com>> 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
>>> (pgsql-es-ayuda(at)postgresql(dot)org
>>> <mailto:pgsql-es-ayuda(at)postgresql(dot)org>__)
>>> 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 (pgsql-es-ayuda(at)postgresql(dot)org)
>> Para cambiar tu suscripción:
>> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>
>
>

--
Mario Sileone

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda