VPN სერვერის დატვირთვა განმარტებული: მომხმარებლები, CPU თუ ასვლის არხი?
დატვირთვის დაბალი ქულა შეიძლება ნიშნავდეს უსაქმურ მომხმარებლებს, თავისუფალ CPU-ს ან ფართო ასვლის არხს. სანამ მას სწრაფს უწოდებთ, წაიკითხეთ loadavg, ინტერფეისის მრიცხველები და სტატუსის ფაილი.
0.4 დატვირთვაზე მჯდომი კარიბჭე მაინც შეიძლება იცოცოს მის უკან მყოფი ყოველი მომხმარებლისთვის. საშუალო დატვირთვა ითვლის დავალებებს, რომლებიც გაშვებადია ან ჩარჩენილია შეუწყვეტელ ძილში, და ოთხბირთვიან ჰოსტზე ერთი გაჯერებული პროცესი საკმარისია მისი 1.0-ისკენ უბიძგებლად, სანამ სამი ბირთვი უსაქმოდ ზის. ამ რიცხვის როგორც რეზერვის წაკითხვა ბოლო წერტილის არჩევისას ყველაზე გავრცელებული შეცდომაა. იმას, რაც ტუნელს რეალურად ზღუდავს, ჩვეულებრივ ოთხიდან ერთ-ერთია: ერთი დაკავებული ბირთვი, ასვლის არხი, მის წინ არსებული რიგი ან ერთი სესიის პოლიტიკა, რომელიც არავის დაუდგენია.
საშუალო დატვირთვა დავალებებს ითვლის, არა გამტარობას
ბირთვი აღრიცხავს შესრულების რიგს და შეყვანა-გამოყვანის მომლოდინე დავალებების რაოდენობას, შემდეგ ორივეს ასწორებს ერთი, ხუთი და თხუთმეტი წუთის განმავლობაში. ამ განმარტებაში არაფერი ახსენებს ბაიტებს, პაკეტებს ან ტუნელებს. ჩარჩენილი საცავის მქონე ჰოსტს შეუძლია მაღალი დატვირთვა შეატყობინოს თითქმის ტრაფიკის გარეშე, ხოლო ჰოსტს, რომელიც გიგაბიტს უშვებს ბირთვის მონაცემთა ბილიკზე, შეუძლია კომფორტული დატვირთვა შეატყობინოს.
ამიტომ დატვირთვის ტუნელის წარმადობასთან დაკავშირება მოითხოვს ხედვას თითოეული ბირთვის მიხედვით. თუ ერთი ბირთვი სავსეა, საინფორმაციო დაფაზე ჯამური პროცენტი მაინც კარგად გამოიყურება:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20მესამე ბრძანებაა ის, რაც VPN ჰოსტებზე ყველაზე მეტად მნიშვნელოვანია. OpenVPN 2.x-ში მომხმარებლის სივრცეში პაკეტების დამუშავება დიდწილად სერიულია თითოეული პროცესისთვის, ამიტომ ერთი დაკავებული ნაკადი შეიძლება გახდეს ზედა ზღვარი, მაშინ როცა დაფა იუწყება უხვ თავისუფალ სიმძლავრეს. თუ თქვენი ნელი პერიოდის დროს ერთი ნაკადი იკავებს ბირთვის უმეტეს ნაწილს, ჰოსტი მთლიანობაში არ არის არასაკმარისად აღჭურვილი; ის შეზღუდულია იმ განზომილებაში, რომელიც შემთხვევით მნიშვნელოვანია.
ყურადღება მიაქციეთ დროსაც. თხუთმეტწუთიანი საშუალოები მალავს იმ აფეთქებას, რომელმაც ზარი გააფუჭა, ამიტომ საჩივრის შემდეგ გადაღებული ეკრანის სურათი სუსტი მტკიცებულებაა. აიღეთ ნიმუშები პრობლემის დროს და შეინახეთ დროის ნიშანი გამოტანილ მონაცემებთან ერთად.
ასვლის არხი და მის წინ არსებული რიგი
ინტერფეისის მრიცხველები პასუხობენ გამტარობის კითხვას, რომელზეც CPU-ის ციფრები ვერ პასუხობს. ისინი ასევე გამოყოფენ სიმძლავრეს დანაკარგისგან, და ეს სხვადასხვა გაუმართაობაა სხვადასხვა გადაწყვეტით:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitთქვენი ტესტის დროს გამოყოფილ სიჩქარესთან ახლოს მყოფი კავშირი სწორედ განმარტებაა, და თავისუფალი CPU-ის არც ერთი რაოდენობა ამას არ ცვლის. qdisc-ის ხაზი ამატებს დეტალს, რომელიც ინტერაქტიული ტრაფიკისთვის მნიშვნელოვანია: დაგროვება და დანაკარგები გეუბნებიან, ლოდინობენ თუ არა პაკეტები რიგში გასვლამდე. დიდი ატვირთვის დროს სავსე რიგი ქმნის ზუსტად იმ სიმპტომს, რომლის გამოც ხალხი დისტანციურ სერვერს ადანაშაულებს, ანუ ნელი ზარები კავშირზე, რომელიც ჯერ კიდევ კარგად გამოიყურება გაზომვებში.
გადაგზავნის მრიცხველები იჭერენ შემთხვევას, როცა პაკეტები გადის, მაგრამ არასოდეს აღწევს სუფთად. თუ ნელი ფანჯრის დროს გადაგზავნები იზრდება და ინტერფეისი სიმძლავრეს შორსაა, პრობლემა ბილიკშია და არა ჰოსტზე, და იმავე ქალაქში სხვა ბოლო წერტილზე გადასვლა არ დაეხმარება.
სესიების რაოდენობა მოთხოვნას აღწერს, არა რეზერვს
ყოველი საჯარო კატალოგი აჩვენებს დაკავშირებული მომხმარებლების რაღაც რაოდენობას, და მათგან თითქმის არც ერთი არ გეუბნებათ, რას აკეთებენ ეს მომხმარებლები. ინტერაქტიულ სამუშაოს მქონე ოცი სესია და დიდ ფაილებს მწოვარი ოთხი სესია ერთსა და იმავე ტექნიკაზე ძალიან განსხვავებულ დატვირთვას ქმნის. მეორე ნიმუში მომხმარებლების რაოდენობაში უხილავია, და სწორედ ის აფუჭებს საღამოს. ამიტომ სესიების რიცხვი საუკეთესოდ მოთხოვნის მინიშნებად იკითხება, არასოდეს როგორც განცხადება თავისუფალი სიმძლავრის შესახებ.
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
თქვენს მიერ კონტროლირებულ ჰოსტზე სტატუსის ფაილი აძლევს დაკარგულ განზომილებას. OpenVPN წერს პერიოდულ სურათს, რომელიც მოიცავს თითო კლიენტის ბაიტურ მრიცხველებს, და ეს საკმარისია იმის სანახავად, არის თუ არა ერთი სესია პასუხისმგებელი მთელ ასვლის არხზე:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusათი წამის დაშორებით ორი ნიმუში ამ კუმულაციურ მრიცხველებს თითო კლიენტის სიჩქარედ აქცევს. სწორედ ეს არის ის გაზომვა, რომელსაც მომხმარებლების რაოდენობა ცვლის, და ასევე აღმოაჩენთ, რომ ერთი არასწორად კონფიგურირებული კლიენტი ყოველ ღამე იმავე საათში აჯერებს კავშირს.
სესიის ლიმიტები პოლიტიკაში იმალება
სერვერი შეიძლება უსაქმური იყოს და მაინც უარი გითხრათ გამტარობის მოცემაზე. სიჩქარის ლიმიტები, თითო კლიენტის გამტარობის ჭერი და ტრაფიკის ფორმირება ხშირად საერთო სახელის ან აუზის მიხედვით გამოიყენება, ამიტომ ერთსა და იმავე კარიბჭეზე ორმა მომხმარებელმა შეიძლება სრულიად განსხვავებული შედეგი მიიღოს. მექანიზმი დახვეწილი არ არის, მაგრამ გარედან უხილავია, რადგან ტუნელი ორივე შემთხვევაში ნორმალურად ადის.
ფორმირებას ეძებეთ ტუნელის ინტერფეისზე და არა ფიზიკურზე. შეამოწმეთ, მიჰყვება თუ არა ლიმიტი მომხმარებელს, სერტიფიკატს ან მისამართების აუზს. თუ თქვენი სატესტო ანგარიში ულიმიტო აუზში ხვდება, დაასკვნით, რომ სერვერი რიგზეა და მომჩივანი მომხმარებელი ცდება. ასეთი დასკვნა უარესია, ვიდრე დასკვნის არარსებობა, რადგან ის ბილეთს ხურავს.
შეადარეთ ორი ბოლო წერტილი ერთი ფიქსირებული დავალებით
კლიენტის მხრიდან ექსპერიმენტი ჯერ კიდევ ღირს ჩატარებად, მაგრამ მხოლოდ მაშინ, თუ ცვლადები დაფიქსირებულია. გამოიყენეთ იგივე მოწყობილობა, იგივე წვდომის ქსელი, იგივე პროტოკოლი და იგივე დანიშნულების ფაილი, შემდეგ გაიმეორეთ მსგავს მანძილზე მდებარე მეორე ბოლო წერტილის წინააღმდეგ. ყველაფერი, რაც გაშვებებს შორის იცვლება, დღის დროის ჩათვლით, აბინძურებს შედეგს.
ჩაწერეთ წარუმატებლობები ისევე ყურადღებით, როგორც წარმატებები. სერია, სადაც სამი ბოლო წერტილი მუშაობს და ერთი დროის ლიმიტს აღწევს, უფრო ინფორმატიულია, ვიდრე ოთხი სიჩქარის რიცხვი, რადგან ის ბილიკის ან პოლიტიკის პრობლემაზე მიუთითებს და არა სიმძლავრის. გაუშვით ყოველი შემთხვევა სულ მცირე ორჯერ; ერთი ნელი ნიმუში გაზიარებულ ქსელში არაფერს ამტკიცებს.
და ბოლოს, შეინახეთ შეგროვებული რიცხვები იმ მტკიცებასთან ერთად, რომელსაც ისინი უჭერენ მხარს. "ამ ბოლო წერტილმა გადაცემა იმავე ფანჯარაში შეასრულა, სადაც მეორე ჩაიჭედა" დასაცავია, მაშინ როცა "ეს ბოლო წერტილი უფრო სწრაფია" იწვევს კამათს, რომელსაც მთავარი გვერდის ქულით ვერ მოიგებთ. OpenVPN 2.6-ის სახელმძღვანელო აღწერს სტატუსის ფაილს და ფორმირების პარამეტრებს, თუ ჰოსტის მხარისთვის ზუსტი მითითებები გჭირდებათ.