Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WnT8t-0008OY-Bi for pgsql-performance@arkaria.postgresql.org; Thu, 22 May 2014 13:34:43 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WnT8s-0005aW-2x for pgsql-performance@arkaria.postgresql.org; Thu, 22 May 2014 13:34:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1WnT8r-0005aQ-AI for pgsql-performance@postgresql.org; Thu, 22 May 2014 13:34:41 +0000 Received: from server13-scl.nuevasync.com ([64.13.138.208] helo=mail.nuevasync.com) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WnT8n-0001O9-LS for pgsql-performance@postgresql.org; Thu, 22 May 2014 13:34:40 +0000 Received: from [192.168.80.214] (unknown [69.51.127.178]) by mail.nuevasync.com (Postfix) with ESMTP id F036E2B0065 for ; Thu, 22 May 2014 07:34:33 -0600 (MDT) Message-ID: <537DFCEC.40800@boreham.org> Date: Thu, 22 May 2014 07:34:36 -0600 From: David Boreham User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Profiling PostgreSQL References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 5/22/2014 7:27 AM, Dimitris Karampinas wrote: > Is there any way to get the call stack of a function when profiling > PostgreSQL with perf ? > I configured with --enable-debug, I run a benchmark against the system > and I'm able to identify a bottleneck. > 40% of the time is spent on an spinlock yet I cannot find out the > codepath that gets me there. > Using --call-graph with perf record didn't seem to help. > > Any ideas ? > Can you arrange to run 'pstack' a few times on the target process (either manually or with a shell script)? If the probability of the process being in the spinning state is high, then this approach should snag you at least one call stack. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance