From: | Erik Jones <erik(at)myemma(dot)com> |
---|---|
To: | Bruce McAlister <bruce(dot)mcalister(at)blueface(dot)ie> |
Cc: | pgsql-general(at)postgresql(dot)org, Richard Huxton <dev(at)archonet(dot)com> |
Subject: | Re: Recovery/Restore and Roll Forward Question. |
Date: | 2007-06-21 17:21:34 |
Message-ID: | 23505E27-E370-4821-920E-F4CCEC25CFD0@myemma.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Jun 21, 2007, at 5:16 AM, Bruce McAlister wrote:
> Thats exactly what I think. There is something strange going on. At
> the
> moment I think it is the disk I am writing the data to that is slow,
> possibly due to the fact that it is mounted up as "forcedirectio",
> so as
> not to interfere with the file system cache which we want to have
> mainly
> pg datafiles in, and the RAID controller has this particular logical
> driver configured as write-through, so there is no buffering in-
> between.
> The cpu's and network are not the problem here (2 x Dual Core Opterons
> and Quad Gigabit Ethernet, total cpu usage is around 10%, NIC's are
> pushing around 3Mbit/s over each).
>
> It's not all that big to be honest, the total database size is around
> 11GB and I'm currently recking my head to find out how to improve the
> backup times, and not adversely affect our running instance. I just
> recently tried to use UFS snapshots, but the backing store filled up
> before i could complete a backup of the snapshot. I need to find a way
> to improve the write speed of our destination disk. I have another
> question in this pg group about autovacuum that is not running on
> one of
> our database tables which adds an average of around 2.1GB of bloat to
> the database each day. I've now (today) scheduled a cron job every 10
> minutes to get around this in the meantime. Hopefully that should
> reduce
> the amount of data backed up by 2GB when we get to the bottom of that
> issue (autovacuum)
>
You said in your other thread that your on Solaris 10, right? We are
as well and just discovered that having stats_block_level set to on
increases write volume a lot and noticed a significant drop when we
turned it off as well a significant drop in wal file traffic. The
same goes for stats_row_level (wrt write volume at least), but you
need that if you want query information to come through
pg_stat_activity (we left that on). We just migrated off of a server
wherein forcedirectio actually helped us a lot, but now we're
wondering if that was due to us having forcedirectio on. We only at
the beginning of a lot of systems migrations and restructuring so now
that we have some new avenues and room to experiment, I'll try to
post our results in a couple weeks.
Erik Jones
Software Developer | Emma®
erik(at)myemma(dot)com
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com
From | Date | Subject | |
---|---|---|---|
Next Message | Germán Hüttemann Arza | 2007-06-21 17:46:50 | Throwing exceptions |
Previous Message | Michael Glaesemann | 2007-06-21 17:13:38 | Re: finding items with 0 rels for a 0 to many relationship |