🥇Kumaha mariksa disk nganggo fio pikeun pagelaran anu cekap pikeun jsb

Catetan. narjamahkeun.: Artikel ieu mangrupa hasil tina mini-panalungtikan dilumangsungkeun ku insinyur IBM Cloud dina pilarian sahiji solusi pikeun masalah nyata patali operasi database etcd. Tugas anu sami relevan pikeun urang, kumaha ogé, jalan refleksi sareng tindakan para pangarang tiasa pikaresepeun dina kontéks anu langkung lega.

kasimpulan ringkes sakabéh artikel: fio na etcd

Kinerja kluster jsbd gumantung pisan kana laju neundeun dasar. etcd ékspor rupa métrik Prometheus pikeun ngawas kinerja. Salah sahijina nyaéta wal_fsync_duration_seconds. Dina dokuméntasi pikeun jsb éta nyebutkeunPanyimpen éta tiasa dianggap cukup gancang upami persentil ka-99 métrik ieu henteu langkung ti 10 mdet…

Upami anjeun nimbang-nimbang nyetél kluster jsb dina mesin Linux sareng hoyong nguji naha drive (sapertos SSDs) cekap gancang, kami nyarankeun ngagunakeun panguji I / O anu populer anu disebut. fio. Ieu cukup pikeun ngajalankeun paréntah di handap ieu (directory test-data kedah aya dina partisi dipasang tina drive anu diuji):

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

Tetep ngan ukur ningali kaluaran sareng pariksa naha persentil ka-99 pas fdatasync dina 10 ms. Upami kitu, teras drive anjeun jalan cukup gancang. Ieu conto kaluaran:

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]

Sababaraha catetan:

Dina conto di luhur, kami parantos nyaluyukeun parameter --size и --bs pikeun kasus husus. Pikeun meunangkeun hasil bermakna tina fio, tangtukeun niléy anu cocog pikeun pamakean anjeun. Kumaha carana milih aranjeunna bakal dibahas dihandap.
Salila tés wungkul fio ngamuat subsistem disk. Dina kahirupan nyata, kamungkinan prosés sanésna bakal nyerat kana disk (salain anu aya hubunganana sareng wal_fsync_duration_seconds). Beban tambahan ieu tiasa ningkat wal_fsync_duration_seconds. Kalayan kecap séjén, lamun persentil 99th ti nguji jeung fio, ngan rada kirang ti 10 mdet, aya kasempetan alus yén kinerja gudang teu cukup.
Pikeun tés anjeun peryogi versi fio teu leuwih handap 3.5, sabab vérsi anu langkung lami henteu ngahijikeun hasil fdatasync dina wangun persentil.
Kacindekan di luhur ngan ukur kutipan leutik tina kacindekan umum fio.

Leuwih lengkep ngeunaan fio na jsb

Sababaraha kecap ngeunaan WALs jsb

Sacara umum, database ngagunakeun logging proaktif (tulis-payun logging, WAL). jsb ogé kapangaruhan. Sawala ngeunaan WAL saluareun ruang lingkup artikel ieu, tapi pikeun tujuan urang, naon nu peryogi kauninga yén unggal anggota kluster etcd nyimpen WAL dina gudang pengkuh. etcd nyerat sababaraha operasi neundeun nilai konci (sapertos apdet) ka WAL sateuacan ngalaksanakeunana. Lamun titik ngadat jeung restarts antara snapshots, jsb bakal bisa cageur transaksi saprak snapshot saméméhna dumasar kana eusi WAL.

Ku kituna, unggal waktos a klien nambahkeun konci ka toko KV atawa ngamutahirkeun nilai hiji konci aya, jsb nambahkeun pedaran operasi ka WAL, nu mangrupakeun file biasa di toko pengkuh. etcd WAJIB 100% yakin yen entri WAL sabenerna geus disimpen saméméh lajengkeun. Pikeun ngahontal ieu dina Linux, teu cekap nganggo panggero sistem write, Kusabab operasi nulis sorangan ka média fisik bisa ditunda. Contona, Linux bisa nyimpen entri WAL dina cache kernel dina mémori (contona, dina cache kaca) pikeun sawatara waktu. Pikeun mastikeun yén data ditulis ka média, panggero sistem kudu invoked sanggeus nulis fdatasync - ieu mangrupikeun naon anu dilakukeun ku etcd (sapertos anu anjeun tingali dina kaluaran di handap ieu strace; Ieuh 8 - Deskriptor file WAL):

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>

Hanjakal, nulis ka panyimpenan pengkuh butuh sababaraha waktu. Palaksanaan fdatasync anu berkepanjangan tiasa mangaruhan kinerja jsb. Dina dokuméntasi gudang dituduhkeun, yén pikeun pagelaran cukup perlu yén persentil 99th durasi sadaya nelepon fdatasync nalika nyerat kana file WAL kirang ti 10 mdet. Aya métrik anu aya hubunganana sareng panyimpen, tapi tulisan ieu bakal difokuskeun kana éta.

Valueing neundeun jeung fio

Anjeun tiasa evaluate naha gudang tangtu cocog pikeun pamakéan ku jsbd ngagunakeun utiliti fio - panguji I / O anu populér. Émut yén disk I/O tiasa lumangsung ku sababaraha cara: singkronisasi/async, seueur kelas syscall anu béda, sareng saterasna. Sisi séjén koin éta fio sesah pisan dianggo. Utilitasna ngagaduhan seueur parameter, sareng kombinasi anu béda-béda nilaina nyababkeun hasil anu béda-béda. Pikeun kéngingkeun perkiraan anu lumayan pikeun jsb, anjeun kedah mastikeun yén beban nyerat anu dibangkitkeun ku fio sacaket-gancangna kana beban nyerat file WAL jsb:

Ieu ngandung harti yén dihasilkeun fio beban sahenteuna kudu runtuyan nulis padeukeut kana file, dimana unggal nulis diwangun ku panggero sistem writedituturkeun ku fdatasync.
Pikeun ngaktipkeun tulisan sequential, anjeun kudu nangtukeun bandéra --rw=write.
yen fio nulis maké telepon write (tinimbang sauran sistem anu sanés - contona, pwrite), ngagunakeun bandéra --ioengine=sync.
Tungtungna, bandéra --fdatasync=1 ensures yén unggal write kuduna fdatasync.
Dua parameter sanésna dina conto urang nyaéta: --size и --bs - bisa rupa-rupa gumantung kana kasus pamakéan husus. Bagian salajengna bakal ngajelaskeun konfigurasi maranéhanana.

Naha urang milih fio sareng kumaha urang diajar kumaha nyetél éta

Catetan ieu asalna tina kasus nyata anu urang tepang. Urang kungsi klaster on Kubernetes v1.13 kalawan monitoring on Prometheus. SSDs dipaké salaku gudang keur etcd v3.2.24. Métrik jsb nunjukkeun latén anu luhur teuing fdatasync, sanajan klaster éta dianggurkeun. Pikeun kami, metrics ieu sigana pisan dubious, sarta kami teu yakin naon kahayang maranéhna digambarkeun. Sajaba ti éta, klaster diwangun ku mesin virtual, ku kituna teu mungkin keur nyebutkeun naha reureuh éta alatan virtualization atawa SSD ieu ngalepatkeun.

Salaku tambahan, kami nganggap rupa-rupa parobahan dina konfigurasi hardware sareng software, ku kituna kami peryogi cara pikeun meunteun aranjeunna. Tangtu, eta bakal mungkin ngajalankeun etcd dina unggal konfigurasi sarta kasampak dina métrik Prometheus pakait, tapi nu bakal merlukeun signifikan usaha . Anu kami diperyogikeun nyaéta cara anu saderhana pikeun ngira-ngira konfigurasi khusus. Kami hoyong nguji pamahaman kami ngeunaan métrik Prometheus anu asalna tina jsb.

Ieu diperlukeun pikeun ngajawab dua masalah:

Kahiji, naon beban I / O dihasilkeun ku etcd nalika nulis kana file WAL kasampak kawas? Naon sistem panggero anu dipaké? Naon ukuran blok rékaman?
Kadua, anggap urang gaduh jawaban kana patarosan di luhur. Kumaha baranahan beban pakait jeung fio? Barina ogé fio - Utiliti pisan fléksibel sareng seueur parameter (ieu gampang pikeun pariksa, contona, di dieu - kira-kira. tarjamah.).

Urang direngsekeun duanana masalah jeung pendekatan dumasar-komando sarua lsof и strace:

