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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: xinsong wu
Дата:
Сообщение: Development Partner
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: postgresql system file size