Rust-ის სერვერის წარმადობა: entity-ები და FPS

Rust-ის სერვერის ჯანმრთელობა ერთი რიცხვია: მისი frame rate, სიმულაციის tick-ების რაოდენობა, რომელსაც წამში ასრულებს. როცა ის ეცემა, კარები გვიან იღება, მოთამაშეები rubber-band-ს განიცდიან და ბრძოლები უსამართლოდ ჩანს. ყველაზე მეტად მას entity-ების რაოდენობა ამცირებს - ყოველი კედელი, ყუთი, ტურელი, მძინარე მოთამაშე და დაგდებული ნივთი, რომელსაც სერვერი თვალს ადევნებს - და ის wipe-ის დღიდან შემდეგ wipe-მდე იზრდება. ამის შემდეგ მოდის plugin-ები, garbage collection-ის პაუზები და რუკის ზომა. გამოსწორებები, ღირებულების მიხედვით: decay ჩართული დატოვე, რუკის ზომა მოთამაშეების რაოდენობას მოარგე, plugin-ები hook-ების დროის მიხედვით შეამოწმე, garbage collector-ს მარაგი მიეცი, ყოველდღე გადატვირთე და wipe განრიგით გააკეთე. ჯერ serverinfo-თი გაზომვა ამ ყველაფერს გამოცნობიდან საკონტროლო სიად აქცევს.

გაზომვა, სანამ რამეს შეცვლი#

ორი კონსოლის ბრძანება გეუბნება იმის უმეტესობას, რაც გჭირდება.

> server.fps> serverinfo{  "Hostname": "Longship | EU | Biweekly",  "MaxPlayers": 75, "Players": 61, "Queued": 0, "Joining": 1,  "EntityCount": 184213,  "Framerate": 58.0,  "Memory": 11240,  "Collections": 312,  "NetworkIn": 412000, "NetworkOut": 3950000,  "Uptime": 51320}

serverinfo იგივე გამოძახებაა, რომელსაც სტატუსის ბოტები და RCON ინსტრუმენტები იყენებენ, ასე რომ შეგიძლია ყოველ რამდენიმე წუთში ჩაწერო და მთელი wipe-ის მრუდი დაინახო. სტატია Rust RCON და WebRCON ამისთვის მოკლე სკრიპტს შეიცავს. ერთი ნიმუში ცოტას გეუბნება; ერთი კვირის ნიმუშები გეუბნება, lag მოთამაშეების რაოდენობას მიჰყვება, entity-ების რაოდენობას თუ მუშაობის დროს, და თითოეულს სხვადასხვა გამოსწორება აქვს.

რას ნიშნავს სერვერის FPS და რა არის ჯანსაღი#

სერვერი სიმულაციას ციკლში უშვებს და Framerate არის ის, რამდენჯერ სრულდება ეს ციკლი წამში. ეს მოთამაშეების გრაფიკის frame rate არ არის, და სერვერი 30-ზე შეიძლება სრულიად გლუვად იგრძნობოდეს, მაშინ როცა კლიენტი 30-ზე ასე არ იგრძნობოდა.

ეს უხეში დიაპაზონებია და არა წესები - წყნარი PvE სერვერი 25-ზე უფრო ბედნიერია, ვიდრე დატვირთული PvP სერვერი 40-ზე, რომელიც 5-მდე ეცემა. ნახტომები საშუალოებზე მნიშვნელოვანია: სერვერი, რომლის საშუალო 50-ია, მაგრამ ყოველ რამდენიმე წუთში ერთნიშნა რიცხვებამდე ჩერდება, სტაბილურ 30-ზე უარესად იგრძნობა.

სერვერი თავს fps.limit-ის მნიშვნელობაზე ზღუდავს. ზღვრის აწევა ვერ ქმნის წარმადობას, რომელიც არ არსებობს. მისი დაახლოებით 60-მდე დაწევა გაზიარებულ მანქანაზე გონივრულია, რადგან ამის ზემოთ დახარჯული ციკლები მოთამაშეებისთვის ფუჭია და მეზობლებს ართმევს. ზოგად ცნებას განიხილავს სტატია რას ნიშნავს სინამდვილეში tick rate.

entity-ები: მთავარი ხარჯი#

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

ახალ პროცედურულ რუკაზე რაოდენობა ძირითადად გარემო და monument-ებია. შემდეგ მოთამაშეები აშენებენ. დატვირთულ სათემო სერვერს კვირაში ათობით ათასი entity შეიძლება დაემატოს, და სერვერი, რომელმაც wipe კომფორტული frame rate-ით დაიწყო, მას ჭირით ამთავრებს, იმავე აპარატურითა და იმავე მოთამაშეების რაოდენობით. სწორედ wipe აბრუნებს მას თავიდან.

რა ზრდის entity-ებს, დაახლოებით ამ თანმიმდევრობით:

• ბაზები. დიდი კომპლექსები ასობით ბლოკით, გარე კედლებითა და ათობით ყუთით. კლანები მარტოხელებზე მეტს აშენებენ.
• deployable ობიექტები. ყოველი ყუთი, ღუმელი, ქოთანი, აბრა, სანათი და ხაფანგი.
• მიტოვებული ბაზები. decay-ის გარეშე ისინი არასოდეს ქრება.
• ელექტრო და ინდუსტრიული სისტემები. კონვეიერები, სორტერები და გაყვანილობიანი სისტემები entity-ებია, რომლებიც ყოველ tick-ზე სამუშაოსაც აკეთებენ.
• დაგდებული ნივთები და გვამები ბრძოლების შემდეგ, სანამ არ გაქრება.
• თავიანთ ბაზებში მძინარე მოთამაშეები, რომლებიც გასვლის შემდეგ entity-ებად რჩებიან.

entity-ების ზრდის კონტროლი#

• decay და upkeep ჩართული დატოვე. ვანილა decay მიტოვებულ ბაზებს ერთ-ორ დღეში აშორებს; upkeep გიგანტური ბაზების შენახვას ძვირს ხდის. decay.scale 0 თვიურ სერვერზე ბოლო კვირის უთამაშებლად ქცევის ყველაზე საიმედო გზაა. decay-ის პარამეტრებს ხსნის სტატია server.cfg და convar-ები.
• რუკის ზომა მოთამაშეების რაოდენობას მოარგე. უფრო დიდი რუკა მოთამაშეებს მშენებლობისთვის მეტ ადგილს და NPC-ებით სავსე მეტ monument-ს აძლევს. მოთამაშეების ცხრილი მოცემულია სტატიაში საკუთარი რუკები და პროცედურული ზომა.
• wipe საკმარისად ხშირად გააკეთე. თუ წარმადობა მესამე კვირაში ინგრევა, ორკვირიანი რიტმი ამას ნებისმიერ plugin-ზე სუფთად აგვარებს. როგორ მოარგო რიტმები ფორსირებულ განახლებას, განიხილავს სტატია ყოველთვიური ფორსირებული wipe-ის განრიგი.
• შეზღუდე, რისი განთავსებაც შეუძლია ერთ ჯგუფს. მშენებლობის ლიმიტის plugin-ები ზღუდავენ ბლოკებს ან კონკრეტულ deployable ობიექტებს თითო მოთამაშეზე ან თითო Tool Cupboard-ზე. მაღალი gather rate-ის modded სერვერზე ისინი თითქმის სავალდებულოა, რადგან 5x რესურსი 5x ბაზას ქმნის.
• ყველაზე ცუდ დამნაშავეებს პირდაპირ გაუმკლავდი. ადმინს debugcamera-ით შეუძლია იპოვოს კომპლექსი, რომელიც დანარჩენ ყველაფერზე ათჯერ დიდია. მის მფლობელებთან საუბარი ჩვეულებრივ უფრო ეფექტურია, ვიდრე წესი, რომელსაც არავინ კითხულობს.

დასუფთავების plugin-ები, რომლებიც entity-ებს პერიოდულად ტაიმერით შლიან, უკანასკნელი საშუალებაა. ისინი სიმპტომს მკურნალობენ და შლიან იმას, რაც მოთამაშეებისთვის მნიშვნელოვანია, ისეთ მომენტებში, რომლებსაც არ აპატიებენ.

ძვირი ბაზების პოვნა

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

