Linux TOP

On Wed, 21 Oct 2009, Waldomiro wrote:

I'm afraid of two things, one is the "load average", I think 3 is too
much, another is the "swap", almost 4GB of swap, I think that is too much
swap.

Am I right?

Not necessarily.

Can I use those indicators to know if my database is ok?

Perhaps.

Google is your friend. For example, enter the search term "linux load
averages" and one of the first hits is:

<http://www.lifeaftercoffee.com/2006/03/13/unix-load-averages-explained/&gt;

Do the same thing to understand swap.

Rich

On Wed, 21 Oct 2009, Waldomiro wrote:

top - 16:16:30 up 42 days, 13:23,ￜ 4 users,ￜ load average: 3.13, 3.52, 3.36
Cpu(s):ￜ 1.4%us,ￜ 1.1%sy,ￜ 0.0%ni, 84.4%id, 12.9%wa,ￜ 0.0%hi,ￜ 0.2%si,ￜ 0.0%st
Mem:ￜ 16432240k total, 16344596k used,ￜￜￜ 87644k free,ￜￜￜ 27548k buffers
Swap: 10241428k total,ￜ 3680860k used,ￜ 6560568k free,ￜ 6230376k cached

I'm afraid of two things, one is the "load average", I think 3 is too much

You're at 12.9% waiting for I/O and 84.4% idle. That means your average
load consists of three processes who are stuck waiting for I/O at any
given time. The I/O is what you should be worried about, not the load
average.

another is the "swap", almost 4GB of swap, I think that is too much
swap.

It does look like your server is using much more RAM than it actually has,
which is the likely reason for all the disk I/O. If you sort the top
output by memory, you might see why that is.

The information provided by top on Linux isn't very good though; take a
look at /proc/meminfo for more details. Rather than rely on top's math,
instead I usually capture the output from:

ps -e -o pid,rss,vsz,size,user,cmd

And add things up myself instead, taking into account the shared bits each
of the PostgreSQL processes includes.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

From pgsql-general-owner@postgresql.org Wed Oct 21 19:08:59 2009

Received: from localhost (unknown [200.46.208.211])
by mail.postgresql.org (Postfix) with ESMTP id 9E6216330DC
for <pgsql-general-postgresql.org@mail.postgresql.org>; Wed, 21 Oct 2009 19:08:59 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024)
with ESMTP id 94790-07
for <pgsql-general-postgresql.org@mail.postgresql.org>;
Wed, 21 Oct 2009 22:08:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.223.182])
by mail.postgresql.org (Postfix) with ESMTP id C9978632E70
for <pgsql-general@postgresql.org>; Wed, 21 Oct 2009 19:08:48 -0300 (ADT)
Received: by iwn12 with SMTP id 12so3592769iwn.15
for <pgsql-general@postgresql.org>; Wed, 21 Oct 2009 15:08:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=9aAVHP7eZ90k3cKiWR3il7gkgfsYKH+99SFSGzDqh6o=;
b=cNqoO+6fHeR71uIkMM9kQDS4eKmoJfssXFCAc9WxnvT4AtiMYKP6OwVmAD9Fv7KaRX
cBMmVV6USUYQH/pHNIQoKw6ZjWTXf5fM0a0NMccprVwq6qs4Ldyh1bXuq6ly/paEMa8T
YxmR6YC42AcYQrYhgfOWG+xk/EZKDvIwxZXKU=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:content-transfer-encoding;
b=H7U5EX2gh4GPzOhT9mci2i8NSewwaQV2srT8O5J9wLIwtXm6N5PQBmo/f0COJj0xHa
uI4FfID4K+tABGEzV2v3trs1AH9FxfD1iBxCDKxifywVB1h2tzAo3SAeNvgTv08tzsTW
EWCNBrVne0IBH6eEhzAfan+VQqcMwlUhr/PUM=
MIME-Version: 1.0
Received: by 10.231.4.149 with SMTP id 21mr722970ibr.26.1256162927462; Wed, 21
Oct 2009 15:08:47 -0700 (PDT)
In-Reply-To: <alpine.GSO.2.01.0910211744440.1257@westnet.com>
References: <4ADF52E4.90704@shx.com.br>
<alpine.GSO.2.01.0910211744440.1257@westnet.com>
Date: Wed, 21 Oct 2009 16:08:47 -0600
Message-ID: <dcc563d10910211508v73e2f530sad05438b84dbd7cb@mail.gmail.com>
Subject: Re: Linux TOP
From: Scott Marlowe <scott.marlowe@gmail.com>
To: Greg Smith <gsmith@gregsmith.com>
Cc: Waldomiro <waldomiro@shx.com.br>, pgsql-general@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.486 tagged_above=-10 required=5 tests=AWL=0.113,
BAYES_00=-2.599
X-Spam-Level:
X-Archive-Number: 200910/817
X-Sequence-Number: 154511

