Skip site navigation (1) Skip section navigation (2)

Re: Amazon EC2 CPU Utilization

From: Jim Mlodgenski <jimmy76(at)gmail(dot)com>
To: Mike Bresnahan <mike(dot)bresnahan(at)bestbuy(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Amazon EC2 CPU Utilization
Date: 2010-01-28 01:22:52
Message-ID: dd92004a1001271722q5f62124g21ec01c0228bdab8@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-general
On Wed, Jan 27, 2010 at 6:37 PM, Mike Bresnahan
<mike(dot)bresnahan(at)bestbuy(dot)com>wrote:

> Greg Smith <greg <at> 2ndquadrant.com> writes:
> > Could you try this again with "top -c", which will label these
> > postmaster processes usefully, and include the pgbench client itself in
> > what you post?  It's hard to sort out what's going on in these
> > situations without that style of breakdown.
>
> As a further experiment, I ran 8 pgbench processes in parallel. The result
> is
> about the same.
>
> Let's start from the beginning. Have you tuned your postgresql.conf file?
What do you have shared_buffers set to? That would have the biggest effect
on a test like this.


> top - 18:34:15 up 17 min,  2 users,  load average: 0.39, 0.40, 0.36
> Tasks: 217 total,   8 running, 209 sleeping,   0 stopped,   0 zombie
> Cpu(s): 22.2%us,  8.9%sy,  0.0%ni, 68.7%id,  0.0%wa,  0.0%hi,  0.0%si,
>  0.3%st
> Mem:   7358492k total,  1611148k used,  5747344k free,    11416k buffers
> Swap:        0k total,        0k used,        0k free,  1248408k cached
>
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>
>
>  1506 postgres  20   0  197m 134m 132m S 29.4  1.9   0:09.27 postgres:
> postgres
> postgres [local] idle
>
>  1524 postgres  20   0  197m 134m 132m R 29.4  1.9   0:05.13 postgres:
> postgres
> postgres [local] idle
>
>  1509 postgres  20   0  197m 134m 132m R 27.1  1.9   0:08.58 postgres:
> postgres
> postgres [local] SELECT
>
>  1521 postgres  20   0  197m 134m 132m R 26.4  1.9   0:05.77 postgres:
> postgres
> postgres [local] SELECT
>
>  1512 postgres  20   0  197m 134m 132m S 26.1  1.9   0:07.62 postgres:
> postgres
> postgres [local] idle
>
>  1520 postgres  20   0  197m 134m 132m R 25.8  1.9   0:05.31 postgres:
> postgres
> postgres [local] idle
>
>  1515 postgres  20   0  197m 134m 132m S 23.8  1.9   0:06.94 postgres:
> postgres
> postgres [local] SELECT
>
>  1527 postgres  20   0  197m 134m 132m S 21.8  1.9   0:04.46 postgres:
> postgres
> postgres [local] SELECT
>
>  1517 postgres  20   0 49808 2012 1544 R  5.3  0.0   0:01.02 pgbench -S -c
> 1 -T
> 30
>
>  1507 postgres  20   0 49808 2012 1544 R  4.6  0.0   0:01.70 pgbench -S -c
> 1 -T
> 30
>
>  1510 postgres  20   0 49808 2008 1544 S  4.3  0.0   0:01.32 pgbench -S -c
> 1 -T
> 30
>
>  1525 postgres  20   0 49808 2012 1544 S  4.3  0.0   0:00.79 pgbench -S -c
> 1 -T
> 30
>
>  1516 postgres  20   0 49808 2016 1544 S  4.0  0.0   0:01.00 pgbench -S -c
> 1 -T
> 30
>
>  1504 postgres  20   0 49808 2012 1544 R  3.3  0.0   0:01.81 pgbench -S -c
> 1 -T
> 30
>
>  1513 postgres  20   0 49808 2016 1544 S  3.0  0.0   0:01.07 pgbench -S -c
> 1 -T
> 30
>
>  1522 postgres  20   0 49808 2012 1544 S  3.0  0.0   0:00.86 pgbench -S -c
> 1 -T
> 30
>
>  1209 postgres  20   0 63148 1476  476 S  0.3  0.0   0:00.11 postgres:
> stats
> collector process
>
>
>
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



-- 
--
Jim Mlodgenski
EnterpriseDB (http://www.enterprisedb.com)

In response to

Responses

pgsql-bugs by date

Next:From: GeorgeDate: 2010-01-28 04:13:15
Subject: BUG #5298: emedded SQL in C to get the record type from plpgsql
Previous:From: Tom LaneDate: 2010-01-27 23:59:10
Subject: Re: problem with segmentation fault error

pgsql-general by date

Next:From: Scott MarloweDate: 2010-01-28 04:01:37
Subject: Re: How much work is it to add/drop columns, really?
Previous:From: Yan Cheng CheokDate: 2010-01-28 01:15:58
Subject: Re: Problem after installing triggering function

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group