Eng kuerz Geschicht iwwer fio an etc
Cluster Leeschtung hänkt gréisstendeels vun der Leeschtung vu senger Lagerung of. etcd exportéiert e puer Metriken op fir déi gewënschte Späicherleistungsinformatioun ze bidden. Zum Beispill, d'wal_fsync_duration_seconds Metrik. : Fir datt d'Späichere séier genuch ugesi gëtt, muss den 99. Prozentsaz vun dëser Metrik manner wéi 10ms sinn. Wann Dir plangt en etcd Cluster op Linux Maschinnen ze lafen a wëllt evaluéieren ob Är Späichere séier genuch ass (zB SSD), kënnt Dir benotzen ass e populär Tool fir I/O Operatiounen ze testen. Fëllt de folgende Kommando aus, wou Test-Daten de Verzeechnes ënner dem Späichermontagepunkt sinn:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestDir musst just d'Resultater kucken a kontrolléieren datt den 99. Prozenttil vun der Dauer manner wéi 10 ms. Wann jo, hutt Dir raisonnabel séier Späichere. Hei ass e Beispill vun de Resultater:
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]Notizen
- Mir hunn d' --size an --bs Optiounen fir eise bestëmmte Szenario personaliséiert. Fir en nëtzlecht Resultat vu fio ze kréien, gitt Är eege Wäerter. Wou se ze kréien? Liesen .
- Wärend dem Test kënnt all I/O-Laascht aus fio. An engem real-Liewen Szenario wäert et méiglecherweis aner Schreif Ufroen an d'Späichere kommen nieft deenen am Zesummenhang mat wal_fsync_duration_seconds. Déi extra Laascht wäert de Wäert vun wal_fsync_duration_seconds erhéijen. Also wann den 99. Prozentsaz no bei 10ms ass, leeft Är Späichere vu Geschwindegkeet.
- Huelt d'Versioun net manner wéi 3.5 (déi virdrun weisen keng fdatasync Dauerpercentile).
- Hei uewen ass just en Ausschnëtt vun de Resultater vum fio.
Laang Geschicht iwwer Fio an etcd
Wat ass WAL an etcd
Normalerweis benotzen Datenbanken ; etcd benotzt et och. Mir wäerten net de Write-ahead Log (WAL) am Detail hei diskutéieren. Et ass genuch fir eis ze wëssen datt all Member vum etcd Cluster et an enger persistenter Lagerung hält. etcd schreift all Schlësselwäertoperatioun (wéi en Update) op WAL ier se an de Buttek applizéiert gëtt. Wann ee vun de Stockage Memberen Crash an Restart tëscht Snapshots, kann et lokal Transaktiounen zanter dem leschte Snapshot vum WAL Inhalt restauréiert.
Wann e Client e Schlëssel an de Schlësselwäertgeschäft bäidréit oder de Wäert vun engem existente Schlëssel aktualiséiert, etcd registréiert d'Operatioun am WAL, wat eng regulär Datei an der persistenter Lagerung ass. etcd MUSS ganz sécher sinn datt d'WAL Entrée tatsächlech geschitt ass ier Dir mat der Veraarbechtung weidergeet. Op Linux ass ee Systemruff net genuch fir dëst. , well déi aktuell Schreiwen op kierperlech Späichere kann verspéit ginn. Zum Beispill kann Linux e WAL Entrée an engem Cache am Kernel Memory (wéi e Säit Cache) fir eng Zäit späicheren. A fir datt d'Donnéeën präzis op persistent Späichere geschriwwe ginn, ass de fdatasync System Uruff nom Schreiwen gebraucht, an etcd benotzt se just (wéi Dir am Resultat vun der Aarbecht kënnt gesinn , wou 8 de WAL Dateibeschreiwung ass):
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>Leider geschitt d'Schreiwen op persistent Späichere net direkt. Wann de fdatasync Uruff lues ass, wäert d'Leeschtung vum etcd System leiden. datt d'Späichere séier genuch ugesi gëtt, wann am 99. Prozenttil fdatasync Uriff manner wéi 10ms daueren fir an d'WAL Datei ze schreiwen. Et ginn aner nëtzlech Metriken fir Späicheren, awer an dësem Post schwätze mir nëmmen iwwer dës Metrik.
Schätzung Stockage mat fio
Wann Dir musst evaluéieren ob Är Späichere gëeegent ass fir etcd, benotzt fio, e ganz populäre I / O Lasttestinstrument. Et sollt een drun erënneren datt d'Diskoperatioune ganz ënnerschiddlech sinn: Synchron an asynchron, vill Klassen vu Systemruffen, etc. Als Resultat ass fio zimlech schwéier ze benotzen. Et huet vill Parameteren, a verschidde Kombinatioune vun hire Wäerter produzéiere ganz verschidden I / O Aarbechtslaascht. Fir adäquate Zuelen fir etcd ze kréien, sollt Dir suergen datt d'Test Schreiflaascht vu fio sou no wéi méiglech un der aktueller Belaaschtung vun etcd ass wann Dir WAL Dateien schreift.
Dofir sollt fio op d'mannst eng Laascht vun enger Serie vu sequentiellen Schreiwen op d'Datei erstellen, all Schreiwen besteet aus engem Systemruff gefollegt vum fdatasync System Uruff. Sequentiell Schreiwen op fio erfuerderen d' --rw = Schreifoptioun. Fir fio de Schreifsystem ze benotzen wann Dir schreift, anstatt , Dir sollt den --ioengine=sync Parameter uginn. Schlussendlech, fir fdatasync no all Schreiwen ze ruffen, musst Dir den --fdatasync=1 Parameter derbäisetzen. Déi aner zwou Optiounen an dësem Beispill (--Gréisst an -bs) sinn skriptspezifesch. An der nächster Sektioun wäerte mir Iech weisen wéi Dir se opstellt.
Firwat genau fio a wéi mir geléiert hunn et opzestellen
An dësem Post beschreiwen mir e richtege Fall. Mir hunn e Cluster v1.13 déi mir mam Prometheus iwwerwaacht hunn. etcd v3.2.24 gouf op enger SSD gehost. Etcd Metriken hunn fdatasync latencies ze héich gewisen, och wann de Cluster näischt gemaach huet. D'Metrike ware komesch a mir woussten net wierklech wat se bedeiten. De Cluster bestoung aus virtuelle Maschinnen, et war néideg ze verstoen wat de Problem war: a kierperlechen SSDs oder an der Virtualiséierungsschicht. Zousätzlech hu mir dacks Ännerungen un der Hardware a Software Konfiguratioun gemaach, a mir brauche e Wee fir hir Resultater ze evaluéieren. Mir kéinten etcd an all Konfiguratioun lafen a Prometheus Metriken kucken, awer dat ass ze vill Stress. Mir hunn no engem zimlech einfache Wee gesicht fir eng spezifesch Konfiguratioun ze evaluéieren. Mir wollte kucken ob mir Prometheus Metriken aus etcd richteg verstinn.
Mee dofir hu missen zwee Problemer geléist ginn. Als éischt, wéi gesäit d'I/O-Laascht aus, déi etcd erstellt beim Schreiwen op WAL? Wat System Appellen ginn benotzt? Wat ass d'Gréisst vun de Rekorder? Zweetens, wa mir dës Froen beäntweren, wéi reproduzéieren mir eng ähnlech Aarbechtslaascht mat fio? Vergiesst net datt fio e ganz flexibel Tool mat villen Optiounen ass. Mir hu béid Problemer mat enger Approche geléist - d'Befehle benotzen и . lsof lëscht all Dateideskriptoren déi vum Prozess benotzt ginn an hir verbonne Dateien. A mat Strace kënnt Dir e scho lafende Prozess ënnersichen, oder e Prozess starten an iwwerpréiwen. strace dréckt all System Uriff aus dem Prozess deen iwwerpréift gëtt (a seng Kannerprozesser). Dat lescht ass ganz wichteg, well etcd just eng ähnlech Approche mécht.
Mir hunn als éischt Strace benotzt fir den etcd Server fir Kubernetes ze entdecken wann et keng Laascht op de Stärekoup war. Mir hunn gesinn datt bal all WAL records ongeféier déiselwecht Gréisst waren: 2200-2400 Bytes. Dofir, am Kommando am Ufank vum Post, hu mir de Parameter -bs=2300 spezifizéiert (bs heescht d'Gréisst an Bytes fir all Fio-Entrée). Bedenkt datt d'Gréisst vun der etcd Entrée hänkt vun der etcd Versioun, Verdeelung, Parameter Wäerter, etc., an beaflosst d'fdatasync Dauer. Wann Dir en ähnlechen Szenario hutt, ënnersicht Är etcd Prozesser mat Strace fir déi exakt Zuelen erauszefannen.
Dann, fir eng gutt Iddi ze kréien wat den etcd Dateisystem mécht, hu mir et mat Strace an den -ffttT Optiounen ugefaang. Also hu mir probéiert d'Kandprozesser z'ënnersichen an d'Ausgab vun all vun hinnen an enger separater Datei opzehuelen, an och detailléiert Berichter iwwer den Start an d'Dauer vun all Systemruff ze kréien. Mir hunn lsof benotzt fir eis Analyse vum Strace-Output ze bestätegen a kucken wéi eng Dateideskriptor fir wéi en Zweck benotzt gouf. Also mat der Hëllef vu Strace goufen déi uewe gewisen Resultater kritt. Synchroniséierung Zäit Statistiken confirméiert datt wal_fsync_duration_seconds aus etcd konsequent mat fdatasync rifft mat WAL Fichier descriptors ass.
Mir sinn duerch d'Dokumentatioun fir fio gaang an hunn Optiounen fir eise Skript gewielt fir datt fio eng Laascht ähnlech wéi etcd generéiert. Mir iwwerpréift och System rifft an hir Dauer vun Lafen fio aus strace, ähnlech ze etcd.
Mir hunn de Wäert vum --size Parameter suergfälteg gewielt fir déi ganz I/O Belaaschtung vu fio ze representéieren. An eisem Fall ass dëst d'Gesamtzuel vun de Bytes, déi op d'Späichere geschriwwe sinn. Et huet sech erausgestallt direkt proportional zu der Unzuel vu Schreiwen (an fdatasync) System Uruff. Fir e bestëmmte Wäert vun bs, d'Zuel vun fdatasync rifft = Gréisst / bs. Well mer un de Prozentsaz interesséiert waren, musse mir genuch Echantillon hunn fir sécher ze sinn, a mir hunn berechent datt 10^4 fir eis genuch wier (dat sinn 22 Mebibytes). Wann --Gréisst méi kleng ass, kënnen Auslänner optrieden (zum Beispill e puer fdatasync Uriff daueren méi laang wéi soss an beaflossen den 99.
Probéiert et selwer
Mir hunn Iech gewisen wéi Dir Fio benotzt a kuckt ob d'Späichere séier genuch ass fir etcd gutt ze maachen. Elo kënnt Dir et fir Iech selwer ausprobéieren andeems Dir zum Beispill virtuelle Maschinnen mat SSD Späichere benotzt .
Source: will.com