Angelo Astorga escribió:
> es un copy a una tabla que posee 2 millones de registro.
¿cuál es el problema entonces? Parece obvio que una lectura de una
tabla completa debería saturar los recursos que le entregues, para poder
terminar la lectura lo antes posible.
--
Álvaro Herrera
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 revisara proceso que consu
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 con el postmaster, aplique
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 n
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 2 millones de registro.
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 que
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 años?
https://access.redhat
drasticamente y al volver a levantar el servicio sube
rápidamente al 100%,
Saludos,
-- Mensaje reenviado --
De: *Alvaro Herrera* <mailto:alvhe...@alvh.no-ip.org>>
Fecha: 19 de diciembre de 2017, 14:45
Asunto: Re: [MASSMAIL]Postgresql problema !!!
Para: Miguel Panue
drasticamente y al volver a levantar el servicio sube rápidamente al
100%,
Saludos,
-- Mensaje reenviado --
De: Alvaro Herrera
Fecha: 19 de diciembre de 2017, 14:45
Asunto: Re: [MASSMAIL]Postgresql problema !!!
Para: Miguel Panuera IUVADE
Cc: gilberto.casti...@etecsa.cu, Angelo Astorga
Miguel Panuera IUVADE escribió:
> Una pregunta a los listeros, alguna funcion puede hacer que el procesador
> se vaya a 100???
claro ...
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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.
>
>
>
> On 2017-12-19 11:52, An
Supones Angelo que debes darnos un poco mas de información, So versión
de PostgreSQL, etc.
On 2017-12-19 11:52, Angelo Astorga wrote:
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
14 matches
Mail list logo