მათი პოვნა ადმინის საქმეა debugcamera-ით ან noclip-ით და ერთი საღამოთი. იფრინე რუკაზე სიმაღლიდან, ჩაინიშნე ყველაზე დიდი კომპლექსები და deployable ობიექტების ყველაზე მჭიდრო მტევნები და შეიხედე მათში, რომლებსაც გაყვანილი ელექტროობა და კონვეიერები აქვთ, რომლებიც ყოველ tick-ზე სამუშაოსაც აკეთებენ. modded სერვერზე ადმინის რადარის plugin-ები ამას ამოკლებს, რადგან ყუთებსა და deployable ობიექტებს კედლებში აჩვენებენ.

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

plugin-ები და hook-ების დრო#

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

Oxide-ზე oxide.plugins თითოეულ plugin-ს მის hook-ებში დახარჯული საერთო დროით ჩამოთვლის. დატვირთული საღამოს შემდეგ ამ დროით დაალაგე. Carbon-ზე ჩაშენებული profiler-ი hook-ებსა და plugin-ებს შენ მიერ არჩეულ ფანჯარაში აღრიცხავს, რაც უკეთესი მტკიცებულებაა. ნიმუშები, რომლებიც სიის თავში ჩნდება:

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

წყნარ საღამოს ჩამოტვირთე საეჭვო და შემდეგ საღამოს, იმავე მოთამაშეების რაოდენობისას, frame rate შეადარე. ბრძანებებს განიხილავს სტატიები Oxide (uMod) plugin-ები და Carbon თუ Oxide.

მეხსიერება და garbage collection#

Rust Unity-ის თამაშია და მისი სათამაშო კოდი managed runtime-ზე მუშაობს garbage collector-ით. როცა სერვერი ობიექტებს გამოყოფს და აგდებს, ნაგავი გროვდება; collection სამუშაოს აჩერებს, რომ ის დაიბრუნოს. ხშირი collection-ები რეგულარულ ჩავარდნებად ჩანს - frame rate მოკლედ ეცემა და აღდგება - ხოლო Collections serverinfo-ში სწრაფად იზრდება.

Rust გთავაზობს gc.buffer-ს, მარაგის რაოდენობას (MB-ში), რომელსაც collector-ი collection-მდე ინახავს. უფრო დიდი buffer ნიშნავს ნაკლებ, უფრო დიდ collection-ს, მეტი გამოყენებული მეხსიერების ფასად. სერვერზე, რომელსაც ზედმეტი მეხსიერება აქვს, მისი აწევა გავრცელებული და ეფექტური ცვლილებაა; სერვერების სახელმძღვანელოები ჩვეულებრივ რამდენიმე ათას მეგაბაიტამდე მნიშვნელობებს იყენებენ. დააყენე ის გაშვების ხაზზე, შეამოწმე შენი build-ის convar-ები find gc.-ით და შემდეგ ადევნე თვალი როგორც ჩავარდნებს, ისე მთლიან მეხსიერებას. buffer-ის აწევა სერვერზე, რომელიც უკვე მეხსიერების ლიმიტთან ახლოსაა, ჩავარდნებს მეხსიერების ამოწურვით გაჩერებაზე ცვლის, რაც უარესია.

მეხსიერება მუშაობის დროსთან და entity-ების რაოდენობასთან ერთადაც იზრდება. აქედან ორი წესი გამომდინარეობს:

1. მეხსიერება wipe-ის ბოლოსთვის შეარჩიე, არა დასაწყისისთვის. სერვერს, რომელიც პირველ დღეს 9 GB-ზეა, მეოცე დღისთვის შეიძლება 14 GB დასჭირდეს.
2. დატვირთული სერვერები ყოველდღე გადატვირთე. წყნარ საათზე დაგეგმილი, წინასწარ გამოცხადებული რესტარტი მეხსიერებას აბრუნებს და დაგროვილ მდგომარეობას ასუფთავებს. როგორ გააკეთო ეს ხალხის გაღიზიანების გარეშე, ხსნის სტატია რესტარტის განრიგები, რომლებიც ეხმარება.

say "Server restart in 10 minutes - find a safe spot"server.saverestart 600 "Daily restart"

CPU, მოთამაშეები და მთავარი ნაკადი#

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

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

NPC-ები, ცხოველები და მოვლენები

CPU-ს ყველა ხარჯი მოთამაშეებიდან არ მოდის. მეცნიერები monument-ებზე, რუკაზე მოხეტიალე ცხოველები, საპატრულო ვერტმფრენი, სატვირთო გემი და სხვა დაგეგმილი მოვლენები ყველა ფიქრობს და მოძრაობს სერვერზე, და მათი ხარჯი რუკასთან ერთად იზრდება: უფრო დიდ სამყაროს მეტი monument და მეტი spawn-ის ფართობი აქვს, შესაბამისად მეტი მათგანიც. უმეტესად ეს სტაბილური ფონური დატვირთვაა და არა პრობლემა, მაგრამ ხსნის, რატომ შეიძლება ცარიელმა დიდმა რუკამ შესამჩნევი CPU გამოიყენოს და რატომ არის მოვლენებით მდიდარი plugin-ები, რომლებიც დამატებით NPC-ებს, raidable ბაზებს ან უფრო ხშირ მოვლენებს ამატებენ, ყველაზე ძვირ რაღაცებს შორის, რისი დაყენებაც შეგიძლია.

თუ ასეთ კონტენტს ამატებ, თითო ნაწილი დაამატე და frame rate მსგავსი მოთამაშეების რაოდენობისას შეადარე მანამდე და მერე. raidable-base plugin-ის ფასი, რომელიც ათობით შეიარაღებულ NPC-ს აჩენს, ძალიან განსხვავებულია წყნარ სამშაბათს და შაბათ საღამოს, როცა ყველა ჯგუფი ონლაინაა.

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

დიაგნოსტიკის ცხრილი#

როცა სერვერი გამუდმებით გადაიტვირთება#

Rust-ის სერვერი, რომელიც თავის მეხსიერების ლიმიტს აჭარბებს, ჩერდება. RE:NODE-ზე კონტეინერს, რომელიც მეხსიერების ლიმიტს აღწევს, kernel აჩერებს და სუფთად გადატვირთავს, ნაცვლად იმისა, რომ swap-ში დატოვოს, ასე რომ სიმპტომი რესტარტია სათამაშო ლოგში სასარგებლო ინფორმაციის გარეშე, და ბოლო შენახვის შემდეგ ყველაფერი იკარგება. ავარიების დამკვირვებელი დაუგეგმავ რესტარტებს ითვლის; საათში სამი სერვერის გვერდზე გაფრთხილებას და ავტომატურ ticket-ს იწვევს. თუ ამას ხედავ, მიზეზი თითქმის ყოველთვის wipe-ის განმავლობაში მეხსიერების ზრდაა, გამოსწორებები კი ზემოთ მოცემულია: decay, რუკის ზომა, ყოველდღიური რესტარტი და ბოლო დღისთვის საკმარისი მეხსიერება. server.saveinterval-ის შემოკლება ზღუდავს, რა უჯდება თითოეული რესტარტი. სხვა მიზეზებს განიხილავს სტატია რატომ გადაიტვირთება შენი სათამაშო სერვერი გამუდმებით.

FAQ#

რა არის კარგი სერვერის FPS Rust-ისთვის?

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

რამდენი entity არის ზედმეტი Rust-ის სერვერისთვის?

ფიქსირებული რიცხვი არ არსებობს; ეს CPU-ზე, plugin-ებსა და იმაზეა დამოკიდებული, რა entity-ებია. სანაცვლოდ ტენდენციას ადევნე თვალი: თუ frame rate ეცემა, როცა EntityCount wipe-ის განმავლობაში იზრდება, entity-ები ამ აპარატურაზე შენი ლიმიტია.

უფრო დიდი რუკა მეტ lag-ს იწვევს?

ირიბად. უფრო დიდი რუკა მეტ რელიეფს, მეტ monument-სა და NPC-ს შეიცავს და მოთამაშეებს მეტი ბაზისთვის ადგილს აძლევს. მოთამაშეების რაოდენობაზე მორგებული, კარგია; ზედმეტად დიდი, ცარიელი სივრცისთვის მეხსიერებასა და CPU-ს ხარჯავს.

ყოველდღე უნდა გადავტვირთო ჩემი Rust-ის სერვერი?

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

ეხმარება Rust-ს ClearLag-ის სტილის დასუფთავების plugin-ები?

იშვიათად, და მოთამაშეებს აღიზიანებს. decay, upkeep, მშენებლობის ლიმიტები და გონივრული wipe-ის რიტმი entity-ებს წყაროშივე აკონტროლებს; ტაიმერით ნივთების წაშლა უკანასკნელი საშუალებაა.