Re: ~400 TPS - good or bad?
От | Greg Smith |
---|---|
Тема | Re: ~400 TPS - good or bad? |
Дата | |
Msg-id | 4C13F225.5020400@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: ~400 TPS - good or bad? (Szymon Kosok <szymon@mwg.pl>) |
Список | pgsql-performance |
Szymon Kosok wrote: > I've found in mailing list archive that scale = 1 is not good idea. So > we have ran pgbench -s 200 (our database is ~3 GB) -c 10 -t 3000 and > get about ~600 TPS. Good or bad? > pgbench in its default only really tests commit rate, and often that's not what is actually important to people. Your results are normal if you don't have a battery-backed RAID controller. In that case, your drives are only capable of committing once per disk rotation, so if you have 7200RPM drives that's no more than 120 times per second. On each physical disk commit, PostgreSQL will include any other pending transactions that are waiting around too. So what I suspect you're seeing is about 100 commits/second, and on average 6 of the 10 clients have something ready to commit each time. That's what I normally see when running pgbench on regular hard drives without a RAID controller, somewhere around 500 commits/second. If you change the number of clients to 1 you'll find out what the commit rate for a single client is, that should help validate whether my suspicion is correct. I'd expect a fairly linear increase from 100 to ~600 TPS as your client count goes from 1 to 10, topping out at under 1000 TPS even with much higher client counts. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
В списке pgsql-performance по дате отправления: