Re: Multiprocessor performance
От | Jan Wieck |
---|---|
Тема | Re: Multiprocessor performance |
Дата | |
Msg-id | 200106051537.f55FbNe01609@jupiter.us.greatbridge.com обсуждение исходный текст |
Ответ на | Multiprocessor performance ("Valentin Puente" <vpuente@atc.unican.es>) |
Список | pgsql-hackers |
Valentin Puente wrote: > Hi all, > > I'm not a postgres hacker, but I' think that you must be the most > appropriate person to give me a pointer about this question.... sorry for > any possible mistake. > > Now I'm trying to use postgresql plus the pgbench like a > first test to stress the interconnection system in a parallel machine. I > know that tpc-b is just a toy (no too much real... but before to do > something more complex like tpc-c y want to see the postgres behavior). > > Ok...well I'm running this benchmarks in different SMP machines (SGI with 4 > to 8 processors and the results are odd). The best performance is achieved > with just one backend (1 client). When I try to run more clients the tps > falls quickly. > > In all cases I see that when I increase the number of clients the total CPU > usage falls. With one client I can see a 100% usage (after a warm-up to get > all data from disk - I'm running without fsync and with a large shared > buffer).My systems have a lot of memory then this is normal. But when I try > with more clients each CPU usage falls between 40% for 2 clients to 10% to 8 > clients. I assume the access to the shared memory through critical regions > (lock-unlock) must be one reason... but this is too much. I've heard that > locks in postgress are at page level instead tuple level. I'm wrong?. > > Some suggestion about this?. What was the scaling factor on pgbench initialization? if you used the 1-default, your bottleneck is the single rowin the branches table, which everyone wants to lock for update. Try pgbench -i -s <10 or higher> <dbname> to give it a kick. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
В списке pgsql-hackers по дате отправления: