---

Hvad er Jeres erfaringer med diske og databaser?

Specifikt om det er en fordel at stripe en masse diske og uddele
partioner som logiske units, have en stor beskidt striped partion
eller at lave separate arrays?

Med striped mener jeg striped mirrors.

--
Lars Kim Lund
http://www.net-faq.dk/

---

On Wed, 23 Apr 2003 16:51:13 +0200, Lars Kim Lund <lkl@fabel.dk>
wrote:

>
>Hvad er Jeres erfaringer med diske og databaser?
>
>Specifikt om det er en fordel at stripe en masse diske og uddele
>partioner som logiske units, have en stor beskidt striped partion
>eller at lave separate arrays?
>
>Med striped mener jeg striped mirrors.

Helt klart så mange (små) diske som muligt.

Vi har 48 x 18 GB til en 100 brugers Oracledatabase. Og det er stadig
diskene vi venter på ~1-5 % svartid er fra diskene.

Vi har sat dem i raid-0+1 (striped mirrors som du skriver), og
tildelst et antal mirrors a 18GB til et stripeset, som passer til det
data/trafik vi skal bruge pågældende volume (logisk unit) til. Fx. til
vores DATA-diske bruger vi 8 mirrorset, index har 8 mirrorset, og så
videre. Jo flere logiske units og derved diske du kan skrive til
samtidig, des større performance.

Næste led er så fødning af diskene. Kan din bus klare det?

Vi har et MA8000 san/diskrack til dette formål. Der er så også
redundans i dette setup, og lidt cache.


--

/Dan MOrtensen
Svar ikke pr. mail, da din mailserver vil blive blacklisted
listme@listme.dsbl.org
Don't use my email - your mail server will be blacklisted.

---

Dan MOrtensen <listme@listme.dsbl.org> wrote:

>>Specifikt om det er en fordel at stripe en masse diske og uddele
>>partioner som logiske units, have en stor beskidt striped partion
>>eller at lave separate arrays?
>>
>>Med striped mener jeg striped mirrors.
>
>Helt klart så mange (små) diske som muligt.
>
>Vi har 48 x 18 GB til en 100 brugers Oracledatabase. Og det er stadig
>diskene vi venter på ~1-5 % svartid er fra diskene.
>
>Vi har sat dem i raid-0+1 (striped mirrors som du skriver), og
>tildelst et antal mirrors a 18GB til et stripeset, som passer til det
>data/trafik vi skal bruge pågældende volume (logisk unit) til. Fx. til
>vores DATA-diske bruger vi 8 mirrorset, index har 8 mirrorset, og så
>videre. Jo flere logiske units og derved diske du kan skrive til
>samtidig, des større performance.

Det handler vel et eller andet sted om i/o - og det får men ved at
have mange spindels. Lad os tage dit eksempel.

48 diske fordel på 3 units af 16 diske i striped mirrors.

Alternativet kunne være at lave et striped mirror på alle 48 diske og
lave 3 logiske units ud af det. Eller det kunne være at have et stort
striped mirror på 48 diske men kun een logisk unit.

Fordelen ved at have 48 diske i stedet for 3 x 16 er at der er flere
spindels og dvs. mere i/o. Ulempen ved at partitionere det kan være at
disksystemet kommer til at "springe" mellem de forskellige partitioner
og problemet med een stor unit kunne være at man får et stort
filsystem.

Du nævner selv parallellisme - men det opnår man jo også ved at have
mange spindels. Og mætning af cache er jo det samme uanset om du
opdeler det eller ej.

Jeg kender ikke selv svaret - men jeg synes diskussionen er
interessant. Jeg har tidligere brugt separate arrays men jeg er ikke
længere så overbevist om at det er det rigtige.

>Næste led er så fødning af diskene. Kan din bus klare det?

Det var et mere generelt spørgsmål. Konkret har vi lige som Jer et
MA8k, dobbelt HSG80 med spejlet cache og 2 FC switche.

>Vi har et MA8000 san/diskrack til dette formål. Der er så også
>redundans i dette setup, og lidt cache.

Joda - du husker at spejle din cache, ikke?

--
Lars Kim Lund
http://www.net-faq.dk/

---

"Lars Kim Lund" <lkl@fabel.dk> wrote in message
news:0t9davcrklmauophnt424206p46ep5ipas@dtext.news.tele.dk...
>
> Hvad er Jeres erfaringer med diske og databaser?
>
> Specifikt om det er en fordel at stripe en masse diske og uddele
> partioner som logiske units, have en stor beskidt striped partion
> eller at lave separate arrays?
>
> Med striped mener jeg striped mirrors.

Performancemæssigt er det en balanceakt som samtidig i høj grad afhænger af
hvilken RAID controller der styrer tingene i sidste ende.

Administrationsmæssigt er det en balanceakt mellem hvad der er optimalt for
performance og hvad der er optimalt for administration.

Dernæst har databasetypen og brugsmønstret stor indflydelse. En
datawarehouse (DW) database har typisk et helt andet access mønster end en
typisk front-end kundedatabase.

Min erfaring fra den kunde jeg er udstationeret hos er at langt de fleste
non-DW løsninger med tilstrækkelig RAM har yderst begrænset disk access
bortset fra under backup og når en eller anden query uheldigvis ender op med
full table scan.
D.v.s. her kan man ofte vægte det administrationsmæssige forholdsvist højt
uden at det går ud over performance.
Disse systemer (hvor jeg arbejder) når sjældent over 100 MB/s samlet I/O
throughput bortset fra under backup og ligget typisk på under 20 MB/s.

DW løsninger derimod har som regel generelt høj I/O som stiller store krav
til optimalt disk layout rent performance mæssigt.
Disse systemer ligger som regel højt i MB/s throughput. Vores "værste"
maskine ligger typisk på 500-600 MB/s med peaks lige under 800 MB/s.

Databasens features har også betydning. Oracle 8i og opefter har f.eks.
features (pertitionering m.m.) der gør det nemmere at få noget optimalt ud
af sit storagelayout uden at det går ud over administrationen.

M.h.t. RAM, under x86 kan det være et problem at løse det med RAM dels på
grund af 4 GB limit og dernæst 2 GB per process limit.
Vi har som regel betydeligt mere RAM. Større maskiner som regel 16-32 GB, og
der caches kraftigt hvilket eliminerer meget af den disk I/O man ellers
ville have haft.

Hvis du laver seperate arrays, d.v.s. 2 diske striped som en unit bliver den
distribuerede performance (mange samtidige brugere der ikke laver det
samme)god, næsten uanset hvor dårlig en RAID controller du bruger, men I/O
per second per unit bliver for lav hvilket medfører at en full table scan
eller noget andet grimt bliver en flaskehals med mindre databasefilerne er
distribueret over flere units.
Du skal op på 4-6 diske per unit for at få en fornuftig I/Os. Med mere end 6
kan du rende ind i det problem at unit'en som helhed er overkill i forhold
til hvad forbindelsen til host'en (især ved gammeldags SCSI) kan klare.
Med få meget store units kan du samtidig rende ind i problemer med at RAID
controlleren ikke er god nok til at servicere parallelle tasks, d.v.s.
unit'en bliver muligvis god m.h.t. I/Os per sekund og isør throughput, men
hvis den bliver bedt om 20 forskellige ting på samme tid så går det galt.

Det kan ofte betale sig at teste sig frem til brugbar viden. Jeg bruger som
regel programmet iozone. Det tester både sekventiel og random access og kan
samtidig sættes til at gøre det med mange samtidige tests.
Ex.:
iozone -t 4 -s 9g -F /data/01/foo.1 /data/02/foo.01 /data/03/foo.01
/data/04/foo.01

Tester med 4 threads og filer på 9 GB i 4 filer. Så kan man så prøve at se
hvordan det går hvis disse 4 filer befinder sig på 4 individuelle units
eller 4 logisk partitions i en stor unit, og hvordan det går hvis man har
flere filer inde i hver logisk eller fysisk unit.
Det er ganske god lærdom at sætte en dag af til hver controller type og køre
disse tests på en fast datastørrelse, f.eks. 100 GB og så se hvordan
controlleren opfører sig hvis det er flere små units, een stor og hvilken
effekt det har på sekventiel & random samt read & write.

Jeg ved ikke om du har kigget lidt på HSV110 ?. På mit arbejde har vi nogle
maskiner med disse, og de har vendt grundigt op og ned på hvordan vi
konfigurerer og administrerer storage. Vi tænker nu stort set udelukkende i
hvad der er nemmest for os rent administrativt og så finder controlleren
selv ud af at gøre det optimalt rent performance mæssigt. Vores DW disk
performance steg ca. til det dobbelte da vik gik fra 8 x HSG80 til 2 x
HSV110.

Selv med HSG80 og HSZ70 er jeg mere tilhænger af få store units fremfor
mange små når det ikke er DW. Den samlede performance er næsten lige så god
som flere mindre units og man undgår i mange tilfælde administrative
problemer.
Een stor har jeg aldrig lavet, men nogle få store ja, f.eks.

/Jesper