Laju gudang cocog pikeun jsb? Hayu urang nanya ka fio

Carita pondok ngeunaan fio sareng jsb

kinerja klaster jsb sakitu legana gumantung kana kinerja gudang na. etcd ékspor sababaraha metrics ka Prometheuspikeun nyadiakeun inpo kinerja gudang nu dipikahoyong. Contona, métrik wal_fsync_duration_seconds. Dokuméntasi pikeun etcd nyebutkeun: Pikeun neundeun dianggap cukup gancang, persentil ka-99 métrik ieu kedah kirang ti 10ms. Upami anjeun ngarencanakeun ngajalankeun kluster etcd dina mesin Linux sareng hoyong ngevaluasi upami panyimpen anjeun cukup gancang (misalna SSD), anjeun tiasa nganggo fio mangrupakeun alat populér pikeun nguji I / O operasi. Jalankeun paréntah di handap ieu, dimana test-data mangrupikeun diréktori handapeun tempat panyimpen:

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

Anjeun ngan perlu kasampak dina hasil jeung pariksa yen persentil 99th durasi fdatasync kirang ti 10 ms. Upami kitu, anjeun gaduh panyimpenan anu lumayan gancang. Ieu conto hasil:

  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]

catetan

• Kami parantos nyaluyukeun pilihan --size sareng --bs pikeun skenario khusus urang. Pikeun meunangkeun hasil mangpaat ti fio, nyadiakeun nilai sorangan. Dimana meunang aranjeunna? Maca kumaha urang diajar ngonpigurasikeun fio.
• Salila tés, sadaya beban I / O asalna tina fio. Dina skénario kahirupan nyata, sigana bakal aya panyuratan nyerat anu sanés kana panyimpenan salian ti anu aya hubunganana sareng wal_fsync_duration_seconds. Beban tambahan bakal ningkatkeun nilai wal_fsync_duration_seconds. Janten upami persentil ka-99 caket kana 10ms, panyimpenan anjeun parantos gancang.
• Candak versi fio teu leuwih handap 3.5 (anu sateuacanna henteu nunjukkeun persentil durasi fdatasync).
• Di luhur ngan ukur snippet hasil tina fio.

carita panjang ngeunaan fio na jsb

Naon WAL di jsb

Biasana nganggo pangkalan data nulis-payun log; jsb ogé ngagunakeun éta. Kami moal ngabahas log nulis payun (WAL) sacara rinci di dieu. Ieu cukup keur urang uninga yen unggal anggota kluster etcd ngajaga eta dina gudang pengkuh. etcd nyerat unggal operasi konci-nilai (sapertos apdet) ka WAL sateuacan nerapkeun ka toko. Upami salah sahiji anggota panyimpen nabrak sareng dibalikan deui antara jepretan, éta sacara lokal tiasa ngabalikeun transaksi ti saprak gambar terakhir ku eusi WAL.

Nalika klien nambihan konci ka toko nilai-konci atanapi ngapdet nilai konci anu tos aya, jsb ngarékam operasi di WAL, anu mangrupikeun file biasa dina panyimpenan anu tetep. etcd WAJIB yakin lengkep yen entri WAL sabenerna lumangsung saméméh neruskeun kalawan processing. Dina Linux, hiji panggero sistem teu cukup pikeun ieu. nulis, saprak sabenerna nulis ka gudang fisik bisa ditunda. Contona, Linux Ubuntu tiasa nyimpen entri WAL dina cache dina mémori kernel (sapertos kaca cache) pikeun sawatara waktu. Sareng supados datana leres-leres ditulis kana panyimpenan anu terus-terusan, sauran sistem fdatasync diperyogikeun saatos nyerat, sareng sajabana ngan ukur nganggona (sapertos anu anjeun tingali dina hasil padamelan. tali, dimana 8 mangrupikeun deskriptor file WAL):

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>

Hanjakalna, nulis ka panyimpenan anu terus-terusan henteu lumangsung sacara instan. Lamun fdatasync nelepon slow, kinerja sistem jsb bakal sangsara. Dokuméntasi pikeun etcd nyebutkeunyén gudang dianggap cukup gancang lamun, dina persentil 99th, fdatasync nelepon nyandak kirang ti 10ms nulis kana file WAL. Aya métrik mangpaat anu sanés pikeun neundeun, tapi dina tulisan ieu urang ngan ukur ngobrol ngeunaan métrik ieu.

Estimasi neundeun jeung fio

Upami anjeun kedah ngira-ngira upami panyimpenan anjeun cocog pikeun jsb, paké fio, alat uji beban I/O anu populer pisan. Perlu diinget yén operasi disk tiasa béda-béda: sinkron sareng asinkron, seueur kelas telepon sistem, jsb. Hasilna, fio rada sesah dianggo. Éta ngagaduhan seueur parameter, sareng kombinasi anu béda tina nilaina ngahasilkeun beban kerja I / O anu béda pisan. Pikeun meunangkeun angka nyukupan pikeun etcd, anjeun kudu mastikeun yén beban nulis test ti fio sacaket mungkin jeung beban sabenerna ti etcd nalika nulis file WAL.

Ku alatan éta, fio kedah, sahenteuna, ngadamel beban tina séri tulisan anu berurutan kana file, unggal tulisan bakal diwangun ku panggero sistem. nulisdituturkeun ku panggero sistem fdatasync. Sequential nyerat kana fio merlukeun pilihan --rw=write. Pikeun fio ngagunakeun nelepon Sistim nulis nalika nulis, tinimbang nulis, Anjeun kudu nangtukeun parameter --ioengine=sync. Tungtungna, pikeun nelepon fdatasync saatos unggal nyerat, anjeun kedah nambihan parameter --fdatasync=1. Dua pilihan séjén dina conto ieu (--ukuran sareng -bs) khususna naskah. Dina bagian salajengna, kami bakal nunjukkeun anjeun kumaha nyetélana.

Naha persis fio na kumaha urang diajar nyetél éta

Dina tulisan ieu, urang ngajelaskeun kasus nyata. Urang boga klaster Kubernetes v1.13 nu urang diawaskeun kalawan Prometheus. etcd v3.2.24 ieu hosted on SSD. Métrik jsb nunjukkeun latén fdatasync anu luhur teuing, sanaos kluster henteu ngalakukeun nanaon. Métrikna anéh sareng urang henteu terang naon hartosna. klaster diwangun ku mesin virtual, éta perlu ngartos naon masalahna: dina SSDs fisik atawa dina lapisan virtualization. Sajaba ti éta, urang mindeng nyieun parobahan hardware jeung software konfigurasi, sarta kami diperlukeun cara pikeun evaluate hasil maranéhanana. Urang tiasa ngajalankeun jsb dina unggal konfigurasi sareng ningali métrik Prometheus, tapi éta repot teuing. Kami milarian cara anu saderhana pikeun ngevaluasi konfigurasi khusus. Kami hoyong pariksa naha urang ngartos métrik Prometheus tina etcd leres.

Tapi pikeun ieu, dua masalah kedah direngsekeun. Kahiji, naon I / O beban nu jsb dijieun nalika nulis ka WAL kasampak kawas? Naon sistem panggero anu dipaké? Naon ukuran rékaman? Kadua, upami urang ngajawab patarosan ieu, kumaha urang ngahasilkeun beban kerja anu sami sareng fio? Tong hilap yén fio mangrupikeun alat anu fleksibel sareng seueur pilihan. Urang ngarengsekeun duanana masalah dina hiji pendekatan - ngagunakeun paréntah lsof и tali. lsof daptar sadaya deskriptor file anu dianggo ku prosés sareng file anu aya hubunganana. Tur kalawan strace, Anjeun bisa nalungtik hiji prosés geus ngajalankeun, atawa ngamimitian prosés jeung nalungtik eta. strace nyitak sadaya telepon sistem tina prosés anu ditaliti (sareng prosés anakna). Anu terakhir penting pisan, sabab etcd ngan ukur nyandak pendekatan anu sami.

Urang mimiti dipaké strace ngajajah server etcd pikeun Kubernetes lamun euweuh beban dina kluster. Urang nempo yén ampir kabéh rékaman WAL kira-kira ukuranana sarua: 2200–2400 bait. Ku alatan éta, dina paréntah di awal pos, urang nangtukeun parameter -bs = 2300 (bs hartina ukuran dina bait pikeun tiap éntri fio). Catet yén ukuran éntri etcd gumantung kana versi etcd, distribusi, nilai parameter, jeung sajabana, sarta mangaruhan durasi fdatasync. Upami anjeun gaduh skenario anu sami, pariksa prosés jsb anjeun kalayan strace pikeun milarian nomer anu pasti.

Teras, pikeun kéngingkeun ide anu saé ngeunaan naon anu dilakukeun ku sistem file jsb, urang mimitian ku strace sareng pilihan -ffttT. Janten urang nyobian mariksa prosés anak sareng ngarékam kaluaran masing-masing dina file anu misah, sareng ogé nampi laporan anu lengkep ngeunaan ngamimitian sareng durasi unggal telepon sistem. Kami nganggo lsof pikeun ngonfirmasi analisa kaluaran strace sareng ningali deskriptor file mana anu dianggo pikeun tujuan naon. Janten kalayan bantosan strace, hasil anu dipidangkeun di luhur dicandak. Statistik waktos sinkronisasi dikonfirmasi yén wal_fsync_duration_seconds ti etcd konsisten sareng fdatasync nelepon sareng deskriptor file WAL.

Urang indit ngaliwatan dokuméntasi pikeun fio sarta milih pilihan pikeun Aksara urang ambéh fio bakal ngahasilkeun beban sarupa etcd. Kami ogé pariksa telepon sistem sareng durasina ku ngajalankeun fio ti strace, sami sareng etcd.

Kami geus taliti milih nilai parameter --size pikeun ngagambarkeun sakabéh I / beban O ti fio. Dina kasus urang, ieu mangrupikeun jumlah total bait anu ditulis kana panyimpenan. Tétéla éta langsung sabanding jeung jumlah nulis (jeung fdatasync) panggero sistem. Pikeun nilai bs nu tangtu, jumlah fdatasync panggero = ukuran / bs. Kusabab kami kabetot dina persentil, urang kedah gaduh sampel anu cukup pikeun mastikeun, sareng urang ngitung yén 10 ^ 4 bakal cekap pikeun urang (éta 22 mebibyte). Lamun --size leuwih leutik, outliers bisa lumangsung (contona, sababaraha fdatasync nelepon leuwih lila ti biasa tur mangaruhan persentil 99th).

Coba sorangan

Urang némbongkeun Anjeun cara make fio tur tingal lamun gudang boga speed cukup pikeun kinerja tinggi jsb. Ayeuna anjeun tiasa nyobian nyalira nganggo, contona, mesin virtual sareng panyimpenan SSD IBM awan.

sumber: www.habr.com