Re: pgbench cpu overhead (was Re: lazy vxid locks, v1)
От | Alvaro Herrera |
---|---|
Тема | Re: pgbench cpu overhead (was Re: lazy vxid locks, v1) |
Дата | |
Msg-id | 1308024332-sup-3315@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: pgbench cpu overhead (was Re: lazy vxid locks, v1) (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: pgbench cpu overhead (was Re: lazy vxid locks, v1)
Re: pgbench cpu overhead (was Re: lazy vxid locks, v1) |
Список | pgsql-hackers |
Excerpts from Jeff Janes's message of lun jun 13 20:27:15 -0400 2011: > On Mon, Jun 13, 2011 at 7:03 AM, Stefan Kaltenbrunner > <stefan@kaltenbrunner.cc> wrote: > ... > > > > > > so it seems that sysbench is actually significantly less overhead than > > pgbench and the lower throughput at the higher conncurency seems to be > > cause by sysbench being able to stress the backend even more than > > pgbench can. > > Hi Stefan, > > pgbench sends each query (per connection) and waits for the reply > before sending another. I noticed that pgbench's doCustom (the function highest in the profile posted) returns doing nothing if the connection is supposed to be "sleeping"; seems an open door for busy waiting. I didn't check the rest of the code to see if there's something avoiding that condition. I also noticed that it seems to be very liberal about calling INSTR_TIME_SET_CURRENT in the same function which perhaps could be optimizing by calling it a single time at entry and reusing the value, but I guess that would show up in the profile as a kernel call so it's maybe not a problem. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: