CPU თუ RAM: რომელი აკავებს სინამდვილეში შენს სერვერს

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

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

მეხსიერება ინახავს მდგომარეობას. ჩატვირთულ სამყაროს, მასში არსებულ entity-ებს, chunk cache-ს, plugin-ის მონაცემებს, JVM heap-ს. მეხსიერება წყვეტს, რამდენი შეიძლება ერთდროულად არსებობდეს. მას მკაცრი ზღვარი აქვს: ხაზის ქვემოთ ყველაფერი კარგადაა, ზემოთ პროცესი კვდება. ლიმიტიან კონტეინერზე "მეხსიერება ცოტათი აკლია" არ არსებობს - ან ლიმიტის ქვემოთ ხარ, ან მკვდარი.

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

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

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

მათი გარჩევა ოცდაათ წამში#

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

მეხსიერების სწორად კითხვა#

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

Java სერვერზე JVM heap -Xmx-ით დგება და heap მთელი პროცესი არ არის. Metaspace, thread stack-ები, direct byte buffer-ები, JIT code cache და garbage collector-ის საკუთარი სტრუქტურები მის გარეთ ცხოვრობს. დააყენე -Xmx4G 4 GB კონტეინერში და პროცესი 4 GB-ს გადააჭარბებს და მოკვდება, თამაშის ლოგში არაფრით, რადგან თამაშს მეხსიერება არ გაუთავდა - კონტეინერს გაუთავდა.

# Leave the JVM headroom. On a 6 GB plan:$ java -Xms5G -Xmx5G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \    -XX:MaxGCPauseMillis=200 -XX:+AlwaysPreTouch -XX:+DisableExplicitGC \    -jar paper.jar nogui

გონივრული წესია -Xmx კონტეინერის ლიმიტის 80-85%-ზე, მინიმუმ 512 MB დარჩენილით და სრული გიგაბაიტით ყველაფერზე, რაც mod-ებს შეიცავს. -Xms-ის -Xmx-ის ტოლად დაყენება -XX:+AlwaysPreTouch-თან ერთად ნიშნავს, რომ heap წინასწარ ივსება, ამიტომ მეხსიერების გრაფიკი პირველივე წუთიდან შემაშფოთებლად და ბრტყლად გამოიყურება - ეს სწორია და განზრახ არის და არა leak. Minecraft-ის JVM flag-ები და Java ვერსიები გადის დანარჩენ flag-ებს, ხოლო Node-ის მეხსიერების ლიმიტები ახსნილი ეხება ეკვივალენტურ პრობლემას Node აპლიკაციებისთვის, რომლებსაც საკუთარი, ცალკე heap ჭერი აქვთ.

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

$ free -h                                  # what the system has left$ dmesg -T | grep -i "killed process"      # the kernel's own record of a kill$ journalctl -k | grep -i oom              # same, on a systemd box# With cgroup v2, which is what a container limit actually is:$ cat /sys/fs/cgroup/memory.max            # the limit, in bytes$ cat /sys/fs/cgroup/memory.current        # what is in use right now$ cat /sys/fs/cgroup/memory.events         # oom_kill counts, cumulative

memory.events არის ის, რომელიც უნდა იცოდე. თუ oom_kill ნულზე მეტია, ამ კონტეინერში რაღაც მეხსიერების გამო მოკლეს და ახლა თეორიის ნაცვლად ფაქტი გაქვს. Linux swap და OOM killer არის გრძელი ვერსია.

მეხსიერების გრაფიკის ფორმა გეუბნება, რომელი სახის მეხსიერების პრობლემა გაქვს:

• ადის, შემდეგ ბრტყელდება, ლიმიტზე გაცილებით დაბლა. ჯანსაღია. ასე გამოიყურება სწორად ზომადი სერვერი.
• ლიმიტამდე ადის და იქ რჩება მიჭედებული. ან heap, რომელსაც უთხრეს, რომ ყველაფერი დაეკავებინა, ან ნამდვილი დეფიციტი. შეამოწმე, tick-ის დროც ცუდია თუ არა; მიჭედებული გრაფიკი კარგი tick-ის დროებით ჩვეულებრივ უბრალოდ -Xms-ია.
• ხერხისებრი, ღრმა და ხშირი. Garbage collection ძლიერ მუშაობს, რადგან heap მცირეა სამუშაო სიმრავლისთვის. ეს CPU-ს ხარჯავს და tick-ის დროების ნახტომებად ჩანს.
• ნელა ადის დღეების განმავლობაში და არასოდეს ეცემა. leak, ან სამყარო, რომელიც ნამდვილად ისევ იზრდება. ყოველკვირეული გადატვირთვა მას ფარავს; profiler პოულობს.

CPU-ს სწორად კითხვა#

რიცხვი, რომელსაც უნდა უყურო, არ არის "CPU-ს გამოყენება". ეს არის იმ thread-ის CPU-ს გამოყენება, რომელიც მნიშვნელოვანია, იმ ლიმიტის მიმართ, რომელიც იყიდე.

$ top -H -p $(pgrep -f paper.jar)   # per-thread, not per-process$ uptime                            # load average over 1, 5, 15 minutes$ vmstat 1 5                        # r = runnable, st = stolen by the hypervisor# cgroup v2 again - this is the one that proves throttling:$ cat /sys/fs/cgroup/cpu.max        # quota and period, e.g. "250000 100000"$ cat /sys/fs/cgroup/cpu.stat       # nr_throttled, throttled_usec

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

სამი რამ აბნევს ხალხს აქ:

ოთხბირთვიანი allocation 25%-იანი გამოყენებით შეიძლება მაინც CPU-ს ზღვარზე იყოს. თუ ერთი thread ერთი ბირთვის 100%-ზეა მიჭედებული და სამი ბირთვი უსაქმოა, პროცესის დონის ხედი 25%-ს აჩვენებს. top -H სიმართლეს აჩვენებს. ეს დატვირთული გეიმ სერვერის ნორმალური მდგომარეობაა, რადგან სიმულაცია ერთი thread-ია.

Steal time შენი CPU არ არის. vmstat-ის st სვეტი არის დრო, რომელიც შენს ვირტუალურ CPU-ს სურდა გაეშვა და hypervisor-მა სხვას მისცა. თანმიმდევრულად არანულოვანი steal ნიშნავს, რომ ჰოსტი გადაჭარბებულადაა გაყიდული, და შენს მხარეს არანაირი დარეგულირება არ ეხმარება. გაზიარებული CPU და ხმაურიანი მეზობლები ეხება, რისი გაკეთება შეგიძლია ამის შესახებ.

Load average პროცენტი არ არის. 4.0 ოთხბირთვიან ყუთზე სრულად დაკავებულია; იგივე 4.0 ერთბირთვიან კონტეინერზე ნიშნავს, რომ სამი რამ მუდმივად ელოდება. წაიკითხე ის შენი allocation-ის მიმართ.

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

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

რა უნდა გააკეთო, როცა ეს მეხსიერებაა#

1. პირველ რიგში შეამოწმე `-Xmx` კონტეინერის ლიმიტთან. მეტ გეგმას მოკლავს არასწორად დაყენებული heap, ვიდრე ნამდვილი დეფიციტი. ამის გამოსწორება უფასოა.
2. შეამცირე ის, რაც ჩატვირთულია. შეამცირე view-distance და simulation-distance, შეამოკლე სამყაროს საზღვარი, წინასწარ დააგენერირე და არა ცოცხლად, გაასუფთავე დაგროვილი entity-ები. ყოველი chunk, რომელსაც არ ინახავ, მეხსიერებაა, რომელიც არ გჭირდება.
3. იპოვე leak, სანამ მას გამოკვებავ. მეხსიერება, რომელიც სამუდამოდ იზრდება, plugin ან mod არის. profiler მას წუთებში ასახელებს; უფრო დიდი გეგმა უბრალოდ ვადას გადაწევს.
4. შემდეგ და მხოლოდ შემდეგ იყიდე მეხსიერება. ეს ერთადერთი პრობლემაა, რომელსაც უფრო დიდი გეგმა ნამდვილად წყვეტს, სუფთად და სამუდამოდ.

მეხსიერების პრობლემები გარკვეული აზრით კარგი სახეობისაა: მათ აქვთ განსაზღვრული მიზეზი, განსაზღვრული გამოსწორება და გამოსწორება ფულთან ერთად იზრდება. რამდენი RAM სჭირდება Minecraft სერვერს და რამდენი მოთამაშე ეტევა სერვერზე ორივე ზომის შერჩევას ავლებს.

რა უნდა გააკეთო, როცა ეს CPU-ა#

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

1. იპოვე ძვირი რამ. CPU-ზე მიბმული სერვერების უმეტესობას ერთი მიზეზი აქვს და არა ზოგადი დეფიციტი: mob farm, plugin, რომელიც ყოველ თამაშის tick-ზე მუშაობს, hopper-ების ჯაჭვი, სკრიპტი, რომელიც database query-ს პირდაპირ ასრულებს. სანამ სხვას რამეს გააკეთებ, გააპროფილე - spark profiler Minecraft-ისთვის, სხვა თამაშში - ეკვივალენტი.
2. გააკეთე ნაკლები სამუშაო თითო tick-ზე. შეამცირე simulation distance, შეზღუდე entity-ების რაოდენობა, გაზარდე ინტერვალი ყველაფერზე, რაც დაგეგმილია, ამოიღე plugin-ები, რომლებსაც არ იყენებ. აქ ცხოვრობს დიდი მოგება.
3. გადაიტანე ბლოკირებადი სამუშაო მთავარი thread-იდან. სინქრონული დისკზე ჩაწერა ან პირდაპირი database გამოძახება tick-ის ბიუჯეტს არაფრის კეთებაში ხარჯავს. ასინქრონული შენახვა და pooled კავშირები კონფიგურაციაა და არა აპარატურა.
4. იყიდე საათის სიხშირე და არა ბირთვები. თუ პირველი სამი ნაბიჯი ამოწურულია, დარჩენილი ბერკეტი უფრო სწრაფი ბირთვია. ეს ჩვეულებრივ ნიშნავს სხვა მანქანას და არა უფრო დიდ allocation-ს იმავეზე - dedicated მანქანები არის ადგილი, სადაც CPU-ს მოდელი ნამდვილად სახელდება, რაც ერთადერთი გზაა, საათის სიხშირე ყიდვამდე შეადარო.
5. მიიღე მოთამაშეების ნაკლები რაოდენობა. არაპოპულარულია, პატიოსანია და ზოგჯერ სწორი.

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

გაანალიზებული მაგალითი#

Paper სერვერი 4 GB, 2 vCPU გეგმაზე. ოცი მუდმივი მოთამაშე, ერთი წლის სამყარო, ყოველ საღამოს "ლაგის" შესახებ საჩივრები.

/mspt   -> 48.6/312.4, 44.1/312.4, 29.8/486.0memory  -> pinned at 3.9 GB of 4 GB all dayCPU     -> 185% of an allowed 200%, all evening

წაიკითხე ეს სამი ხაზი ერთად. მეხსიერების გრაფიკი მიჭედებულია, რაც პასუხს ჰგავს - მაგრამ heap დაყენებული იყო -Xms3G -Xmx3G-ით, ამიტომ, რა თქმა უნდა, ის მიჭედებულია, და OOM მოვლენები არ არის. CPU თავისი allocation-ის 92%-ზეა და ერთი thread აკეთებს ყველაფერს. tick-ის საშუალო დრო 50 ms ბიუჯეტის ზღვარზეა, მაქსიმუმი კი მისი თითქმის ათჯერადი.

დიაგნოზი არის CPU, მასზე ნახტომების პრობლემით. 486 ms მაქსიმუმი 29.8 ms საშუალოსგან ცალკე საკითხია: რაღაც დროდადრო ნახევარ წამს ხარჯავს, და ეს ჩვეულებრივ chunk-ის გენერაციაა სამყაროს საზღვარზე ან autosave. profiler-მა ნამდვილი დამნაშავეები დაახლოებით ათ წუთში იპოვა: view-distance=12 სერვერზე, სადაც ექვსზე შორს არავინ იყურება, და 3 000 დაგროვილი item entity ერთ ბაზაში.

გამოსწორება არაფერი დაჯდა. view-distance=8, simulation-distance=6, item-ის despawn ტაიმერი, და tick-ის საშუალო დრო 18 ms-მდე ჩამოვიდა. 4 GB გეგმა არასოდეს ყოფილა პრობლემა. მფლობელს რომ 8 GB ეყიდა, გრაფიკი უფრო ჯანსაღად გამოიყურებოდა და სერვერი ზუსტად ისევე იგრძნობოდა.

სწორი რამის ყიდვა#

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

FAQ#

გახდის მეტი RAM ჩემს სერვერს უფრო სწრაფს?

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

რას ნიშნავს 2 vCPU სინამდვილეში?

ერთი ბირთვის ორასი პროცენტი, როგორც შემზღუდველი. ეს არ ნიშნავს ორ ბირთვს, რომელიც შენთვის არის დაჯავშნილი, და რადგან გეიმ სერვერების უმეტესობა ერთ thread-ზე სიმულირდება, ერთ thread-ს მაინც მხოლოდ ამ allocation-ის 100%-ის გამოყენება შეუძლია. მეორე ბირთვი ფარავს ქსელს, შენახვას, garbage collection-ს და ყველაფერს სიმულაციის გარშემო.

რატომ იყენებს ჩემი სერვერი ყოველთვის 100% CPU-ს?

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

ჩემი ჰოსტი ამბობს 8 GB, Minecraft კი მხოლოდ 6-ს ხედავს. რატომ?

იმიტომ, რომ -Xmx განზრახ კონტეინერის ლიმიტზე დაბლა დაყენდა. JVM-ს heap-ის გარეთ მეხსიერება სჭირდება thread-ებისთვის, metaspace-ისთვის და buffer-ებისთვის, და heap, რომელიც კონტეინერის სრულ ზომაზეა დაყენებული, პროცესს კლავს. 6 GB heap 8 GB კონტეინერში სწორია.

შეცდომის შეტყობინების გარეშე ჩავარდნა ყოველთვის მეხსიერებაა?

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

მეტი ბირთვი უნდა ვიყიდო თუ უფრო სწრაფი ბირთვი?

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