Jeff Frost <[EMAIL PROTECTED]> writes:
> Got my oprofile man page reading done. Here's the general opreport:
> ...
> And the postgres one:
> samples %symbol name
> 3894022 12.6488 LWLockAcquire
> 3535497 11.4842 slot_deform_tuple
> 3030280 9.8431 LWLockRelease
> 2279699 7.4050 H
On Tue, 24 Apr 2007, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
Well, finally got this system upgraded to 8.1.8, but unfortunately, that did
not resolve this. Is there any reasonable way to see where this function is
spending it's time?
I've grown enamored of oprofile lately ---
Jeff Frost <[EMAIL PROTECTED]> writes:
> Well, finally got this system upgraded to 8.1.8, but unfortunately, that did
> not resolve this. Is there any reasonable way to see where this function is
> spending it's time?
I've grown enamored of oprofile lately --- if you're on a recent Linux
system
On Fri, 16 Mar 2007, Jeff Frost wrote:
On Fri, 16 Mar 2007, Jeff Frost wrote:
On Fri, 16 Mar 2007, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
... Interestingly, when you
strace the backend, it doesn't appear to be doing too much...here's some
sample output:
select(0, NULL, NU
On Fri, 16 Mar 2007, Jeff Frost wrote:
On Fri, 16 Mar 2007, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
... Interestingly, when you
strace the backend, it doesn't appear to be doing too much...here's some
sample output:
select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
semop
On Fri, 16 Mar 2007, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
... Interestingly, when you
strace the backend, it doesn't appear to be doing too much...here's some
sample output:
select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
semop(3932217, 0x7fbfffd150, 1) = 0
se
Jeff Frost <[EMAIL PROTECTED]> writes:
> ... Interestingly, when you
> strace the backend, it doesn't appear to be doing too much...here's some
> sample output:
> select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
> semop(3932217, 0x7fbfffd150, 1) = 0
> semop(3932217, 0x7fbfffd150, 1)
Everything else except the one postmaster process hum along just fine. I.e.
nothing else appears to take much system resources at all. Autovac is set with
the 8.2.x default settings. Oh, and the data was ANALYZE'd after it got moved
to the new server. Here's the code in case we have something
Are the stat collector and autovacuum processes in good shape?
--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
On 3/16/07, Jeff Frost <[EMAIL PROTECTED]> wrote:
I've got a client that has a function in a db which had been humming along
quite nicely on 2xOpteron 275, PG 8.1.5, 8GB of RAM. No
