[Gllug] Painfully slow MySql performance on 64-bit Atom processor
dev at archonet.com
Wed Jan 19 20:31:12 UTC 2011
On 19/01/11 17:02, Richard W.M. Jones wrote:
> On Wed, Jan 19, 2011 at 09:30:32AM +0000, Richard Huxton wrote:
>> Contrary to what you might think, this is less useful for databases than
>> other applications. RDBMs tend to handle their own transaction logs
>> carefully anyway.
> Are you sure about this last point? I'm pretty sure if the RDBMS is
> relying on fsync not to lie, then if fsync lies then Bad Things
You need fsync to work (not necessarily the case with Linux + IDE/SATA).
Most "my database just got slower" complaints are where fsync just did
However, for a transaction log you're sequentially writing whole
disk-blocks (or a multiple thereof) that can re-create all the data-file
changes. Once a transaction-worth of blocks are written, an fsync is
called and provided it returns success it doesn't matter whether the
data files get written to or not.
The barriers let you group writes together and guarantee group A are all
safely on disk before group B get written. This protects against cases
where the disk-cache re-sorts A+B blocks and you end up with e.g. B's
blocks and A's journal changes.
It provides (IIUC) protection against metadata corruption, but not data
Gllug mailing list - Gllug at gllug.org.uk
More information about the GLLUG