On 11/22/2010 12:21 AM, Ivan Voras wrote:
The "semwait" part is from PostgreSQL - probably shared buffer locking,
but there's a large number of processes regularly in sbwait - maybe
something can be optimized here?
I think this paper was mentioned before, did you read it?... "An
Analysis of L
Ivan Voras wrote:
On 23 November 2010 10:35, David Xu wrote:
Ivan Voras wrote:
and the overall behaviour is similar - the processes spend a lot of time
in "sbwait" and "ksem" states.
Strange, the POSIX semaphore in head branch does not use ksem, it is
based on umtx, there is no limit on PO
On 23 November 2010 10:35, David Xu wrote:
> Ivan Voras wrote:
>> and the overall behaviour is similar - the processes spend a lot of time
>> in "sbwait" and "ksem" states.
>>
> Strange, the POSIX semaphore in head branch does not use ksem, it is
> based on umtx, there is no limit on POSIX semaph
Ivan Voras wrote:
On 11/23/10 01:26, Ivan Voras wrote:
On 11/22/10 17:37, David Xu wrote:
Mark Felder wrote:
I recommend posting this on the Postgres performance list, too.
Regards,
Mark
I think if PostgreSQL uses semaphore for inter-process locking,
it might be a good idea to use POSI
On 11/23/10 01:26, Ivan Voras wrote:
On 11/22/10 17:37, David Xu wrote:
Mark Felder wrote:
I recommend posting this on the Postgres performance list, too.
Regards,
Mark
I think if PostgreSQL uses semaphore for inter-process locking,
it might be a good idea to use POSIX semaphore exits i
On 11/22/10 17:37, David Xu wrote:
Mark Felder wrote:
I recommend posting this on the Postgres performance list, too.
Regards,
Mark
I think if PostgreSQL uses semaphore for inter-process locking,
it might be a good idea to use POSIX semaphore exits in our head
branch, the new POSIX semap
Mark Felder wrote:
I recommend posting this on the Postgres performance list, too.
Regards,
Mark
I think if PostgreSQL uses semaphore for inter-process locking,
it might be a good idea to use POSIX semaphore exits in our head
branch, the new POSIX semaphore implementation now supports
pro
I recommend posting this on the Postgres performance list, too.
Regards,
Mark
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsub
This is not a request for help but a report, in case it helps developers
or someone in the future. The setup is:
AMD64 machine, 24 GB RAM, 2x6-core Xeon CPU + HTT (24 logical CPUs)
FreeBSD 8.1-stable, AMD64
PostgreSQL 9.0.1, 10 GB shared buffers, using pgbench with a scale
factor of 500 (7.5 GB
