Re: Recovery/Restore and Roll Forward Question.
От | Erik Jones |
---|---|
Тема | Re: Recovery/Restore and Roll Forward Question. |
Дата | |
Msg-id | 23505E27-E370-4821-920E-F4CCEC25CFD0@myemma.com обсуждение исходный текст |
Ответ на | Re: Recovery/Restore and Roll Forward Question. (Bruce McAlister <bruce.mcalister@blueface.ie>) |
Список | 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@myemma.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
В списке pgsql-general по дате отправления: