Re: Performance on Sun Fire X4150 x64 (dd, bonnie++, pgbench)
От | Stephane Bailliez |
---|---|
Тема | Re: Performance on Sun Fire X4150 x64 (dd, bonnie++, pgbench) |
Дата | |
Msg-id | 488460ED.8090001@gmail.com обсуждение исходный текст |
Ответ на | Re: Performance on Sun Fire X4150 x64 (dd, bonnie++, pgbench) (Greg Smith <gsmith@gregsmith.com>) |
Ответы |
Re: Performance on Sun Fire X4150 x64 (dd, bonnie++,
pgbench)
Re: Performance on Sun Fire X4150 x64 (dd, bonnie++, pgbench) |
Список | pgsql-performance |
Greg Smith wrote: > > Note that I've had some issues with the desktop Ubuntu giving slower > results in tests like this than the same kernel release using the > stock kernel parameters. Haven't had a chance yet to see how the > server Ubuntu kernel fits into that or exactly what the desktop one is > doing wrong yet. Could be worse--if you were running any 8.04 I expect > your pgbench results would be downright awful. Ah interesting. Isn't it a scheduler problem, I thought CFQ was the default for desktop ? I doublechecked the 7.10 server on this box and it's really the deadline one that is used: cat /sys/block/sdb/queue/scheduler noop anticipatory [deadline] cfq Do you have some more pointers on the 8.04 issues you mentioned ? (that's deemed to be the next upgrade from ops) >> postgresql 8.2.9 with data and xlog as mentioned above > There are so many known performance issues in 8.2 that are improved in > 8.3 that I'd suggest you really should be considering it for a new > install at this point. Yes I'd definitely prefer to go 8.3 as well but there are a couple reasons for now I have to suck it up: - 8.2 is the one in the 7.10 repository. - I need plr as well and 8.3-plr debian package does not exist yet. (I know in both cases we could recompile and install it from there, but ...) > In general, you'll want to use a couple of clients per CPU core for > pgbench tests to get a true look at the scalability. Unfortunately, > the way the pgbench client runs means that it tends to top out at 20 > or 30 thousand TPS on read-only tests no matter how many cores you > have around. But you may find operations where peak throughput comes > at closer to 32 clients here rather than just 8. ok. Make sense. > As far as the rest of your results go, Luke's comment that you may > need more than one process to truly see the upper limit of your disk > performance is right on target. More useful commentary on that issue > I'd recomend is near the end of > http://www.commandprompt.com/blogs/joshua_drake/2008/04/is_that_performance_i_smell_ext2_vs_ext3_on_50_spindles_testing_for_postgresql/ > Yeah I was looking at that url as well. Very useful. Thanks for all the info Greg. -- stephane
В списке pgsql-performance по дате отправления: