Salvestuskiirus sobib jne? Küsime fio käest

Lühike lugu fio-st jne

Klastri jõudlus jne sõltub suuresti selle salvestusruumi jõudlusest. etcd ekspordib mõned mõõdikud asukohta Prometheussoovitud salvestuse jõudluse teabe esitamiseks. Näiteks mõõdik wal_fsync_duration_seconds. etcd dokumentatsioon ütleb: et salvestust saaks pidada piisavalt kiireks, peab selle mõõdiku 99. protsentiil olema väiksem kui 10 ms. Kui plaanite Linuxi masinates käitada etcd-klastrit ja soovite hinnata, kas teie salvestusruum on piisavalt kiire (nt SSD), võite kasutada FiO on populaarne tööriist I/O toimingute testimiseks. Käivitage järgmine käsk, kus test-data on salvestusruumi ühenduspunkti all olev kataloog:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Peate lihtsalt tulemusi vaatama ja kontrollima, kas kestuse 99. protsentiil fdatasync vähem kui 10 ms. Kui jah, siis on teil suhteliselt kiire salvestusruum. Siin on näide tulemuste kohta:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

Märkused

• Oleme kohandanud valikuid --size ja --bs meie konkreetse stsenaariumi jaoks. Fio-st kasuliku tulemuse saamiseks esitage oma väärtused. Kust neid saada? Lugege kuidas me õppisime fio konfigureerima.
• Testimise ajal tuleb kogu I/O koormus fio-lt. Reaalse elu stsenaariumi korral tuleb salvestusruumi tõenäoliselt muid kirjutamistaotlusi peale wal_fsync_duration_seconds-iga seotud taotluste. Lisakoormus suurendab wal_fsync_duration_seconds väärtust. Nii et kui 99. protsentiil on 10 ms lähedal, hakkab teie salvestusruumi kiirus otsa saama.
• Võtke versioon FiO vähemalt 3.5 (eelmised ei näita fdatasynci kestuse protsentiile).
• Ülal on vaid väljavõte fio tulemustest.

Pikk lugu fiost ja jne

Mis on WAL jne

Tavaliselt kasutavad andmebaasid ette kirjutamise logi; etcd kasutab ka seda. Me ei käsitle siin üksikasjalikult ettekirjutamise logi (WAL). Meile piisab teadmisest, et etcd klastri iga liige hoiab seda püsivas mälus. etcd kirjutab iga võtmeväärtuse toimingu (nt värskenduse) WAL-i enne selle poodi rakendamist. Kui üks salvestusliigetest jookseb kokku ja taaskäivitub hetktõmmiste vahel, saab see kohapeal taastada tehingud alates viimasest WAL-sisu hetktõmmisest.

Kui klient lisab võtmeväärtuste salve võtme või värskendab olemasoleva võtme väärtust, salvestab etcd toimingu WAL-i, mis on püsimälus tavaline fail. etcd PEAB olema enne töötlemise jätkamist täiesti kindel, et WAL-i sisestus toimus. Linuxis ei piisa selleks ühest süsteemikutsest. kirjutama, kuna tegelik kirjutamine füüsilisse salvestusruumi võib viibida. Näiteks võib Linux mõnda aega salvestada WAL-kirje kerneli vahemällu (näiteks lehe vahemällu). Ja selleks, et andmed saaks täpselt püsimällu kirjutada, on pärast kirjutamist vaja fdatasynci süsteemikutset ja etcd lihtsalt kasutab seda (nagu töö tulemusest näha kiirus, kus 8 on WAL-faili deskriptor):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Kahjuks ei toimu püsivale salvestusruumile kirjutamine kohe. Kui fdatasynci kõne on aeglane, kannatab etcd süsteemi jõudlus. etcd dokumentatsioon ütlebet salvestusruumi peetakse piisavalt kiireks, kui 99. protsentiili puhul kulub fdatasynci kõnedel WAL-faili kirjutamiseks vähem kui 10 ms. Salvestamise jaoks on ka muid kasulikke mõõdikuid, kuid selles postituses räägime ainult sellest mõõdikust.

Salvestusruumi hindamine fio abil

Kui teil on vaja hinnata, kas teie salvestusruum sobib jne, kasutage fio, väga populaarset I/O koormuse testimise tööriista. Tuleb meeles pidada, et kettatoimingud võivad olla väga erinevad: sünkroonsed ja asünkroonsed, paljud süsteemikõnede klassid jne. Selle tulemusena on fio kasutamine üsna keeruline. Sellel on palju parameetreid ja nende väärtuste erinevad kombinatsioonid toovad kaasa väga erineva I/O töökoormuse. Et saada adekvaatseid arve etcd kohta, peaksite WAL-failide kirjutamisel veenduma, et fio testkirjutuskoormus oleks võimalikult lähedane etcd tegelikule koormusele.

