როგორც პოსტების უმეტესობა, განაწილებული სერვისის პრობლემაა, ამ სერვისს დავარქვათ ალვინი. ამჯერად პრობლემა თავად ვერ აღმოვაჩინე, კლიენტის მხრიდან ბიჭებმა შემატყობინეს.

ერთ დღეს გამეღვიძა უკმაყოფილო ელფოსტაზე ხანგრძლივი დაგვიანების გამო ელვინთან, რომლის გაშვებასაც უახლოეს მომავალში ვგეგმავდით. კონკრეტულად, კლიენტმა განიცადა 99-ე პროცენტული შეყოვნება რეგიონში 50 ms, რაც ბევრად აღემატება ჩვენს ლატენტურ ბიუჯეტს. ეს გასაკვირი იყო, რადგან მე ფართოდ გამოვტესტე სერვისი, განსაკუთრებით ლატენტურობაზე, რაც ჩვეულებრივი საჩივარია.

სანამ ელვინს ჩავატარებდი ტესტირებაში, ჩავატარე ბევრი ექსპერიმენტი 40 ათასი მოთხოვნით წამში (QPS), ყველა აჩვენა შეყოვნება 10 ms-ზე ნაკლები. მზად ვიყავი მეთქვა, რომ არ ვეთანხმები მათ შედეგებს. მაგრამ წერილს კიდევ ერთხელ გადავხედე, რაღაც ახალი შევნიშნე: მათ მიერ ნახსენები პირობები ზუსტად არ მქონდა გამოცდილი, მათი QPS ბევრად დაბალი იყო ვიდრე ჩემი. მე გამოვცადე 40k QPS-ზე, მაგრამ ისინი მხოლოდ 1k-ზე. მე ჩავატარე კიდევ ერთი ექსპერიმენტი, ამჯერად დაბალი QPS-ით, მხოლოდ მათ დასამშვიდებლად.

მას შემდეგ, რაც მე ვწერ ბლოგს ამის შესახებ, თქვენ ალბათ უკვე მიხვდით, რომ მათი რიცხვი სწორი იყო. მე გამოვცადე ჩემი ვირტუალური კლიენტი არაერთხელ, იგივე შედეგით: მოთხოვნების დაბალი რაოდენობა არა მხოლოდ ზრდის შეყოვნებას, არამედ ზრდის მოთხოვნის რაოდენობას 10 ms-ზე მეტი შეყოვნებით. სხვა სიტყვებით რომ ვთქვათ, თუ 40k QPS-ზე დაახლოებით 50 მოთხოვნა წამში აჭარბებდა 50 ms-ს, მაშინ 1k QPS-ზე იყო 100 მოთხოვნა 50 ms-ზე მეტი ყოველ წამში. პარადოქსი!

ძიების შევიწროება

მრავალი კომპონენტის მქონე განაწილებულ სისტემაში შეყოვნების პრობლემის წინაშე, პირველი ნაბიჯი არის ეჭვმიტანილთა მოკლე სიის შექმნა. მოდით, ცოტა ღრმად ჩავუღრმავდეთ ელვინის არქიტექტურას:

კარგი საწყისი წერტილი არის დასრულებული I/O გადასვლების სია (ქსელის ზარები/დისკის ძიება და ა.შ.). შევეცადოთ გაერკვნენ, სად არის შეფერხება. კლიენტთან აშკარა I/O-ს გარდა, ელვინი დგამს დამატებით ნაბიჯს: ის წვდება მონაცემთა მაღაზიას. თუმცა, ეს საცავი მუშაობს იმავე კლასტერში, როგორც ალვინი, ამიტომ შეყოვნება იქ უფრო ნაკლები უნდა იყოს ვიდრე კლიენტთან. ასე რომ, ეჭვმიტანილთა სია:

1. ქსელური ზარი კლიენტიდან ელვინთან.
2. ქსელური ზარი ელვინიდან მონაცემთა მაღაზიაში.
3. მოძებნეთ დისკზე მონაცემთა მაღაზიაში.
4. ქსელური ზარი მონაცემთა საწყობიდან ელვინთან.
5. ქსელური ზარი ელვინისგან კლიენტთან.

შევეცადოთ გადავკვეთოთ რამდენიმე პუნქტი.

მონაცემთა შენახვას არაფერი აქვს საერთო

პირველი, რაც გავაკეთე, იყო ელვინის გადაქცევა პინგ-პინგ სერვერზე, რომელიც არ ამუშავებს მოთხოვნებს. როდესაც ის მიიღებს მოთხოვნას, ის აბრუნებს ცარიელ პასუხს. თუ შეყოვნება მცირდება, მაშინ ელვინის ან მონაცემთა საწყობის დანერგვის ხარვეზი არაფერია. პირველ ექსპერიმენტში ვიღებთ შემდეგ გრაფიკს:

როგორც ხედავთ, არ არის გაუმჯობესება პინგ-პინგ სერვერის გამოყენებისას. ეს ნიშნავს, რომ მონაცემთა საწყობი არ ზრდის შეყოვნებას და ეჭვმიტანილთა სია განახევრებულია:

1. ქსელური ზარი კლიენტიდან ელვინთან.
2. ქსელური ზარი ელვინისგან კლიენტთან.

დიდი! სია სწრაფად მცირდება. მეგონა, თითქმის მივხვდი მიზეზს.

gRPC

ახლა დროა გაგაცნოთ ახალი მოთამაშე: gRPC. ეს არის ღია კოდის ბიბლიოთეკა Google-ისგან პროცესის პროცესში მყოფი კომუნიკაციისთვის RPC. თუმც gRPC კარგად ოპტიმიზირებული და ფართოდ გამოყენებული, პირველად ვიყენებდი მას ამ ზომის სისტემაზე და ველოდი, რომ ჩემი დანერგვა არაოპტიმალური იქნებოდა - რბილად რომ ვთქვათ.

Наличие gRPC დასტაში წარმოიშვა ახალი კითხვა: შესაძლოა ეს ჩემი განხორციელებაა ან მე gRPC იწვევს ლატენტურ პრობლემას? სიაში ახალი ეჭვმიტანილის დამატება:

1. კლიენტი ურეკავს ბიბლიოთეკას gRPC
2. ბიბლიოთეკა gRPC კლიენტის ბიბლიოთეკაში ქსელის ზარს აკეთებს gRPC სერვერზე
3. ბიბლიოთეკა gRPC კონტაქტები ელვინი (ოპერაცია არ არის პინგ-პონგის სერვერის შემთხვევაში)

იმისათვის, რომ წარმოდგენა მოგცეთ, თუ როგორ გამოიყურება კოდი, ჩემი კლიენტი/ალვინის განხორციელება დიდად არ განსხვავდება კლიენტ-სერვერისგან. ასინქრონული მაგალითები.

შენიშვნა: ზემოთ ჩამოთვლილი სია ოდნავ გამარტივებულია, რადგან gRPC შესაძლებელს ხდის გამოიყენოს საკუთარი (თარგი?) ძაფების მოდელი, რომელშიც გადახლართულია შესრულების დასტა. gRPC და მომხმარებლის განხორციელება. სიმარტივის მიზნით, ჩვენ დავრჩებით ამ მოდელზე.

პროფილირება ყველაფერს გამოასწორებს

მონაცემთა მაღაზიების გადაკვეთის შემდეგ, მეგონა, რომ თითქმის დავასრულე: ”ახლა ადვილია! მოდით გამოვიყენოთ პროფილი და გავარკვიოთ სად ხდება შეფერხება. ” მე ზუსტი პროფილის დიდი გულშემატკივარი, რადგან პროცესორები ძალიან სწრაფია და ყველაზე ხშირად არ წარმოადგენს ბოსტნეულს. შეფერხებების უმეტესობა ხდება მაშინ, როდესაც პროცესორმა უნდა შეწყვიტოს დამუშავება სხვა რამის გასაკეთებლად. CPU-ის ზუსტი პროფილირება სწორედ ამას აკეთებს: ის ზუსტად იწერს ყველაფერს კონტექსტური გადამრთველები და ცხადყოფს სად ხდება შეფერხებები.

მე ავიღე ოთხი პროფილი: მაღალი QPS (დაბალი შეყოვნებით) და პინგ-პონგის სერვერით დაბალი QPS (მაღალი შეყოვნებით), როგორც კლიენტის, ასევე სერვერის მხარეს. და ყოველი შემთხვევისთვის, მე ასევე ავიღე პროცესორის პროფილის ნიმუში. პროფილების შედარებისას, მე ჩვეულებრივ ვეძებ ზარების ანომალიურ დასტას. მაგალითად, ცუდ მხარეზე მაღალი შეყოვნებით არის კიდევ ბევრი კონტექსტური გადამრთველი (10 ჯერ ან მეტი). მაგრამ ჩემს შემთხვევაში, კონტექსტური გადამრთველების რაოდენობა თითქმის იგივე იყო. ჩემდა საშინლად, იქ არაფერი იყო მნიშვნელოვანი.

დამატებითი გამართვა

სასოწარკვეთილი ვიყავი. მე არ ვიცოდი რა სხვა ინსტრუმენტების გამოყენება შემეძლო და ჩემი შემდეგი გეგმა არსებითად იყო ექსპერიმენტების გამეორება სხვადასხვა ვარიაციით, ვიდრე პრობლემის მკაფიო დიაგნოსტიკა.

Რა იქნება თუ

თავიდანვე მაწუხებდა კონკრეტული 50ms შეყოვნება. ეს ძალიან დიდი დროა. მე გადავწყვიტე, რომ ამომეჭრა კოდიდან ნაწილაკები, სანამ არ გავარკვევდი, თუ რომელი ნაწილი იწვევდა ამ შეცდომას. შემდეგ მოვიდა ექსპერიმენტი, რომელმაც იმუშავა.

ჩვეულებისამებრ, უკანდახედვით ჩანს, რომ ყველაფერი აშკარა იყო. მე დავაყენე კლიენტი იმავე აპარატზე, როგორც ელვინი - და გავუგზავნე მოთხოვნა localhost. და ლატენტურობის ზრდა გაქრა!

ქსელში რაღაც არასწორი იყო.

ქსელის ინჟინრის უნარების სწავლა

უნდა ვაღიარო: ჩემი ცოდნა ქსელური ტექნოლოგიების შესახებ საშინელია, განსაკუთრებით იმის გათვალისწინებით, რომ მათთან ყოველდღე ვმუშაობ. მაგრამ ქსელი იყო მთავარი ეჭვმიტანილი და მე უნდა მესწავლა მისი გამართვა.

საბედნიეროდ, ინტერნეტს უყვარს ისინი, ვისაც სწავლა სურს. პინგისა და ტრასერტის კომბინაცია საკმარისად კარგი დასაწყისი იყო ქსელის ტრანსპორტის პრობლემების გამართვისთვის.

პირველ რიგში, მე გავუშვი ფსპინგი ელვინის TCP პორტამდე. მე გამოვიყენე ნაგულისხმევი პარამეტრები - არაფერი განსაკუთრებული. ათასზე მეტი პინგიდან არცერთი არ აღემატებოდა 10 ms-ს, გარდა პირველის გახურებისთვის. ეს ეწინააღმდეგება 50-ე პროცენტულზე 99 ms შეყოვნების დაფიქსირებულ ზრდას: იქ, ყოველ 100 მოთხოვნაზე, უნდა გვენახა დაახლოებით ერთი მოთხოვნა 50 ms შეყოვნებით.

მერე ვცადე კონცერტი: შეიძლება იყოს პრობლემა ელვინსა და კლიენტს შორის მარშრუტის ერთ-ერთ კვანძში. მაგრამ მკვლევარიც ხელცარიელი დაბრუნდა.

ასე რომ, ეს არ იყო ჩემი კოდი, gRPC დანერგვა ან ქსელი, რომელიც იწვევდა შეფერხებას. დავიწყე ფიქრი, რომ ამას ვერასდროს გავიგებდი.

ახლა რა OS-ზე ვართ

gRPC ფართოდ გამოიყენება Linux-ზე, მაგრამ ეგზოტიკური Windows-ზე. გადავწყვიტე ექსპერიმენტი გამომეცადა, რამაც იმუშავა: შევქმენი Linux-ის ვირტუალური მანქანა, შევადგინე ალვინი ლინუქსისთვის და გავავრცელე იგი.

და აი, რა მოხდა: Linux-ის პინგ-პონგის სერვერს არ ჰქონდა იგივე შეფერხებები, როგორც Windows-ის მსგავს ჰოსტს, თუმცა მონაცემთა წყარო არ განსხვავდებოდა. გამოდის, რომ პრობლემა Windows-ისთვის gRPC განხორციელებაშია.

ნაგლის ალგორითმი

მთელი ეს დრო მეგონა დროშა მაკლდა gRPC. ახლა მე მესმის, რა არის სინამდვილეში gRPC Windows-ის დროშა აკლია. ვიპოვე შიდა RPC ბიბლიოთეკა, რომელიც დარწმუნებული ვიყავი, რომ კარგად იმუშავებდა ყველა მითითებული დროშისთვის Winsock. შემდეგ მე დავამატე ყველა ეს დროშები gRPC-ში და განვათავსე ელვინი Windows-ზე, დაყენებული Windows-ის პინგ-პონგის სერვერზე!

თითქმის შესრულებულია: დავიწყე დამატებული დროშების ამოღება თითო-ოროლა, სანამ რეგრესია არ დაბრუნდება, რათა შემეძლოს ზუსტი მიზეზის დადგენა. სამარცხვინო იყო TCP_NODELAY, ნაგლის ალგორითმის გადამრთველი.

ნაგლის ალგორითმი ცდილობს შეამციროს ქსელში გაგზავნილი პაკეტების რაოდენობა შეტყობინებების გადაცემის შეფერხებით, სანამ პაკეტის ზომა არ გადააჭარბებს ბაიტების გარკვეულ რაოდენობას. მიუხედავად იმისა, რომ ეს შეიძლება კარგი იყოს საშუალო მომხმარებლისთვის, ის დამღუპველია რეალურ დროში სერვერებისთვის, რადგან OS შეაფერხებს ზოგიერთ შეტყობინებას, რაც იწვევს დაბალ QPS-ზე ჩამორჩენას. უ gRPC ეს დროშა დაყენებული იყო Linux-ის იმპლემენტაციაში TCP სოკეტებისთვის, მაგრამ არა Windows-ში. მე ეს ვარ შესწორებული.

დასკვნა

დაბალი QPS-ზე მაღალი შეყოვნება გამოწვეული იყო OS-ის ოპტიმიზაციით. რეტროსპექტივაში, პროფილირებამ არ გამოავლინა შეყოვნება, რადგან ის გაკეთდა ბირთვის რეჟიმში და არა შიგნით მომხმარებლის რეჟიმი. არ ვიცი, შესაძლებელია თუ არა ნაგლის ალგორითმის დაკვირვება ETW გადაღების საშუალებით, მაგრამ საინტერესო იქნებოდა.

რაც შეეხება ლოკალჰოსტის ექსპერიმენტს, ის სავარაუდოდ არ შეეხო ქსელის რეალურ კოდს და ნაგლის ალგორითმი არ მუშაობდა, ამიტომ შეყოვნების პრობლემები გაქრა, როდესაც კლიენტმა ლოკალჰოსტის მეშვეობით მიაღწია ალვინს.

შემდეგ ჯერზე, როცა დაინახავთ შეყოვნების ზრდას, რადგან წამში მოთხოვნის რაოდენობა მცირდება, ნაგლის ალგორითმი უნდა იყოს თქვენს ეჭვმიტანილთა სიაში!

წყარო: www.habr.com