تيئن ۾ گهڻيون پوسٽون, появилась проблема с распределённой службой, назовём эту службу Элвин. На этот раз я не сам обнаружил проблему, мне сообщили ребята с клиентской части.

Однажды я проснулся от недовольного письма из-за больших задержек у Элвина, которого мы планировали запустить в ближайшее время. В частности, клиент столкнулся с задержкой 99-го процентиля в районе 50 мс, намного выше нашего бюджета задержки. Это было удивительно, так как я тщательно тестировал сервис, особенно на задержки, ведь это предмет частых жалоб.

ان کان اڳ جو آئون ايلون کي جانچ ۾ رکان، مون 40k سوالن في سيڪنڊ (QPS) سان ڪيترائي تجربا ڪيا، سڀ 10ms کان گھٽ جي دير ڏيکاريندي. مان اعلان ڪرڻ لاءِ تيار هوس ته مان انهن جي نتيجن سان متفق نه آهيان. پر خط تي هڪ ٻي نظر وجهندي، مون ڪجهه نئين ڳالهه محسوس ڪئي: مون انهن شرطن جي بلڪل جانچ نه ڪئي هئي، جن جو انهن ذڪر ڪيو آهي، انهن جو QPS مون کان گهڻو گهٽ هو. مون 40k QPS تي آزمايو، پر اھي رڳو 1k تي. مون هڪ ٻيو تجربو ڪيو، هن ڀيري هيٺين QPS سان، صرف انهن کي راضي ڪرڻ لاءِ.

جيئن ته مان هن بابت بلاگنگ ڪري رهيو آهيان، توهان شايد اڳ ۾ ئي سمجهي ورتو آهي ته انهن جا انگ صحيح هئا. مون پنهنجي ورچوئل ڪلائنٽ کي بار بار آزمايو، ساڳئي نتيجي سان: درخواستن جو گهٽ تعداد نه رڳو دير سان وڌائي ٿو، پر 10 ايم ايس کان وڌيڪ جي دير سان درخواستن جو تعداد وڌائي ٿو. ٻين لفظن ۾، جيڪڏهن 40k QPS تي اٽڪل 50 درخواستون في سيڪنڊ 50 ms کان وڌي ويون آهن، ته پوءِ 1k QPS تي 100 درخواستون هيون 50 ms هر سيڪنڊ کان مٿي. پيراڊڪس!

ڳولها کي تنگ ڪرڻ

جڏهن ڪيترن ئي حصن سان ورهايل نظام ۾ ويڪرائي مسئلي سان منهن ڏيڻو پوي ٿو، پهريون قدم مشڪوڪ جي هڪ مختصر فهرست ٺاهڻ آهي. اچو ته ايلون جي فن تعمير ۾ ٿوري گهڻي کوٽائي ڪريون:

هڪ سٺو شروعاتي نقطو مڪمل ٿيل I/O ٽرانزيڪشن جي هڪ فهرست آهي (نيٽ ورڪ ڪالز/ڊسڪ لوڪ اپ، وغيره). اچو ته اهو سمجهڻ جي ڪوشش ڪريون ته دير ڪٿي آهي. ڪلائنٽ سان واضح I/O کان علاوه، ايلون هڪ اضافي قدم کڻندو آهي: هو ڊيٽا اسٽور تائين رسائي ڪري ٿو. بهرحال، هي اسٽوريج ساڳئي ڪلستر ۾ هلندي آهي Alvin، تنهنڪري اتي ويڪرائي ڪلائنٽ جي ڀيٽ ۾ گهٽ هجڻ گهرجي. تنهن ڪري، شڪي ماڻهن جي فهرست:

1. نيٽورڪ ڪال ڪلائنٽ کان ايلون تائين.
2. نيٽ ورڪ ڪال ايلون کان ڊيٽا اسٽور ڏانهن.
3. ڊيٽا اسٽور ۾ ڊسڪ تي ڳولا ڪريو.
4. نيٽ ورڪ ڪال ڊيٽا گودام کان الون تائين.
5. Сетевой вызов от Элвина к клиенту.

