Re: semtimedop instead of setitimer/semop/setitimer
От | Manfred Spraul |
---|---|
Тема | Re: semtimedop instead of setitimer/semop/setitimer |
Дата | |
Msg-id | 3F6C8DD3.3020309@colorfullife.com обсуждение исходный текст |
Ответ на | Re: semtimedop instead of setitimer/semop/setitimer (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: semtimedop instead of setitimer/semop/setitimer
|
Список | pgsql-hackers |
Tom Lane wrote: >Oh, pgbench ;-). Are you aware that you need a "scale factor" (-s) >larger than the number of clients to avoid unreasonable levels of >contention in pgbench? > No. What about adding a few reasonable examples to README? I've switched to "pgbench -c 10 -s 11 -t 1000 test". Is that ok? Now the semop calls are virtually gone. That leaves the question why sysv sem showed up high in the dbt2 benchmarks, but that's another question. I'm back to my original idea: align the data buffers to speed up the user space/kernel space transfers. It looks good: before: (with/without connection) 105.031776//105.093682 105.201246//105.260008 after aligning: 112.664320//112.730542 111.031901//111.098496 111.685869/111.751130 Tested with 7.3.4. Initially I tried to increase MAX_ALIGNOF to 16, but the result didn't work: pgbench failed with: <<< ERROR: CREATE DATABASE cannot be executed from a function createdb: database creation failed <<< For my test I've manually edited shmem and aligned all allocations to 16 byte offsets. I'll try to compile the 7.4 cvs tree, probably someone makes wrong assumptions about the alignment values. -- Manfred
В списке pgsql-hackers по дате отправления: