გაზიარებული CPU და ხმაურიანი მეზობლები: რას ქირაობ სინამდვილეში

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

რას ნიშნავს "გაზიარებული" სინამდვილეში#

მანქანის დაყოფის ორი გზა არსებობს და წნეხის ქვეშ ისინი სხვადასხვაგვარად იქცევიან.

სრული ვირტუალიზაცია (KVM, VMware, Hyper-V) ყველა მომხმარებელს აძლევს ვირტუალურ მანქანას ვირტუალური CPU-ებით. vCPU არის thread, რომელსაც hypervisor რეალურ ბირთვზე ამოძრავებს, როცა მოისურვებს. თუ hypervisor-ს 32 thread აქვს და 96 vCPU გაყიდა, ეს 3:1 overcommit-ია და მუშაობს იმიტომ, რომ მომხმარებლების უმეტესობა დროის უმეტეს ნაწილს უქმია. როცა უქმი არ არიან, შენი vCPU რიგში დგას და რეალურ ბირთვს ელოდება, სტუმრის ბირთვი კი ამ ლოდინს steal time-ად აღრიცხავს.

კონტეინერები (Docker, LXC და ყველაფერი, რაც მათზეა აგებული, Pterodactyl-სა და Wings-ის ჩათვლით) ვირტუალურ მანქანას ტოვებენ. ყოველი კონტეინერი პროცესების ჯგუფია ჰოსტის საკუთარ ბირთვზე, namespace-ებით შემოღობილი და cgroup-ებით შეზღუდული. არ არსებობს ვირტუალური CPU, საიდანაც რამეს მოიპარავენ - შენი პროცესები ჰოსტის run queue-შია ყველა დანარჩენის გვერდით, ბირთვის დამგეგმავი კი შენს ლიმიტს უშუალოდ ახორციელებს.

ეს განსხვავება დიაგნოსტიკისთვის მნიშვნელოვანია. VM-ში შეჯიბრს vmstat-ის ერთი სვეტით ზომავ. კონტეინერში steal time თითქმის ყოველთვის ნულია, შეჯიბრი კი დაგეგმვის დაყოვნებად ჩანს, რომელსაც ნაგულისხმევად არაფერი გიჩვენებს. თამაშებისა და აპების ჰოსტინგის უმეტესობა, Pterodactyl-ის ტიპის პანელზე მყოფი ყველაფრის ჩათვლით, კონტეინერის შემთხვევაა.

თავად ლიმიტი ორ ფაილშია. cgroup v2-ზე, რასაც თანამედროვე ბირთვები იყენებენ:

$ cat /sys/fs/cgroup/cpu.max250000 100000$ cat /sys/fs/cgroup/cpu.weight100

cpu.max არის კვოტა და პერიოდი მიკროწამებში: 250,000 მიკროწამი CPU დრო ყოველ 100,000 მიკროწამიან ფანჯარაში, რაც 2.5 ბირთვია. cpu.weight არის პროპორციული წილი, რომელიც გამოიყენება, როცა რამდენიმე cgroup ერთდროულად ითხოვს მანქანას, 1-დან 10,000-მდე სკალაზე, ნაგულისხმევი 100. cgroup v1-ის წარმოდგენებია cpu.cfs_quota_us, cpu.cfs_period_us და cpu.shares (ნაგულისხმევი 1024), და ძველ ჰოსტებზე ისევ შეგხვდება.

სამი გზა, რომლითაც ჰოსტი CPU-ს ყოფს#

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

წონაზე დაფუძნებული გაყიდვიდან მოდის "მაქსიმუმ 4 vCPU" და "burstable". ის გულუხვია, როცა მანქანა მშვიდია, და სწორედ ის წყობაა, რომელიც ხმაურიანი მეზობლების ჩივილებს წარმოქმნის, რადგან შეჯიბრისას ისევე იმას კარგავ, რაც გაყიდვების გვერდზე გაჩვენეს.

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

როგორ გამოიყურება ხმაურიანი მეზობელი შიგნიდან#

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

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