jeung lsof Anjeun tiasa ningali sadaya deskriptor file anu dianggo ku prosés, ogé file anu dirujuk.
jeung strace anjeun tiasa nganalisis prosés anu parantos jalan atanapi ngajalankeun prosés sareng nonton éta. Paréntah nampilkeun sadaya sauran sistem anu dilakukeun ku prosés ieu sareng, upami diperyogikeun, turunanana. Anu terakhir penting pikeun prosés anu forking, sareng etcd mangrupikeun prosés sapertos kitu.

Hal kahiji anu urang lakukeun nyaéta ngagunakeun strace pikeun nalungtik server etcd dina klaster Kubernetes bari éta dianggurkeun.

Ku kituna kapanggih yén blok catetan WAL pisan padet dikelompokeun, ukuran mayoritas éta dina rentang 2200-2400 bait. Éta sababna paréntah di awal tulisan ieu nganggo bandéra --bs=2300 (bs nyaéta ukuran dina bait unggal blok tulis di fio).

Perhatikeun yén ukuran blok nulis jsbd bisa rupa-rupa gumantung kana versi, deployment, nilai parameter, jsb. - éta mangaruhan durasi fdatasync. Upami Anjeun gaduh kasus pamakéan sarupa, analisa kalawan strace prosés jsbd anjeun pikeun meunangkeun nilai up-to-date.

Teras, pikeun kéngingkeun ideu anu jelas sareng komprehensif ngeunaan kumaha etcd jalan sareng sistem file, urang ngamimitian ti handapeun. strace kalawan bandéra -ffttT. Ieu ngamungkinkeun pikeun moto prosés anak sareng nyerat kaluaran masing-masing kana file anu misah. Salaku tambahan, inpormasi lengkep ngeunaan waktos ngamimitian sareng durasi unggal telepon sistem dicandak.

Urang ogé dipaké paréntah lsofpikeun mastikeun pamahaman anjeun kaluaran strace dina watesan file descriptor ieu dipaké pikeun tujuan nu. Kuring meunang kacindekan strace, sarua jeung nu di luhur. Manipulasi statistik sareng waktos sinkronisasi dikonfirmasi yén métrik wal_fsync_duration_seconds ti etcd cocog nelepon fdatasync kalawan deskriptor file WAL.

Pikeun ngahasilkeun kalawan fio beban kerja anu sami sareng ti jsbd, dokuméntasi utiliti ditaliti sareng parameter anu cocog pikeun tugas urang dipilih. Kami parantos marios yén telepon sistem anu leres nuju lumangsung sareng ngonfirmasi durasina ku jalan fio ti strace (sakumaha ieu dilakukeun dina kasus jsb).

Perhatian khusus dibayar pikeun nangtukeun nilai parameter --size. Ieu ngagambarkeun total I / O beban dihasilkeun ku utilitas fio. Dina kasus urang, ieu mangrupikeun jumlah total bait anu ditulis ka média. Éta sabanding langsung sareng jumlah telepon write (jeung fdatasync). Pikeun husus bs jumlah telepon fdatasync sarua size / bs.

Kusabab kami kabetot dina persentil, kami hoyong jumlah sampel anu cukup ageung janten signifikan sacara statistik. Sarta mutuskeun éta 10^4 (anu pakait jeung ukuran 22 MB) bakal cukup. Nilai parameter anu langkung alit --size masihan sora anu langkung jelas (contona, telepon fdatasync, nu nyandak leuwih lila ti biasana sarta mangaruhan persentil 99th).

Terserah anjeun

Artikel nembongkeun kumaha carana make fio hiji bisa nangtoskeun naha média dimaksudkeun pikeun pamakéan ku etcd cukup gancang. Ayeuna terserah anjeun! Anjeun tiasa ngajalajah mesin virtual nganggo panyimpenan basis SSD dina jasa éta IBM awan.

PS ti penerjemah

Kalayan kasus pamakéan siap-dijieun fio Pikeun tugas séjén, tingali dokuméntasi atanapi langsung ka repositories proyék (aya leuwih loba di antarana ti disebutkeun dina dokuméntasi).

PPS ti penerjemah

Baca ogé dina blog urang:

sumber: www.habr.com

Kumaha mariksa disk kalawan fio pikeun pagelaran cukup pikeun jsb