თამაშის სერვერის CPU: სიხშირე თუ ბირთვები

თითქმის ყველა თამაშის სერვერი თავის სიმულაციას ერთ thread-ზე უშვებს, ამიტომ CPU-ს მოთხოვნა არის არა "რამდენი ბირთვი", არამედ "რამდენად სწრაფია ერთი ბირთვი და ჩემია თუ არა ის მაშინ, როცა მჭირდება". ტიპურ სერვერს სჭირდება ერთი სწრაფი ბირთვი მთავარი ციკლისთვის და დამატებით ნახევარიდან ერთ ბირთვამდე შენახვისთვის, ქსელისთვის და garbage collection-ისთვის - სწორედ ამიტომ ფარავს 1.5-დან 2 vCPU-მდე თამაშების უმეტესობას და სწორედ ამიტომ აგებს 8 ნელი ბირთვი 2 სწრაფთან ყოველ ჯერზე. გამონაკლისები რეალურია, მაგრამ ცოტაა: Factorio-ს უზარმაზარი ქარხნები, მძიმედ დასკრიპტული Arma და FiveM სერვერები და მოდიფიცირებული survival თამაშები, რომლებიც პარალელურად სამყაროს აგენერირებენ. ეს პოსტი განმარტავს, რატომ წყვეტს ყველაფერს მთავარი thread, გაძლევს რეალისტურ ბირთვების რაოდენობას თითო თამაშზე და გაჩვენებს, როგორ დაამტკიცო, რომ ზღვარი CPU-ა, სანამ მასში მეტ ფულს გადაიხდი.

სამუშაოს მთავარი thread აკეთებს#

თამაშის სერვერი ციკლია. ყოველ tick-ზე ის კითხულობს მოთამაშეების შეყვანას, ამოძრავებს ყველა entity-ს, ითვლის დარტყმებს, უშვებს სკრიპტებსა და plugin-ებს და თითოეულ კლიენტს უგზავნის snapshot-ს იმისა, რაც შეიცვალა. შემდეგ კი ელოდება შემდეგ tick-ს. ციკლი ფიქსირებული სიხშირით მუშაობს და ყოველი სიხშირე სერვერს თითო tick-ზე დროის ფიქსირებულ ბიუჯეტს აძლევს:

ამ ციკლის მთავარი თვისება ისაა, რომ ის თანმიმდევრულია. B entity-ის მოძრაობა დამოკიდებულია იმაზე, სად აღმოჩნდა A entity, plugin-ის event handler-ი იმ მოვლენის შემდეგ ეშვება, რომელსაც ამუშავებს, snapshot კი მაშინ იწყობა, როცა ყველაფერი დანარჩენი დასრულებულია. ძრავებს შეუძლიათ და ხშირად გადააქვთ კიდეც გვერდითი სამუშაოები სხვა thread-ებზე - chunk-ების ჩატვირთვა, pathfinding-ის მოთხოვნები, შეკუმშვა, დისკზე ჩაწერა - მაგრამ თავად სიმულაცია რიგით უნდა მოხდეს, ერთ thread-ზე, ბიუჯეტის ფარგლებში. როცა ვერ ეტევა, tick გვიანდება, მოთამაშეები კი გვიან tick-ს გრძნობენ როგორც rubber-banding-ს, დაგვიანებულ დარტყმებს და კარებს, რომლებიც ღილაკზე დაჭერიდან ერთი წამის შემდეგ იღება. რას ნიშნავს სინამდვილეში tick rate დეტალურად განიხილავს, როგორ აჩვენებს მას თითოეული ძრავი.

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

რას ყიდულობ სინამდვილეში vCPU-ითა და CPU პროცენტით#

ჰოსტინგი CPU-ს ორი გზით ყიდის და ისინი სხვადასხვა რამეს ნიშნავს.

vCPU ვირტუალურ მანქანაზე ჩვეულებრივ ერთი აპარატული thread-ია. hyper-threading-ის ან SMT-ის მქონე პროცესორზე თითოეული ფიზიკური ბირთვი ორ thread-ს წარმოადგენს, ერთ ბირთვზე ორი დატვირთული thread კი მის შემსრულებელ ბლოკებს იყოფს, ასე რომ თითოეული შესამჩნევად ნაკლებს იღებს, ვიდრე სრული ბირთვია. ზოგი ჰოსტი ერთ vCPU-ს ერთ ფიზიკურ ბირთვად ყიდის, ზოგი კი ერთ thread-ად; წარწერა არ გეუბნება, რომელია.

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

პრაქტიკული შედეგი თამაშისთვის: 1.5 vCPU-ის ლიმიტი არის ერთი სრული ბირთვი მთავარი thread-ისთვის და ნახევარი ბირთვი ყველაფერი დანარჩენისთვის. 2.5 vCPU-ის ლიმიტი არის ერთი სრული ბირთვი და ერთნახევარი ყველაფერი დანარჩენისთვის. ვერცერთი ვერ აქცევს მთავარ thread-ს იმაზე სწრაფად, ვიდრე ერთ ბირთვს შეუძლია. თუ შენი სერვერის მთავარი thread უკვე სრულ ბირთვს იღებს, უფრო მაღალი დონე მხოლოდ მაშინ გეხმარება, თუ "ყველაფერი დანარჩენი" იჭყლიტებოდა - რაც ხდება კიდეც, ძირითადად შენახვისას, სამყაროს გენერაციისას და როცა garbage collector-ი ეშვება.

გაზიარებული CPU და ხმაურიანი მეზობლები კითხვის მეორე ნახევარს ფარავს: შენი წილი დაჯავშნილია თუ ნარჩენი, და როგორ გაზომო steal time სერვერის შიგნიდან.

რამდენ ბირთვს იყენებს სინამდვილეში თითო თამაში#

ეს რეალისტური რიცხვებია ჩვეულებრივი ჯგუფისთვის სტანდარტულ ან მსუბუქად მოდიფიცირებულ სერვერზე. "მთავარი thread" არის სამუშაო, რომლის დაყოფაც შეუძლებელია; "გვერდითი სამუშაო" ის არის, რაც მეორე ბირთვით სარგებლობს.

სამი რამ გამოირჩევა.

პირველი: ცხრილის ქვედა ნაწილი "სუსტი" არ არის. Terraria და Counter-Strike 1.6 მართლაც თანამედროვე ბირთვის მცირე ნაწილს იყენებენ. მათთვის მეტის ყიდვა უსაქმო დროის ყიდვაა.

მეორე: ცხრილის თავში მყოფი თამაშები იქ იმიტომ არიან, რომ მათი გვერდითი სამუშაო დიდია, და არა იმიტომ, რომ სიმულაცია მასშტაბირდება. Rust-ის სერვერი გარკვეული ინტერვალით ათობით ან ასობით მეგაბაიტის save-ს წერს და garbage collector-ს დიდ მართულ heap-ზე უშვებს; ორივეს სჭირდება ბირთვი, რომელიც მთავარი thread არ არის. 7 Days to Die აწყობს chunk-ების mesh-ებს და ბევრი ზომბის AI pathing-ს უშვებს. არცერთი მათგანი მეხუთე ბირთვისგან უფრო სწრაფ tick-ს არ იღებს.

მესამე: ორი თამაში CPU-ს ლიმიტებს მეტი პროცესის გაშვებით წყვეტს და არა მეტი thread-ით. Arma 3 AI-ს headless კლიენტებზე გადააქვს - ეს ცალკე თამაშის პროცესებია, რომლებიც სერვერს მოთამაშეებივით უერთდებიან და AI ჯგუფებს იბარებენ - ასე რომ მისია ასობით AI ერთეულით სამ ან ოთხ ბირთვს სამი ან ოთხი მთავარი thread-ის სახით იყენებს. Arma 3-ის headless კლიენტები აღწერს გამართვას. Don't Starve Together ზედა სამყაროსა და გამოქვაბულებს ორ სერვერულ პროცესად უშვებს, ასე რომ კლასტერი გამოქვაბულებით არის ორი მთავარი thread, რომლებიც ერთ გამოყოფილ რესურსს იყოფენ.

ერთი ბირთვის სიჩქარე: რა შეადარო#

თუ VDS-ისთვის აპარატურას ირჩევ ან ჰოსტებს ადარებ, შეადარე ერთი thread-ის წარმადობა და არა ბირთვების რაოდენობა ან საერთო benchmark-ის ქულა.

• ერთი thread-ის benchmark-ის ქულები (Geekbench single-core, PassMark single-thread, Cinebench single-core) tick-ის დროის ყველაზე ახლო მაჩვენებელია. მრავალბირთვიანი ქულა არასწორ რიცხვს ამრავლებს.
• Boost სიხშირე უფრო მნიშვნელოვანია, ვიდრე საბაზისო, მაგრამ მხოლოდ მაშინ, თუ boost მდგრადია. დესკტოპის პროცესორი, რომელიც ერთ ბირთვს მთელი დღე სრულ boost-ზე ატარებს, სულ სხვანაირად იქცევა, ვიდრე მკვრივი სერვერული პროცესორი, რომლის ყველა ბირთვის სიხშირე დატვირთვისას ერთი გიგაჰერცით დაბალია.
• Cache მნიშვნელოვანია სიმულაციებისთვის. თამაშები ყოველ tick-ზე entity-ებისა და chunk-ების დიდ სიებს გადაუყვებიან; პროცესორი, რომელსაც თითო ბირთვზე მეტი cache აქვს, ამ სიის მეტ ნაწილს ახლოს ინახავს, და სწორედ ამიტომ ჯობნის დიდი cache-ის მქონე ზოგი დესკტოპის პროცესორი თამაშის დატვირთვაზე იმ სერვერულ ჩიპებს, რომლებსაც მეტი ბირთვი აქვთ.
• თაობა მნიშვნელოვანია. ახალი დესკტოპის ბირთვი იმავე სიხშირეზე თითო tick-ში შესამჩნევად მეტს აკეთებს, ვიდრე ხუთი თაობით ძველი. მხოლოდ სიხშირე სხვადასხვა არქიტექტურას შორის შესადარებელი არ არის.

პატიოსანი პასუხი იმ ადამიანების უმეტესობისთვის, ვინც თამაშის სერვერს ქირაობს, ისაა, რომ ზუსტ პროცესორს არ გეტყვიან და ვერც აირჩევ, ასე რომ benchmark, რომელსაც შეგიძლია ენდო, შენი სერვერის tick-ის დროა შენივე დატვირთვისას. RE:NODE-ზე ერთადერთი მითითებული პროცესორის მოდელი Intel i9-9900K-ია VDS-ის ხაზზე; გაზიარებულ თამაშის node-ებს მითითებული მოდელი არ აქვთ, ქვემოთ მოცემული tick-ის დროის მეთოდები კი ნებისმიერ მათგანზე ერთნაირად მუშაობს.

როგორ დაამტკიცო, რომ ზღვარი CPU-ა#

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

წაიკითხე თამაშის საკუთარი tick-ის რიცხვები

ყველა სერიოზული თამაშის სერვერი აჩვენებს, რამდენ ხანს გრძელდება მისი tick-ები. გაიგე, სად აჩვენებს შენი:

• Minecraft: /mspt Paper-ზე ან /spark tps. MSPT დაახლოებით 40-45-ზე მეტი ნიშნავს, რომ სერვერი ზღვართან ახლოსაა; TPS 20-ზე დაბლა ნიშნავს, რომ ზღვარს უკვე გადასცდა.
• Factorio: რიცხვი UPS-ია, რომლის ჩვენებაც მიერთებულ კლიენტს F4-ის debug პარამეტრებით შეუძლია. ქარხანა, რომელიც 60 UPS-ს ვერ ინარჩუნებს, განსაზღვრებით CPU-ზეა მიბმული, და მასთან ერთად ყველა მოთამაშე ნელდება.
• Rust: server.fps აჩვენებს სერვერის მიმდინარე კადრების სიხშირეს. ჯანსაღი სერვერი 30-ზე გაცილებით მაღლა მუშაობს; ის, რომელიც რეიდების დროს ერთნიშნა რიცხვებისკენ ეშვება, მთავარი thread-ის დროს ამოწურავს.
• Arma 3: #monitor 1 ადმინის კლიენტიდან ყოველ წამს ბეჭდავს სერვერის FPS-სა და მეხსიერებას. სერვერის FPS დაახლოებით 20-ზე დაბლა ის წერტილია, სადაც AI და ტრანსპორტი შესამჩნევად იტანჯება.
• Source თამაშები: stats სერვერის კონსოლში აჩვენებს CPU-ს, შემავალ და გამავალ ტრაფიკს, uptime-სა და FPS-ს.
• FiveM: სერვერი საკუთარ კონსოლში გაფრთხილებას წერს, როცა tick ზედმეტად დიდხანს გრძელდება, profiler record კი იჭერს, სად წავიდა დრო.

წაიკითხე გრაფიკი ლიმიტთან მიმართებით

პანელის CPU-ს გრაფიკი გამოყოფილ რესურსთან მიმართებით იზომება. სამი ფორმა, სამი მნიშვნელობა:

1. ბრტყელია ლიმიტზე, მოთამაშეები კი ჩივიან. ჭერი გამოყოფილი რესურსია. უფრო მაღალი დონე დაგეხმარება, თუ არსებობს რეალური გვერდითი სამუშაო, რომელსაც ის შეიწოვს.
2. ლიმიტზე საგრძნობლად დაბლაა, მოთამაშეები კი ჩივიან. მთავარი thread დაახლოებით ერთ ბირთვზეა ამოწურული, ან სხვა რამ არის არასწორად. მეტი გამოყოფილი რესურსი არ დაგეხმარება; დაგეხმარება ნაკლები სამუშაო თითო tick-ზე.
3. რეგულარული ინტერვალებით ხტება. შენახვა, დაგეგმილი ამოცანები ან backup-ები. სანამ რამეს შეცვლი, შეამოწმე, ემთხვევა თუ არა ნახტომები lag-ის შესახებ საჩივრებს.

შეხედე thread-ებს და არა პროცესს

VDS-ზე ან შენს საკუთარ მანქანაზე თითოეული thread-ის ცალკე ნახვა შეგიძლია:

$ top -H -p "$(pgrep -f RustDedicated)"$ pidstat -t -p "$(pgrep -f RustDedicated)" 1

top -H პროცესების ნაცვლად thread-ებს ჩამოთვლის. თუ ერთი thread 98-100%-ზე დგას, დანარჩენები კი თითქმის უსაქმოდ არიან, ეს მთავარი thread-ია და ეს არის ჭერი. pidstat -t (sysstat პაკეტიდან) იმავე სურათს გაძლევს მუდმივად განახლებადი ლოგის სახით, რომელიც დატვირთული საღამოს განმავლობაში შეგიძლია გაშვებული დატოვო. პროცესის სახელი შენი თამაშის binary-ით ჩაანაცვლე. თამაშის სერვერის CPU-ს გამოყენების წაკითხვა ერთი thread-ის სურათს უფრო სიღრმისეულად ხსნის, სერვერის დატვირთვის გრაფიკის წაკითხვა კი პანელის მხარეს ფარავს.

რა ზრდის CPU-ს გამოყენებას მოთამაშეების გაზრდის გარეშე#

CPU-ს პრობლემების უმეტესობას ქმნიან ადამიანები, რომლებიც სერვერს მართავენ, და არა ისინი, ვინც მასზე თამაშობენ. იმის მიხედვით, რამდენად ხშირად ჩნდება:

• Plugin-ები და სკრიპტები. Minecraft-ის plugin-ის ყოველი event handler-ი, ყოველი SourceMod plugin-ი, ყოველი FiveM რესურსი while true ციკლითა და მოკლე ლოდინით მთავარ thread-ზე ეშვება. ერთ ცუდად დაწერილს შეიძლება ოცდაათ მოთამაშეზე მეტი დაუჯდეს. ამისთვის profiler-ები არსებობს - spark, FiveM-ის profiler-ი, SourceMod-ის საკუთარი profiler-ი - და ისინი დამნაშავეს სახელით გეტყვიან.
• Entity-ები. მობების ფერმები, ნივთების გროვები, Rust-ის deployable-ები, Zomboid-ის ზომბების პოპულაცია, ARK-ის მოშინაურებული ცხოველები, 7 Days to Die-ის horde. CPU იზრდება იმის მიხედვით, რისი განახლებაც ყოველ tick-ზეა საჭირო, entity-ების რაოდენობა კი restart-ებს შორის ჩუმად იზრდება.
• სამყაროს გენერაცია. ახალი რელიეფის კვლევა ყველაზე ძვირი რამაა, რასაც survival და sandbox სერვერების უმეტესობა აკეთებს. რუკის წინასწარი გენერაცია (Minecraft-ის Chunky, Rust-ის ფიქსირებული seed-ის რუკები, რომლებიც ერთხელ გენერირდება) ამ ხარჯს მშვიდ საათზე გადაიტანს.
• სიმულაციის მანძილი. Minecraft-ის simulation-distance, 7 Days to Die-ის ServerMaxAllowedViewDistance, DayZ-ის network bubble - ყოველი პარამეტრი, რომელიც აქტიურ არეს აფართოებს, თითო tick-ის სამუშაოს ამრავლებს.
• თავად tick rate. Source თამაშის 128 tick-ზე გაშვება თითო tick-ის ბიუჯეტს 64-თან შედარებით ორჯერ ამცირებს. CS2-ის შეჯიბრებითი სერვერისთვის აზრიც ეს არის; ჩვეულებრივი სერვერისთვის კი ეს არაფერზე დახარჯული CPU-ა.

თითო თამაშის შენიშვნები, რომელთა ცოდნაც ღირს#

Minecraft. Paper chunk-ების ჩატვირთვასა და განათების სამუშაოს ნაწილს მთავარი thread-იდან გადააქვს, სწორედ ამიტომ იყენებს Paper სერვერი ერთზე მეტ ბირთვს ისე, რომ ამას არცერთი პარამეტრი არ ითხოვს. Folia უფრო შორს მიდის და სამყაროს რეგიონებად ყოფს, რომლებიც ცალკე thread-ებზე ასრულებენ tick-ს, მაგრამ plugin-ების უმეტესობას ტეხს; ის დიდი სერვერებისთვისაა, რომლებიც ყველაფერ დანარჩენს გაიზარდნენ. ყველა დანარჩენისთვის Paper-ის ოპტიმიზაცია არის ადგილი, სადაც CPU-ს მოიგებ.

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

Rust. Rust-ის ხარჯი entity-ების რაოდენობაა. სერვერი wipe-ის დღეს და იგივე სერვერი ექვსი დღის შემდეგ სხვადასხვა მანქანაა, რადგან ყოველი სამშენებლო ბლოკი და deployable არის entity, რომელიც სერვერმა მის ახლოს მყოფ ყველას ქსელით უნდა გაუგზავნოს. CPU wipe-ის ციკლის განმავლობაში მეხსიერებასთან ერთად იზრდება.

შუტერები. Counter-Strike 2, TF2 და Insurgency: Sandstorm ფიქსირებულ რუკას ტვირთავენ და მეხსიერებაში ინახავენ; მათი ხარჯი თითო მოთამაშის tick-ის სამუშაოა, რომელიც მცირე და მუდმივია. სტანდარტული CS2 სერვერი ათი მოთამაშისთვის ამას ძლივს ამჩნევს. ცვლის plugin-ები, ბოტები და GOTV.

Unreal ძრავის survival თამაშები. Palworld, ARK, The Front, Satisfactory და Soulmask Unreal-ის გამოყოფილ სერვერს უშვებენ, რომელიც მართლაც იყენებს რამდენიმე thread-ს ქსელისთვის, ჩატვირთვისა და ფიზიკისთვის. მათი მთავარი თამაშის thread მაინც ზღვარია, როცა ბაზები დიდდება, მეხსიერების მადა კი ჩვეულებრივ ისედაც გაიძულებს აირჩიო დონე, რომელსაც საკმარისი CPU აქვს.

CPU-ს წილის არჩევა#

მოკლე გზა გადაწყვეტილებამდე, რომელიც თამაშების უმეტესობისთვის მუშაობს:

1. დაიწყე თამაშისთვის რეკომენდებული წილით: 1-1.5 vCPU მსუბუქი თამაშებისთვის, 2 survival და sandbox თამაშებისთვის, 2.5-3 დიდი მოდიფიცირებული ან დასკრიპტული სერვერებისთვის.
2. ერთი კვირა ატარე რეალური მოთამაშეებით და წაიკითხე თამაშის საკუთარი tick-ის რიცხვები ყველაზე დატვირთულ საათზე და არა საშუალო.
3. თუ tick-ის დრო ჯანსაღია, გაჩერდი. დამატებით CPU-ს წილს ვერავინ იგრძნობს.
4. თუ tick-ის დრო ცუდია და პანელის გრაფიკი გამოყოფილ რესურსზე ბრტყელია, დონე აიწიე. RE:NODE-ზე CPU-ს წილი ყოველ დონესთან ერთად იზრდება, გეგმის შეცვლა კი ლიმიტს უკვე არსებულ სერვერზე ცვლის და მას თავიდან არ აწყობს.
5. თუ tick-ის დრო ცუდია და გრაფიკი გამოყოფილ რესურსზე დაბლაა, ჭერი მთავარი thread-ია. გააკეთე profiling და მოაშორე დატვირთვა; ამას ვერცერთი დონე ვერ გამოასწორებს.

RE:NODE-ის თამაშის გეგმების უმეტესობა 0.5 vCPU-დან, ყველაზე პატარა Terraria-სა და Counter-Strike 1.6-ის დონეებზე, 3.5-მდე მიდის ყველაზე დიდ survival დონეებზე, ხოლო RAM და დისკი მათთან ერთად იზრდება. თამაშის სერვერის მოთხოვნები თამაშების მიხედვით ყველა თამაშის საწყის წერტილს ერთ ცხრილში გაძლევს.

FAQ#

იყენებენ თუ არა თამაშის სერვერები რამდენიმე ბირთვს?

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

ცუდია თუ არა hyper-threading თამაშის სერვერებისთვის?

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

რატომ ლაგავს ჩემი სერვერი, როცა CPU-ს გამოყენება მხოლოდ 40%-ია?

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

გამოასწორებს თუ არა უფრო სწრაფი CPU rubber-banding-ს?

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

რამდენი CPU სჭირდება მოდიფიცირებულ სერვერს?

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