Re: [PATCH] dtrace probes for memory manager
От | Greg Smith |
---|---|
Тема | Re: [PATCH] dtrace probes for memory manager |
Дата | |
Msg-id | 4B1EBC68.5030500@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [PATCH] dtrace probes for memory manager (Bernd Helmle <mailings@oopsware.de>) |
Ответы |
Re: [PATCH] dtrace probes for memory manager
|
Список | pgsql-hackers |
Bernd Helmle wrote: > I've tried to benchmark this now on my (fairly slow compared to server > hardware) MacBook and see some negative trend for those memory probes > in pgbench. Running dozens of rounds with pgbench (scale 150, 10 > clients / 1000 transactions) That makes for a 5.5 minute test, which is unfortunately close to the default checkpoint period. You're going to want a pgbench configuration that's doing thousands of operations per second to measure this overhead I think, and let it run a bit longer. The difference you're seeing could easily be just that that the "with probes" result had more checkpoints happen during testing than the other one--if it got even a single checkpoint more, that could be enough to throw results off using the default test and such low TPS results. Try this instead, which will give you a test where checkpoints have a minimal impact, but lots of memory will be thrown around: pgbench -i -s 10 <db> pgbench -S -c 10 -T 600 <db> That will do just SELECT statements against a much smaller database (about 160MB) and will run for 10 minutes each time. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: