Re: zLinux Load Testing Experience - Mailing list pgsql-general

From Merlin Moncure
Subject Re: zLinux Load Testing Experience
Date
Msg-id CAHyXU0zVUCpQgnJJvVQtEbE1_DnaBrU5DrjuTCyU=g2QHR3eDg@mail.gmail.com
Whole thread Raw
In response to Re: zLinux Load Testing Experience  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: zLinux Load Testing Experience
List pgsql-general
On Tue, Apr 30, 2013 at 12:26 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Tue, Apr 30, 2013 at 8:28 AM, Andrew Hastie <andrew@ahastie.net> wrote:
>>
>> I'm currently working on a project porting an application from RedHat
>> Linux on Intel onto IBM zLinux. Our application requires PostgreSQL at
>> version 9.n, so the PostgreSQL binaries have been built using the standard
>> build tools from source. Everything appears run correctly. However as part
>> of performance testing, our IBM and Linux SysProgs have been "poking around"
>> using strace and have reported the following (which they think is an error
>> condition) when hooking up to the postmaster processes:-
>>
>> read(3, 0x3ffff875ee0, 16) = -1 EAGAIN (Resource temporarily unavailable)
>> poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}], 2, 200) = 0 (Timeout)
>> read(3, 0x3ffff875ee0, 16) = -1 EAGAIN (Resource temporarily unavailable)
>> poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}], 2, 10000) = 0
>> (Timeout)
>> ... repeated many times
>>
>
>
> That does not look like the postmaster process.  It looks like probably the
> background writer process.
>
> It is normal, and doesn't explain high CPU utilization.

yeah: we're probably a couple of steps in front of deep system
profiling.   Helpful things to provide to help diagnose would be:

*) 'explain analyze' of the queries that are eating cpu
*) more details about the hardware -- how many cpu, etc.
*) better definition of 'perceived high CPU utilisation'
*) some correlating performance tests, expecially cpu bound pgbench
tests (pgbench -S)

merlin


pgsql-general by date:

Previous
From: Ben Chobot
Date:
Subject: Re: Basic question on recovery and disk snapshotting
Next
From: "Carlo Stonebanks"
Date:
Subject: Re: Simple SQL INSERT to avoid duplication failed: why?