Re: multi-threaded pgbench
От | Greg Smith |
---|---|
Тема | Re: multi-threaded pgbench |
Дата | |
Msg-id | alpine.GSO.2.01.0907281204310.29621@westnet.com обсуждение исходный текст |
Ответ на | Re: multi-threaded pgbench (Josh Williams <joshwilliams@ij.net>) |
Ответы |
Re: multi-threaded pgbench
|
Список | pgsql-hackers |
On Tue, 28 Jul 2009, Josh Williams wrote: > Maybe pgbench itself is less of a bottleneck in this environment, > relatively speaking? On UNIXish systems, you know you've reached the conditions under which the threaded pgbench would be helpful if the pgbench client program itself is taking up a large percentage of a CPY just by itself. If your test system is still setup, it might be interesting to try the 64 and 128 client cases with Task Manager open, to see what percentage of the CPU the pgbench driver program is using. If the pgbench client isn't already pegged at a full CPU, I wouldn't necessarily threading it to help--it would just add overhead that doesn't buy you anything, which seems to be what you're measuring. All the Linux tests suggest that limit tends up show up at over 20,000 TPS nowawadys, so maybe your Window system is bottlenecking somewhere completely different before it reaches saturation on the client. In any case, Josh's review is exactly what I wanted to see here--the code does compile and run successfully for someone besides its author under Windows. Making it *effective* on that platform might end up being outside the scope of what we want to chew on right now. I'll have updated performance results to submit later this week against the updated patch. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-hackers по дате отправления: