სერვერის დატვირთვის გრაფიკის კითხვა: მეხსიერება, CPU და დისკი

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

რას ზომავს პანელი სინამდვილეში#

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

მეხსიერება იკითხება container-ის საკუთარი ბირთვის აღრიცხვიდან და არა თამაშიდან. ეს მთელი პროცესების ჯგუფია: JVM heap პლუს ყველაფერი მის გარეთ, ან Node პროცესი პლუს ყველა buffer, პლუს სხვა ყველაფერი, რაც container-ში მუშაობს. ეს არ არის ის, რასაც -Xmx ამბობს და არც ის, რასაც თამაში /mem-ში ან spark-ის შეჯამებაში აცხადებს. 6 GB container-ში 5 GB heap-ით გაშვებული Minecraft სერვერი პანელში დაახლოებით 5.5 GB-ს აჩვენებს და თამაშში 5 GB-ს, და არცერთი რიცხვი არ არის არასწორი.

არის დახვეწილი ნიუანსი, რაც ღირს ცოდნად: cgroup v2-ზე ბირთვის მეხსიერების ნედლი მრიცხველი შეიცავს page cache-ს, რომელიც container-მა გამოიწვია - ფაილის მონაცემები, რომლებსაც ბირთვი ინახავს, რადგან შეიძლება ისევ წაიკითხონ. უმეტესი პანელი აჩვენებს მაჩვენებელს, რომელიც აქტიურ ფაილურ ქეშს აკლებს, ეს იგივეა, რასაც docker stats აჩვენებს, მაგრამ ყველა ასე არ იქცევა. თუ შენი მეხსიერების ხაზი backup-ის ან დიდი ფაილის კოპირების დროს ახტება და მერე უკან ეშვება ისე, რომ არაფერი ჩავარდნილა, შენ ქეშს უყურებდი და არა აპლიკაციას.

CPU არის პროცენტი ერთი ბირთვიდან, ხოლო გეგმის მაჩვენებელი ჭერია. 100 არის ერთი ბირთვი, 250 - ორნახევარი. გრაფიკი 210%-ზე გატეხილი არ არის; ეს ნიშნავს, რომ ორი ბირთვის ტოლი სამუშაო სრულდება. RE:NODE-ზე ეს ჭერი მყარი throttle-ია იმ წილამდე, რომელიც იყიდე, ამიტომ ხაზი, რომელიც მას აწვება, ლიმიტია, რომელიც თავის საქმეს აკეთებს, ხოლო სერვერი 100%-ზე ნელია და არა პრობლემაში - მისი ამის გამო არასოდეს ჩერდება.

სინჯის აღების ინტერვალი არის საზღვარი იმისა, რის თქმაც ნებისმიერ გრაფიკს შეუძლია. გრაფიკზე წერტილი არის საშუალო ან სინჯი რამდენიმე წამზე. პიკი, რომელიც 400 მილიწამს გრძელდება, საერთოდ არ ჩანს. ეს უზარმაზარ მნიშვნელობას იძენს, რადგან რასაც მოთამაშეები უჩივიან - stutter, rubber-band, გაყინვა - მილიწამების მასშტაბზე ხდება, რესურსების გრაფიკები კი უკეთეს შემთხვევაში წამების მასშტაბის ინსტრუმენტია. თუ საჩივარია "ერთი წამით დალაგდა", გრაფიკი არასწორი ხელსაწყოა და თამაშის შიგნით tick-ის მეტრიკები სწორი. რას ნიშნავს tick rate სინამდვილეში მათ განიხილავს.

მეხსიერების ხაზი#

მეხსიერება ხაზია, რომელზეც ყველაზე მეტს მოქმედებენ და ყველაზე ნაკლებად ესმით. ხუთი ფორმა თითქმის ყველაფერს ფარავს.

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

პირველი წუთიდან სწორი ხაზი ჭერთან. თითქმის ყოველთვის წინასწარ დაკავებული heap. JVM, რომელიც -Xms-ით -Xmx-ის ტოლად და -XX:+AlwaysPreTouch-ით გაეშვა, მთელ heap-ს დაუყოვნებლივ, განზრახ იჭერს და შეეხება, ამიტომ გრაფიკი ერთი მოთამაშის შემოსვლამდეც მიმაგრებულია. ის საგანგაშოდ გამოიყურება და სწორია. შეამოწმე tick-ის დრო: მიმაგრებული მეხსიერება კარგი tick-ის დროით უბრალოდ დაყენებული flag-ია.

რეგულარული ხერხი, რომელიც იმავე ფსკერს უბრუნდება. Garbage collection ნორმალურად მუშაობს. ფსკერი შენი ცოცხალი მონაცემებია; კბილები - ნაგავი collection-ებს შორის. გასასწორებელი არაფერია. ღრმა, ხშირი კბილები ხილული პაუზებით ნიშნავს, რომ heap სამუშაო სიმრავლისთვის ცოტათი პატარაა, რაც CPU-ს ჯდება.

ხერხი მზარდი ფსკერით. ყოველი collection წინაზე ნაკლებს აბრუნებს. ეს არის leak და ნებისმიერ გრაფიკზე ყველაზე მოქმედებისკენ მიმართული ფორმა. ის დასრულდება crash-ით იმ დროს, რომელსაც ვერ აირჩევ. Node აპლიკაციისთვის შესაბამისი გაზომვა აღწერილია პოსტში Node.js-ის მეხსიერების ლიმიტები; Minecraft-ისთვის ჩვეულებრივ plugin-ია და spark profiler მას დაასახელებს.

ვერტიკალური აწევა ლიმიტამდე და შემდეგ უფსკრული ნულამდე. Out-of-memory kill. Container ლიმიტს მიაღწია, ბირთვმა ის გააჩერა და ხაზი ქვემოდან თავიდან იწყება, როცა სერვერი უკან ბრუნდება. RE:NODE-ზე ეს განზრახ ქცევაა - container ჩერდება და სუფთად რესტარტდება იმის ნაცვლად, რომ swap-ში ჩავიდეს და მანქანა ჩაითრიოს - და ეს ნიშნავს, რომ კონსოლი crash report-ის გარეშე მოულოდნელად წყდება. თუ ეს ფორმა მეორდება, გაქვს რესტარტების ციკლი და არა crash: რატომ რესტარტდება შენი გეიმ სერვერი განუწყვეტლივ სრული დიაგნოსტიკაა.

CPU-ს ხაზი#

CPU ხაზია, რომელსაც ხალხი უგულებელყოფს და არ უნდა.

პიკები ჭერამდე რამდენიმე წამით. World-ის შენახვა, chunk-ების გენერაციის ნაკადი, backup-ის დაწყება, plugin-ის დაგეგმილი ამოცანა. თითქმის ყოველთვის კარგადაა. პიკი, რომელიც დაემთხვა გაყინვას, რომელიც მოთამაშეებმა შეამჩნიეს, ღირს დროის გაზომვად - თუ ის ყოველ ხუთ წუთში ხდება, ეს შენი autosave-ის ინტერვალია და შეიძლება გადაიტანო ან შეამოკლო.

საათობით ჭერზე მდგრადად. სიმულაცია ვერ ეწევა და მეხსიერების არანაირი რაოდენობა ამას ვერ შეცვლის. ეს throttling-ია: შენი container კვოტაზე ჩერდება, განმეორებით, tick-ის შუაში. shell წვდომით ამას დაამტკიცებ:

$ cat /sys/fs/cgroup/cpu.statnr_periods 940213nr_throttled 71204throttled_usec 902133945

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

ზუსტად 100%-ზე მიმაგრებული გეგმაზე, რომელიც 200 ან 250-ს უშვებს. ნებისმიერ პანელზე ყველაზე ხშირად არასწორად გაგებული მდგომარეობა. ერთი thread გაჯერებულია და განაწილების დანარჩენი ნაწილი უქმია, რაც დატვირთული გეიმ სერვერის ნორმალური მდგომარეობაა, რადგან თითქმის ყველა ძრავა თავის სიმულაციას ერთ thread-ზე უშვებს. მეტი ბირთვის ყიდვა აქ არაფერს აკეთებს; უფრო სწრაფი ბირთვი კი აკეთებს. CPU თუ RAM: რომელი აფერხებს რეალურად შენს სერვერს განსხვავებას სათანადოდ განიხილავს.

ფსკერთან, სანამ ყველაფერი ნელია. სერვერი ელოდება და არა მუშაობს - დისკს, ქსელურ გამოძახებას ან lock-ს. plugin, რომელიც მთავარ thread-ზე ბაზის query-ს აკეთებს, ზუსტად ამას იძლევა: დაბალი CPU, საშინელი tick-ის დრო. ასევე - წარუმატებელი DNS lookup timeout-ით.

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

დისკის ხაზი#

დისკს ორ სხვადასხვა რამეს ეძახიან და მხოლოდ ერთი მათგანი ჩანს ჩვეულებრივ გრაფიკზე.

დისკის გამოყენება არის გამოყენებული გიგაბაიტები გეგმის განაწილების მიმართ. ის ნელა მოძრაობს და მნიშვნელოვანია მხოლოდ ზედა ნაწილში, სადაც ძალიან მნიშვნელოვანია: სერვერს, რომელსაც ჩაწერა არ შეუძლია, შენახვა არ შეუძლია, ხოლო სავსე დისკის გამო შეწყვეტილი შენახვა ისაა, როგორ ზიანდება world-ები და არა უბრალოდ იკარგება. 85% აღიარე ხაზად, სადაც იძიებ, და არა 99%.

რა ავსებს დისკს, იმის მიხედვით, რამდენად ხშირად არის ეს პასუხი:

