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
|
Список | 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 по дате отправления: