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.1001211151240.6195@aragorn.flymine.org обсуждение исходный текст |
Ответ на | Re: a heavy duty operation on an "unused" table kills my server (Greg Smith <greg@2ndquadrant.com>) |
Список | pgsql-performance |
On Wed, 20 Jan 2010, Greg Smith wrote: >> Basically, to an extent, that's right. However, when you get 16 drives or >> more into a system, then it starts being an issue. > > I guess if I test a system with *only* 16 drives in it one day, maybe I'll > find out. *Curious* What sorts of systems have you tried so far? As the graph I just sent shows, the four schedulers are pretty-much identical in performance, until you start saturating it with simultaneous requests. CFQ levels out at a performance a little lower than the other three. > Seriously though, there is some difference between a completely synthetic > test like you noted issues with here, and anything you can see when running > the database. Granted, this test is rather synthetic. It is testing the rather unusual case of lots of simultaneous random small requests - more simultaneous requests than we advise people to run backends on a server. You'd probably need to get a RAID array a whole lot bigger than 16 drives to have a "normal workload" capable of demonstrating the performance difference, and even that isn't particularly major. Would be interesting research if anyone has a 200-spindle RAID array hanging around somewhere. Matthew -- A good programmer is one who looks both ways before crossing a one-way street. Considering the quality and quantity of one-way streets in Cambridge, it should be no surprise that there are so many good programmers there.
В списке pgsql-performance по дате отправления: