Levyjärjestelmän kuormituksen ja viiveiden simulointi ei ole helppoa koska kyse on monimutkaisesta järjestelmästä missä on useammalla tasolla välimuisteja sekä resurssien jakoa.
Sain kuitenkin viimein tehtyä mielessäni olevan hyvin yksinkertaisen simuloinnin jossa simuloidaan suoraan erillisiin levyihin kohdistuvaa kuormaa ja etenkin sitä miten kuorman kasvaessa ajallisesti päällekkäiset lukupyynnöt vaikuttavat lukupyyntöjen viiveisiin. Levy on rajallinen resurssi ja yksinkertaisimmillaan jokainen lukupyyntö kestää keskimäärin nykylevyillä 5,5 millisekuntia. Nykyisillä levyillä on kuitenkin käytössä oma sisäinen "asynkroninen" jononsa kuten NCQ tai TCQ joka mahdollistaa levylukujen järjestäminen levyn sisällä niin että se voidaan tehdä pienimmällä mahdollisella lukupään liikkeellä. Kuitenkin keskimäärin voidaan vielä sanoa että nykyjärjestelmässä 5,5ms on hyvä hakuaika.
Johtuen tuossa hakuajasta levyllä on myös maksimi lukujen määrä sekunnissa mikä on 1s/5,5ms eli noin 180 IOPS.
Levyistä hyviä suorituskykytestejä löytyy täältä:
StorageReview.com Benchmark Database
SSD-levyjen hakuajat ovat tietenkin huomattavasti nopeammat joten niitä on tässä edes turha käsitellä.
Käytin oman levyio-simulaattorini tekoon kaikkein kehittyneintä työkalua eli Exceliä :)
Kun annan parametreiksi IOPS, levyjen määrän, testin keston sekunteina ja levyn keskimääräisen hakuajan, kaavani luo satunnaisluvulla tarvittaman määrän testihakuja. Kaava jakaa nämä jokaiselle levylle erikseen ja laskee päällekkäistä operaatioista aiheutuvan lisäviiveen. Kaavan maksimimäärä testihauille on tällä hetkellä 15000 ja teknisesti onnistuisi luultavasti ainakaan 64000 mutta se ei ole tarpeen koska huomattavasti pienemmälläkin määrällä saa simulaatiossa jo riittävän tarkkuuden.
Ajoin testit kymmenellä levyllä ja testien simuloidut kestot olivat 7-10 sekunnin välillä. Excel suoriutui niistä kohtuullisen nopeasti, kaavojen päivitys eli yhden testin ajo kesti n. 15 sekuntia neljällä prosessorilla.
Käyrässä pystyakseli on hakuaika millisekunneissa ja vaaka-akseli IOPS. Kymmenen levyn järjestelmässä 5,5ms hakuajalla 1800 IOPS on teoreettinen maksimi.
Kun tuo arvo ylitetään, vain nuo 1800 IOPS suoritetaan ja sen yli menevät pyynnöt jäävät jonoon joka kasvaa jatkuvasti. Johtuen simuloinnin lyhyydestä keskimääräinen hakuaika on vielä "järkevä" vaikka pitempään simuloitaessa levyjonon koko kasvaa jatkuvasti ja hakuaika on käytännössä ikuinen ts. järjestelmä on jumissa ja kyselyt keskeytyvät timeoutiin.
Yllä olevassa kaaviossa on keskimääräinen hakuaika kuormituksen funktiona. Pystyakseli on logaritminen. Pienellä kuormalla 5,5ms hakuaika saavutetaan mutta kuorman kasvaessa rinnakkaisten hakupyyntöjen määrä kasvaa ja kun levyt ovat kuormittuneet n. 50% niin hakuaika on kasvanut jo 8,1 millisekuntiin. Kun hakuaika on jo 20 millisekuntia, niin levyjärjestelmä on jo kuormittunut 80%:iin.
Todellisuus tietenkin on taas monimutkaisempi. NCQ ja TCQ-ominaisuudet levyissä alkavat toimia vasta kun levyillä on jo jonoja ts. ne tasaavat hakuajan nousua suuremmalla kuormalla. Samalla se tarkoittaa myös että levyllä ei jonoja ole jos hakuaika on lähellä minimiä.
Samoin olen tässä käsitellyt vain hajalukuja. Riippuen kannan kuormasta osa hauista on hajalukuja ja osa taulujen läpilukuja yms. missä haetaan suuri määrä peräkkäin tallennettua dataa ts. peräkkäislukuja joissa lukupään siirtymistä on vähemmän ja luku siksi tehokkaampaa.
Mielenkiintoinen näkökanta on myös kuinka paljon levyviiveet aiheuttavat käyttäjien työajan menetystä. Jos kaikki levyhaku on käyttäjien tekemää( mitä se harvoin on) niin voidaan laskea työajan menetykset kuorman kasvun ja niiden viiveiden kasvun myötä. Jos tiedetään käyttäjien tekemien hakujen osuus koko kuormasta, voidaan allaolevaa kaaviota myös arvioida sillä kertoimella.
Ajatuksena tuossa on että kun tunnin aikana tehdään tunnin ajan levyhakuja, vievät ne samalla käyttäjien työaikaa saman verran. Jos hakuaika tuplaantuu, viedään kahden hengen työaika. Levykuorma tietenkin vaihtelee päivän aikana, joten silloin verrataan keskimääräistä kuormitusta työaikana. Kun siis 10 levyn järjestelmää kuormitetaan 600 IOPSn verran, vie se normaalien levyviiveiden lisäksi yhden hengen työpanoksen johtuen rinnakkaisuudesta tulevista lisäviiveistä. Jos järjestelmä on kuormittunut 80%:iin niin rinnakkaisuuden viemä käyttäjäaika vastaa jo 16 käyttäjän työpanosta. Laskelmia levynkuormituksesta ja käyttäjäviiveistä kannattaakin käyttää tukena levyjärjestelmän tehotarpeita ja kustannuksia arvioitaessa
Samaa levykuormituksen arviointia voi käyttää myös esimerkiksi Hadoopin levyjen määrää suunniteltaessa.
Sain kuitenkin viimein tehtyä mielessäni olevan hyvin yksinkertaisen simuloinnin jossa simuloidaan suoraan erillisiin levyihin kohdistuvaa kuormaa ja etenkin sitä miten kuorman kasvaessa ajallisesti päällekkäiset lukupyynnöt vaikuttavat lukupyyntöjen viiveisiin. Levy on rajallinen resurssi ja yksinkertaisimmillaan jokainen lukupyyntö kestää keskimäärin nykylevyillä 5,5 millisekuntia. Nykyisillä levyillä on kuitenkin käytössä oma sisäinen "asynkroninen" jononsa kuten NCQ tai TCQ joka mahdollistaa levylukujen järjestäminen levyn sisällä niin että se voidaan tehdä pienimmällä mahdollisella lukupään liikkeellä. Kuitenkin keskimäärin voidaan vielä sanoa että nykyjärjestelmässä 5,5ms on hyvä hakuaika.
Johtuen tuossa hakuajasta levyllä on myös maksimi lukujen määrä sekunnissa mikä on 1s/5,5ms eli noin 180 IOPS.
Levyistä hyviä suorituskykytestejä löytyy täältä:
StorageReview.com Benchmark Database
SSD-levyjen hakuajat ovat tietenkin huomattavasti nopeammat joten niitä on tässä edes turha käsitellä.
Käytin oman levyio-simulaattorini tekoon kaikkein kehittyneintä työkalua eli Exceliä :)
Kun annan parametreiksi IOPS, levyjen määrän, testin keston sekunteina ja levyn keskimääräisen hakuajan, kaavani luo satunnaisluvulla tarvittaman määrän testihakuja. Kaava jakaa nämä jokaiselle levylle erikseen ja laskee päällekkäistä operaatioista aiheutuvan lisäviiveen. Kaavan maksimimäärä testihauille on tällä hetkellä 15000 ja teknisesti onnistuisi luultavasti ainakaan 64000 mutta se ei ole tarpeen koska huomattavasti pienemmälläkin määrällä saa simulaatiossa jo riittävän tarkkuuden.
Ajoin testit kymmenellä levyllä ja testien simuloidut kestot olivat 7-10 sekunnin välillä. Excel suoriutui niistä kohtuullisen nopeasti, kaavojen päivitys eli yhden testin ajo kesti n. 15 sekuntia neljällä prosessorilla.
Käyrässä pystyakseli on hakuaika millisekunneissa ja vaaka-akseli IOPS. Kymmenen levyn järjestelmässä 5,5ms hakuajalla 1800 IOPS on teoreettinen maksimi.
Kun tuo arvo ylitetään, vain nuo 1800 IOPS suoritetaan ja sen yli menevät pyynnöt jäävät jonoon joka kasvaa jatkuvasti. Johtuen simuloinnin lyhyydestä keskimääräinen hakuaika on vielä "järkevä" vaikka pitempään simuloitaessa levyjonon koko kasvaa jatkuvasti ja hakuaika on käytännössä ikuinen ts. järjestelmä on jumissa ja kyselyt keskeytyvät timeoutiin.
Yllä olevassa kaaviossa on keskimääräinen hakuaika kuormituksen funktiona. Pystyakseli on logaritminen. Pienellä kuormalla 5,5ms hakuaika saavutetaan mutta kuorman kasvaessa rinnakkaisten hakupyyntöjen määrä kasvaa ja kun levyt ovat kuormittuneet n. 50% niin hakuaika on kasvanut jo 8,1 millisekuntiin. Kun hakuaika on jo 20 millisekuntia, niin levyjärjestelmä on jo kuormittunut 80%:iin.
Todellisuus tietenkin on taas monimutkaisempi. NCQ ja TCQ-ominaisuudet levyissä alkavat toimia vasta kun levyillä on jo jonoja ts. ne tasaavat hakuajan nousua suuremmalla kuormalla. Samalla se tarkoittaa myös että levyllä ei jonoja ole jos hakuaika on lähellä minimiä.
Samoin olen tässä käsitellyt vain hajalukuja. Riippuen kannan kuormasta osa hauista on hajalukuja ja osa taulujen läpilukuja yms. missä haetaan suuri määrä peräkkäin tallennettua dataa ts. peräkkäislukuja joissa lukupään siirtymistä on vähemmän ja luku siksi tehokkaampaa.
Mielenkiintoinen näkökanta on myös kuinka paljon levyviiveet aiheuttavat käyttäjien työajan menetystä. Jos kaikki levyhaku on käyttäjien tekemää( mitä se harvoin on) niin voidaan laskea työajan menetykset kuorman kasvun ja niiden viiveiden kasvun myötä. Jos tiedetään käyttäjien tekemien hakujen osuus koko kuormasta, voidaan allaolevaa kaaviota myös arvioida sillä kertoimella.
Ajatuksena tuossa on että kun tunnin aikana tehdään tunnin ajan levyhakuja, vievät ne samalla käyttäjien työaikaa saman verran. Jos hakuaika tuplaantuu, viedään kahden hengen työaika. Levykuorma tietenkin vaihtelee päivän aikana, joten silloin verrataan keskimääräistä kuormitusta työaikana. Kun siis 10 levyn järjestelmää kuormitetaan 600 IOPSn verran, vie se normaalien levyviiveiden lisäksi yhden hengen työpanoksen johtuen rinnakkaisuudesta tulevista lisäviiveistä. Jos järjestelmä on kuormittunut 80%:iin niin rinnakkaisuuden viemä käyttäjäaika vastaa jo 16 käyttäjän työpanosta. Laskelmia levynkuormituksesta ja käyttäjäviiveistä kannattaakin käyttää tukena levyjärjestelmän tehotarpeita ja kustannuksia arvioitaessa
Samaa levykuormituksen arviointia voi käyttää myös esimerkiksi Hadoopin levyjen määrää suunniteltaessa.
Comments
Post a Comment