Попробуем вычеркнуть некоторые пункты.

ڊيٽا اسٽوريج ان سان ڪو به تعلق ناهي

پهرين شيء جيڪا مون ڪئي هئي Alvin کي هڪ پنگ پنگ سرور ۾ تبديل ڪيو ويو جيڪو درخواستن تي عمل نٿو ڪري. جڏهن اهو هڪ درخواست وصول ڪري ٿو، اهو هڪ خالي جواب ڏئي ٿو. جيڪڏهن ويڪرائي گھٽجي ٿي، ته پوءِ ايلون ۾ هڪ بگ يا ڊيٽا گودام تي عمل درآمد ڪجهه به نه ٻڌو ويو آهي. پهرين تجربي ۾ اسان کي هيٺيون گراف ملي ٿو:

Как видим, при использовании сервера ping-ping не наблюдается никаких улучшений. Это означает, что хранилище данных не увеличивает задержку, а список подозреваемых сокращается вдвое:

1. نيٽورڪ ڪال ڪلائنٽ کان ايلون تائين.
2. Сетевой вызов от Элвина к клиенту.

زبردست! فهرست تيزيءَ سان سُڪي رهي آهي. مون سوچيو ته مون تقريباً سبب سمجهي ورتو هو.

جي آر پي سي

ھاڻي اھو وقت آھي توھان کي ھڪڙي نئين پليئر سان متعارف ڪرائڻ جو: جي آر پي سي. هي هڪ اوپن سورس لائبريري آهي گوگل طرفان ان-پروسيس ڪميونيڪيشن لاءِ آر پي سي... جيتوڻيڪ gRPC چڱي طرح بهتر ۽ وڏي پيماني تي استعمال ڪيو ويو، اهو منهنجو پهريون ڀيرو هو ان کي هن سائيز جي سسٽم تي استعمال ڪندي ۽ مون کي اميد هئي ته منهنجي عمل درآمد سبوپيٽمل آهي - گهٽ ۾ گهٽ چوڻ لاء.

دستيابي gRPC اسٽيڪ ۾ هڪ نئين سوال کي جنم ڏنو: ٿي سگهي ٿو اهو منهنجو عمل آهي يا پاڻ gRPC دير جي مسئلي جو سبب؟ لسٽ ۾ نئون مشڪوڪ شامل ڪرڻ:

1. گراهڪ لائبريري کي سڏي ٿو gRPC
2. لائبريري gRPC на клиенте выполняет сетевой вызов библиотеки gRPC سرور تي
3. لائبريري gRPC رابطا ايلون (پنگ پونگ سرور جي صورت ۾ ڪو آپريشن ناهي)

توهان کي هڪ خيال ڏيڻ لاءِ ته ڪوڊ ڪهڙو نظر اچي ٿو، منهنجو ڪلائنٽ/ايلون عمل درآمد ڪلائنٽ-سرور وارن کان گهڻو مختلف ناهي async مثال.

نوٽ: مٿي ڏنل فهرست ٿورو سادو آهي ڇاڪاڻ ته gRPC даёт возможность использования собственной (шаблонной?) потоковой модели, в которой переплетаются стек выполнения gRPC ۽ استعمال ڪندڙ تي عملدرآمد. سادگي جي خاطر، اسان هن نموني کي لٺ ڪنداسين.

پروفائلنگ سڀڪنھن شيء کي ٺيڪ ڪندو

ڊيٽا اسٽورن کي پار ڪرڻ کان پوء، مون سوچيو ته مان تقريبا مڪمل ٿي چڪو آهيان: "هاڻي اهو آسان آهي! اچو ته پروفائل لاڳو ڪريون ۽ معلوم ڪريو ته دير ڪٿي ٿي ٿئي. اي درست پروفائلنگ جو وڏو پرستار, потому что CPU очень быстры и чаще всего не являются узким местом. Большинство задержек происходит, когда процессор должен остановить обработку, чтобы сделать что-то ещё. Точное профилирование CPU сделано именно для этого: оно точно записывает все контекстные переключатели ۽ اهو واضح ڪري ٿو ته دير ڪٿي ٿيندي آهي.

مون چار پروفائيل کنيا: هاءِ QPS سان (گهٽ ويڪرائي) ۽ پنگ-پانگ سرور سان گهٽ QPS سان (هاءِ دير سان) ، ٻئي ڪلائنٽ پاسي ۽ سرور جي پاسي. ۽ صرف صورت ۾، مون هڪ نموني پروسيسر پروفائل پڻ ورتو. جڏهن پروفائلز جي مقابلي ۾، آئون عام طور تي هڪ غير معمولي ڪال اسٽيڪ ڳولي ٿو. مثال طور، خراب پاسي تي اعلي ويڪرائي سان گڏ ڪيترائي وڌيڪ حوالا سوئچز (10 ڀيرا يا وڌيڪ). پر منهنجي صورت ۾، حوالن جي سوئچز جو تعداد لڳ ڀڳ ساڳيو هو. منهنجي خوف ۾، اتي ڪا به اهم شيء نه هئي.

Дополнительная отладка

Я был в отчаянии. Я не знал, какие ещё инструменты можно использовать, а мой следующий план состоял по сути в повторении экспериментов с разными вариациями, а не чётком диагностировании проблемы.

ڇا جيڪڏهن

С самого начала меня беспокоила конкретное время задержки 50 мс. Это очень большое время. Я решил, что буду вырезать куски из кода, пока не смогу выяснить точно, какая часть вызывает эту ошибку. Затем последовал эксперимент, который сработал.

هميشه وانگر، hindsight ۾ اهو لڳي ٿو ته سڀڪنھن شيء کي پڌرو هو. مون ڪلائنٽ کي ساڳي مشين تي رکيو جيئن Alvin - ۽ هڪ درخواست موڪلي localhost. И увеличение задержки исчезло!

نيٽ ورڪ ۾ ڪجهه غلط هو.

سکيا نيٽ ورڪ انجنيئر صلاحيتن

مون کي تسليم ڪرڻ گهرجي: نيٽ ورڪ ٽيڪنالاجيز جي منهنجي ڄاڻ خوفناڪ آهي، خاص طور تي ان حقيقت تي غور ڪندي ته آئون انهن سان هر روز ڪم ڪريان. پر نيٽ ورڪ بنيادي شڪي هو، ۽ مون کي سکڻ جي ضرورت هئي ته ان کي ڊيب ڪيئن ڪجي.

خوش قسمت، انٽرنيٽ انهن کي پيار ڪري ٿو جيڪي سکڻ چاهيندا آهن. پنگ ۽ ٽريسرٽ جو ميلاپ نيٽ ورڪ ٽرانسپورٽ جي مسئلن کي ڊيبگ ڪرڻ لاءِ ڪافي سٺي شروعات وانگر لڳي رهيو هو.

پهرين، مون شروع ڪيو پي ايس پينگ ايلون جي TCP بندرگاهه ڏانهن. مون ڊفالٽ سيٽنگون استعمال ڪيون - ڪجھ خاص. هڪ هزار پنگ کان وڌيڪ، ڪو به 10 ايم ايس کان وڌيڪ نه آهي، گرم ڪرڻ لاء پهرين هڪ جي استثنا سان. اهو 50th سيڪڙو تي 99 ms جي ويڪرائي ۾ مشاهدو ڪيل واڌ جي برعڪس آهي: اتي، هر 100 درخواستن لاء، اسان کي 50 ms جي دير سان هڪ درخواست ڏسڻ گهرجي.

پوء مون ڪوشش ڪئي ٽرڪر: اليون ۽ ڪلائنٽ جي وچ ۾ رستي ۾ ھڪڙي نوڊس تي ھڪڙو مسئلو ٿي سگھي ٿو. پر ٽريڪٽر به خالي هٿ موٽي آيو.

