Re: Linux mis-reporting memory

From: Adam Tauno Williams <adamtaunowilliams(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Linux mis-reporting memory
Date: 2007-10-02 18:37:30
Message-ID: 1191350250.5466.6.camel@aleph.wmmi.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> >> But then why is it not reporting that in the "Swap: used"
> >> section ? It
> >> only reports 42308k used swap.
> > Hm, good point.
> > The other possibility is that Postgres just hasn't even touched a
> > large part
> > of its shared buffers.
> Sorry for the late reply...
> No, this is on a very active database server; the working set is
> almost certainly larger than memory (probably by a fair margin :( ),

"almost certainly"

> and all of the shared buffers should be in use.

"should be"

It would be better to just check! :) The catalogs and informational
views will give you definitive answers to these quests.

> I'm leaning towards "top on linux == dumb".

I disagree, it just isn't the appropriate tool for the job. What top
tells you is lots of correct information, it just isn't the right
information.

For starters try -
SELECT
'HEAP:' || relname AS table_name,
(heap_blks_read + heap_blks_hit) AS heap_hits,
ROUND(((heap_blks_hit)::NUMERIC / (heap_blks_read + heap_blks_hit) *
100), 2) AS heap_buffer_percentage
FROM pg_statio_user_tables
WHERE (heap_blks_read + heap_blks_hit) > 0
UNION
SELECT
'TOAST:' || relname,
(toast_blks_read + toast_blks_hit),
ROUND(((toast_blks_hit)::NUMERIC / (toast_blks_read + toast_blks_hit) *
100), 2)
FROM pg_statio_user_tables
WHERE (toast_blks_read + toast_blks_hit) > 0
UNION
SELECT
'INDEX:' || relname,
(idx_blks_read + idx_blks_hit) AS heap_hits,
ROUND(((idx_blks_hit)::NUMERIC / (idx_blks_read + idx_blks_hit) * 100),
2)
FROM pg_statio_user_tables
WHERE (idx_blks_read + idx_blks_hit) > 0

--
Adam Tauno Williams, Network & Systems Administrator
Consultant - http://www.whitemiceconsulting.com
Developer - http://www.opengroupware.org

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Joshua D. Drake 2007-10-02 21:06:20 Re: performance of like queries
Previous Message Kevin Kempter 2007-10-02 17:31:45 performance of like queries