თამაშის სერვერის CPU: რას ნიშნავს 100% ერთ thread-ზე

თამაშის პანელზე CPU ერთი ბირთვის პროცენტებით ითვლება: 100% არის ერთი სრულად დატვირთული ბირთვი, 250% - ორნახევარი. თამაშის სერვერების უმეტესობა სამუშაოს ძირითად ნაწილს ერთ მთავარ thread-ზე აკეთებს, რომელსაც მაქსიმუმ ერთი ბირთვის გამოყენება შეუძლია, ამიტომ სერვერი, რომელიც 250%-იან გეგმაზე სტაბილურ 100%-ს აჩვენებს, ჩვეულებრივ "40%-ზე" კი არ არის - ეს არის მთავარი thread, რომელსაც დრო ამოეწურა, მოთამაშეები კი ამას ლაგად გრძნობენ. მეტი ბირთვის დამატება ამას არაფერს შველის. გეგმის საკუთარ ლიმიტზე მაჩვენებელი კიდევ სხვა რამეს ნიშნავს: კონტეინერი იზღუდება (throttling) იმ წილამდე, რაც მას მიეცა. ამ ორი შემთხვევის ერთმანეთისგან და ორივეს ჯანმრთელი დატვირთვისგან გარჩევა თამაშის სერვერის CPU-ის გრაფიკის წაკითხვის მთელი ხელოვნებაა, და ამას დაახლოებით ერთი წუთი სჭირდება, როცა იცი, რას უნდა შეხედო.

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

როგორ ითვლება CPU-ის პროცენტი#

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

თამაშის პანელები პირველს იყენებს. სერვერს 250 ლიმიტით შეუძლია აჩვენოს ნებისმიერი რამ 0%-დან 250%-მდე, და რიცხვი პირდაპირ ნიშნავს "რამდენი ბირთვის სამუშაო შესრულდა ამ წამში". RE:NODE-ის კატალოგიც ლიმიტს ასე უთითებს - cpu ერთი ბირთვის პროცენტია და მკაცრი ლიმიტი, ამიტომ 2.5 vCPU-ით ჩამოთვლილი გეგმა 250%-იანი ჭერია.

კონვენციას მნიშვნელობა აქვს, რადგან Windows-ის დესკტოპიდან მოსული ხალხი 100%-ს "მაქსიმუმად" კითხულობს, 25%-ს კი "საკმარის მარაგად". პანელზე 100% 250%-იან გეგმაზე შეიძლება გრაფიკზე ყველაზე ცუდი მაჩვენებელი იყოს, 250% კი სავსებით ნორმალური.

რატომ არის თამაშის სერვერების უმეტესობა ერთნაკადიანი იქ, სადაც ეს მნიშვნელოვანია#

თამაშის სერვერი ციკლს ასრულებს. მისი ყოველი გავლა - tick - კითხულობს მოთამაშეების input-ს, ამოძრავებს ყველა ობიექტს, უშვებს AI-ს, ითვლის ფიზიკასა და ბრძოლას და შედეგს უკან აგზავნის. tick უნდა დასრულდეს ფიქსირებული დროის ბიუჯეტში, რომ თამაში განზრახული სიჩქარით მუშაობდეს.

tick-ის შიგნით სამუშაო ძირითადად თანმიმდევრულია: ზომბის მოძრაობა დამოკიდებულია იმაზე, სად წავიდა მოთამაშე, რაც დამოკიდებულია მიღებულ input-ზე, რომელიც თანმიმდევრობით უნდა დამუშავდეს. თამაშის ძრავებს შეუძლიათ და აკეთებენ კიდეც სამუშაოს ნაწილის სხვა thread-ებზე გადატანას - chunk-ების გენერაცია და განათება Minecraft-ში, შენახვა, ქსელი, გზის პოვნა ზოგ Unity-ის თამაშში, ფიზიკა ზოგ Unreal-ის თამაშში - მაგრამ ძირითადი სიმულაცია ერთ thread-ზე ცხოვრობს. როცა ამ thread-ს თავის ბიუჯეტზე მეტი სჭირდება, სერვერი ჩამორჩება, და მის გვერდით უმოქმედო ბირთვების ვერანაირი რაოდენობა ვერ დაეხმარება.

სწორედ ამიტომ თამაშის ჰოსტინგისთვის ყველაზე მნიშვნელოვანი მახასიათებელი ერთი thread-ის სიჩქარეა - რამდენად სწრაფად ასრულებს ერთი ბირთვი სამუშაოს ერთ ნაკადს - და ამიტომაა რას ნიშნავს სინამდვილეში tick rate ამ პოსტის სასარგებლო თანამგზავრი.

გრაფიკის წაკითხვა: ოთხი ფორმა#

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

დაბალი და წვეტიანი

საშუალო 100%-ზე საგრძნობლად დაბალია, წვეტებით, როცა მოთამაშეები შემოდიან, chunk-ები გენერირდება ან სამყარო ინახება. ეს ჯანმრთელია. შენახვის წვეტი 150%-მდე ორი წამით ფონური thread-ია, რომელიც თავის საქმეს აკეთებს, და სწორედ ამისთვისაა დამატებითი ბირთვები.

ბრტყელი დაახლოებით 100%-ზე, როცა გეგმა მეტს იძლევა

სერვერი აჩვენებს სტაბილურ 95-105%-ს გეგმაზე, რომელიც 200%-ს ან 300%-ს უშვებს. ეს არის მნიშვნელოვანი შემთხვევა. ის თითქმის ყოველთვის ნიშნავს, რომ მთავარი thread მთელ ბირთვს უწყვეტად იყენებს - tick-ებს შორის არასოდესაა უქმად, რადგან tick-ს არასოდეს ამთავრებს ადრე. მოთამაშეები ხედავენ ლაგს, rubber-banding-ს ან ეცემა tick rate. გამოსავალი ნაკლები სამუშაოა თითო tick-ზე ან უფრო სწრაფი ბირთვი და არა მეტი ბირთვი.

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

ბრტყელი გეგმის ლიმიტზე

გრაფიკი ზუსტად ლიმიტზეა მიჭედილი - 250% 250%-იან გეგმაზე - და ხაზი ზემოდან ბრტყელია, თითქოს დანით იყოს მოჭრილი. კონტეინერი იმაზე მეტ CPU-ს ითხოვს, ვიდრე ნებადართულია, და იზღუდება. ყველა thread, მთავრის ჩათვლით, ყოველი დაგეგმვის პერიოდის ნაწილში ჩერდება. ეს ის შემთხვევაა, როცა გეგმაზე მეტი CPU ნამდვილად ეხმარება, ან როცა უნდა იპოვო, რა იყენებს ყველა ამ thread-ს - ხშირად სამყაროს გენერაცია, რუკის რენდერერი ან ცუდად მომუშავე plugin საკუთარი thread pool-ით.

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

დღეების განმავლობაში სტაბილურად მზარდი

ნელი ზრდა, რომელიც მხოლოდ restart-ზე ნულდება, თავისთავად CPU-ის პრობლემა არ არის. ჩვეულებრივ რაღაც გროვდება - ობიექტები, დაყრილი ნივთები, მზარდი სია, რომელსაც plugin ყოველ tick-ზე გადაუყვება - და CPU-ის მრუდი სიმპტომია. იპოვე, რა იზრდება; თამაშის სერვერის მეხსიერების გაჟონვა იმავე ნიმუშის მეხსიერების მხარეს განიხილავს.

მთავარი thread-ის თავად პოვნა#

პანელის გრაფიკი ყველა thread-ის ჯამია. იმის სანახავად, ერთი thread არის თუ არა მიჭედილი, თითო thread-ის მაჩვენებლები გჭირდება. shell-ით შენს სერვერზე ან VDS-ზე:

# per-thread view of one process; press H in top to toggle threads$ top -H -p "$(pgrep -f server.jar)"# a one-off list of threads sorted by CPU$ ps -L -o tid,pcpu,comm -p "$(pgrep -f server.jar)" --sort=-pcpu | head# per-thread CPU every second (needs the sysstat package)$ pidstat -t -p "$(pgrep -f server.jar)" 1

Minecraft-ზე მთავარ thread-ს Server thread ჰქვია; Unity-ის თამაშში ის ჩვეულებრივ პროცესის პირველი thread-ია; Source-ის სერვერში ეს თავად პროცესია, რომლის გვერდითაც სულ რამდენიმე სხვაა. თუ ერთი thread 95-100%-ზე დგას და დანარჩენები დაბალია, სერვერი მთავარ thread-ზეა შეზღუდული, მიუხედავად იმისა, რას აჩვენებს ჯამი.