• Log ფაილები, რომლებსაც არაფერი ახვევს. logs/*.log.gz-ის წლები ყველაზე გავრცელებული მიზეზია და ყველაზე ადვილად გასასწორებელი.
• Crash report-ები და heap dump-ები, რომლებიც ზუსტად იმ მომენტში იწერება, როცა არავინ უყურებს.
• world-ის backup-ები ადგილზე - ისინი, რომლებსაც თავად თამაში წერს world-ის გვერდით, რომლებიც არავითარი სასარგებლო გაგებით backup არ არის, რადგან იმ დისკს იზიარებს, რასაც იცავს.
• ჩამოტვირთული workshop ან mod კონტენტი, რომელიც ვერსიებს შორის გროვდება.
• აპლიკაციებისთვის: dependency-ების ხეები, დუბლირებული თითო deploy-ზე, და build ქეშები.

$ du -sh /home/container/* | sort -h | tail -20$ find /home/container -type f -size +100M -exec ls -lh {} \;

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

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

ფორმების კატალოგი#

სამი გრაფიკის ერთად კითხვა#

ერთი ხაზი განცალკევებით გამოცნობაა. ტექნიკა ყოველთვის ერთი და იგივეა:

1. აიღე დროის ნიშნული. ჰკითხე, როდის იყო ცუდი, ათი წუთის სიზუსტით. ამის გარეშე მთელ დღეს უყურებ და ყველაფერი საეჭვოა.
2. იპოვე, რომელი ხაზი დაიძრა პირველი. არა რომელი გამოიყურება ყველაზე ცუდად - რომელი შეიცვალა დანარჩენებზე ადრე. მეხსიერება, რომელიც იზრდება და შემდეგ CPU-ს თან მიიყოლებს, მეხსიერების პრობლემაა. CPU, რომელიც ივსება და რიგს აგროვებინებს, CPU-ს პრობლემაა.
3. წაიკითხე კონსოლი იმავე დროის ნიშნულზე. გრაფიკი ამბობს, რომ რაღაც შეიცვალა; log ჩვეულებრივ ამბობს, რა. RE:NODE-ზე კონსოლი და გრაფიკები ერთ გვერდზეა, ანუ ერთ საათზე. კონსოლის კითხვა აღწერს, რას უნდა დააკვირდე.
4. იკითხე, რა შეიცვალა იმ დღეს. mod, plugin, კონფიგის რედაქტირება, მოთამაშეების რაოდენობის რეკორდი, თამაშის განახლება. ამ თანმიმდევრობით, რადგან ეს არის ალბათობის თანმიმდევრობა.

მეოთხე ტოტი ყველაზე მეტ ფულს გიზოგავს. სამი მშვიდი გრაფიკი და უკმაყოფილო მოთამაშეები ნიშნავს, რომ პრობლემა იმ რესურსებში არ არის, რომლებსაც მეტს გიყიდიან. ეს არის ქსელის გზა, ერთი კლიენტი, მანქანაზე მეზობელი ან ერთი დაბლოკვის ოპერაცია, რომელიც ნებისმიერ სინჯში გამოსაჩენად ძალიან მოკლეა. Latency, jitter და packet loss და გაზიარებული CPU და ხმაურიანი მეზობლები ორივე გარე შემთხვევას განიხილავს.

საკუთარი ნორმალურის დადგენა#

სწორი რიცხვი არ არსებობს, მხოლოდ ნორმალური შენი სერვერისთვის. 4 GB Minecraft სერვერი 3.6 GB-ზე ან სრულიად ჯანსაღია, ან crash-ამდე ორი საათი აშორებს, და მარტო გრაფიკი ვერ გეტყვის, რომელი. რაც გეტყვის, ისაა შედარება იმავე სერვერთან კარგ საღამოს.

ამიტომ ბაზისი განზრახ აიღე, სანამ ყველაფერი რიგზეა:

• კარგ საღამოს, პიკზე, ჩაიწერე მეხსიერება, CPU და მოთამაშეების რაოდენობა ერთად. თარიღიანი screenshot სჯობს იმის მოგონებას, როგორ გამოიყურებოდა.
• ჩაიწერე იგივე სამი რიცხვი 04:00-ზე, როცა არავინ თამაშობს. ეს არის შენი უქმი ფსკერი და მანძილი უქმსა და პიკს შორის არის რიცხვი, რომელიც შენს რეზერვს რეალურად აღწერს.
• ჩაწერე ისინი ტექსტურ ფაილში თარიღით. პანელის ისტორია სასრულია და შედარება, რომელიც სამ თვეში გინდა, კვირასთან იქნება, რომელიც უკვე გადაიფურცლა.
• გაიმეორე ნებისმიერი სახელდებადი ცვლილების შემდეგ: ახალი plugin, ვერსიის განახლება, გეგმის შეცვლა, world-ის იმპორტი.

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

მთელი მეთოდის დამუშავებული მაგალითი. 6 GB, 2 vCPU Paper სერვერი, ოცი რეგულარული მოთამაშე, საჩივრები საღამოს lag-ზე.

memory  5.9 GB of 6.0 GB, flat from the first minute, no cliffscpu     40% overnight, 185% of an allowed 200% from 19:00 to 23:00disk    41 GB of 50 GB, up from 33 GB nine days ago

წაიკითხე თანმიმდევრობით: მეხსიერების ხაზი მიმაგრებულია, მაგრამ უფსკრული არ აქვს და მიმაგრებულად იწყება, ესე იგი, ეს არის -Xms5G -Xmx5G pre-touch-ით და ის პრობლემა არ არის, რა საშინლადაც არ უნდა გამოიყურებოდეს. CPU ხაზი ზუსტად იმ საათებში ივსება, როცა ხალხი უჩივის, რაც პასუხია კითხვაზე, რომელიც დაისვა. და დისკის ხაზი, რომელზეც არავინ იკითხა, დღეში დაახლოებით 900 MB-ს იმატებს და ლიმიტს დაახლოებით ცხრა დღეში მიაღწევს, რის შემდეგაც სერვერს შენახვა აღარ შეეძლება. lag-ის საჩივარი CPU-ს პრობლემაა; რაც გათიშვას გამოიწვევდა, იყო 14 GB დაუხვეველი log-ები.

როცა გრაფიკი პრობლემის ადგილას არ არის#

ოთხი შემთხვევა, როცა ხაზები პატიოსანია და უსარგებლო:

• ერთ მოთამაშეს ცუდი დრო აქვს. მარშრუტიზაციის პრობლემა ამ მოთამაშესა და მანქანას შორის. გრაფიკები მას ვერ აჩვენებს; traceroute აჩვენებს.
• Stutter წამზე ნაკლებია. სინჯის ინტერვალზე დაბლა, ანუ კონსტრუქციით უხილავი. გამოიყენე თამაშის tick-ის დროები, რომლებიც სწორ გარჩევადობაზე ზომავს. Minecraft-ისთვის ეს არის /mspt და profiler; რატომ ეცემა TPS და რა უნდა გააკეთო გრძელი ვერსიაა.
• სერვერი გარეგან რამეს ელოდება. ბაზას, ვებ API-ს, ლიცენზიის შემოწმებას. CPU დაბალია, მეხსიერება სწორია, ყველაფერი ნელია.
• კლიენტია პრობლემა. განსაკუთრებით მოდიფიცირებულ კლიენტებთან, სადაც მოთამაშის საკუთარი frame rate არის გამოცდილება და სერვერი უდანაშაულოა.

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

FAQ#

ჩემი მეხსიერება 95%-ზეა. უნდა გავაუმჯობესო?

ამ რიცხვით მარტო - არა. თუ ის სერვერის გაშვებიდან 95%-ზე სწორია, ეს წინასწარ დაკავებული heap-ია და კარგადაა. თუ საათებში იზრდება 95%-მდე და შემდეგ სერვერი თავად რესტარტდება, ეს out-of-memory kill-ია და ან heap არის არასწორად დაყენებული, ან მართლა მეტი გჭირდება. სანამ რამეს დახარჯავ, heap-ის პარამეტრი შეადარე container-ის ლიმიტს.

რატომ აჩვენებს CPU 200%-ს, როცა მხოლოდ 2 vCPU მაქვს?

იმიტომ, რომ მაჩვენებელი პროცენტია ერთი ბირთვიდან და არა მთელი შენი განაწილებიდან. ორი vCPU არის 200%, ამიტომ გრაფიკი 200%-ზე არის სრულად გამოყენებული განაწილება და არა ორჯერ გადატვირთული. ეს იგივე კონვენციაა, რასაც top Linux-ზე იყენებს.

CPU-ს ეკლიანი გრაფიკი ცუდია?

ჩვეულებრივ - არა. პიკები არის შენახვები, chunk-ების ჩატვირთვა, backup-ები და დაგეგმილი ამოცანები, რომლებიც თავის საქმეს აკეთებენ. მნიშვნელოვანია, ემთხვევა თუ არა პიკები იმას, რასაც მოთამაშეები ამჩნევენ, და ბრუნდება თუ არა ხაზი ოდესმე ქვემოთ. პლატო პრობლემაა; ღობის მსგავსი ნახაზი მომუშავე სერვერია.

გრაფიკი კარგად ჩანდა, სანამ სერვერი lag-ავდა. რა მოხდა?

ან lag ერთ სინჯზე მოკლე იყო, ან საერთოდ რესურსის პრობლემა არ იყო. Tick-ის lag მილიწამებში ხდება; გრაფიკები წამებში იღებენ სინჯს. გაზომე თამაშის საკუთარი tick-ის დროებით და შეადარე ორი საათი, სანამ დაასკვნი, რომ გრაფიკი გატეხილია.

რამდენ ხანს უნდა ვუყურო გრაფიკს, სანამ რაიმეს გადავწყვეტ?

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

აგვარებს თუ არა რესტარტი მზარდ მეხსიერების ფსკერს?

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