X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id CA54652B1E
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Wed, 17 Aug 2005 05:14:26 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 91460-05
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Wed, 17 Aug 2005 08:14:25 +0000 (GMT)
Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41])
	by svr1.postgresql.org (Postfix) with ESMTP id BC77452B38
	for <pgsql-performance@postgresql.org>;
	Wed, 17 Aug 2005 05:14:23 -0300 (ADT)
Received: (from www@localhost)
	by mail0.rawbw.com (8.11.6p2/8.11.6) id j7H8EPA52792
	for pgsql-performance@postgresql.org;
	Wed, 17 Aug 2005 01:14:25 -0700 (PDT)
Received: from 198.144.203.173 ([198.144.203.173])
	by webmail.rawbw.com (IMP) with HTTP
	for <mudfoot@shell.rawbw.com>; Wed, 17 Aug 2005 01:14:24 -0700
Message-ID: <1124266464.4302f1e0d5d30@webmail.rawbw.com>
Date: Wed, 17 Aug 2005 01:14:24 -0700
From: mudfoot@rawbw.com
To: pgsql-performance@postgresql.org
Subject: Re: Performance problem using V3 protocol in jdbc driver
References: 
 <03E7D3E231BB7B4A915A6581D4296CC6015D534E@NSNOVPS00411.nacio.xythos.com>
In-Reply-To: 
 <03E7D3E231BB7B4A915A6581D4296CC6015D534E@NSNOVPS00411.nacio.xythos.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 198.144.203.173
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.178 required=5 tests=[NO_REAL_NAME=0.178]
X-Spam-Level: 
X-Archive-Number: 200508/199
X-Sequence-Number: 13946

Quoting Barry Lind <blind@xythos.com>:

<snip>
>  
> 
> What I see when running the V3 protocol under 'top' is that the postgres
> processes are routinely using 15% or more of the CPU each, when running
> the V2 protocol they use more like 0.3%.
> 
>  
> 
> Does anyone have any suggestions on an approach to debug a problem like
> this?
> 
>  

Tracing system calls is a good starting point--truss on Solaris, strace on Linux
(Redhat anyway), ktrace on BSD.  The difference between 0.3% and 15% CPU
utilization under similar load will very likely (though not with complete
certainty) be showing very noticeably different system call activity.

If you notice a difference in system call activity, then that would probably
provide a hint as to what's going on--where the inefficiency lies.  It's
possible to spin the CPU up without any system calls, but system call tracing
can be done pretty quickly and you should be able to see any interesting
patterns emerge quite quickly.

^
|

This method is a good starting point for troubleshooting just about any funny
process activity.  And it comes with the added benefit of not having to know
ahead of time about the specific matter at hand (JDBC implementation, in this
case).  :-)  That's having your cake and eating it, too.

> 
> Thanks,
> 
> --Barry
> 
>