Dan Harris <[EMAIL PROTECTED]> writes:
> Since you mentioned the number of semops is distressingly high, does this
> indicate a tuning problem?
More like an old-version problem. We've done a lot of work on
concurrent performance since 8.0.x, and most likely you are hitting
one of the bottlenecks
Tom Lane wrote:
Dan Harris <[EMAIL PROTECTED]> writes:
Here's the strace summary as run for a few second sample:
% time seconds usecs/call callserrors syscall
-- --- --- - -
97.250.671629 92 7272 s
Today, I looked at 'top' on my PG server and saw a pid that reported 270
hours of CPU time. Considering this is a very simple query, I was
surprised to say the least. I was about to just kill the pid, but I
figured I'd try and see exactly what it was stuck doing for so long.
If you are
Dan Harris <[EMAIL PROTECTED]> writes:
> Here's the strace summary as run for a few second sample:
> % time seconds usecs/call callserrors syscall
> -- --- --- - -
> 97.250.671629 92 7272 semop
>1.7
Today, I looked at 'top' on my PG server and saw a pid that reported 270 hours
of CPU time. Considering this is a very simple query, I was surprised to say
the least. I was about to just kill the pid, but I figured I'd try and see
exactly what it was stuck doing for so long.
Here's the strac
