Re: 100% CPU pg processes that don't die.

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: 100% CPU pg processes that don't die.
Дата
Msg-id dcc563d10808102053ja35ee8ete04e9b36eaafd10d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 100% CPU pg processes that don't die.  ("Scott Marlowe" <scott.marlowe@gmail.com>)
Ответы Re: 100% CPU pg processes that don't die.  (Greg Smith <gsmith@gregsmith.com>)
Список pgsql-general
On Sat, Aug 9, 2008 at 2:54 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> On Sat, Aug 9, 2008 at 2:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> "Scott Marlowe" <scott.marlowe@gmail.com> writes:
>>> I'm load testing a machine, and i'm seeing idle in transaction
>>> processes that are no longer hooked to any outside client, that pull
>>> 100% CPU and can't be kill -9ed.
>>
>> To my knowledge, the only way a process can't be kill -9'd is if it's
>> stuck inside the kernel (typically, doing I/O to a nonresponsive disk).
>> There's certainly no way for a userland process to defend itself against
>> kill -9.  So my immediate response would have been to look for a
>> hardware problem, or failing that a kernel bug.  I see from the
>> subsequent thread that indeed hardware failure looks to be the answer,
>> but that should have been your first assumption.
>
> It was before this. That's why I'd swapped the RAID cards.  It's just
> that this is the first time this has happened without killing the box,
> so I wanted to be sure it didn't look like something else to anybody.

Just as a followup several hours later the other machine started
producing the same effects.  I'm gonna go trawl through the lkml to
see if they have any info on this problem.

The good news is that both Centos 5.2 and Ubuntu 7.10 seem immune to
this particular bug, and have been running 13 hours now without a
hitch.

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

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: Response time between shared buffer cache and operating system
Следующее
От: Robert Treat
Дата:
Сообщение: Re: mailing list/newsgroup disconnect