Re: a heavy duty operation on an "unused" table kills my server

Поиск
Список
Период
Сортировка
От Matthew Wakeling
Тема Re: a heavy duty operation on an "unused" table kills my server
Дата
Msg-id alpine.DEB.2.00.1001201319310.6195@aragorn.flymine.org
обсуждение исходный текст
Ответ на Re: a heavy duty operation on an "unused" table kills my server  (Greg Smith <greg@2ndquadrant.com>)
Ответы Re: a heavy duty operation on an "unused" table kills my server  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-performance
On Fri, 15 Jan 2010, Greg Smith wrote:
>> It seems to me that CFQ is simply bandwidth limited by the extra processing
>> it has to perform.
>
> I'm curious what you are doing when you see this.

16 disc 15kRPM RAID0, when using fadvise with more than 100 simultaneous
8kB random requests. I sent an email to the mailing list on 29 Jan 2008,
but it got thrown away by the mailing list spam filter because it had an
image in it (the graph showing interesting information). Gregory Stark
replied to it in
http://archives.postgresql.org/pgsql-performance/2008-01/msg00285.php

I was using his synthetic test case program.

> My theory has been that the "extra processing it has to perform" you describe
> just doesn't matter in the context of a fast system where physical I/O is
> always the bottleneck.

Basically, to an extent, that's right. However, when you get 16 drives or
more into a system, then it starts being an issue.

Matthew

--
For every complex problem, there is a solution that is simple, neat, and wrong.
                                                      -- H. L. Mencken

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

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Следующее
От: Kaloyan Iliev Iliev
Дата:
Сообщение: Re: Change query join order