Re: Further info : Very high load average but no cpu utilization ?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Further info : Very high load average but no cpu utilization ?
Дата
Msg-id 13062.1021132784@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Further info : Very high load average but no cpu utilization ?  ("Rajesh Kumar Mallah." <mallah@trade-india.com>)
Ответы Re: Further info : Very high load average but no cpu utilization ?  ("Rajesh Kumar Mallah." <mallah@trade-india.com>)
Список pgsql-sql
"Rajesh Kumar Mallah." <mallah@trade-india.com> writes:
> [root@linux10320 root2]# ps auxwww| grep post
> postgres  1131  0.0  0.0 139424   4 ?        D    May1004/usr/local/pgsql/bin/postmaster
> postgres  1132  0.0  0.0 140412   4 ?        D    May10   0:13 postgres: stats buffer process
> postgres  1133  0.0  0.0 139576   4 ?        S    May10   0:18 postgres: stats collector process
> postgres  8046  0.0  0.0 238712   4 ?        D    00:25   0:13 postgres: tradein tradein_clients 130.94.20.27 SELECT
> postgres  8089  0.0  0.0 139812   4 ?        D    00:26   0:00 postgres: checkpoint subprocess
> postgres 11442  0.0  0.0 218152   4 ?        D    04:25   0:03 postgres: tradein tradein_clients 130.94.20.27 SELECT
> postgres 15453  0.1  0.0     0    0 ?        Z    08:17   0:09 [postmaster <defunct>]
> postgres 15455  0.0  0.0     0    0 ?        Z    08:17   0:00 [postmaster <defunct>]
> postgres 15456  0.0  0.0     0    0 ?        Z    08:18   0:00 [postmaster <defunct>]
> postgres 15457  0.0  0.0     0    0 ?        Z    08:19   0:00 [postmaster <defunct>]
> postgres 15462  0.0  0.0     0    0 ?        Z    08:20   0:01 [postmaster <defunct>]

I think your postmaster is stuck; it should have reaped those defunct
subprocesses instantly.  Given that you also seem to have a stuck
checkpoint process (8 hours to run a checkpoint?) there is probably
something hosed in the interprocess communication logic, but it's hard
to guess what from this amount of info.

At this point probably your best bet is to kill all the running postgres
processes (try SIGTERM first, then SIGKILL if that doesn't work) and
launch a postmaster from a fresh start.  Don't forget the ulimit this
time.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_stat_get_backend_pid seems to be listing non existant
Следующее
От: "Rajesh Kumar Mallah."
Дата:
Сообщение: Re: core file found...