From: | CaptainX0r <captainx0r(at)yahoo(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Sun vs. Mac |
Date: | 2003-01-14 19:38:28 |
Message-ID: | 20030114193828.37133.qmail@web21106.mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> I believe top's percent-of-CPU numbers for individual
> processes are time
> averages over a minute or so, so the ramping effect is
> unsurprising.
Thanks - this makes much more sense.
> > This doesn't really tell me much, except I'm guessing that
> > PG is CPU bound?
>
> Yup, that seems pretty clear. Next step is to find out what
> the heck
> it's doing. My instinct would be to use gprof. Recompile
> with
> profiling enabled --- if you're using gcc, this should work
> cd postgres-distribution/src/backend
> make clean
> make PROFILE=-pg all
> make install-bin -- may need to stop postmaster
> Next run some sample queries (put them all into one session).
> After quitting the session, find gmon.out in the
> $PGDATA/base/nnn/ subdirectory corresponding to your database,
> and feed it to gprof.
> The results should show where the code hotspot is.
Well if that isn't a fancy bit of info.... Thanks!
gprof says:
Fatal ELF error: can't read ehdr (Request error: class
file/memory mismatch)
I'm guessing that's not what we're expecting... I'm using
/usr/ccs/bin/gprof - maybe there's a better one?
-X
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Vernon Wu | 2003-01-14 19:42:07 | How good I can get |
Previous Message | Josh Berkus | 2003-01-14 19:32:32 | Re: 7.3.1 New install, large queries are slow |