Дотроо байдлаар ихэнх бичлэгүүд, түгээсэн үйлчилгээнд асуудал гарлаа, энэ үйлчилгээг Alvin гэж нэрлэе. Энэ удаад би өөрөө асуудлыг олж мэдээгүй тул үйлчлүүлэгчийн залуус надад мэдэгдсэн.

Нэгэн өдөр би ойрын ирээдүйд эхлүүлэхээр төлөвлөж байсан Алвинтай удаан хугацаагаар саатсаны улмаас сэтгэл дундуур байсан имэйлээр сэрлээ. Тодруулбал, үйлчлүүлэгч 99 мс-ийн бүсэд 50 дэх хувийн хоцролтыг мэдэрсэн нь бидний хоцрогдлын төсвөөс хамаагүй өндөр байна. Би энэ үйлчилгээг өргөнөөр туршиж үзсэнийхээ дараа, ялангуяа нийтлэг гомдол байдаг хоцрогдолтой үед энэ нь үнэхээр гайхширсан.

Би Алвиныг туршилтанд оруулахаасаа өмнө секундэд 40 мянган асуулт (QPS) бүхий олон туршилт хийсэн бөгөөд бүгд 10 мс-ээс бага хоцролтыг харуулсан. Би тэдний дүгнэлттэй санал нийлэхгүй байгаагаа мэдэгдэхэд бэлэн байсан. Гэхдээ захидлыг дахин харахад би нэг шинэ зүйлийг анзаарав: Би тэдний дурдсан нөхцөлүүдийг яг таг туршиж үзээгүй, тэдний QPS нь минийхээс хамаагүй доогуур байсан. Би 40k QPS дээр туршиж үзсэн, гэхдээ тэд зөвхөн 1k дээр. Би тэднийг тайвшруулахын тулд өөр нэг туршилтыг энэ удаад бага QPS-тэй хийсэн.

Би энэ тухай блог хөтөлж байгаа болохоор тэдний тоо зөв байсныг та аль хэдийн ойлгосон байх. Би виртуал үйлчлүүлэгчээ дахин дахин туршиж үзсэн бөгөөд ижил үр дүнд хүрсэн: цөөн тооны хүсэлт нь хоцролтыг нэмэгдүүлээд зогсохгүй 10 мс-ээс дээш хоцролттой хүсэлтийн тоог нэмэгдүүлдэг. Өөрөөр хэлбэл, 40k QPS-д секундэд 50 орчим хүсэлт 50 мс-ээс хэтэрсэн бол 1k QPS-д секунд тутамд 100 мс-ээс дээш 50 хүсэлт ирдэг байсан. Парадокс!

Хайлтыг нарийсгаж байна

Олон бүрэлдэхүүн хэсэгтэй тархсан системд хоцрогдлын асуудал тулгарвал эхний алхам бол сэжигтнүүдийн товч жагсаалтыг гаргах явдал юм. Алвины архитектурыг бага зэрэг гүнзгийрүүлье:

Сайн эхлэлийн цэг бол оролт гаралтын дууссан шилжилтийн жагсаалт юм (сүлжээний дуудлага/диск хайх гэх мэт). Саатал хаана байгааг олж мэдэхийг хичээцгээе. Үйлчлүүлэгчтэй тодорхой I/O хийхээс гадна Элвин нэмэлт алхам хийдэг: тэр мэдээллийн сан руу ордог. Гэсэн хэдий ч энэ хадгалалт нь Alvin-тэй ижил кластерт ажилладаг тул хоцролт нь үйлчлүүлэгчтэй харьцуулахад бага байх ёстой. Тиймээс сэжигтний жагсаалт:

1. Үйлчлүүлэгчээс Алвин руу сүлжээний дуудлага.
2. Алвинаас мэдээллийн сан руу сүлжээний дуудлага.
3. Мэдээллийн сангаас дискнээс хай.
4. Мэдээллийн агуулахаас Алвин руу сүлжээний дуудлага.
5. Алвинаас үйлчлүүлэгч рүү сүлжээний дуудлага.

Зарим зүйлийг хасахыг хичээцгээе.

Мэдээлэл хадгалах нь үүнтэй ямар ч холбоогүй юм

Миний хийсэн хамгийн эхний зүйл бол Алвиныг хүсэлтийг боловсруулдаггүй ping-ping сервер болгон хөрвүүлэх явдал байв. Хүсэлтийг хүлээн авах үед энэ нь хоосон хариулт өгдөг. Хэрэв саатал багасвал Alvin эсвэл өгөгдлийн агуулахын хэрэгжилтэд алдаа гарах нь сонсогдоогүй зүйл биш юм. Эхний туршилтаар бид дараах графикийг олж авна.

Таны харж байгаагаар ping-ping серверийг ашиглахад сайжруулалт байхгүй байна. Энэ нь өгөгдлийн агуулах нь хоцролтыг нэмэгдүүлэхгүй бөгөөд сэжигтнүүдийн жагсаалтыг хоёр дахин багасгасан гэсэн үг юм.

