[OSM-dev] Server maintenance today
nick at nickhill.co.uk
Sat May 5 00:05:59 BST 2007
I have fitted the database server with 8Gb RAM along with an upgrade to T at H hard
drive. Oliver can access the new, additional T at H hard drive on dev.
Hopefully this will make tomorrow's changes quicker and easier to deploy.
I have upgraded RAM on API from 512M to 2GB.
After exhaustive tests, and buying an array of RAID controllers, the Linux MD
software RAID0 in conjunction with an Adaptec AHA2940U2W provided the optimal
solution. Out-performing a Mylex Megaraid 170 by more than a factor of two and
substantially out-performing an Adaptec 3000s hardware RAID . Software RAID
providing 470-570 seeks/sec with 2 drives on a 16Gb data block.
I heard suggestions about SATA controllers being worthwhile investigating, and
bore those in mind. In practical database-like tests performed with Bonnie++, I
have seen no measurable I/O improvement on systems using SATA over IDE/PATA. The
best through-put in terms of seeks/sec I have seen with SATA is a Seagate
barracuda connected to an Nvidia 570. This gives 150 seeks/sec. Used in
conjunction with a jmicron AHCI controller supporting NCQ/TCQ or to a VIA
southbridge, gives around 100 seeks/sec (a motherboard I rejected for the
database, also had memory corruption issues).
A similar Seagate PATA drive connected to the Nforce chipset returned 152
seeks/sec. As far as I am concerned, the hype around SATA is just that. A single
10k SCSI drive connected to an AHA2940U2W yields >300 seeks/sec.
My current view on SATA is: The technology provides a thinner cable useful for
better air circulation. The technology eliminates the possibility of
master/slave confusion. The technology provides no real-world performance
advantage. SATA cables are easily inadvertently dislodged. Incompatibilities are
common with SATA controller/drive combinations. Eg WD (and in my experience
Samsung) SATA drives and SATA 300 controllers.
More information about the dev