🥇Carane mriksa disk nganggo fio kanggo kinerja sing cukup kanggo etcd

Cathetan. nerjemahake.: Artikel iki minangka asil riset mini sing ditindakake dening insinyur IBM Cloud kanggo nggoleki solusi kanggo masalah nyata sing ana gandhengane karo operasi database etcd. Tugas sing padha cocog kanggo kita, nanging dalane pikiran lan tumindak penulis bisa uga menarik ing konteks sing luwih jembar.

Ringkesan ringkes saka kabeh artikel: fio lan etcd

Kinerja kluster etcd gumantung banget marang kacepetan panyimpenan dhasar. Kanggo ngawasi kinerja, etcd ngekspor macem-macem metrik Prometheus. Salah sijine yaiku wal_fsync_duration_seconds. Ing dokumentasi etcd jarene, panyimpenan kasebut bisa dianggep cukup cepet yen persentil 99 saka metrik iki ora ngluwihi 10 ms...

Yen sampeyan nimbang nyetel kluster etcd ing mesin Linux lan pengin nyoba apa drive panyimpenan (kayata SSD) cukup cepet, disaranake nggunakake tester I/O populer sing diarani fio. Mung mbukak printah ing ngisor iki (directory test-data kudu dumunung ing partisi sing dipasang ing drive sing diuji):

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

Kabeh sing isih ana yaiku ndeleng output lan priksa manawa cocog karo persentil kaping 99 fdatasync ing 10 ms. Yen mangkono, drive sampeyan cukup cepet. Punika conto output:

fsync/fdatasync/sync_file_range:
  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]

Cathetan sawetara:

Ing conto ing ndhuwur kita wis nyetel paramèter --size и --bs kanggo kasus tartamtu. Kanggo entuk asil sing migunani saka fio, nemtokake nilai sing cocog kanggo kasus panggunaan sampeyan. Cara milih dheweke bakal dibahas ing ngisor iki.
Sajrone testing mung fio ngemot subsistem disk. Ing urip nyata, ana kemungkinan proses liyane (saliyane sing ana gandhengane karo wal_fsync_duration_seconds). Beban tambahan kasebut bisa nyebabake paningkatan wal_fsync_duration_seconds. Ing tembung liyane, yen persentil 99th dijupuk saka testing karo fio, mung rada kurang saka 10 ms, ana kasempatan apik sing kinerja panyimpenan ora cukup.
Kanggo test sampeyan kudu versi fio ora kurang saka 3.5, amarga versi lawas ora nglumpukake asil fdatasync ing wangun persentil.
Kesimpulan ing ndhuwur mung minangka cuplikan cilik saka kesimpulan sakabèhé fio.

Rincian babagan fio lan etcd

A words sawetara bab WALs etcd

Biasane, database nggunakake logging proaktif (write-ahead logging, WAL). etcd iki uga ditrapake. Diskusi babagan WAL ngluwihi ruang lingkup artikel iki, nanging kanggo tujuan iki sampeyan kudu ngerti: Saben anggota kluster etcd nyimpen WAL ing panyimpenan sing terus-terusan. etcd nulis sawetara operasi nyimpen nilai kunci (kayata nganyari) menyang WAL sadurunge nglakokake. Yen simpul tubrukan lan miwiti maneh antarane jepretan, etcd bisa mulihake transaksi digawa metu wiwit gambar asli seko sadurungé adhedhasar isi WAL.

Mangkono, saben-saben klien nambah tombol kanggo nyimpen KV utawa nganyari Nilai saka tombol ana, etcd nambah gambaran saka operasi kanggo WAL, kang file biasa ing panyimpenan ngengkel. etcd kudu 100% yakin yen entri WAL bener disimpen sadurunge nerusake. Kanggo entuk iki ing Linux, ora cukup nggunakake panggilan sistem write, wiwit operasi nulis dhewe kanggo medium fisik bisa telat. Contone, Linux bisa nyimpen entri WAL ing cache kernel ing memori (kayata cache kaca) kanggo sawetara wektu. Kanggo mesthekake yen data ditulis ing media, telpon sistem kudu dijaluk sawise nulis fdatasync - iki persis apa sing ditindakake etcd (kaya sing bisa dideleng ing output ing ngisor iki strace; kene 8 - WAL file handle):

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

Sayange, nulis menyang panyimpenan tetep mbutuhake sawetara wektu. Njupuk wektu dawa kanggo ngrampungake telpon fdatasync bisa impact etcd kinerja. Ing dokumentasi kanggo repositori dituduhakesing kanggo kinerja cekap perlu persentil 99th saka durasi kabeh telpon fdatasync nalika nulis menyang file, WAL kurang saka 10 ms. Ana metrik liyane sing ana gandhengane karo panyimpenan, nanging artikel iki bakal fokus ing siji iki.

Evaluasi panyimpenan nggunakake fio

Sampeyan bisa ngevaluasi apa panyimpenan tartamtu cocok kanggo nggunakake etcd nggunakake sarana fio - tester I/O populer. Elinga yen disk I / O bisa kedadeyan kanthi cara sing beda-beda: sinkronisasi / asinkron, macem-macem kelas panggilan sistem, lsp. Sisih liyane saka duwit receh iku fio arang banget angel kanggo nggunakake. Utilitas kasebut duwe akeh paramèter, lan kombinasi sing beda-beda saka nilai kasebut nyebabake asil sing beda. Kanggo entuk perkiraan sing cukup kanggo etcd, sampeyan kudu mesthekake yen beban tulis sing digawe dening fio meh padha karo beban tulis etcd menyang file WAL:

Iki tegese sing digawe fio beban kerja kudu paling sethithik minangka seri nulis urutan menyang file, ing ngendi saben operasi nulis kalebu panggilan sistem writeditututi karo fdatasync.
Kanggo ngaktifake rekaman urutan, sampeyan kudu nemtokake gendera --rw=write.
sing fio nulis nganggo telpon write (lan dudu telpon sistem liyane - contone, pwrite), gunakake gendera --ioengine=sync.
Akhire, gendéra --fdatasync=1 njamin sing konco saben write kudu fdatasync.
Loro paramèter liyane ing conto kita: --size и --bs - bisa beda-beda gumantung ing kasus panggunaan tartamtu. Bagean sabanjure bakal nerangake carane ngatur.

Apa kita milih fio lan carane kita sinau carane nyetel

Cathetan iki asale saka kasus nyata sing ditemoni. Kita duwe kluster ing Kubernetes v1.13 kanthi ngawasi Prometheus. drive ngalangi negara digunakake minangka panyimpenan kanggo etcd v3.2.24. metrik etcd nuduhake latensi dhuwur banget fdatasync, sanajan kluster ora aktif. Kita nemokake metrik iki bisa ditakoni lan ora yakin apa sing diwakili. Kajaba iku, kluster kasebut kalebu mesin virtual, mula ora bisa dingerteni manawa wektu tundha amarga virtualisasi utawa SSD kudu disalahake.

Kajaba iku, kita ndeleng macem-macem owah-owahan ing konfigurasi hardware lan piranti lunak, mula kita butuh cara kanggo ngevaluasi. Mesthi, iku bakal bisa kanggo mbukak etcd ing saben konfigurasi lan katon ing metrik Prometheus cocog, nanging iki mbutuhake gaweyan wujud. We needed cara prasaja kanggo ngira-ngira konfigurasi tartamtu. Kita pengin nyoba pangerten babagan metrik Prometheus sing teka saka etcd.

Kanggo nindakake iki, rong masalah kudu ditanggulangi:

Pisanan, apa I / O mbukak sing etcd ngasilake nalika nulis menyang file WAL katon kaya? Panggilan sistem apa sing digunakake? Apa ukuran blok nulis?
Kapindho, ayo kita duwe jawaban kanggo pitakonan ing ndhuwur. Carane ngasilake beban sing cocog karo fio? Sawise kabeh fio - sarana banget fleksibel karo akeh paramèter (iki gampang diverifikasi, contone, kene - kira-kira. transl.).

We ditanggulangi loro masalah nggunakake pendekatan basis printah padha lsof и strace:

Kanthi bantuan saka lsof Sampeyan bisa ndeleng kabeh deskriptor file sing digunakake dening proses, uga file sing dirujuk.
Kanthi bantuan saka strace sampeyan bisa nganalisa proses sing wis mlaku utawa mbukak proses lan mirsani. Printah kasebut nampilake kabeh panggilan sistem sing digawe dening proses iki lan, kanthi opsional, turunane. Sing terakhir penting kanggo proses sing forking, lan etcd minangka salah sawijining proses kasebut.

Babagan pisanan sing ditindakake yaiku nggunakake strace kanggo sinau server etcd ing kluster Kubernetes nalika lagi nganggur.

Mangkono, ditemokake yen blok nulis ing WAL diklompokake banget, mayoritas ana ing kisaran 2200-2400 bita. Pramila prentah ing wiwitan artikel iki nggunakake gendera --bs=2300 (bs - ukuran ing bita saben pemblokiran rekaman ing fio).

Elinga yen ukuran blok nulis etcd bisa beda-beda gumantung saka versi, penyebaran, nilai parameter, lsp. - iki mengaruhi durasi fdatasync. Yen sampeyan duwe kasus panggunaan sing padha, analisa nganggo strace proses etcd sampeyan kanggo entuk nilai paling anyar.

Banjur, kanggo entuk pangerten sing jelas lan lengkap babagan cara kerjane etcd karo sistem file, kita mlayu saka ngisor strace karo gendéra -ffttT. Iki ndadekake iku bisa kanggo njupuk pangolahan anak lan nulis output saben file kapisah. Kajaba iku, informasi rinci dipikolehi babagan wayahe wiwitan lan durasi saben telpon sistem.

Kita uga nggunakake perintah kasebut lsofkanggo konfirmasi pangerten output strace babagan apa deskriptor file digunakake kanggo tujuan apa. Asil punika strace, padha karo ing ndhuwur. Manipulasi statistik karo kaping sinkronisasi dikonfirmasi sing metrik wal_fsync_duration_seconds saka etcd cocog telpon fdatasync karo deskriptor file WAL.

Kanggo generate nggunakake fio beban kerja padha karo beban saka etcd, dokumentasi sarana ditliti lan paramèter sing cocog kanggo tugas kita dipilih. Kita nggawe manawa telpon sistem sing bener melu lan ngonfirmasi durasi kanthi mlaku fio saka strace (kaya sing ditindakake ing kasus etcd).

Perhatian khusus wis dibayar kanggo nemtokake nilai parameter kasebut --size. Iku nggantosi total I / O mbukak kui dening sarana fio. Ing kasus kita, iki minangka jumlah total bita sing ditulis ing media. Iku langsung ceceg karo nomer telpon write (lan fdatasync). Kanggo tartamtu bs nomer telpon fdatasync podo karo size / bs.

Amarga kasengsem ing persentil, kita ngupaya kanggo mesthekake yen jumlah sampel cukup gedhe kanggo makna statistik. Lan padha mutusaké sing 10^4 (sing cocog karo ukuran 22 MB) bakal cukup. Nilai parameter sing luwih cilik --size ngasilake swara sing luwih jelas (contone, telpon fdatasync, sing luwih suwe tinimbang biasane lan mengaruhi persentil kaping 99).

Terserah kowe

Artikel nuduhake carane nggunakake fio sampeyan bisa ngira-ngira apa media dimaksudaké kanggo nggunakake etcd cukup cepet. Saiki terserah sampeyan! Sampeyan bisa njelajah mesin virtual kanthi panyimpenan basis SSD ing layanan kasebut IBM Cloud.

PS saka penerjemah

Kanthi conto panggunaan sing wis siap fio kanggo ngatasi masalah liyane bisa ditemokake ing dokumentasi utawa langsung menyang repositori proyek (Ana luwih akeh tinimbang sing kasebut ing dokumentasi).

PPS saka penerjemah

Waca uga ing blog kita:

Source: www.habr.com

Carane mriksa disk karo fio kanggo kinerja cekap kanggo etcd