From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | captainx0r(at)yahoo(dot)com |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Sun vs. Mac |
Date: | 2003-01-14 18:15:54 |
Message-ID: | 17342.1042568154@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
CaptainX0r <captainx0r(at)yahoo(dot)com> writes:
> Well, I've got the Sun box now, but I don't really have acces to
> the G3. FWIW, top shows postgres slowly taking up all the CPU -
> over the course of a minute or so it gradually ramps up to
> around 90%. Once the query is complete, however, top shows the
> CPU ramping down slowly, ~1-2% per second over the next 2
> minutes which I find very strange.
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.
> 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 before install
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | scott.marlowe | 2003-01-14 18:26:09 | Re: Sun vs. Mac |
Previous Message | CaptainX0r | 2003-01-14 18:10:54 | Re: Sun vs. Mac - best Postgres platform? |