Partities icm RAID langzaam?

[arnoman]

Ik heb met mijn baas de volgende discussie over een server die we hier hebben draaien. Het betreft een SuperMicro server met vier hardeschijven in een Raid5 met hotspare configuratie.

Mijn baas is er heilig van overtuigd dat het aanmaken van een partitie op deze array aanzienlijke vertraging zal opleveren voor de daarop draaiende SQL server. De database van het boekhoudprogramma is echter maar 10gb groot en er zullen maximaal 10 gebruikers tegerlijkertijd op werken.
Naast het feit dat ik zelf niet echt een voorstander ben van het niet splitsen van het OS en databases over partities, moeten er ook dagelijks diverse backups van andere servers naar deze server gemaakt worden. Alle informatie, dus OS, db en backups op 1 grote partitie is m.i. vragen om problemen..

Mijn baas komt zelf met -in mijn ogen- enkel drogredenen. Zijn er harde feiten die zijn claim onderbouwen?

De specificaties van de server:
cpu: Xeon E5405 2ghz
mem: 8gb
hd: 4x 1tb 7200rpm
cont: Areca, RAID5+ 1 hotspare
os: Windows 2008 64bit
sql: SQL 2005

[ Voor 0% gewijzigd door arnoman op 23-12-2008 11:31 . Reden: areca ]

[Fauna]

Met partitioneren krijg je kleinere partities. In theorie is het voor een OS sneller zoeken op een kleine HD/partitie, maar dat heb ik nooit in een benchmark gezien. Een ander puntje is dat je door partitioneren een beetje kan bepalen welke data op welk stuk van de schijf staat. Zo kan je het OS of de database op de buitenste sectoren van een HD forceren, dat wel aanmerkelijk sneller kan zijn. Iig voor de throughput, voor de random seek en write acties die je bij een database zult hebben weer een heel stuk minder.

[arnoman]

Als ik jouw post goed interpreteer kan een partities, mits goed geconfigureerd dus juist een snelheidswinst opleveren?

[Fauna]

Ja, zeker. Als je de gemiddelde HD benchmark grafieken ziet beginnen die tegenwoordig bij 100MB/s op de buitenste sectoren naar 60MB/s op de binnenste. Maar nogmaals, dat zijn sequential reads, en da's heel wat anders dan DB-activiteit.

[metallicelmo]

Is het niet sneller om het OS op aparte disks te zetten en de database op weer andere schijven? (aparte disks en partitie)

[LeLo]

Partities maken of niet zal voor de snelheid niets uitmaken (of in ieder geval voor de gebruikers niet merkbaar zijn). Partities voor OS en data en evt. backup om zo een scheiding te maken, is natuurlijk wel aan te raden, al is het alleen al om te voorkomen dat door een backup je systeemschijf volloopt en je OS stopt.

Verder is een Raid-5 volume een van de tragere opties voor een database, aangezien iedere IO naar het volume resulteert in drie disk-IO's en wat overhead voor de berekeningen door de controller. Een Raid-10 (een stripeset die je mirrored, of andersom) is sneller omdat iedere IO maar twee disk-IO's oplevert en er geen moeilijke berekeningen nodig zijn om de data weg te schrijven.

Maar: in jullie geval lijkt het me geen probleem om Raid-5 te gebruiken en als de baas dat wil, om alle data bij het OS op één partitie te dumpen. Beetje onoverzichtelijk en jammer als de schijf volloopt, maar geen performance issue...

[The-Force]

Ben het met LeLo Raid5 is in principe niet de juiste keuze voor een DB server, maar het is wel een goedkope, veilige opstelling, je hebt er maar 4 schijven voor nodig

Beste is OS in mirror , DB in raid 10, + 1 disk in global hot spare.
Maar deze opstelling kost je dus 7 schijven....

Als je raid5 doet is extra partitie niet echt sneller, wel makkelijker en praktischer, zeker voor defragmentatie.
Daarnaast kun je makkelijker eventueel OS opnieuw installeren terwijl de database gewoon op de andere partitie kan blijven staan.

[jeroentb]

Nog een bijkomstigheid, als je partitie waar je database op staat volloopt, kun je nog leuke problemen verwachten met je database Wat voor sqlserver gebruik je ?