| From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Florian Weimer <fweimer(at)bfk(dot)de>, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org, Greg Smith <greg(at)2ndquadrant(dot)com> |
| Subject: | Re: SSDs with Postgresql? |
| Date: | 2011-04-21 20:08:46 |
| Message-ID: | BANLkTinZmaVLUR-vu4qHphPn0p5-h7oHWA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, Apr 21, 2011 at 11:22 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Florian Weimer <fweimer(at)bfk(dot)de> writes:
>> * Adrian Klaver:
>>>> Interesting. Is there an easy way to monitor WAL traffic in away?
>
>>> They are found in $DATA/pg_xlog so checking the size of that
>>> directory regularly would get you the information.
>
>> But log files are recycled, so looking at the directory alone does not
>> seem particularly helpful.
>
> "du" would be useless, but you could check the name of the newest WAL
> segment file from time to time, and do a bit of math to see how much
> WAL had been written since the previous time.
I'd think using sysstat packages sar is the way to see how much work
your drives are doing. Assuming the sysstat package / daemon is set
to monitor disk block activity.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2011-04-21 20:18:15 | Re: Poor performance of btrfs with Postgresql |
| Previous Message | Joseph S | 2011-04-21 18:41:06 | getting EXPLAIN output from inside a function |