Re: Spurious Stalls

Поиск
Список
Период
Сортировка
От Steve Kehlet
Тема Re: Spurious Stalls
Дата
Msg-id CA+bfosFpSGLYAO3Le1JRPoGAA53aQXcBMxZKgZmOY0t3s2d1Eg@mail.gmail.com
обсуждение исходный текст
Ответ на Spurious Stalls  (Christopher Nielsen <cnielsen@atlassian.com>)
Список pgsql-general
The cpu utilization increases to nearly 100%, in user space, and stays there, until the database is restarted.

postgres  1323 47.1  2.3 6667212 6087388 ?     Rs   00:00 276:00  \_ postgres: bitbucket bitbucket 172.17.10.1(5114) SELECT          

I see you have long-query logging enabled, what was this query doing? It seems like the oddball from your ps output, it was taking half your CPU. Or did you have to kill the db before it logged anything out. If so, while debugging something with a memory problem here we set up a cronjob to log out all running queries every minute, before the oom-killer would start killing stuff, maybe you could catch the culprit next time.

For the pids that you included strace outputs for, curious, why did you pick them? Were they using a lot of CPU? Except for the postmaster one (81372), I didn't see them in the ps output.


В списке pgsql-general по дате отправления:

Предыдущее
От: Jaco Engelbrecht
Дата:
Сообщение: Re: Spurious Stalls
Следующее
От: Khangelani Gama
Дата:
Сообщение: Using pg_start_backup() and pg_stop_backup() - using 9.1.2.2