[OSM-talk] Server maintenance today

[Nick Hill]

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.