On Wed, Oct 21, 2009 at 4:01 PM, Greg Smith <gsmith@gregsmith.com> wrote:

On Wed, 21 Oct 2009, Waldomiro wrote:

top - 16:16:30 up 42 days, 13:23,=A0 4 users,=A0 load average: 3.13, 3.5=

2,

3.36
Cpu(s):=A0 1.4%us,=A0 1.1%sy,=A0 0.0%ni, 84.4%id, 12.9%wa,=A0 0.0%hi,=A0=

0.2%si,

0.0%st
Mem:=A0 16432240k total, 16344596k used,=A0=A0=A0 87644k free,=A0=A0=A0 =

27548k buffers

Swap: 10241428k total,=A0 3680860k used,=A0 6560568k free,=A0 6230376k c=

ached

I'm afraid of two things, one is the "load average", I think 3 is too mu=

ch

You're at 12.9% waiting for I/O and 84.4% idle. =A0That means your averag=

e

load consists of three processes who are stuck waiting for I/O at any giv=

en

time. =A0The I/O is what you should be worried about, not the load averag=

e.

another is the "swap", almost 4GB of swap, I think that is too much swap=

.

It does look like your server is using much more RAM than it actually has=

,

which is the likely reason for all the disk I/O. =A0If you sort the top o=

utput

by memory, you might see why that is.

This is a common misunderstanding.

In this:

Mem: 16432240k total, 16344596k used, 87644k free, 27548k buffers
Swap: 10241428k total, 3680860k used, 6560568k free, 6230376k cached

The 6.2G cached is considered part of the 16G used

So it's not using more memory than it has. It's just the accounting
is inobvious.

Scott Marlowe <scott.marlowe@gmail.com> writes:

In this:

Mem: 16432240k total, 16344596k used, 87644k free, 27548k buffers
Swap: 10241428k total, 3680860k used, 6560568k free, 6230376k cached

The 6.2G cached is considered part of the 16G used

So it's not using more memory than it has. It's just the accounting
is inobvious.

Right, but it still appears that there's something close to 14G of
actual memory use (exclusive of kernel disk buffers). If that's
the true requirement of the set of processes being run, 16G of RAM
is pretty darn marginal, and he should go buy more. But first it
would be prudent to find out where the memory is going. Also, one
thing I'd do immediately is to watch "vmstat 1" for awhile to see if
there's a lot of swap activity. If that's where the I/O is going,
it'd be another signal that memory pressure is the real issue.

regards, tom lane

On Wed, 21 Oct 2009, Scott Marlowe wrote:

In this:

Mem: 16432240k total, 16344596k used, 87644k free, 27548k buffers
Swap: 10241428k total, 3680860k used, 6560568k free, 6230376k cached

The 6.2G cached is considered part of the 16G used

So it's not using more memory than it has. It's just the accounting
is inobvious.

This is a snapshot. The fact that 3.7GB of swap is used here suggests
there may have been more memory used at some point in the past then we're
seeing now; that's more what I was commenting on. A look at the si/so
figures in vmstat should nail down whether that's still going on or not
now, as Tom already suggested.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

On Wed, Oct 21, 2009 at 4:25 PM, Greg Smith <gsmith@gregsmith.com> wrote:

On Wed, 21 Oct 2009, Scott Marlowe wrote:

In this:

Mem:  16432240k total, 16344596k used,    87644k free,    27548k buffers
Swap: 10241428k total,  3680860k used,  6560568k free,  6230376k cached

The 6.2G cached is considered part of the 16G used

So it's not using more memory than it has.  It's just the accounting
is inobvious.

This is a snapshot.  The fact that 3.7GB of swap is used here suggests there
may have been more memory used at some point in the past then we're seeing
now; that's more what I was commenting on.  A look at the si/so figures in
vmstat should nail down whether that's still going on or not now, as Tom
already suggested.

Definitely. not arguing the guy doesn't have problems, just that the
way top accounts for memory is rather misleading for most folks.