Таким образом, причиной задержки был не мой код, не реализация gRPC и не сеть. Я уже начал волноваться, что никогда этого не пойму.

هاڻي اسان ڪهڙي او ايس تي آهيون

gRPC لينڪس تي وڏي پيماني تي استعمال ٿيل، پر ونڊوز تي ڌار ڌار. مون هڪ تجربو ڪرڻ جو فيصلو ڪيو، جيڪو ڪم ڪيو: مون هڪ لينڪس ورچوئل مشين ٺاهي، لينڪس لاء ايلون مرتب ڪيو، ۽ ان کي ترتيب ڏنو.

۽ ھتي اھو آھي ڇا ٿيو: لينڪس پنگ پونگ سرور وٽ ساڳيا دير نه ھئي ونڊوز ھوسٽ وانگر، جيتوڻيڪ ڊيٽا جو ذريعو مختلف نه ھو. اهو ظاهر ٿئي ٿو ته مسئلو Windows لاء gRPC عمل درآمد ۾ آهي.

ناگل جي الگورتھم

اهو سڄو وقت مون سوچيو ته مان هڪ پرچم وڃائي رهيو آهيان gRPC. هاڻي مان سمجهان ٿو ته اهو ڇا آهي gRPC ونڊوز پرچم غائب آهي. مون کي هڪ اندروني RPC لائبريري ملي آهي جيڪا مون کي يقين هئي ته سڀني پرچم سيٽن لاء سٺو ڪم ڪندو ونسڪ. ان کان پوء مون انهن سڀني جھنڊن کي gRPC ۾ شامل ڪيو ۽ ونڊوز تي ايلون کي ترتيب ڏنو، هڪ پيچ ٿيل ونڊوز پنگ-پانگ سرور ۾!

تقريبا ٿي ويو: مون شامل ٿيل جھنڊن کي ھڪڙي وقت تي ھٽائڻ شروع ڪيو جيستائين رجعت واپس نه آئي تنھنڪري مان سبب کي نشانو بڻائي سگھان. اها بدنام هئي TCP_NODELAY، ناگل جي الگورتھم سوئچ.

ناگل جي الگورتھم пытается уменьшить количество пакетов, отправленных по сети, путём задержки передачи сообщений до тех пор, пока размер пакета не превысит определённое количество байт. Хотя это может быть приятно для среднего пользователя, но разрушительно для серверов реального времени, поскольку ОС будет задерживать некоторые сообщения, вызывая задержки на низком QPS. У gRPC был установлен этот флаг в реализации Linux для сокетов TCP, но не для Windows. Я это درست ڪيو.

ٿڪل

گھٽ QPS تي اعلي ويڪرائي OS جي اصلاح جي سبب هئي. پوئتي موٽڻ ۾، پروفائلنگ دير جي نشاندهي نه ڪئي ڇاڪاڻ ته اهو اندر جي بدران ڪنيل موڊ ۾ ڪيو ويو استعمال ڪندڙ موڊ. مون کي خبر ناهي ته ناگل جي الگورتھم کي ETW جي گرفتاري ذريعي ڏسي سگهجي ٿو، پر اهو دلچسپ هوندو.

جيئن ته لوڪل هوسٽ جي تجربي لاءِ، اهو شايد اصل نيٽ ورڪنگ ڪوڊ کي هٿ نه آيو ۽ ناگل جو الگورٿم نه هليو، تنهن ڪري دير سان مسئلا ختم ٿي ويا جڏهن ڪلائنٽ لوڪل هوسٽ ذريعي ايلون تائين پهتو.

ايندڙ وقت جڏهن توهان ڏسندا ته ويڪرائي ۾ اضافو ٿيو جيئن في سيڪنڊ جي درخواستن جو تعداد گهٽجي ٿو، ناگل جو الگورتھم توهان جي شڪي ماڻهن جي فهرست تي هجڻ گهرجي!

جو ذريعو: www.habr.com