1. Үйлчлүүлэгчээс Алвин руу сүлжээний дуудлага.
2. Алвинаас үйлчлүүлэгч рүү сүлжээний дуудлага.

Агуу их! Жагсаалт хурдан буурч байна. Би учрыг нь бараг олсон гэж бодсон.

gRPC

Одоо таныг шинэ тоглогчтой танилцуулах цаг болжээ. gRPC. Энэ бол процессын явцад харилцахад зориулагдсан Google-ийн нээлттэй эхийн номын сан юм CPR... Гэсэн хэдий ч gRPC сайн оновчлогдсон бөгөөд өргөн хэрэглэгддэг, энэ бол би үүнийг ийм хэмжээний систем дээр анх удаа ашиглаж байсан бөгөөд миний хэрэгжилтийг хамгийн багадаа оновчтой гэж бодож байсан.

тушаал gRPC стек дэх шинэ асуулт гарч ирэв: магадгүй энэ нь миний хэрэгжүүлэлт эсвэл би юм gRPC саатлын асуудал үүсгэж байна уу? Жагсаалтад шинэ сэжигтнийг нэмж оруулах:

1. Үйлчлүүлэгч номын сан руу залгадаг gRPC
2. номын сан gRPC үйлчлүүлэгч дээрх номын сан руу сүлжээний дуудлага хийдэг gRPC сервер дээр
3. номын сан gRPC холбоо барих Алвин (пинг теннисний серверт ажиллахгүй)

Код нь ямар харагддаг талаар танд ойлголт өгөхийн тулд миний үйлчлүүлэгч/Алвины хэрэгжилт нь үйлчлүүлэгч-серверийнхээс тийм ч их ялгаатай биш юм. асинх бус жишээнүүд.

Тэмдэглэл: Дээрх жагсаалтыг бага зэрэг хялбарчилсан учраас gRPC Гүйцэтгэлийн стек нь хоорондоо холбогдсон өөрийн (загвар?) урсгалтай загварыг ашиглах боломжтой болгодог. gRPC болон хэрэглэгчийн хэрэгжилт. Энгийн байхын тулд бид энэ загварыг баримтлах болно.

Профайл хийх нь бүх зүйлийг засах болно

Мэдээллийн сангуудыг зураад би бараг дууслаа гэж бодсон: "Одоо амархан боллоо! Профайлыг ашиглаж, саатал хаана байгааг олж мэдье." I нарийн профайлын том шүтэн бишрэгч, учир нь CPU нь маш хурдан бөгөөд ихэнхдээ гацаа үүсгэдэггүй. Ихэнх саатал нь процессор өөр зүйл хийхийн тулд боловсруулалтыг зогсоох ёстой үед тохиолддог. Нарийвчлалтай CPU-ийн профайл нь үүнийг хийдэг: энэ нь бүх зүйлийг үнэн зөв бүртгэдэг контекст шилжүүлэгч хаана саатал гарахыг тодорхой болгодог.

Би дөрвөн профайл авсан: өндөр QPS (бага хоцролттой) болон бага QPS (өндөр хоцролттой) ширээний теннисний сервертэй, үйлчлүүлэгч болон серверийн аль алинд нь. Мөн ямар ч тохиолдолд би процессорын профайлын дээжийг авсан. Профайлыг харьцуулахдаа би ихэвчлэн хэвийн бус дуудлагын стекийг хайдаг. Жишээлбэл, хоцрогдол ихтэй муу тал дээр өөр олон контекст шилжүүлэгч байдаг (10 ба түүнээс дээш удаа). Гэхдээ миний хувьд контекст шилжүүлэгчийн тоо бараг ижил байсан. Миний аймшигтай нь тэнд ямар ч чухал зүйл байгаагүй.

Нэмэлт дибаг хийх

Би цөхрөлд автсан. Би өөр ямар хэрэгсэл ашиглаж болохоо мэдэхгүй байсан бөгөөд миний дараагийн төлөвлөгөө бол асуудлыг тодорхой оношлохын оронд өөр өөр хувилбараар туршилтуудыг давтах явдал байв.

Хэрвээ

Би анхнаасаа л тодорхой 50 мс хоцрогдолд санаа зовж байсан. Энэ бол маш том хугацаа юм. Би яг аль хэсэг нь энэ алдааг үүсгэж байгааг олж мэдэх хүртлээ кодыг хэсэгчлэн хасахаар шийдсэн. Дараа нь үр дүнтэй туршилт гарч ирэв.

Ердийнх шигээ эргээд харахад бүх зүйл тодорхой байсан бололтой. Би үйлчлүүлэгчийг Алвинтай ижил машин дээр байрлуулж, хүсэлт илгээсэн localhost. Мөн хоцрогдлын өсөлт алга болсон!

Сүлжээнд ямар нэг зүйл буруу байна.

Сүлжээний инженерийн ур чадварт суралцах

Би хүлээн зөвшөөрөх ёстой: Сүлжээний технологийн талаархи миний мэдлэг аймшигтай, ялангуяа би тэдэнтэй өдөр бүр ажилладаг гэдгээ бодвол. Гэхдээ сүлжээ нь гол сэжигтэн байсан тул би үүнийг хэрхэн дибаг хийх талаар сурах хэрэгтэй болсон.

Аз болоход интернет сурах хүсэлтэй хүмүүст хайртай. Ping болон tracert-ийн хослол нь сүлжээний тээврийн асуудлыг засахад хангалттай сайн эхлэл мэт санагдсан.

Эхлээд би эхлүүлсэн PsPing Алвины TCP порт руу. Би анхдагч тохиргоог ашигласан - онцгой зүйл байхгүй. Мянга гаруй пингээс дулаарах эхнийхийг эс тооцвол нэг нь ч 10 мс-ээс хэтрээгүй. Энэ нь 50-р хувь дээр ажиглагдсан хоцролт 99 мс-ээр нэмэгдсэнтэй зөрчилдөж байна: тэнд 100 хүсэлт тутамд бид 50 мс хоцролттой нэг хүсэлтийг харах ёстой байсан.

Дараа нь би оролдсон трасерт: Алвин болон үйлчлүүлэгчийн хоорондох маршрутын аль нэгэнд асуудал гарсан байж магадгүй. Гэвч мөрдөгч бас хоосон буцаж ирэв.

Тиймээс саатал үүсгэсэн нь миний код, gRPC хэрэгжилт эсвэл сүлжээ биш байсан. Би үүнийг хэзээ ч ойлгохгүй гэж санаа зовж эхэлсэн.

Одоо бид ямар үйлдлийн системтэй вэ

gRPC Линукс дээр өргөн хэрэглэгддэг, харин Windows дээр чамин. Би туршилт хийхээр шийдсэн бөгөөд энэ нь амжилттай болсон: Би Линуксийн виртуал машин бүтээж, Linux-д зориулсан Alvin-ийг эмхэтгэж, түүнийгээ байршуулсан.

Тэгээд юу болсон бэ: Линуксийн ширээний теннисний сервер нь ижил төстэй Windows хосттой адил сааталгүй байсан ч мэдээллийн эх сурвалж нь өөр байсангүй. Асуудал нь Windows-д зориулсан gRPC хэрэгжилтэд байгаа нь харагдаж байна.

Наглийн алгоритм

Энэ бүх хугацаанд би өөрийгөө далбаа дутуу байна гэж бодсон gRPC. Энэ үнэхээр юу болохыг одоо би ойлгож байна gRPC Windows-ын далбаа байхгүй байна. Би бүх туг дээр сайн ажиллана гэдэгт итгэлтэй байсан дотоод RPC номын санг олсон Винсок. Дараа нь би эдгээр бүх тугуудыг gRPC-д нэмээд Alvin-г Windows дээр засварласан Windows ping-pong серверт байрлуулсан!

Бараг л Дууссан: Би шалтгааныг тогтоохын тулд регресс буцаж ирэх хүртэл нэмсэн тугуудыг нэг нэгээр нь устгаж эхэлсэн. Энэ нь гутамшигтай байсан TCP_NODELAY, Наглийн алгоритмын шилжүүлэгч.

Наглийн алгоритм багцын хэмжээ тодорхой тооны байтаас хэтрэх хүртэл мессеж дамжуулахыг хойшлуулах замаар сүлжээгээр илгээсэн пакетуудын тоог багасгахыг оролддог. Хэдийгээр энэ нь жирийн хэрэглэгчдэд тааламжтай байж болох ч үйлдлийн систем нь зарим мессежийг хойшлуулж, QPS-ийн хоцрогдол үүсгэдэг тул бодит цагийн серверүүдэд хортой юм. У gRPC Энэ тугийг TCP залгуурт зориулсан Линукс хэрэгжүүлэлтэд суулгасан боловч Windows дээр биш. Би бол энэ зассан.

дүгнэлт

Бага QPS-ийн хоцролт нь үйлдлийн системийн оновчлолоос үүдэлтэй. Эргээд харахад, профайл хийхдээ хоцролтыг илрүүлээгүй, учир нь энэ нь цөмийн горимд биш харин цөмийн горимд хийгдсэн байдаг хэрэглэгчийн горим. Nagle-ийн алгоритмыг ETW-ийн зураг авалтаар ажиглаж болох эсэхийг би мэдэхгүй, гэхдээ энэ нь сонирхолтой байх болно.

Localhost-ийн туршилтын хувьд, энэ нь бодит сүлжээний кодыг хөндөөгүй, Nagle-ийн алгоритм ажиллахгүй байсан тул үйлчлүүлэгч нь localhost-ээр дамжуулан Alvin-д хүрэх үед саатлын асуудал арилсан.

Дараагийн удаад секундэд ирэх хүсэлтийн тоо буурах тусам хоцролт нэмэгдэж байгааг харах үед Наглегийн алгоритм таны сэжигтний жагсаалтад байх ёстой!

Эх сурвалж: www.habr.com