Angelo creo que te podrian ayudar mas facil si copias literalmente la
salida del
select * from pg_stat_activity where pid = ;
El 20 de diciembre de 2017, 13:10, Alvaro Herrera
escribió:
> Angelo Astorga escribió:
> > Hola Daymel,
> > Me pediste que vía comando top
es un copy a una tabla que posee 2 millones de registro.
El problema que ahora que este servidor no esta en producción funciona
bien, pero no quiero meterlo a producción y que comience con lo mismo.
Por lo tanto, como saber si el postgresql como ambiente esta operando
normalmente, para no tener
Angelo Astorga escribió:
> Hola Daymel,
> Me pediste que vía comando top revisara proceso que consume cpu, eso hice y
> el proceso esta asociados con el postmaster, aplique comando vinculado con
> el pid del proceso
> select * from pg_stat_activity where pid = ;
>
> y hace mención a una tabla que
No nos dices si es una consulta, vacuum o algo más. Esa es la información
relevante.
Saludos
El 20 dic. 2017 1:05 p.m., "Angelo Astorga"
escribió:
> Hola Daymel,
> Me pediste que vía comando top revisara proceso que consume cpu, eso hice
> y el proceso esta asociados
Hola Daymel,
Me pediste que vía comando top revisara proceso que consume cpu, eso hice y
el proceso esta asociados con el postmaster, aplique comando vinculado con
el pid del proceso
select * from pg_stat_activity where pid = ;
y hace mención a una tabla que posee 2 millones de registro, lo cual
Hola Angelo:
El 20 dic. 2017 11:46 a.m., "Angelo Astorga"
escribió:
Ahora que sacamos el servidor de producción, lo estoy revisando y a simple
vista funciona normal.
realice la prueba sugerida por el colega Daymel y acusa id del postmaster
de una tabla que posee más de
Ahora que sacamos el servidor de producción, lo estoy revisando y a simple
vista funciona normal.
realice la prueba sugerida por el colega Daymel y acusa id del postmaster
de una tabla que posee más de 2 millones de registro.
Como saber si el postgresql esta operando normalmente, para no tener
2017-12-19 13:13 GMT-05:00 Angelo Astorga :
> Hola Lista,
> Dada la lectura de vuestras respuestas, cumplo con complementar información
> solicitada.
> Linux RH 4.4.7-3 64 bits + Postgresql Ver. 8.4.18 64 bits
En serio?!
Sabías que RH 4.4 perdió soporte hace más de 7
drasticamente y al volver a levantar el servicio sube
rápidamente al 100%,
Saludos,
-- Mensaje reenviado --
De: *Alvaro Herrera* <alvhe...@alvh.no-ip.org
<mailto:alvhe...@alvh.no-ip.org>>
Fecha: 19 de diciembre de 2017, 14:45
Asunto: Re: [MASSMAIL]Postgresql probl
drasticamente y al volver a levantar el servicio sube rápidamente al
100%,
Saludos,
-- Mensaje reenviado --
De: Alvaro Herrera <alvhe...@alvh.no-ip.org>
Fecha: 19 de diciembre de 2017, 14:45
Asunto: Re: [MASSMAIL]Postgresql problema !!!
Para: Miguel Panuera IUVADE <mpanu...@iuvad
Hola Angelo:
El 19 de diciembre de 2017, 11:52, Angelo Astorga
escribió:
> Hola lista,
> Desde un momento a otro la cpu del servidor se fue a 100%, donde gran
> parte de este consumo lo absorve postgresql. Desconozco que paso, dado que
> el mismo día x la mañana el
Logs de Postgres?, del servidor?,
Una pregunta a los listeros, alguna funcion puede hacer que el procesador
se vaya a 100???
El 19 de diciembre de 2017, 11:56, escribió:
> Supones Angelo que debes darnos un poco mas de información, So versión de
> PostgreSQL, etc.
>
¿Probaste ejecutar:
select * from pg_stat_activity where state <> 'idle';
para ver qué está corriendo el postgres?
El 19 de diciembre de 2017, 13:52, Angelo Astorga
escribió:
> Hola lista,
> Desde un momento a otro la cpu del servidor se fue a 100%, donde gran
> parte
Hola lista,
Desde un momento a otro la cpu del servidor se fue a 100%, donde gran parte
de este consumo lo absorve postgresql. Desconozco que paso, dado que el
mismo día x la mañana el servidor y sus recursos andaban como avión y ahora
solamente al subir servicio postgresql, comienzan las cpu a
14 matches
Mail list logo