Seetõttu peaks fio looma vähemalt koormuse faili järjestikuste kirjutiste seeria kujul, iga kirjutamine koosneb süsteemikutsest kirjutamajärgneb fdatasynci süsteemikutse. Fio järjestikuste kirjutamiste jaoks on vajalik --rw=write. Et fio kasutaks kirjutamisel pigem kirjutamissüsteemi kutsumist, mitte kirjutada, peaksite määrama parameetri --ioengine=sync. Lõpuks, et kutsuda fdatasync pärast iga kirjutamist, peate lisama parameetri --fdatasync=1. Selle näite kaks muud valikut (--size ja -bs) on skriptipõhised. Järgmises jaotises näitame teile, kuidas neid seadistada.

Miks just fio ja kuidas me seda seadistama õppisime

Selles postituses kirjeldame tõelist juhtumit. Meil on klaster Kubernetes v1.13, mida jälgisime Prometheusega. etcd v3.2.24 hostiti SSD-l. Etcd mõõdikud näitasid fdatasynci latentsusaegu liiga kõrgeid, isegi kui klaster ei teinud midagi. Mõõdikud olid imelikud ja me ei teadnud tegelikult, mida need tähendavad. Klaster koosnes virtuaalmasinatest, oli vaja aru saada, milles probleem on: kas füüsilistes SSD-des või virtualiseerimiskihis. Lisaks tegime sageli muudatusi riist- ja tarkvara konfiguratsioonis ning vajasime viisi nende tulemuste hindamiseks. Võiksime käivitada etcd igas konfiguratsioonis ja vaadata Prometheuse mõõdikuid, kuid see on liiga suur tüli. Otsisime üsna lihtsat viisi konkreetse konfiguratsiooni hindamiseks. Tahtsime kontrollida, kas mõistame etcd Prometheuse mõõdikuid õigesti.

Kuid selleks tuli lahendada kaks probleemi. Esiteks, milline näeb välja I/O koormus, mille etcd loob WAL-i kirjutades? Milliseid süsteemikõnesid kasutatakse? Mis on plaatide suurus? Teiseks, kui me neile küsimustele vastame, siis kuidas saaksime fio-ga sarnast töökoormust taastoota? Ärge unustage, et fio on väga paindlik tööriist, millel on palju võimalusi. Mõlemad ülesanded lahendasime ühes lähenemisviisis – käskude abil lsof и kiirus. lsof loetleb kõik protsessis kasutatavad failideskriptorid ja nendega seotud failid. Ja strace abil saate uurida juba töötavat protsessi või käivitada protsessi ja seda uurida. strace prindib kõik uuritava protsessi (ja selle alamprotsesside) süsteemikutsed. Viimane on väga oluline, kuna etcd kasutab just sarnast lähenemist.

Esmalt kasutasime strace'i, et uurida Kubernetese jaoks etcd-serverit, kui klastris polnud koormust. Nägime, et peaaegu kõik WAL-kirjed olid umbes sama suurusega: 2200–2400 baiti. Seetõttu määrasime postituse alguses olevas käsus parameetri -bs=2300 (bs tähendab iga fio kirje suurust baitides). Pange tähele, et etcd kirje suurus sõltub etcd versioonist, jaotusest, parameetrite väärtustest jne ning mõjutab fdatasynci kestust. Kui teil on sarnane stsenaarium, uurige täpsete arvude leidmiseks oma etcd-protsesse strace-ga.

Seejärel, et saada hea ettekujutus sellest, mida failisüsteem etcd teeb, alustasime seda suvanditega strace ja -ffttT. Nii proovisime uurida alamprotsesse ja salvestada nende kõigi väljundid eraldi faili ning saada ka üksikasjalikke aruandeid iga süsteemikõne alguse ja kestuse kohta. Kasutasime lsof-i, et kinnitada oma analüüsi strace väljundi kohta ja vaadata, millist failikirjeldust millisel eesmärgil kasutati. Seega saadi strace abil ülaltoodud tulemused. Sünkroonimisaja statistika kinnitas, et wal_fsync_duration_seconds from etcd on kooskõlas WAL-failide deskriptoritega fdatasynci kõnedega.

Vaatasime läbi fio dokumentatsiooni ja valisime oma skripti jaoks valikud, et fio genereeriks etcd-ga sarnase koormuse. Samuti kontrollisime süsteemikõnesid ja nende kestust, käivitades strace-st sarnaselt etcd-ga fio.

Oleme hoolikalt valinud parameetri --size väärtuse, et see esindaks kogu fio sisend-/väljundkoormust. Meie puhul on see salvestusruumi kirjutatud baitide koguarv. Selgus, et see on otseselt proportsionaalne kirjutamise (ja fdatasync) süsteemikõnede arvuga. Teatud väärtuse bs korral on fdatasynci kõnede arv suurus/bs. Kuna meid huvitas protsentiil, pidi meil olema piisavalt proove, et olla kindel, ja arvutasime, et meile piisab 10^4-st (see on 22 mebibaiti). Kui --size on väiksem, võivad esineda kõrvalekalded (näiteks mitu fdatasynci kõnet võtab tavapärasest kauem aega ja mõjutab 99. protsentiili).

Proovige ise järele

Näitasime teile, kuidas kasutada fio-d ja vaadata, kas salvestusruumil on piisavalt kiirust suure jõudlusega jne. Nüüd saate seda ise proovida, kasutades näiteks SSD-mäluseadmega virtuaalmasinaid IBM Cloud.

Allikas: www.habr.com