გაზომვა, რომელიც მათ ერთმანეთისგან გამოარჩევს, არის ვარიაცია და არა საშუალო. საშუალო მალავს იმას, რასაც მოთამაშეები ნამდვილად გრძნობენ. თუ შენი თამაში tick-ის დროებს აჩვენებს, გამოიყენე მაქსიმუმი და 99-ე პერცენტილი: Minecraft-ის /mspt ბეჭდავს საშუალოებსა და პიკებს ბოლო ხუთი წამის, წუთისა და ხუთი წუთისთვის, და შეჯიბრი პირველად სწორედ პიკის სვეტში ჩნდება. რას ნიშნავს tick rate სინამდვილეში განმარტავს, რატომ გრძნობა კარგი საშუალო საშინელი პიკით უარესი, ვიდრე საშუალო მოკრძალებული, მაგრამ სტაბილური.

გაზომვა: steal, throttling და pressure#

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

Steal time, თუ ვირტუალურ მანქანაში ხარ. vmstat-ის st სვეტი, mpstat-ის %steal სვეტი და /proc/stat-ში cpu სტრიქონის მერვე ველი:

$ vmstat 1 10          # last column: st$ mpstat -P ALL 1 5    # %steal, per core, needs the sysstat package$ grep '^cpu ' /proc/stat

ნებისმიერი მუდმივი მნიშვნელობა დაახლოებით 5%-ზე ზემოთ ნიშნავს, რომ hypervisor შენს დროს სხვას აძლევს, და შენი მხრიდან არანაირი ტიუნინგი მას ვერ დააბრუნებს. ერთჯერადი ერთნიშნა ნახტომები ნორმალურია.

Throttling, ანუ შენი საკუთარი კვოტის აღსრულება:

$ cat /sys/fs/cgroup/cpu.statusage_usec 8012345678user_usec 6902110004system_usec 1110235674nr_periods 940213nr_throttled 7311throttled_usec 41233905

გაყავი nr_throttled nr_periods-ზე. თუ ერთ პროცენტზე ნაკლებია, უგულებელყავი. თუ 5% ან მეტია, შენი კონტეინერი სამუშაოს შუაში არაერთხელ ჩერდება, და ეს შენ ხარ, რომ საკუთარ ჭერს ეჯახები და არა მეზობელი, რომელიც რამეს წაგართმევს. გამოსავალია ნაკლები სამუშაო ან უფრო დიდი წილის ყიდვა - CPU თუ RAM განიხილავს, რომელი.

Pressure stall information, ანუ ის, რომელიც კონტეინერის შეჯიბრს იჭერს. ბირთვებზე, სადაც PSI ჩართულია:

$ cat /proc/pressure/cpusome avg10=12.44 avg60=9.81 avg300=4.02 total=88213445$ cat /sys/fs/cgroup/cpu.pressuresome avg10=11.90 avg60=9.02 avg300=3.88 total=71004112

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

დაგეგმვის დაყოვნება ერთი პროცესისთვის, თუ ამ გარჩევადობით გინდა. /proc/<pid>/schedstat-ის მეორე ველი არის ნანოწამები, რომლებიც პროცესმა run queue-ში ლოდინში გაატარა, კუმულატიურად პროცესის დაწყებიდან. ამოიღე ორჯერ, ერთი წუთის დაშორებით, და გაყავი ინტერვალზე.

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

$ sysbench cpu --cpu-max-prime=20000 --time=10 --threads=1 run | grep 'events per second'

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

შენი პრობლემა თუ მანქანის#

ბოლო სტრიქონი ხალხს მუდმივად ერევა. ერთი მოთამაშე, რომელსაც საშინელი დრო აქვს, მარშრუტიზაციის ან კავშირის პრობლემაა და არა CPU-სი, და მას უფრო დიდი გეგმა კი არა, latency, jitter და packet loss სჭირდება.

მეზობლები დისკზე, ქსელსა და ქეშში#

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

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

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

მეხსიერების გამტარუნარიანობა და ბოლო დონის ქეში. ნამდვილად უხილავი. შენი მეხსიერების ლიმიტი შენია, მაგრამ მეხსიერებამდე გზა და გაზიარებული L3 ქეში - არა, და მეზობელი დიდი სამუშაო მონაცემთა ნაკრებით შენს ცხელ მონაცემებს ქეშიდან გამოდევნის. ამის წასაკითხი მრიცხველი კონტეინერის შიგნიდან არ არსებობს. ის ჩანს როგორც იგივე დატვირთვა, რომელიც უმიზეზოდ 10-20%-ით მეტს გრძელდება, და ეს ერთ-ერთი მიზეზია, რის გამოც benchmark-ის ვარიაცია გაზიარებულ აპარატურაზე სრულად არასოდეს ნულდება.

რა შეგიძლია ამის წინააღმდეგ გააკეთო#

თანმიმდევრობით, ყველაზე იაფიდან დაწყებული.

1. დაამტკიცე, სანამ კამათს დაიწყებ. ორი გაზომვა ერთმანეთისგან ერთი კვირის დაშორებით, იმავე მეთოდით, მაშინ, როცა პრობლემა ხდება. "ლაგავს" ვერავინ ამუშავებს, შენც ჩათვლით.
2. ჯერ საკუთარი ვარიაცია მოაცილე. garbage collection-ის პაუზა, სინქრონული სამყაროს შენახვა, plugin, რომელიც მთავარ thread-ზე ბაზას მიმართავს, და პიკზე გაშვებული backup ყველა იგივე ტალღოვანობას იძლევა, რასაც მეზობელი. გაასწორე ისინი და რაც დარჩება, ნამდვილად გარეგანია. სერვერის დატვირთვის გრაფიკის კითხვა პირველი გავლაა.
3. გრაფიკები საათის დასაწყისიდან გადაიტანე. ყველა 0 0 * * *-ს ირჩევს. აირჩიე 0 4 * * * ან 17 3 * * * და გაცილებით ნაკლებ ადამიანს ეჯიბრები, შენი ჰოსტის საკუთარი მოვლის ჩათვლით. Cron გამოსახულებები განმარტებით სინტაქსს შეიცავს; დაგეგმილი ამოცანები, რომლებიც ღირს - სიას.
4. გახსენი ticket რიცხვებით. ჰოსტს შეუძლია კონტეინერი უფრო მშვიდ კვანძზე გადაიტანოს, და ჰოსტი, რომელსაც შენი მხრიდან steal-ის ან pressure-ის მონაცემები ხედავს, ამას ჩვეულებრივ დიდი კამათის გარეშე აკეთებს. RE:NODE-ზე პანელიდან ticket ყველა თანამშრომელს აღწევს და კერძო დანართებს იღებს, რაც გრაფიკის screenshot-ისთვის სწორი ადგილია.
5. იყიდე მკაცრი კვოტა და არა burst წილი. თუ გაქვს არჩევანი "მაქსიმუმ 4 vCPU"-სა და "2 vCPU, გარანტირებულს" შორის, მეორე უკეთესი პროდუქტია ყველაფერში, რასაც დაყოვნების ბიუჯეტი აქვს, თუმცა ცარიელ მანქანაზე benchmark-ში უარესია.
6. იყიდე მანქანა. განხილულია ქვემოთ, და ის ნამდვილად ბოლო საშუალებაა და არა პირველი.

რაც არ ეხმარება: nice და renice (ისინი შენს საკუთარ პროცესებს ერთმანეთის მიმართ აწესრიგებენ და არა სხვა მომხმარებლის პროცესების მიმართ), CPU pinning კონტეინერის შიგნიდან, რომელსაც არ ფლობ, და მეტი მეხსიერების ყიდვა. CPU-ს შეჯიბრში მყოფ სერვერზე მეხსიერების დამატება იმ გრაფიკს ცვლის, რომელსაც უყურებ, და არაფერს, რასაც მოთამაშეები გრძნობენ.

როდის ღირს გამოყოფილი ბირთვი#

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

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

• Tick-ის თანმიმდევრულობა პროდუქტია. კომპეტიციური shooter, racing სერვერი, ყველაფერი, სადაც 40 ms ჰიტჩი წაგებული რაუნდია. საშუალო არასოდეს იყო მეტრიკა; უარესი შემთხვევა არის ის, რასაც ხალხი იმახსოვრებს და რის გამოც წავა.
• ვინმეს დაყოვნების ბიუჯეტი დაჰპირდი. API გამოქვეყნებული p99-ით, გადახდის ნაკადი, ყველაფერი, რასაც კონტრაქტი ახლავს. რიცხვს, რომელსაც არ აკონტროლებ, ვერ დაპირდები.
• დატვირთვა ნამდვილად იყენებს რამდენიმე ბირთვს განუწყვეტლივ. კომპილაციები, ვიდეოს კოდირება, მონაცემთა ბაზა პარალელური სკანირებით. გეიმ სერვერების უმეტესობა ასეთი არ არის - სიმულაცია ერთი thread-ია, ამიტომ გამოყოფილი მერვე ბირთვი იმას არ იძლევა, რასაც უფრო სწრაფი პირველი ბირთვი უფრო იაფად მოგცემდა.

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

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

FAQ#

რა არის CPU steal time ზუსტად?

დრო, როცა შენი ვირტუალური CPU გასაშვებად მზად იყო და hypervisor-მა ფიზიკური ბირთვი სხვა სტუმარს მისცა. მას სტუმრის ბირთვი აღრიცხავს vmstat-ში, mpstat-სა და /proc/stat-ში. ის მხოლოდ სრულ ვირტუალიზაციაში არსებობს - კონტეინერის შიგნით hypervisor არ არის, ამიტომ steal ნულია მაშინაც კი, როცა მანქანა მძიმედ არის დატვირთული, და სანაცვლოდ pressure stall information უნდა უყურო.

ნიშნავს თუ არა 2 vCPU, რომ ორი ბირთვი ჩემთვისაა დაჯავშნილი?

თითქმის არასოდეს. კონტეინერზე ეს ნიშნავს ერთი ბირთვის 200%-ს, როგორც throttle-ს: მთლიანი რაოდენობა, რომელიც შენს პროცესებს დაგეგმვის პერიოდში შეუძლიათ გამოიყენონ. ვირტუალურ მანქანაზე ეს ორი დასაგეგმი thread-ია, რომელთაც hypervisor რეალურ ბირთვებზე ათავსებს, როცა ისინი თავისუფალია. არცერთი დაჯავშნა არ არის, თუ ჰოსტი ცალსახად არ ამბობს, რომ ბირთვები მიბმულია.

ჩემი სერვერი 100% CPU-ზე დგას. მალე შემაჩერებენ?

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

შეუძლია თუ არა ხმაურიან მეზობელს ჩემი სერვერის ჩამოგდება?

პირდაპირ - არა. შეჯიბრი აყოვნებს და არა კლავს. რაც მას შეუძლია, არის timeout-ის ლიმიტზე გადაყვანა - watchdog, რომელიც სერვერს კლავს, თუ 60 წამში არ უპასუხა, health check, რომელიც ზედიზედ სამჯერ ვარდება, მონაცემთა ბაზის კავშირი, რომელიც ნებდება. თუ ნელი მუშაობის ნაცვლად ჩავარდნებს ხედავ, ჯერ ნახე რატომ გადაიტვირთება შენი გეიმ სერვერი განუწყვეტლივ; შეჯიბრი იშვიათად არის მთელი ამბავი.

როგორ დავუმტკიცო ჰოსტს?

გაუგზავნე დროის ნიშნულები და რიცხვები: cpu.pressure ან %steal ნიმუშები ცუდი ფანჯრიდან, შენი cpu.stat, რომელიც აჩვენებს, რომ არ იყავი throttle-ში, და tick-ის ან პასუხის დროის გრაფიკი იმავე პერიოდისთვის. ეს კომბინაცია ძნელი სადავოა და ადვილი სამოქმედოდ. ზედსართავები - არა.

ყოველთვის უფრო სწრაფია გამოყოფილი მანქანა?

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