🥇Fio ilə diskləri etcd | üçün kifayət qədər performans üçün necə yoxlamaq olar ProHoster

Qeyd. tərcümə.: Bu məqalə, etcd verilənlər bazasının işləməsi ilə bağlı real problemin həlli üçün IBM Cloud mühəndisləri tərəfindən aparılan mini-tədqiqatın nəticəsidir. Bənzər bir tapşırıq bizim üçün aktual idi, lakin müəlliflərin düşüncələri və hərəkətləri daha geniş kontekstdə maraqlı ola bilər.

Bütün məqalənin qısa xülasəsi: fio və s

etcd klasterinin performansı əsas yaddaşın sürətindən çox asılıdır. etcd performansa nəzarət etmək üçün müxtəlif Prometheus ölçülərini ixrac edir. Onlardan biri wal_fsync_duration_seconds. və s. üçün sənədlərdə deyirbu metrikanın 99-cu faizi 10 ms-dən çox olmadıqda bu yaddaş kifayət qədər sürətli hesab edilə bilər ...

Əgər siz Linux maşınlarında etcd klaster qurmağı düşünürsünüzsə və sürücülərin (məsələn, SSD-lər) kifayət qədər sürətli olub olmadığını yoxlamaq istəyirsinizsə, məşhur I/O testerindən istifadə etməyi məsləhət görürük. fio. Aşağıdakı əmri yerinə yetirmək kifayətdir (kataloq test-data sınaqdan keçirilmiş sürücünün quraşdırılmış bölməsində yerləşməlidir):

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

Yalnız çıxışa baxmaq və 99-cu faizin uyğun olub olmadığını yoxlamaq qalır fdatasync 10 ms-də. Əgər belədirsə, sürücünüz kifayət qədər sürətli işləyir. Budur bir nümunə çıxış:

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]

Bir neçə qeyd:

Yuxarıdakı nümunədə biz parametrləri tənzimlədik --size и --bs konkret hal üçün. Mənalı nəticə əldə etmək üçün fio, istifadə vəziyyətinizə uyğun dəyərləri qeyd edin. Onları necə seçmək aşağıda müzakirə olunacaq.
Yalnız sınaq zamanı fio disk alt sistemini yükləyir. Real həyatda çox güman ki, diskə başqa proseslər də yazılacaq ( wal_fsync_duration_seconds). Bu əlavə yük arta bilər wal_fsync_duration_seconds. Başqa sözlə, əgər 99-cu yüzdəlik ilə test edilir fio, yalnız 10 ms-dən bir qədər az, saxlama performansının kifayət etməməsi üçün yaxşı şans var.
Test üçün versiyaya ehtiyacınız olacaq fio 3.5-dən aşağı deyil, çünki köhnə versiyalar nəticələri birləşdirmir fdatasync faizlər şəklində.
Yuxarıdakı nəticə ümumi nəticədən yalnız kiçik bir çıxarışdır fio.

fio və s. haqqında daha çox

WALs və s. haqqında bir neçə söz

Ümumiyyətlə, verilənlər bazası istifadə edir proaktiv giriş (qabaqcadan yazmaq, WAL). etcd də təsirlənir. WAL-ın müzakirəsi bu məqalənin əhatə dairəsi xaricindədir, lakin bizim məqsədlərimiz üçün bilmək lazımdır ki, hər bir etcd klaster üzvü WAL-ı davamlı yaddaşda saxlayır. etcd bəzi açar-dəyər saxlama əməliyyatlarını (yeniləmələr kimi) icra etməzdən əvvəl WAL-a yazır. Əgər qovşaq qəzaya uğrayarsa və snapshotlar arasında yenidən başlayarsa, etcd WAL məzmununa əsaslanaraq əvvəlki snapshotdan sonra əməliyyatları bərpa edə biləcək.

Beləliklə, müştəri hər dəfə KV mağazasına açar əlavə etdikdə və ya mövcud açarın dəyərini yenilədikdə, etcd əməliyyatın təsvirini davamlı mağazada adi fayl olan WAL-a əlavə edir. etcd davam etməzdən əvvəl WAL girişinin həqiqətən yadda saxlandığına 100% əmin olmalıdır. Linux-da buna nail olmaq üçün sistem çağırışından istifadə etmək kifayət deyil write, çünki fiziki mediaya yazma əməliyyatının özü gecikə bilər. Məsələn, Linux bir müddət WAL girişini yaddaşdaxili nüvə keşində (məsələn, səhifə keşində) saxlaya bilər. Məlumatların mediaya yazılmasını təmin etmək üçün yazıdan sonra sistem çağırışı çağırılmalıdır fdatasync - bu, etcd-nin etdiyi şeydir (aşağıdakı çıxışda gördüyünüz kimi strace; Budur 8 - WAL fayl deskriptoru):

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>

Təəssüf ki, davamlı yaddaşa yazmaq bir qədər vaxt aparır. Fdatasync zənglərinin uzun müddət icrası etcd-nin işinə təsir edə bilər. Anbar sənədlərində Göstərilmiş, kifayət qədər performans üçün bütün zənglərin müddətinin 99-cu faizinin olması lazımdır fdatasync WAL faylına yazarkən 10 ms-dən az idi. Yaddaşla bağlı başqa ölçülər də var, lakin bu məqalə bu birinə diqqət yetirəcək.

Fio ilə yaddaşın qiymətləndirilməsi

Utilitdən istifadə edərək müəyyən bir yaddaşın etcd ilə istifadə üçün uyğun olub olmadığını qiymətləndirə bilərsiniz fio — məşhur I/O test cihazı. Nəzərə alın ki, diskin giriş/çıxışı müxtəlif yollarla baş verə bilər: sinxronizasiya/async, bir çox fərqli sistem zəngi sinifləri və s. Sikkənin digər tərəfi də budur fio istifadə etmək son dərəcə çətindir. Faydalı proqram çoxlu parametrlərə malikdir və onların dəyərlərinin müxtəlif birləşmələri tamamilə fərqli nəticələrə gətirib çıxarır. etcd üçün ağlabatan qiymətləndirmə əldə etmək üçün fio tərəfindən yaradılan yazma yükünün etcd-nin WAL faylının yazma yükünə mümkün qədər yaxın olduğundan əmin olmalısınız:

Bu o deməkdir ki, yaradılan fio yük ən azı fayla bir sıra ardıcıl yazılar olmalıdır, burada hər bir yazı sistem çağırışından ibarətdir writeardınca fdatasync.
Ardıcıl yazmağı aktivləşdirmək üçün bayrağı göstərməlisiniz --rw=write.
O fio zənglərdən istifadə edərək yazdı write (digər sistem zəngləri əvəzinə - məsələn, pwrite), bayraqdan istifadə edin --ioengine=sync.
Nəhayət, bayraq --fdatasync=1 təmin edir ki, hər write lazımdır fdatasync.
Nümunəmizdəki digər iki parametr: --size и --bs - xüsusi istifadə vəziyyətindən asılı olaraq dəyişə bilər. Növbəti bölmə onların konfiqurasiyasını təsvir edəcəkdir.

Niyə fio seçdik və onu necə qurmağı öyrəndik

Bu qeyd qarşılaşdığımız real hadisədən irəli gəlir. Prometheus üzərində monitorinqi olan Kubernetes v1.13-də çoxluqumuz var idi. SSD-lər etcd v3.2.24 üçün yaddaş kimi istifadə edilmişdir. Etcd göstəriciləri çox yüksək gecikmələr göstərdi fdatasync, klaster boş olduqda belə. Bizim üçün bu göstəricilər çox şübhəli görünürdü və biz onların tam olaraq nəyi təmsil etdiyinə əmin deyildik. Bundan əlavə, klaster virtual maşınlardan ibarət idi, ona görə də gecikmənin virtualizasiyadan, yoxsa SSD-nin günahkar olduğunu söyləmək mümkün deyildi.

Bundan əlavə, biz aparat və proqram təminatı konfiqurasiyasında müxtəlif dəyişiklikləri nəzərdən keçirdik, ona görə də onları qiymətləndirmək üçün bir yol lazım idi. Əlbəttə ki, hər bir konfiqurasiyada etcd-ni işə salmaq və müvafiq Prometheus göstəricilərinə baxmaq mümkün olardı, lakin bu, xeyli səy tələb edəcəkdir. Bizə lazım olan xüsusi konfiqurasiyanı qiymətləndirmək üçün sadə bir yol idi. Biz etcd-dən gələn Prometey ölçüləri haqqında anlayışımızı yoxlamaq istədik.

Bunun üçün iki problemin həlli tələb olunur:

Birincisi, WAL fayllarına yazarkən etcd tərəfindən yaradılan I/O yükü necə görünür? Hansı sistem zənglərindən istifadə olunur? Rekord bloklarının ölçüsü nədir?
İkincisi, deyək ki, yuxarıdakı suallara cavabımız var. Müvafiq yükü necə təkrarlamaq olar fio? Hər şeydən sonra fio — çoxlu parametrlərlə son dərəcə çevik köməkçi proqram (bunu yoxlamaq asandır, məsələn, burada - təqribən. tərcümə.).

Hər iki problemi eyni komanda əsaslı yanaşma ilə həll etdik lsof и strace:

Ilə lsof proses tərəfindən istifadə edilən bütün fayl deskriptorlarına, eləcə də onların istinad etdiyi fayllara baxa bilərsiniz.
Ilə strace artıq işləyən prosesi təhlil edə və ya bir prosesi işə salıb izləyə bilərsiniz. Komanda bu proses tərəfindən edilən bütün sistem çağırışlarını və lazım olduqda onun nəslini göstərir. Sonuncu çəngəl olan proseslər üçün vacibdir və etcd belə bir prosesdir.

Etdiyimiz ilk şey istifadə etmək oldu strace boş ikən Kubernetes klasterindəki etcd serverini yoxlamaq üçün.

Beləliklə, məlum oldu ki, WAL rekord blokları çox sıx qruplaşdırılıb, əksəriyyətinin ölçüsü 2200-2400 bayt aralığında olub. Buna görə də bu məqalənin əvvəlindəki əmr bayraqdan istifadə edir --bs=2300 (bs hər bir yazma blokunun baytdakı ölçüsüdür fio).

Nəzərə alın ki, etcd yazma bloklarının ölçüsü versiyaya, yerləşdirməyə, parametr dəyərlərinə və s. asılı olaraq dəyişə bilər. - müddətə təsir edir fdatasync. Bənzər bir istifadə halınız varsa, ilə təhlil edin strace müasir dəyərlər əldə etmək üçün etcd prosesləri.

Sonra, etcd-nin fayl sistemi ilə necə işlədiyi barədə aydın və hərtərəfli fikir əldə etmək üçün onu aşağıdan başladıq. strace bayraqlarla -ffttT. Bu, uşaq proseslərini tutmağa və hər birinin çıxışını ayrıca fayla yazmağa imkan verdi. Bundan əlavə, hər bir sistem çağırışının başlama vaxtı və müddəti haqqında ətraflı məlumat əldə edilmişdir.

Biz də əmrdən istifadə etdik lsofçıxış haqqında anlayışınızı təsdiqləmək üçün strace hansı fayl deskriptorunun hansı məqsədlə istifadə edildiyi baxımından. Nəticə aldım strace, yuxarıdakı kimi. Sinxronizasiya müddətləri ilə statistik manipulyasiyalar metrik olduğunu təsdiqlədi wal_fsync_duration_seconds etcd-dən zənglərə uyğun gəlir fdatasync WAL fayl deskriptorları ilə.

Ilə yaratmaq fio etcd-dən oxşar bir iş yükü, yardım proqramının sənədləri öyrənildi və tapşırığımız üçün uyğun parametrlər seçildi. Biz düzgün sistem zənglərinin davam etdiyini və onların müddətini işləməklə təsdiqlədik fio haqqında strace (və s. vəziyyətində edildiyi kimi).

Parametrin dəyərinin müəyyən edilməsinə xüsusi diqqət yetirildi --size. Bu fio yardım proqramı tərəfindən yaradılan ümumi I/O yükünü təmsil edir. Bizim vəziyyətimizdə bu, mediaya yazılan baytların ümumi sayıdır. Zənglərin sayı ilə düz mütənasibdir write (və fdatasync). Konkret üçün bs zənglərin sayı fdatasync bərabərdir size / bs.

Faizlə maraqlandığımız üçün nümunələrin sayının statistik əhəmiyyətli olması üçün kifayət qədər böyük olmasını istədik. Və buna qərar verdi 10^4 (22 MB ölçüsünə uyğundur) kifayət edəcəkdir. Daha kiçik parametr dəyərləri --size daha aydın səs-küy verdi (məsələn, zənglər fdatasync, bu adi haldan daha uzun çəkir və 99-cu faizə təsir edir).

Bu Səndən asılıdır

Məqalədə necə istifadə ediləcəyi göstərilir fio etcd ilə istifadə üçün nəzərdə tutulmuş medianın kifayət qədər sürətli olub olmadığını mühakimə etmək olar. İndi bu sizə aiddir! Xidmətdə SSD əsaslı yaddaşı olan virtual maşınları araşdıra bilərsiniz IBM Cloud.

Tərcüməçidən PS

Hazır istifadə halları ilə fio Digər tapşırıqlar üçün baxın sənədləşdirmə və ya birbaşa layihə depoları (sənədlərdə qeyd olunanlardan daha çoxdur).

Tərcüməçidən PPS

Bloqumuzda da oxuyun:

Mənbə: www.habr.com

etcd üçün kifayət qədər performans üçün fio ilə diskləri necə yoxlamaq olar