shell-ის გარეშე, რაც პანელზე ჩვეულებრივი შემთხვევაა, გზა თამაშის საკუთარი ხელსაწყოებია. Minecraft-ს საუკეთესო აქვს: spark (ჩაშენებულია Paper-ის ბოლო build-ებში, სხვა შემთხვევაში plugin-ია) აჩვენებს CPU-ს თითო thread-ზე და პროფილს იმისა, ზუსტად რას აკეთებდა მთავარი thread. spark-ის ანგარიშის წაკითხვა ერთს ნაბიჯ-ნაბიჯ განიხილავს.

თამაშის საკუთარი რიცხვები CPU-ის გრაფიკზე უკეთესია#

CPU-ის გრაფიკი ამბობს, რამდენად დაკავებულია მანქანა. მოთამაშეებისთვის მნიშვნელოვანია, ასწრებს თუ არა tick-ები დროულად დასრულებას, და თითქმის ყველა თამაში ამას პირდაპირ აცნობებს.

MSPT - მილიწამები tick-ზე - მათგან ყველაზე მკაფიოა. Minecraft-ის სერვერი 20 TPS-ზე შეიძლება თავისი 50 ms ბიუჯეტიდან 5 ms-ს იყენებდეს ან 49 ms-ს, და TPS-ის რიცხვი მათ ვერ გაარჩევს. MSPT გაარჩევს: 45 ms ნიშნავს, რომ ლაგამდე ერთი დატვირთული საღამოა დარჩენილი, რასაც არ უნდა ამბობდეს CPU-ის გრაფიკი. სადაც შენი თამაში tick-ის მაჩვენებელს გთავაზობს, CPU-ის პროცენტის ნაცვლად მას უყურე.

throttling და როგორ დაამტკიცო#

კონტეინერზე CPU-ის ლიმიტს kernel-ის CPU controller აწესებს. cgroups v2-ით ლიმიტი და throttling-ის მთვლელები კონტეინერის შიგნიდან ჩანს, თუ shell გაქვს, მაგალითად VDS-ზე, სადაც Docker მუშაობს:

$ cat /sys/fs/cgroup/cpu.max250000 100000$ cat /sys/fs/cgroup/cpu.statusage_usec 81234567890user_usec 70123456789system_usec 11111111101nr_periods 4211230nr_throttled 18822throttled_usec 912345678

cpu.max იკითხება როგორც "250,000 მიკროწამი CPU ყოველ 100,000-მიკროწამიან პერიოდზე" - ორნახევარი ბირთვი. cpu.stat-ში nr_throttled ითვლის პერიოდებს, რომლებშიც კონტეინერი ამ ჭერს მიაწყდა და შემდეგ პერიოდამდე შეჩერდა. სიხშირისთვის გაყავი nr_periods-ზე: აქ ის ნახევარ პროცენტზე ნაკლებია, რაც ხმაურია. რამდენიმე პროცენტიანი სიხშირე პიკის საათებში, რომელიც ლაგის მომენტებს ემთხვევა, ნამდვილი throttling-ია. throttled_usec-ის სწრაფი ზრდა, სანამ მოთამაშეები წუწუნებენ, იგივე ამბავია დროში.

throttling tick-ზე დაფუძნებულ თამაშებთან ცუდად თავსდება, რადგან ის აფეთქებებით ხდება. სერვერი, რომელიც მთელ კვოტას 100 ms-იანი პერიოდის პირველ 70 ms-ში იყენებს, შემდეგ 30 ms-ით ჩერდება, და tick, რომელსაც ამ მილიწამებიდან 20 სჭირდებოდა, აგვიანებს. ამიტომ შეუძლია სერვერს აჩვენოს საშუალო, რომელიც ლიმიტზე საგრძნობლად დაბალია, და მაინც შეფერხდეს: ფონური thread-ების მოკლე აფეთქებები კვოტას ამოწურავს და მთავარი thread ელოდება.

რა გააკეთო რეალურად მაღალი CPU-ის შემთხვევაში#

როცა იცი, რომელ შემთხვევაში ხარ, გამოსავალიც გამომდინარეობს.

შეზღუდული მთავარ thread-ზე (ბრტყელი დაახლოებით 100%-ზე). შეამცირე სამუშაო თითო tick-ზე. ეს თამაშზეა დამოკიდებული და ჩვეულებრივ ყველაზე ეფექტური რამაა, რისი გაკეთებაც შეგიძლია:

• Minecraft: view-distance-მდე ჯერ simulation-distance შეამცირე, Paper-ის კონფიგებში ობიექტებსა და redstone-ს ზღვარი დაუწესე, სამყარო წინასწარ დააგენერირე, რომ chunk-ების გენერაცია თამაშის დროს არ ხდებოდეს - ნახე Paper-ის ოპტიმიზაციის გზამკვლევი.
• Valheim: ნაკლები ნაგებობის ნაწილი და ნაკლები რელიეფის ცვლილება ერთ ადგილას; ხარჯი იქ კონცენტრირდება, სადაც მოთამაშეები იკრიბებიან.
• Rust: ობიექტების რაოდენობა და რუკის ზომა სერვერის frame time-ზე მოთამაშეების რაოდენობაზე მეტად მოქმედებს.
• Factorio: მეგაბაზის UPS დიზაინის პრობლემაა და არა ჰოსტინგის - ნაკლები inserter, ლენტი და biter თითო tick-ზე.
• Source: დაბალი tick rate, სადაც თამაში უშვებს, ნაკლები bot, ნაკლები plugin, რომელიც ყოველ frame-ში ერევა.

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

შეზღუდული ლიმიტზე. რაღაც ბევრ thread-ს ერთდროულად იყენებს. გავრცელებული მიზეზებია სამყაროს წინასწარი გენერაცია (Chunky Minecraft-ში რამდენიმე thread-ს სრული სიჩქარით იყენებს), რუკის რენდერერები, როგორიცაა Dynmap და BlueMap, შეკუმშვა backup-ების დროს და plugin-ები საკუთარი pool-ებით. მძიმე სამუშაოები მშვიდ საათებზე დაგეგმე, მათ thread-ების რაოდენობას ზღვარი დაუწესე, სადაც ამის საშუალებას იძლევა, ან უფრო მაღალ გეგმაზე გადადი. RE:NODE-ზე გეგმის აწევა იმავე სერვერზე ლიმიტს ცვლის; თავიდან არაფერი იწყობა.

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

გარჩეული მაგალითი#

Paper-ის სერვერი ოცი მოთამაშისთვის გეგმაზე 300%-იანი ლიმიტით. საჩივრები ლაგზე ყოველ საღამოს, დაახლოებით რვა საათიდან.

1. პანელის გრაფიკი აჩვენებს 105-115%-ს 20:00-დან 23:00-მდე და 30-40%-ს დღისით. ლიმიტთან ახლოსაც არ არის, ამიტომ throttling არ არის.
2. /mspt 21:00-ზე აჩვენებს საშუალოს 48 ms-ს, წვეტებით 90-მდე. მთავარი thread თავის ბიუჯეტზეა.
3. spark-ის პროფილი აჩვენებს tick-ის დროის 40%-ს ობიექტების tick-ში, ძირითადად ორ chunk-ში, და 15%-ს hopper-ებში.
4. ორი chunk არის მობების ფერმა და სოფლელების გამრავლების დარბაზი, ორივე წინა კვირას აშენებული.
5. Paper-ის chunk-ზე ობიექტების ლიმიტები და hopper-ების სიხშირის ცვლილება MSPT-ს პიკზე 28 ms-მდე ამცირებს. CPU-ის გრაფიკი საღამოს ახლა დაახლოებით 70%-ზე დგას.

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

FAQ#

რატომ ლაგავს ჩემი სერვერი, როცა CPU მხოლოდ 300%-დან 100%-ზეა?

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

თამაშის სერვერს მეტი ბირთვი სჭირდება თუ უფრო სწრაფი CPU?

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

შეაჩერებს ჩემი ჰოსტი სერვერს 100% CPU-ის გამოყენების გამო?

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

რატომ იყენებს ჩემი სერვერი CPU-ს, როცა ონლაინ არავინაა?

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

CPU-ის პროცენტი პანელზე იგივეა, რაც Task Manager-ში?

არა. პანელი ერთი ბირთვის პროცენტს ითვლის, ამიტომ 200% ორ ბირთვს ნიშნავს. Task Manager მთელი მანქანის პროცენტს ითვლის. ერთი და იგივე დატვირთვა პანელზე შეიძლება 200% იყოს, Task Manager-ში კი 25%.