Rust სერვერს სჭირდება დაახლოებით 8-დან 10 GB-მდე მეხსიერება 3000 ზომის რუკისთვის ორმოცდაათამდე მოთამაშით, 12-დან 16 GB-მდე გავრცელებული 3500-4000 რუკებისთვის 75-დან 125 მოთამაშემდე, და 16-დან 24 GB-მდე 4500-ზე მეტი ზომის რუკისთვის იმ პოპულაციით, რომელიც მას შეავსებს. პატარა კერძო სერვერი მეგობრების ჯგუფისთვის 2000-2500 რუკაზე 6-დან 8 GB-მდე მუშაობს. ეს რიცხვები wipe-ის ბოლოსთვისაა და არა დასაწყისისთვის: Rust-ის მეხსიერების გამოყენება ყველაზე დაბალია wipe-იდან ერთი საათის შემდეგ და ყველაზე მაღალი შემდეგი wipe-ის წინა დღეს, რადგან ყოველი კედელი, ყუთი და ღუმელი, რომელსაც მოთამაშეები დგამენ, მეხსიერებაში რჩება, სანამ რუკა არ გასუფთავდება. ზომა ციკლის ყველაზე დატვირთული დღისთვის შეარჩიე, დატოვე მარაგი შენახვისთვის და გახსოვდეს, რომ ახალი რუკის პირველივე გაშვება ყველაზე მძიმე მომენტია.
რას ინახავს Rust სერვერი მეხსიერებაში#
RustDedicated არის Unity სერვერი, რომელიც მართულ .NET heap-ს იყენებს, და თითქმის ყველაფერი, რაც მან იცის, მუდმივად ამ heap-ში ცხოვრობს. Minecraft-ისგან განსხვავებით, ის არ ცლის სამყაროს იმ ნაწილებს, რომელთა ახლოსაც არავინაა. მთელი რუკა და მასზე არსებული ყველა entity გაშვებიდან გათიშვამდე მეხსიერებაშია, ასე რომ მეხსიერებას განსაზღვრავს სამყაროს ზომა და ის, რამდენი აშენდა მასზე, და მხოლოდ სუსტად - რამდენი ადამიანია შემთხვევით ონლაინ.
მთავარი მომხმარებლები არის:
- თავად რუკა. რელიეფის heightmap, splat და topology ფენები, ბიომების მონაცემები, გზებისა და მდინარეების spline-ები და ყოველი monument და prefab. რუკის მეხსიერება
server.worldsize-თან ერთად წრფივზე სწრაფად იზრდება, რადგან ორივე განზომილება იზრდება და დიდ რუკებზე მეტი monument-ია. - Entity-ები. ყოველი სამშენებლო ბლოკი, კარი, ყუთი, ღუმელი, turret, sleeping bag, დაგდებული ნივთი, გვამი, კასრი, node, ცხოველი და NPC არის ქსელური entity. დატვირთულ სერვერზე მომწიფებული wipe მათ ასობით ათასს ინახავს, და სწორედ ეს ხაზი იზრდება ციკლის განმავლობაში.
- ნივთების კონტეინერები. ყოველი ყუთი თავის ნივთებს ობიექტების სახით ინახავს. მოდიფიცირებულ სერვერზე გაზრდილი stack-ის ზომები ნიშნავს ნაკლებ ნივთს, მაგრამ უფრო დიდ რაოდენობებს, მაღალი gather rate კი სამყაროში მეტ ნივთს ჯამში.
- Plugin-ები. Oxide ან Carbon ყოველ plugin-ს იმავე პროცესში ტვირთავს, მათ მონაცემთა ფაილებთან, cache-ებთან და ტაიმერებთან ერთად. უმეტესობა ცოტა ჯდება; ზოგი მეხსიერებაში დიდ სტრუქტურებს ინახავს.
- Garbage collector-ის მარაგი. მართულ heap-ს სამუშაოდ თავისუფალი ადგილი სჭირდება. მისი ზუსტად ლიმიტამდე მიყვანა collection-ებს უფრო ხშირს და ნელს ხდის.
ბოლო პუნქტი ის არის, რასაც ხალხი ყურადღების გარეშე ტოვებს. Rust სერვერი, რომელიც რეალურად 9 GB ცოცხალ მონაცემს ინახავს, 10 GB-იან კონტეინერში კარგად ვერ იმუშავებს, რადგან collector-ს ადგილი სჭირდება, შენახვის პროცესი კი ჩაწერისას მეხსიერებას გამოყოფს.
RAM სამყაროს ზომისა და პოპულაციის მიხედვით#
ეს სამუშაო რიცხვებია vanilla ან მსუბუქად მოდიფიცირებული სერვერისთვის, გაზომილი ყოველკვირეული wipe-ის ციკლის ბოლოს და არა wipe-ის დღეს.
| სამყაროს ზომა | ონლაინ მოთამაშეები | RAM | შენიშვნები |
|---|---|---|---|
| 1500-2500 | 2-10 მეგობარი | 6-8 GB | კერძო სერვერები, მოკლე wipe-ები |
| 3000 | 50-მდე | 8-10 GB | პატარა და მჭიდრო |
| 3500-4000 | 75-125 | 12-16 GB | საზოგადოებრივი სერვერების ჩვეული დიაპაზონი |
| 4500-5000 | 150+ | 16-24 GB | მხოლოდ იმ პოპულაციით, რომელიც მას შეავსებს |
| ნებისმიერი ზომა, მძიმე plugin-ები | - | დაამატე 2-4 GB | დამოკიდებულია იმაზე, რას ინახავენ plugin-ები |
| საკუთარი რუკა ბევრი prefab-ით | - | დაამატე 2-4 GB | დამოკიდებულია რუკის ავტორზე |
ორი გაფრთხილება ცხრილის შესახებ.
მოთამაშეების სვეტი იმის მაჩვენებელია, რამდენი შენდება, და არა პირდაპირი ხარჯი. ყოველი მიერთებული მოთამაშე ამატებს ქსელურ ბუფერებს და ცოტა მდგომარეობას, შესაძლოა ათობით მეგაბაიტს. გიგაბაიტები ჯდება ის, რასაც ისინი აშენებენ. ოცმოთამაშიანი კლანური სერვერი, სადაც ყოველი ჯგუფი აშენებს კომპლექსს კედლებით, turret-ებითა და ოცი დიდი ყუთით, შეიძლება უფრო მეტ მეხსიერებას საჭიროებდეს, ვიდრე ორმოცდაათმოთამაშიანი სერვერი solo მოთამაშეებით, რომლებიც two-by-two-ებში ცხოვრობენ.
სამყაროს ზომის სვეტი არჩევანია და ეს ყველაზე იაფი ბერკეტია, რაც გაქვს. 4500 რუკა ოცდაათი მოთამაშით ძირითადად ცარიელი მიწაა, რომლის მეხსიერებაში შენახვაშიც იხდი, და თანაც უარესად ითამაშება: ხალხი იფანტება, რეიდები ნაკლებად ხდება და სერვერი მკვდარი ჩანს. რუკის ზომა იმ პოპულაციისთვის აირჩიე, რომელიც რეალურად გყავს. Rust-ის wipe-ები მოთამაშეების დაკარგვის გარეშე განიხილავს, როგორ ეწყობა ერთმანეთს რუკის ზომა, რიტმი და პოპულაცია.
რატომ აღწევს მეხსიერება პიკს wipe-ის წინა დღეს#
დახაზე Rust სერვერის მეხსიერება wipe-ის ციკლის განმავლობაში და მიიღებ აღმავალ ხაზს და არა ბრტყელს. Wipe-ის დღე რუკის მინიმუმიდან იწყება. ყოველი საღამო ამატებს ბაზებს, deployable-ებსა და loot-ს. Upkeep და decay ნაწილს აშორებს, მაგრამ აქტიურ სერვერზე ისინი იმაზე ნაკლებს აშორებენ, ვიდრე მოთამაშეები ამატებენ. ციკლის ბოლო დღისთვის სერვერს შეიძლება რამდენიმე გიგაბაიტით მეტი ეჭიროს, ვიდრე პირველ დღეს.
ამას ორი პრაქტიკული შედეგი აქვს.
- ზომას არასოდეს შეარჩევ wipe-ის დღის მიხედვით. სერვერი, რომელიც ხუთშაბათის wipe-ის შემდეგ ხუთშაბათ ნაშუადღევს 55%-ზე დგას, მომდევნო ოთხშაბათს შეიძლება 95%-ზე იყოს. სანამ გადაწყვეტ, რომ გეგმა სწორია, გრაფიკი მთელი ციკლის განმავლობაში შეამოწმე.
- Restart გააკეთე, მაგრამ ნუ ელი, რომ restart მას ჩამოაგდებს. Restart ათავისუფლებს ფრაგმენტაციას და ყველაფერს, რასაც plugin-ი ჟონავდა, რაც ხშირად გიგაბაიტს ან მეტს აბრუნებს. ის entity-ებს არ აშორებს, რადგან ისინი save-იდან თავიდან იტვირთება. ამას მხოლოდ decay, გასუფთავება და თავად wipe აკეთებს.
რუკის გენერაციის ნახტომი#
რუკის wipe-ის შემდეგ პირველი გაშვება მთელ პროცედურულ სამყაროს მეხსიერებაში აწყობს, სანამ დისკზე ჩაწერს, და ეს არის მეხსიერების ყველაზე მაღალი გამოყენება, რასაც სერვერი ოდესმე მიაღწევს. სერვერი, რომელიც დასრულებულ 4000 რუკას იდეალურად დაიტევდა, შეიძლება მისი გენერაციისას მეხსიერებას ამოწურავდეს.
გენერაციის შემდეგ რუკა სერვერის identity საქაღალდეში ინახება:
server/my_server_identity/ proceduralmap.4000.12345.<protocol>.map proceduralmap.4000.12345.<protocol>.sav player.blueprints.<n>.dbფაილის სახელი შეიცავს სამყაროს ზომას, seed-ს და თამაშის protocol-ის ნომერს. ყოველ შემდეგ გაშვებაზე სერვერი გენერაციის ნაცვლად შენახულ .map-ს ტვირთავს, რაც უფრო სწრაფიცაა და მსუბუქიც. თუ protocol იცვლება (იძულებითი wipe-ის განახლება) ან ზომას ან seed-ს შეცვლი, ის თავიდან აგენერირებს.
თუ wipe-ის შემდეგ პირველი გაშვება ვერ ხერხდება, მეორე კი ხერხდება, ან თუ მხოლოდ რუკის შემცირების შემდეგ მუშაობს, სწორედ ამას წააწყდი. გამოსწორებები, თანმიმდევრობით:
- დარწმუნდი, რომ გენერაციისას მეხსიერებას სხვა არაფერი იყენებს: არცერთი plugin, რომელიც ჩატვირთვისას მძიმე სამუშაოს აკეთებს, არც მეორე პროცესი.
- ერთხელ დააგენერირე ისე, რომ ნაკლებ მოთამაშეს შეეძლოს შემოსვლა, და ხალხი მხოლოდ მაშინ შემოუშვი, როცა
.mapფაილი უკვე არსებობს. - შეამცირე
server.worldsize500-ით. მეხსიერების დაზოგვა რეალურია და ამას ცოტა მოთამაშე შეამჩნევს. - დააგენერირე რუკა სადმე, სადაც მეტი მეხსიერებაა, შემდეგ კი ატვირთე
.mapფაილი იგივე ზომით, seed-ით და protocol-ით სახელში.
გაშვების ხაზი, რომელიც ამ ყველაფერს აყენებს, ჩვეულებრივია:
$ ./RustDedicated -batchmode -nographics \ +server.identity "my_server_identity" \ +server.worldsize 4000 +server.seed 12345 \ +server.maxplayers 100 +server.saveinterval 600 \ +rcon.web 1 +rcon.port 28016 +rcon.password "change-me"server.worldsize იღებს მნიშვნელობებს 1000-დან 6000-მდე. Seed ნებისმიერი მთელი რიცხვია. საკუთარი რუკები ზომისა და seed-ის ნაცვლად იყენებენ server.levelurl-ს, რომელიც ჰოსტინგზე განთავსებულ .map ფაილზე მიუთითებს, და მათი მეხსიერება მთლიანად დამოკიდებულია იმაზე, რამდენი prefab განათავსა ავტორმა.
პარამეტრები, რომლებიც აკონტროლებენ, რამდენი შენდება#
რადგან მეხსიერებას entity-ების რაოდენობა განსაზღვრავს, entity-ების რაოდენობის მაკონტროლებელი პარამეტრები მეხსიერების პარამეტრებია, ამას ამბობენ თუ არა.
| Convar | ნაგულისხმევი | გავლენა მეხსიერებაზე |
|---|---|---|
server.worldsize | გაშვებისას დაყენებული | რუკის მინიმუმი და რამდენად შორს იფანტებიან მოთამაშეები |
decay.scale | 1 | 0 თიშავს decay-ს; მიტოვებული ბაზები არასოდეს ქრება |
decay.upkeep | true | Upkeep დიდი ბაზების შენარჩუნებას რესურსების ფასად აქცევს |
server.maxplayers | გაშვებისას დაყენებული | ირიბად: მეტი მშენებელი, მეტი entity |
server.saveinterval | 600 ბოლო build-ებში | რამდენად ხშირად გამოყოფს მეხსიერებას და წერს შენახვა |
ჩაწერე convar-ის სახელი კონსოლში მარტო და ის მის მიმდინარე მნიშვნელობას დაბეჭდავს - ნაგულისხმევები განახლებებს შორის იცვლებოდა, ამიტომ შენი წაიკითხე და ნუ ენდობი რომელიმე ცხრილს.
Gather rate-ისა და stack-ის ზომის plugin-ები მეხსიერების ფორმას უფრო ცვლიან, ვიდრე ზომას. მაღალი gather ნიშნავს, რომ მოთამაშეებს ყველაფერი უფრო ადრე აქვთ და უფრო დიდ კომპლექსებს უფრო ადრე აშენებენ, ასე რომ 3x სერვერი wipe-ის ბოლოს დამახასიათებელ მეხსიერებას დღეებში აღწევს და არა კვირებში. მოდიფიცირებული სერვერები ცხრილში vanilla-ზე ერთი რიგით მაღლა დაგეგმე.
Plugin-ები: Oxide, Carbon და რა ჯდება ისინი#
Oxide (uMod) და Carbon ორივე plugin-ებს კომპილირებული C#-ის სახით სერვერის პროცესში ტვირთავს. თავად framework რამდენიმე ასეულ მეგაბაიტს ამატებს. ცალკეული plugin-ები უზარმაზრად განსხვავდება:
- იაფი: ჩატის ფორმატირება, kit-ები, teleport-ის ბრძანებები, მარტივი ადმინის ხელსაწყოები. თითოეული კილობაიტებიდან რამდენიმე მეგაბაიტამდე.
- ზომიერი: ეკონომიკისა და მაღაზიის plugin-ები, უფლებებით დატვირთული კონფიგურაციები, რომელთა მონაცემთა ფაილებში ათასობით მოთამაშეა, Discord-ის ხიდები.
- ძვირი: ყველაფერი, რაც მთელ რუკაზე თითო entity-ის მონაცემებს აკვირდება, საკუთარი NPC-ებისა და ივენთების plugin-ები, რომლებიც საკუთარ entity-ებს ქმნიან, მთელი რუკის სტატისტიკისა და ლოგირების plugin-ები, რომლებიც ისტორიას მეხსიერებაში ინახავენ, და loot plugin-ები, რომლებიც დამატებით კონტეინერებს ავსებენ.
Plugin-ების მონაცემთა ფაილები oxide/data-ში ცხოვრობს (ან Carbon-ის carbon/data-ში) და plugin-ის გაშვებისას მეხსიერებაში იტვირთება. მონაცემთა ფაილი, რომელიც მოთამაშეების ისტორიის თვეების განმავლობაში ასობით მეგაბაიტამდე გაიზარდა, ყოველ გაშვებაზე მეხსიერების ხარჯია. დროდადრო შეამოწმე მათი ზომები; Rust-ის Oxide და uMod plugin-ები და Carbon თუ Oxide framework-ებს განიხილავს.
საეჭვო plugin-ის ყველაზე სწრაფი ტესტი მოსაწყენია: ჩამოტვირთე ის oxide.unload PluginName-ით (ან Carbon-ზე c.unload-ით), დაელოდე garbage collection-ს და უყურე, ეცემა თუ არა მეხსიერება. შემდეგ თავიდან ჩატვირთე და უყურე, უბრუნდება თუ არა ზევით.
როგორ დაამტკიცო, რომ პრობლემა მეხსიერებაა#
Rust-ის წარმადობის პრობლემები დაახლოებით თანაბრად იყოფა მეხსიერებასა და მთავარ thread-ს შორის, და გამოსწორებები ერთმანეთს არ ფარავს. შეამოწმე, რომელი გაქვს.
- უყურე მეხსიერებას wipe-ის სრული ციკლის განმავლობაში. თუ ბოლო დღეს პიკი ლიმიტიდან 10%-ის ფარგლებშია, ან მეტი მეხსიერება გჭირდება, ან ნაკლები entity.
- შეამოწმე `server.fps` ყველაზე დატვირთულ საათზე. სერვერის დაბალი FPS ლიმიტზე საგრძნობლად დაბალი მეხსიერებით CPU-ს პრობლემაა: entity-ების რაოდენობა, plugin-ები ან AI. მეტი მეხსიერება მას ვერ შეცვლის. თამაშის სერვერის CPU მოთხოვნები აღწერს, რა გააკეთო სანაცვლოდ.
- შეხედე, როგორ ჩერდება სერვერი. Rust სერვერი, რომელსაც კონტეინერში მეხსიერება ეწურება, მეგობრულ შეცდომას არ ბეჭდავს. ლოგი უბრალოდ წყდება, ხშირად შენახვის შუაში, შემდეგი გაშვება კი ტვირთავს იმას, რაც ბოლოს წარმატებით ჩაიწერა. თუ ლოგი exception-ის გარეშე წყდება, შეხედე მეხსიერების გრაფიკს მის წინა წუთებში.
- შეამოწმე შენახვის დრო. სამყაროს ზრდასთან ერთად შენახვა უფრო დიდხანს გრძელდება და მეტ მეხსიერებას გამოყოფს. შენახვა, რომელიც wipe-ის ბოლო დღეს სერვერს რამდენიმე წამით ყინავს, ნიშანია, რომ სამყარო გეგმისთვის დიდია - ხოლო შენახვამ, რომელიც მეხსიერების ლიმიტმა შეწყვიტა, შეიძლება დაზიანებული
.savდატოვოს.
Rust სერვერის წარმადობა და entity-ები უფრო ღრმად განიხილავს entity-ების რაოდენობასა და სერვერის FPS-ს.
Rust-ის გაშვება ნაქირავებ აპარატურაზე#
Rust RE:NODE-ის თამაშების კატალოგში არ არის, ამიტომ Rust-ის გეგმა, რომელზეც მიგითითებდით, არ არსებობს. საზოგადოებრივი სერვერისთვის პატიოსანი პასუხია მანქანა, სადაც მთელი გამოყოფილი რესურსი შენია: VDS ან dedicated სერვერი. 16 GB-იანი მანქანა 3500-4000 რუკის საზოგადოებრივი სერვერისთვის რეალისტური მინიმუმია, როცა ოპერაციულ სისტემას, backup-ის პროცესსა და შენახვის მარაგს გაითვალისწინებ; 24 GB 4500 რუკას სუნთქვის საშუალებას აძლევს. პატარა მეგობრების სერვერი 2000 რუკაზე 8 GB-ში კარგად გრძნობს თავს.
რაზეც არ უნდა გაუშვა, სამი ჩვევა მეხსიერების ამბავს მოსაწყენს ტოვებს:
- დაგეგმილი ყოველდღიური restart მშვიდ საათზე, წინასწარ თამაშში გაფრთხილებით. ის აბრუნებს ფრაგმენტაციასა და plugin-ების გაჟონვებს, და სწორედ ამ დროს ხდება განახლებები და plugin-ების გადატვირთვა სუფთად. Restart-ის განრიგები, რომლებიც გეხმარება დროის შერჩევას აღწერს.
- Backup ყოველი wipe-ისა და ყოველი განახლების წინ. Identity საქაღალდე თავად სერვერია. გააკეთე
server/<identity>-ის და plugin-ების მონაცემებისა და კონფიგურაციის საქაღალდეების backup. - მეხსიერების შემოწმება ყოველი wipe-ის წინა დღეს. სწორედ ეს რიცხვი გეუბნება, შემდეგ ციკლს უფრო პატარა რუკა სჭირდება თუ უფრო დიდი გეგმა.
VDS-ზე იმასაც შენ ირჩევ, რა ხდება ლიმიტზე. Linux-ის out-of-memory killer ყველაზე დიდ პროცესს აირჩევს, ანუ RustDedicated-ს, და მყისიერად მოკლავს. პატარა swap ფაილი გაფრთხილების დროს გაძლევს და არა მოცულობას - Linux-ის swap და OOM killer ხსნის, რატომ არის ცოტა სასარგებლო და ბევრი კი საქმეს აუარესებს.
FAQ#
საკმარისია თუ არა 8 GB Rust სერვერისთვის?
3000 რუკისთვის დაახლოებით ორმოცდაათ მოთამაშემდე, ან უფრო პატარა რუკისთვის მეგობრების ჯგუფისთვის - კი. გავრცელებული 3500-4000 საზოგადოებრივი რუკისთვის ის wipe-ის დღეს იმუშავებს და კვირის ბოლოსთვის გაუჭირდება. თუ 8 GB გაქვს, რუკის ზომა მას მოარგე და არა პირიქით.
იყენებს თუ არა Rust მეტ RAM-ს მეტი მოთამაშით?
პირდაპირ ცოტას, ირიბად ბევრს. ყოველი კავშირი ათობით მეგაბაიტი ჯდება. ის, რასაც მოთამაშეები აშენებენ, გიგაბაიტები ჯდება, მეტი მოთამაშე კი მეტს აშენებს. სერვერის მეხსიერება entity-ების რაოდენობას გაცილებით ზუსტად მისდევს, ვიდრე ონლაინ მყოფთა რიცხვს.
რატომ დაეცა ჩემი Rust სერვერი wipe-ის შემდეგ პირველ გაშვებაზე?
თითქმის დანამდვილებით რუკის გენერაციის გამო. პროცედურული რუკის აწყობას მეტი მეხსიერება სჭირდება, ვიდრე მის გაშვებას, ახალი ზომის ან seed-ის პირველმა გაშვებამ კი ის უნდა დააგენერიროს. შეამცირე სამყარო 500-ით, ან ერთხელ დააგენერირე მეტი მეხსიერებით და შეინახე .map ფაილი.
იყენებენ თუ არა Oxide plugin-ები ბევრ RAM-ს?
Framework რამდენიმე ასეულ მეგაბაიტს ამატებს, plugin-ების უმეტესობა კი ცოტას. უმცირესობას, რომელიც entity-ებს ქმნის, თითო entity-ის მონაცემებს აკვირდება ან მონაცემთა ფაილებში გრძელ ისტორიას ინახავს, wipe-ის განმავლობაში შეუძლია გიგაბაიტები დაამატოს. გასარკვევად ჩამოტვირთე საეჭვო plugin-ი და უყურე მეხსიერების გრაფიკს.
უნდა გავაკეთო თუ არა ჩემი Rust სერვერის restart ყოველდღე?
დატვირთულ სერვერზე - კი. ყოველდღიური restart აბრუნებს ფრაგმენტირებულ მეხსიერებას და plugin-ის ნებისმიერ გაჟონვას, და განახლებებისთვის პროგნოზირებად დროს გაძლევს. ის entity-ების რაოდენობას არ ამცირებს, ასე რომ ვერ გადაარჩენს სერვერს, რომელიც wipe-ის ბოლოს უბრალოდ ზედმეტად პატარაა თავისი რუკისთვის.




კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.