From: | "Pierre C" <lists(at)peufeu(dot)com> |
---|---|
To: | "Ben Chobot" <bench(at)silentmedia(dot)com>, "Ryan Wexler" <ryan(at)iridiumsuite(dot)com> |
Cc: | "PostgreSQL - Performance" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: performance on new linux box |
Date: | 2010-07-15 22:57:28 |
Message-ID: | op.vfwp121reorkce@apollo13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> Most (all?) hard drives have cache built into them. Many raid cards have
> cache built into them. When the power dies, all the data in any cache is
> lost, which is why it's dangerous to use it for write caching. For that
> reason, you can attach a BBU to a raid card which keeps the cache alive
> until the power is restored (hopefully). But no hard drive I am aware of
> lets you attach a battery, so using a hard drive's cache for write
> caching will always be dangerous.
>
> That's why many raid cards will always disable write caching on the hard
> drives themselves, and only enable write caching using their own memory
> when a BBU is installed.
>
> Does that make more sense?
>
Actually write cache is only dangerous if the OS and postgres think some
stuff is written to the disk when in fact it is only in the cache and not
written yet. When power is lost, cache contents are SUPPOSED to be lost.
In a normal situation, postgres and the OS assume nothing is written to
the disk (ie, it may be in cache not on disk) until a proper cache flush
is issued and responded to by the hardware. That's what xlog and journals
are for. If the hardware doesn't lie, and the kernel/FS doesn't have any
bugs, no problem. You can't get decent write performance on rotating media
without a write cache somewhere...
From | Date | Subject | |
---|---|---|---|
Next Message | Benjamin Krajmalnik | 2010-07-15 23:28:39 | Re: Question of using COPY on a table with triggers |
Previous Message | Pierre C | 2010-07-15 22:46:54 | Re: Question of using COPY on a table with triggers |