Novelo pri fio kaj ktpd
Areto-rendimento plejparte dependas de la agado de ĝia stokado. etcd eksportas kelkajn metrikojn al por provizi la deziratajn konservadajn rendimentajn informojn. Ekzemple, la metriko wal_fsync_duration_seconds. : Por ke konservado estu konsiderata sufiĉe rapida, la 99-a percentilo de ĉi tiu metriko devas esti malpli ol 10ms. Se vi planas ruli etcd-grupon sur Linuksaj maŝinoj kaj volas taksi ĉu via stokado estas sufiĉe rapida (ekz. SSD), vi povas uzi estas populara ilo por testi I/O-operaciojn. Rulu la sekvan komandon, kie test-datumoj estas la dosierujo sub la stoka munta punkto:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestVi nur bezonas rigardi la rezultojn kaj kontroli, ke la 99a procento de la daŭro malpli ol 10 ms. Se jes, vi havas sufiĉe rapidan stokadon. Jen ekzemplo de la rezultoj:
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]Notoj
- Ni agordis la --size kaj --bs-opciojn por nia aparta scenaro. Por akiri utilan rezulton de fio, donu viajn proprajn valorojn. Kie akiri ilin? Legu .
- Dum testado, ĉiu I/O-ŝarĝo venas de fio. En reala scenaro, verŝajne estos aliaj skribpetoj venantaj en la stokadon krom tiuj rilataj al wal_fsync_duration_seconds. La ekstra ŝarĝo pliigos la valoron de wal_fsync_duration_seconds. Do se la 99-a percentilo estas proksima al 10ms, via stokado elĉerpiĝas.
- Prenu la version ne malpli ol 3.5 (la antaŭaj ne montras fdatasync-daŭroprocentojn).
- Supre estas nur fragmento de la rezultoj de fio.
Longa rakonto pri fio kaj ktp
Kio estas WAL en etcd
Kutime datumbazoj uzas ; ankaŭ etcd uzas ĝin. Ni ne diskutos la skriban antaŭan protokolon (WAL) detale ĉi tie. Sufiĉas al ni scii, ke ĉiu membro de la etcd-areto konservas ĝin en konstanta stokado. etcd skribas ĉiun ŝlosil-valoran operacion (kiel ekzemple ĝisdatigo) al WAL antaŭ apliki ĝin al la vendejo. Se unu el la konservadmembroj kraŝas kaj rekomencas inter momentfotoj, ĝi povas loke restarigi transakciojn ekde la lasta momentfoto per WAL-enhavo.
Kiam kliento aldonas ŝlosilon al la ŝlosilvalora vendejo aŭ ĝisdatigas la valoron de ekzistanta ŝlosilo, etcd registras la operacion en WAL, kiu estas regula dosiero en konstanta stokado. etcd DEVAS esti tute certa, ke la eniro WAL efektive okazis antaŭ ol daŭrigi la prilaboradon. En Linukso, unu sistemvoko ne sufiĉas por tio. , ĉar la fakta skribo al fizika stokado povas esti prokrastita. Ekzemple, Linukso povas stoki WAL-eniron en kaŝmemoro en kernmemoro (kiel paĝa kaŝmemoro) dum iom da tempo. Kaj por ke la datumoj estu precize skribitaj al konstanta stokado, la fdatasync-sistemvoko estas necesa post la skribo, kaj etcd nur uzas ĝin (kiel vi povas vidi en la rezulto de la laboro. , kie 8 estas la WAL-dosierpriskribilo):
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>Bedaŭrinde, skribi al konstanta stokado ne okazas tuj. Se la fdatasync-voko estas malrapida, la agado de la etcd-sistemo suferos. ke la stokado estas konsiderata sufiĉe rapida se, en la 99-a percentilo, fdatasync-vokoj bezonas malpli ol 10ms por skribi al la WAL-dosiero. Estas aliaj utilaj metrikoj por stokado, sed en ĉi tiu afiŝo ni nur parolas pri ĉi tiu metriko.
Taksante stokadon kun fio
Se vi bezonas taksi ĉu via stokado taŭgas por etcd, uzu fio, tre populara I/O-ŝarĝa testa ilo. Oni devas memori, ke diskoperacioj povas esti tre malsamaj: sinkronaj kaj nesinkronaj, multaj klasoj de sistemaj vokoj, ktp. Rezulte, fio estas sufiĉe malfacile uzebla. Ĝi havas multajn parametrojn, kaj malsamaj kombinaĵoj de iliaj valoroj produktas tre malsamajn I/O-laborŝarĝojn. Por akiri taŭgajn ciferojn por etcd, vi devus certigi, ke la prova skribŝarĝo de fio estas kiel eble plej proksima al la reala ŝarĝo de etcd dum skribado de WAL-dosieroj.
Tial, fio devus, minimume, krei ŝarĝon de serio de sinsekvaj skriboj al la dosiero, ĉiu skribo konsistos el sistema voko. sekvita de la fdatasync sistemvoko. Sinsekvaj skriboj al fio postulas la --rw=skribi opcion. Por fio uzi la skriban sistemvokon dum skribado, prefere ol , vi devus specifi la --ioengine=sync parametron. Fine, por voki fdatasync post ĉiu skribo, vi devas aldoni la --fdatasync=1 parametron. La aliaj du opcioj en ĉi tiu ekzemplo (--size kaj -bs) estas skript-specifaj. En la sekva sekcio, ni montros al vi kiel agordi ilin.
Kial fio kaj kiel ni lernis agordi ĝin
En ĉi tiu afiŝo, ni priskribas realan kazon. Ni havas areton v1.13 kiun ni monitoris kun Prometheus. etcd v3.2.24 estis gastigita sur SSD. Etcd-metrikoj montris fdatasync-latentecojn tro altajn, eĉ kiam la areto nenion faris. La metrikoj estis strangaj kaj ni ne vere sciis, kion ili signifas. La areto konsistis el virtualaj maŝinoj, necesis kompreni, kio estas la problemo: en fizikaj SSD-oj aŭ en la virtualiga tavolo. Krome, ni ofte faris ŝanĝojn al la aparataro kaj programaro agordo, kaj ni bezonis manieron taksi iliajn rezultojn. Ni povus ruli etcd en ĉiu agordo kaj rigardi Prometheus-metrikon, sed tio estas tro da ĝeno. Ni serĉis sufiĉe simplan manieron taksi specifan agordon. Ni volis kontroli ĉu ni ĝuste komprenas Prometheus-metrikon de etcd.
Sed por tio, du problemoj devis esti solvitaj. Unue, kiel aspektas la I/O-ŝarĝo, kiun etcd kreas dum skribado al WAL? Kiuj sistemvokoj estas uzataj? Kio estas la grandeco de la rekordoj? Due, se ni respondas ĉi tiujn demandojn, kiel ni reproduktas similan laborŝarĝon kun fio? Ne forgesu, ke fio estas tre fleksebla ilo kun multaj elektoj. Ni solvis ambaŭ problemojn per unu aliro - uzante la komandojn и . lsof listigas ĉiujn dosierpriskribilojn uzatajn de la procezo kaj iliajn rilatajn dosierojn. Kaj kun strace, vi povas ekzameni jam funkciantan procezon, aŭ komenci procezon kaj ekzameni ĝin. strace presas ĉiujn sistemvokojn de la ekzamenata procezo (kaj ĝiaj infanaj procezoj). Ĉi-lasta estas tre grava, ĉar etcd nur prenas similan aliron.
Ni unue uzis strace por esplori la etcd-servilon por Kubernetes kiam ne estis ŝarĝo sur la areto. Ni vidis, ke preskaŭ ĉiuj WAL-rekordoj estis proksimume la sama grandeco: 2200–2400 bajtoj. Tial, en la komando komence de la afiŝo, ni specifis la parametron -bs=2300 (bs signifas la grandecon en bajtoj por ĉiu fio-eniro). Notu ke la grandeco de la etcd-eniro dependas de la etcd-versio, distribuo, parametrovaloroj, ktp., kaj influas la fdatasync-daŭron. Se vi havas similan scenaron, ekzamenu viajn etcd-procezojn kun strace por ekscii la ĝustajn nombrojn.
Poste, por havi bonan ideon pri tio, kion faras la dosiersistemo etcd, ni komencis ĝin per strace kaj la opcioj -ffttT. Do ni provis ekzameni la infanajn procezojn kaj registri la eliron de ĉiu el ili en aparta dosiero, kaj ankaŭ ricevi detalajn raportojn pri la komenco kaj daŭro de ĉiu sistema voko. Ni uzis lsof por konfirmi nian analizon de la eligo de streko kaj vidi kiu dosierpriskribilo estas uzata por kiu celo. Do helpe de Strace, la rezultoj montritaj supre estis akiritaj. Sinkronigaj tempostatistikoj konfirmis, ke wal_fsync_duration_seconds de etcd kongruas kun fdatasync-vokoj kun WAL-dosierpriskribiloj.
Ni ekzamenis la dokumentadon por fio kaj elektis eblojn por nia skripto por ke fio generus ŝarĝon similan al etcd. Ni ankaŭ kontrolis sistemajn vokojn kaj ilian daŭron rulante fio de strace, simile al etcd.
Ni zorge elektis la valoron de la --size parametro por reprezenti la tutan I/O-ŝarĝon de fio. En nia kazo, ĉi tio estas la totala nombro da bajtoj skribitaj al la stokado. Ĝi montriĝis rekte proporcia al la nombro da skribaj (kaj fdatasync) sistemvokoj. Por certa valoro de bs, la nombro da fdatasync-vokoj = grandeco/bs. Ĉar ni interesiĝis pri la percentilo, ni devis havi sufiĉe da specimenoj por esti certaj, kaj ni kalkulis, ke 10^4 sufiĉus por ni (tio estas 22 mebibajtoj). Se --size estas pli malgranda, eksteraĵoj povas okazi (ekzemple, pluraj fdatasync-vokoj daŭras pli longe ol kutime kaj influas la 99-an percentilon).
Provu ĝin mem
Ni montris al vi kiel uzi fio kaj vidi ĉu la stokado estas sufiĉe rapida por ke etcd bone agu. Nun vi povas provi ĝin mem uzante, ekzemple, virtualajn maŝinojn kun SSD-stokado .
fonto: www.habr.com