Fio болон бусад зүйлийн тухай богино өгүүллэг
Кластерын гүйцэтгэл
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest
Та зүгээр л үр дүнг харж, үргэлжлэх хугацааны 99 дэх хувь байгаа эсэхийг шалгах хэрэгтэй
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]
Тэмдэглэл
- Бид --size болон --bs сонголтуудыг өөрийн хувилбарт тохируулсан. Fio-аас ашигтай үр дүнд хүрэхийн тулд өөрийн үнэлэмжийг оруулаарай. Тэднийг хаанаас авах вэ? Унших
Бид fio-г хэрхэн тохируулж сурсан . - Туршилтын явцад бүх оролт гаралтын ачаалал fio-аас ирдэг. Бодит хувилбарт wal_fsync_duration_seconds-тай холбоотой бусад бичих хүсэлтүүд хадгалах санд ирэх магадлалтай. Нэмэлт ачаалал нь wal_fsync_duration_seconds-ийн утгыг нэмэгдүүлэх болно. Хэрэв 99 дэх хувь нь 10 мс-тэй ойролцоо байвал таны хадгалах сангийн хурд дуусч байна.
- Хувилбараа аваарай
fio 3.5-аас доошгүй (өмнөх нь fdatasync үргэлжлэх хугацааны хувь хэмжээг харуулдаггүй). - Дээрх нь fio-ийн үр дүнгийн зөвхөн нэг хэсэг юм.
Fio болон бусад зүйлийн тухай урт түүх
etcd-д WAL гэж юу вэ
Ихэвчлэн мэдээллийн санг ашигладаг
Үйлчлүүлэгч түлхүүр утгын хадгалалтад түлхүүр нэмэх эсвэл одоо байгаа түлхүүрийн утгыг шинэчлэх үед etcd нь үйлдлийг WAL-д бүртгэдэг бөгөөд энэ нь байнгын хадгалалтад байдаг ердийн файл юм. etcd боловсруулалтыг үргэлжлүүлэхээс өмнө 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>
Харамсалтай нь байнгын санах ой руу бичих нь тэр дороо тохиолддоггүй. Хэрэв fdatasync дуудлага удаан байвал etcd системийн гүйцэтгэл муудна.
Fio ашиглан хадгалах санг тооцоолж байна
Хэрэв таны хадгалах сан etcd-д тохирох эсэхийг шалгах шаардлагатай бол оролт/гаралтын ачааллыг шалгах маш алдартай хэрэгсэл болох fio-г ашиглаарай. Дискний үйлдлүүд нь маш өөр байж болно гэдгийг санах нь зүйтэй: синхрон ба асинхрон, системийн дуудлагын олон ангиуд гэх мэт. Үүний үр дүнд fio-г ашиглахад нэлээд хэцүү байдаг. Энэ нь олон параметртэй бөгөөд тэдгээрийн утгуудын өөр өөр хослолууд нь маш өөр I/O ажлын ачааллыг үүсгэдэг. etcd-д тохирох тоон үзүүлэлтийг авахын тулд та WAL файлыг бичихдээ fio-ийн туршилтын бичих ачаалал etcd-ийн бодит ачаалалтай аль болох ойрхон байгаа эсэхийг шалгах хэрэгтэй.
Тиймээс, fio хамгийн багадаа файлд дараалсан бичих ачааллыг үүсгэх ёстой бөгөөд бичих бүр нь системийн дуудлагаас бүрдэнэ.
Яагаад fio, бид үүнийг хэрхэн тохируулж сурсан
Энэ нийтлэлд бид бодит тохиолдлыг тайлбарлах болно. Бидэнд кластер бий
Гэхдээ үүний тулд хоёр асуудлыг шийдэх ёстой байв. Нэгдүгээрт, WAL руу бичих үед etcd-ийн үүсгэсэн оролт/гаралтын ачаалал ямар харагддаг вэ? Ямар системийн дуудлагуудыг ашигладаг вэ? Бүртгэлийн хэмжээ хэд вэ? Хоёрдугаарт, хэрэв бид эдгээр асуултад хариулбал, бид ижил төстэй ажлын ачааллыг fio-тэй хэрхэн хуулбарлах вэ? Fio бол маш уян хатан, олон сонголттой хэрэгсэл гэдгийг бүү мартаарай. Бид хоёр асуудлыг нэг арга замаар шийдсэн - командуудыг ашиглан
Кластерт ачаалал байхгүй үед бид эхлээд Kubernetes-д зориулсан etcd серверийг судлахын тулд strace ашигласан. Бараг бүх WAL бичлэгүүд ижил хэмжээтэй байсныг бид харсан: 2200–2400 байт. Тиймээс, нийтлэлийн эхэнд байгаа команд дээр бид -bs=2300 параметрийг зааж өгсөн (bs гэдэг нь fio оруулга бүрийн байт дахь хэмжээг илэрхийлдэг). Etsd оруулгын хэмжээ нь etcd хувилбар, тархалт, параметрийн утга гэх мэтээс хамаарах ба fdatasync үргэлжлэх хугацаанд нөлөөлдөг гэдгийг анхаарна уу. Хэрэв танд ижил төстэй хувилбар байгаа бол нарийн тоог олохын тулд etcd процессуудаа шалгаарай.
Дараа нь etcd файлын систем юу хийж байгааг сайн ойлгохын тулд бид үүнийг strace болон -ffttT сонголтуудаас эхлүүлсэн. Тиймээс бид хүүхдийн процессуудыг шалгаж, тэдгээрийн гаралтыг тус тусад нь файлд бичиж, системийн дуудлагын эхлэл, үргэлжлэх хугацааны талаар нарийвчилсан тайлангуудыг авахыг хичээсэн. Бид lsof-ийг ашиглан strace гаралтын дүн шинжилгээг баталгаажуулж, ямар файлын тодорхойлогчийг ямар зорилгоор ашиглаж байгааг харна. Тиймээс strace-ийн тусламжтайгаар дээр үзүүлсэн үр дүнг олж авсан. Синхрончлолын цагийн статистик нь etcd-ийн wal_fsync_duration_seconds нь WAL файлын тодорхойлогчтой fdatasync дуудлагатай нийцэж байгааг баталсан.
Бид fio-ийн баримт бичгийг судалж үзээд fio нь etcd-тэй төстэй ачааллыг үүсгэхийн тулд скриптийнхээ сонголтыг сонгосон. Бид мөн etcd-тэй адил strace-аас fio-г ажиллуулж системийн дуудлагууд болон тэдгээрийн үргэлжлэх хугацааг шалгасан.
Бид fio-аас оролт/гаралтын ачааллыг бүхэлд нь илэрхийлэхийн тулд --size параметрийн утгыг анхааралтай сонгосон. Манай тохиолдолд энэ нь хадгалах санд бичигдсэн байтуудын нийт тоо юм. Энэ нь бичих (болон fdatasync) системийн дуудлагын тоотой шууд пропорциональ байсан. bs-ийн тодорхой утгын хувьд fdatasync дуудлагын тоо = size/bs. Бид хувь хэмжээг сонирхож байсан тул итгэлтэй байхын тулд хангалттай хэмжээний дээж авах шаардлагатай байсан бөгөөд бид 10^4 хангалттай байх болно гэж тооцоолсон (энэ нь 22 мебибайт). Хэрэв --size бага бол хэт давчуу үзүүлэлт гарч болзошгүй (жишээлбэл, хэд хэдэн fdatasync дуудлага ердийнхөөс удаан үргэлжилж, 99-р хувь нөлөөлдөг).
Өөрөө туршаад үзээрэй
Бид танд fio-г хэрхэн ашиглахыг харуулсан бөгөөд хадгалах сан нь etcd сайн ажиллахад хангалттай хурдан эсэхийг шалгана. Одоо та жишээ нь SSD санах ойтой виртуал машин ашиглан үүнийг өөрөө туршиж үзэх боломжтой
Эх сурвалж: www.habr.com