Re: Choosing a filesystem
От | david@lang.hm |
---|---|
Тема | Re: Choosing a filesystem |
Дата | |
Msg-id | alpine.DEB.1.10.0809131423570.17867@asgard.lang.hm обсуждение исходный текст |
Ответ на | Re: Choosing a filesystem ("Merlin Moncure" <mmoncure@gmail.com>) |
Ответы |
Re: Choosing a filesystem
|
Список | pgsql-performance |
On Fri, 12 Sep 2008, Merlin Moncure wrote: > On Fri, Sep 12, 2008 at 5:11 AM, Greg Smith <gsmith@gregsmith.com> wrote: >> On Fri, 12 Sep 2008, Guillaume Cottenceau wrote: >> >> That's the main thing, and nothing else you can do will accelerate that. >> Without a useful write cache (which usually means RAM with a BBU), you'll at >> best get about 100-200 write transactions per second for any one client, and >> something like 500/second even with lots of clients (queued up transaction >> fsyncs do get combined). Those numbers increase to several thousand per >> second the minute there's a good caching controller in the mix. > > While this is correct, if heavy writing is sustained, especially on > large databases, you will eventually outrun the write cache on the > controller and things will start to degrade towards the slow case. So > it's fairer to say that caching raid controllers burst up to several > thousand per second, with a sustained write rate somewhat better than > write-through but much worse than the burst rate. > > How fast things degrade from the burst rate depends on certain > factors...how big the database is relative to the o/s read cache in > the controller write cache, and how random the i/o is generally. One > thing raid controllers are great at is smoothing bursty i/o during > checkpoints for example. > > Unfortunately when you outrun cache on raid controllers the behavior > is not always very pleasant...in at least one case I've experienced > (perc 5/i) when the cache fills up the card decides to clear it before > continuing. This means that if fsync is on, you get unpredictable > random freezing pauses while the cache is clearing. although for postgres the thing that you are doing the fsync on is the WAL log file. that is a single (usually) contiguous file. As such it is very efficiant to write large chunks of it. so while you will degrade from the battery-only mode, the fact that the controller can flush many requests worth of writes out to the WAL log at once while you fill the cache with them one at a time is still a significant win. David Lang
В списке pgsql-performance по дате отправления: