Re: ayuda con cybercluster

El día 7 de mayo de 2009 8:11, Rodriguez Fernando
<rodriguez(at)ort(dot)edu(dot)uy> escribió:
> Eddy Ernesto Baños Fernández escribió:
>>
>> Hola a todos, tengo el siguiente problema:
>>
>> Estoy configurando un ambiente de producción para PostgreSQL, sobre un
>> entorno de réplica multimaestro usando la herramienta Cybercluster 1.2.1.
>> Cuento con 4 servidores HP Proliant BL 460c G1 con 2x Quad Core @2.00 GHz
>> 8Gb de RAM, luego de alguna investigación acerca del tuning de servidores
>> PostgreSQL para producción, configuré el archivo postgresql.conf de la
>> siguiente manera:
>>
>> (resumo los parámetros en los cuales hice cambios)
>>
>> max_connections = 4000 # ulimit –n 4096
>>
>> shared_buffers = 4194304kB #en /etc/sysctl.conf kernel.shmmax =
>> 68719473766 kernel.shmall = 4294967296
>>
>> maintenance_work_mem = 512MB
>>
>> max_stack_depth = 9MB
>>
>> max_fsm_pages = 900000
>>
>> max_fsm_relations = 50000
>>
>> fsync = on
>>
>> synchronous_commit = on
>>
>> wal_sync_method = fsync
>>
>> wal_buffers = 4MB
>>
>> commit_delay = 1000
>>
>> commit_siblings = 10
>>
>> checkpoint_segments = 128 #en /etc/sysctl.conf kernel.sem = 250 32000 32
>> 300
>>
>> checkpoint_completion_target = 0.9
>>
>> effective_cache_size = 6000MB
>>
>> default_statistics_target = 200
>>
>> constraint_exclusion = off
>>
>> autovacuum = on
>>
>> autovacuum_vacuum_threshold = 500000
>>
>> autovacuum_analyze_threshold = 500000
>>
>> deadlock_timeout = 6s
>>
>> max_locks_per_transaction = 128
>>
>> los servidores están configurados de la siguiente manera: 1 balanceador, 2
>> nodos de BD y 1 replicador en los cuales está instalado el Cybercluster
>> 1.2.1 que trae en su configuración PostgreSQL 8.3, el problema radica en que
>> incluso optimizando la memoria del sistema operativo cuando intentan acceder
>> desde un portal el cual genera aproximadamente 70 consultas por sesión 900
>> usuarios el sistema se literalmente explota, es decir los tiempos de
>> respuesta aumentan demasiado, es decir la página demora en cargar
>> aproximadamente 20 segundos.
>>

deberías separar los benchs para saber de donde proviene la lentitud.
Realiza explains sobre las consultas de manera 'local' en la base y verifica
lo tiempos desde la aplicación con la misma consulta.

verifica el iostat de los servidores.

Cyberculster es lento debido a que utiliza replicación sincrónica. Si
hay mucha carga de datos puede ser que se haga un poco pesado.

puede que necesites en este caso implementar la separación en tablespaces
distintos los índices y crear vistas materializadas para las consultas.

Si utiliza funciones hechas en el desarrollo, verificarlas si están armando
algún cuello de botella.

Calculo que contas con un ambiente de pre-produccion para la base de
datos... sería bueno que aplicaras previamente los cambios allí.

Pegá los resultados de la consulta más pesada que tengas y las estadísticas
de iostat ps -ef y ipcs.

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member