From: Glyn Astill <glynastill@yahoo.co.uk>
To: Thomas SIMON <tsimon@neteven.com>
Cc: pgsql-admin@postgresql.org <pgsql-admin@postgresql.org>
Subject: Re: Performances issues with SSD volume ?
Date: Fri, 22 May 2015 09:37:36 +0000 (UTC)
Message-ID: <339846919.317679.1432287456484.JavaMail.yahoo@mail.yahoo.com> (raw)
In-Reply-To: <555E0E29.4030100@neteven.com>
References: <555E0E29.4030100@neteven.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
> From: Thomas SIMON <tsimon@neteven.com>
> To: Glyn Astill <glynastill@yahoo.co.uk>
> Cc: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
> Sent: Thursday, 21 May 2015, 17:56
> Subject: Re: [ADMIN] Performances issues with SSD volume ?
>
> Le 21/05/2015 16:30, Glyn Astill a écrit :
>>
>>>> I think at this point you could do with going back and trying to
> reproduce
>>>> the issue, then trace back up to pg_stat_activity to see what
> activity could be
>>>> causing the disk i/o. I assume you've tried to reproduce the
> disk issues
>>>> with a simple disk benchmark like bonnie++?
>>> Yes, I think the same thing. Probably I will doing this tomorrow early
>>> in the morning.
>>> I tried to reproduce disk issues with different stress tests like
>>> bonnie, fio, tsung, and I use a more realistic scenario with pgreplay
> to
>>> reproduce my production trafic from postgresql logfile.
>>> However, I'm note sure how to diagnostic performance issues.
>>> I mean, if I see ssd are 100% full, how can I figure out why their
>>> behavior changes ?
>>>
>> Well the disk benchmarks are purely to see what your disks are capable of,
> and help with your initial tuning.
>>
>>
>> You need to trace back which processes are causing most of the IO
> you're seeing, as well as the postgresql logs something like iotop, or dstat
> with the --top-bio option might help you there.
>>
>>
>> You could also look at the pg_statio_user_tables view to narrow down which
> tables are being hit the hardest, which might give you some clues.
> Is there something to activate for seeing something in this table ?
> Because its empty on my production server
>
> postgres=# select * from pg_statio_user_tables;
> relid | schemaname | relname | heap_blks_read | heap_blks_hit |
> idx_blks_read | idx_blks_hit | toast_blks_read | toast_blks_hit |
> tidx_blks_read | tidx_blks_hit
> -------+------------+---------+----------------+---------------+---------------+--------------+-----------------+----------------+----------------+---------------
> (0 rows)
>
Looks like you need to set track_counts=on then. Infact if you've got track_counts off then you're also not running autovacuum, that's a warning flag unless it's intentional.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: glynastill@yahoo.co.uk, tsimon@neteven.com
Subject: Re: Performances issues with SSD volume ?
In-Reply-To: <339846919.317679.1432287456484.JavaMail.yahoo@mail.yahoo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox