Buenas tardes grupo, vuelvo a revivir esta pregunta
Buenos días grupo, tengo un problema en un sistema de la oficina, cada 3
meses aproximadamente un Update sobre una tabla se vuelve muy lento, cual
podría ser la causa y una solución para esto? Solo dandole un reboot al
servidor vuelve todo a la no
Aqui envío mas datos
-[ RECORD 1 ]-+---
relid | 17469
indexrelid| 17531
schemaname| public
relname | tabla1
indexrelname | pk_tabla1_codint
idx_scan | 62275
idx_tup_read | 64746
idx_tup_fetch | 62275
-[ RECORD 2 ]-+---
relid | 174
Aquí envío algunos datos
Version del PostgreSQL = 8.3.3 en un redhat 4.3
-[ RECORD 1 ]--+-
relname| tabla1
relnamespace | 17382
reltype| 17471
relowner | 10
relam | 0
relfilenode| 85147
reltablespace | 0
relpages
En realidad la aplicación no la desarrollé yo, pero está desarrollada con
foxpro
El 29 de abril de 2013 12:54, Jaime Casanova escribió:
> 2013/4/29 marcelo mendoza :
> > Buenos días grupo, tengo un problema en un sistema de la oficina, cada 3
> > meses aproximadamente un Update sobre una tabla s
2013/4/29 marcelo mendoza :
> Buenos días grupo, tengo un problema en un sistema de la oficina, cada 3
> meses aproximadamente un Update sobre una tabla se vuelve muy lento, cual
> podría ser la causa y una solución para esto? Solo dandole un reboot al
> servidor vuelve todo a la normalidad, pero r
Has visto las estadisticas sobre esa tabla?
- Cantidad de tuplas muertas
- Uso de los indices,
- Tamaño de la tabla y los indices.
¿Qué versión de PostgreSQL están usando?
¿Cuánto tienes dedicado al maintenance_work_mem?
El 29 de abril de 2013 11:42, marcelo mendoza
escribió:
El 29 de abril d
hola Fernando y Jaime
*Como dijo Jaime, work_mem es excesivo más si tienes hasta 1000 conexiones
simultáneas. Que por cierto esa cantidad de conexiones es otra barbaridad.
Considera implementar un pool de conexiones con pgbouncer o pgpool2 y limita
las conexiones a la base a 40-60 para tu escenari
> -Mensaje original-
> De: Miguel Angel Hernandez Moreno
>
> Disculpen e tenido un problema algo interesante, tengo tablas
> con millones de registros y hago select muy complejos pero la
> verdad es que el problema no son los SELECT por que los
> Select lo efectua en "ms" y por ejemp
*
a mi alguna vez me paso algo así
el problema fue una mezcla de (1) no hacer full vacumm con cierta
regularidad a la tabla gigantesca que tenia (2) tener demasiadas
relaciones en esa tabla, lo cual hacia que un update masivo removiera
muchas cosas en la db*
de hecho tengo un crontab que hace el f
a mi alguna vez me paso algo así
el problema fue una mezcla de (1) no hacer full vacumm con cierta
regularidad a la tabla gigantesca que tenia (2) tener demasiadas
relaciones en esa tabla, lo cual hacia que un update masivo removiera
muchas cosas en la db
saludos
El día 5 de junio de 2010 17:21,
2010/6/6 Miguel Angel Hernandez Moreno :
>
> effective_cache_size esta en 21GB cuanto ram tienes? si en verdad
> tienes mas de 21GB probablemente puedes subirle un poco a
> shared_buffers
>
> tengo 32 RAM y 16 SWAP
>
32GB supongo, si este es un servidor dedicado podrias poner 8GB en
shared_buffers
*effective_cache_size esta en 21GB cuanto ram tienes? si en verdad
tienes mas de 21GB probablemente puedes subirle un poco a
shared_buffers*
tengo 32 RAM y 16 SWAP
*> work_mem = 1GB # min 64kB
esto me parece excesivamente alto*
cuanto recomiendas y por que
y como deber
2010/6/5 Miguel Angel Hernandez Moreno :
>
> los Select lo efectua
> en "ms" y por ejemplo hago los updates y 3 updatese tardan 1 segundo, y para
tienes triggers en esa tabla? que tal si muestras un EXPLAIN ANALYZE
de alguno de esos UPDATEs
(OJO que eso va a ejecutar el UPDATE asi que mejor que se
13 matches
Mail list logo
