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")
Ответы: Re: Choosing a filesystem  ("Merlin Moncure")
Список: pgsql-performance

Скрыть дерево обсуждения

Choosing a filesystem  (Laszlo Nagy, )
 Re: Choosing a filesystem  (Andrew Sullivan, )
 Re: Choosing a filesystem  (Matthew Wakeling, )
  Re: Choosing a filesystem  (Kenneth Marshall, )
   Re: Choosing a filesystem  ("Kevin Grittner", )
    Re: Choosing a filesystem  (Laszlo Nagy, )
     Re: Choosing a filesystem  ("Scott Marlowe", )
     Re: Choosing a filesystem  (Craig James, )
      Re: Choosing a filesystem  (Guillaume Cottenceau, )
       Re: Choosing a filesystem  (Greg Smith, )
        Re: Choosing a filesystem  ("Merlin Moncure", )
         Re: Choosing a filesystem  (, )
          Re: Choosing a filesystem  ("Merlin Moncure", )
           Re: Choosing a filesystem  (Bruce Momjian, )
            Re: Choosing a filesystem  (Simon Riggs, )
 Re: Choosing a filesystem  ("Scott Marlowe", )
 Re: Choosing a filesystem  (Greg Smith, )
  Re: Choosing a filesystem  (Matthew Wakeling, )
   Re: Choosing a filesystem  (Greg Smith, )

On Fri, 12 Sep 2008, Merlin Moncure wrote:

> On Fri, Sep 12, 2008 at 5:11 AM, Greg Smith <> 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 по дате сообщения:

От: david@lang.hm
Дата:
Сообщение: Re: Choosing a filesystem
От: "Merlin Moncure"
Дата:
Сообщение: Re: Choosing a filesystem