[Gllug] Painfully slow MySql performance on 64-bit Atom processor

[Richard Huxton]

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
> happen.

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 
nothing before.

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 
loss.

-- 
   Richard Huxton
   Archonet Ltd
--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug