From: | Maarten Boekhold <maartenb(at)dutepp2(dot)et(dot)tudelft(dot)nl> |
---|---|
To: | Karl Denninger <karl(at)mcs(dot)net> |
Cc: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Heh, the disappearing problem! |
Date: | 1998-03-10 10:56:57 |
Message-ID: | Pine.SUN.3.91.980310115222.23067B-100000@dutepp2.et.tudelft.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 9 Mar 1998, Karl Denninger wrote:
> On Mon, Mar 09, 1998 at 11:05:49PM -0500, Bruce Momjian wrote:
> > > I've seen this same kind of behavior in a few other places as well; in
> > > places where you are doing reads and writes in a mixed environment (ie: read
> > > something, write something (typically in a different table) based on what
> > > you read) performance of 6.3 has gone in the toilet. Update jobs that used
> > > to run in tens of seconds are requiring several minutes to complete now.
> > >
> > > And again, we're not seeing much disk I/O during this period - but we *ARE*
> > > seeing a hell of a lot of CPU activity, almost all in user mode.
> >
> > OK, how about using postgres -t option or profiling to get the function
> > using so much cpu? This may help us tell where the problem lies. Does
> > anyone else see such problems? All other reports I hear was that 6.3
> > was faster.
>
> Docs on this somewhere?
>
> I'll be happy to profile it if I can figure out how! :-)
I have just figured this out. First, you can get some timing information
from postgresql itself by including '-tpa -tpl -te' on the backend
options, second, you can recompile postgresql with profiling on (look in
Makefile.global for profiling options, adjust them for your syetem).
Then, *don't do a 'make install'* but only copy the postgres binary (in
backend dir) to your postgresql bin-dir, as postgres.profile. Whenever
you want to profile, edit your start-script to use that postgres.profile
as a backend. Run your queries, then copy the profile-output (gmon.out
for gcc profiling) from the *database* directory you did your queries on
(ie. if you connected to database 'template1', it'll be in
data/base/template1).
Then do normal profiling stuff (foor gcc profiling, run 'gprof gmon.out
bin/postgres.profile > prof.out' to get readable output).
If you have questions, please mail me privately.
Maarten
_____________________________________________________________________________
| TU Delft, The Netherlands, Faculty of Information Technology and Systems |
| Department of Electrical Engineering |
| Computer Architecture and Digital Technique section |
| M(dot)Boekhold(at)et(dot)tudelft(dot)nl |
-----------------------------------------------------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1998-03-10 12:45:09 | Re: [QUESTIONS] Development versions... |
Previous Message | Julia A.Case | 1998-03-10 10:00:56 | attlen weirdness? |