Sons of the Forest-ის სერვერის წარმადობა: RAM, CPU და lag

Sons of the Forest-ის dedicated სერვერს პატარა ჯგუფისთვის დაახლოებით 8 GB მეხსიერება და ორი სწრაფი ბირთვი სჭირდება, ოთხიდან ექვს მოთამაშემდე დამკვიდრებული ჯგუფისთვის - 10 GB, ხოლო რვა მოთამაშით სავსე სერვერისთვის, კვირების განმავლობაში ნათამაშებ სამყაროზე - 12 GB და სამი ბირთვი. ის მძიმეა, რადგან მეხსიერებაში დიდ, დეტალურ სამყაროს ინახავს და ყველა კანიბალს, ცხოველსა და ნაგებობას ერთ მთავარ thread-ზე ასიმულირებს, Linux-ზე კი დამატებით ამძიმებს Windows-ის binary-ის Wine-ით გაშვება. dedicatedserver.cfg-ის ორი გასაღები - ActiveTargetFramerate და IdleTargetFramerate - CPU-ს დატვირთვის უმეტეს ნაწილს განსაზღვრავს, ერთი - SaveInterval - კი იმას, თუ როდის გაჭედავს სერვერი. წარმადობის დანარჩენი ამბავი დროს ეხება: სამი დღის განმავლობაში ჩართული სერვერი იმავე, ახლად გაშვებულ სერვერზე ნელია, ხოლო დაგეგმილი restart უფრო მეტ lag-ს აგვარებს, ვიდრე ნებისმიერი პარამეტრი.

ეს სტატია სერვერის ზომის შერჩევასა და სისწრაფის შენარჩუნებას ეხება. ინსტალაცია, port-ები და config-ის ყველა გასაღები აღწერილია Sons of the Forest-ის dedicated სერვერის გზამკვლევში, Wine-ის მექანიკა კი - სტატიაში Wine და Proton მხოლოდ Windows-ზე მომუშავე სერვერებისთვის. აქ მათ საჭიროზე მეტად არ ვიმეორებთ.

რატომ არის სერვერი მძიმე#

ხალხი ამ თამაშთან The Forest-იდან მოდის, რომლის სერვერი 3 GB-ში მშვიდად ეტეოდა, და უკვირს, რომ გაგრძელებას ამაზე ორჯერ მეტი უნდა. განსხვავებას ოთხი რამ ხსნის.

• სამყარო დიდია და მთლიანად ჩატვირთული. კუნძული პირველი თამაშის კუნძულზე გაცილებით დიდი და მკვრივია, სერვერი კი ინახავს ყველაფრის მდგომარეობას, რაც მასში შეიცვალა: ჩამოჭრილი ხეები, დაგდებული ნივთები, მოკლული მტრები, გახსნილი კონტეინერები, ყველა მორი და ჯოხი ყველა ნაგებობაში. ეს მდგომარეობა იზრდება, რაც ჯგუფი იკვლევს და აშენებს, და სერვერის მუშაობისას არ პატარავდება.
• AI სერვერზე მუშაობს. კანიბალების ჯგუფებს, მუტანტებს, ცხოველებსა და თანამგზავრებს მოთამაშეების მანქანები კი არა, სერვერი ასიმულირებს. რაც მეტი აქტიური მოთამაშეა მეტ ადგილას, მით მეტი AI არის ერთდროულად გაღვიძებული, AI კი ყოველი tick-ის ყველაზე ძვირი ნაწილია.
• მშენებლობა ფიზიკაა. Sons of the Forest-ის თავისუფალი მშენებლობა მზა ელემენტების კი არა, ცალკეული მორებისა და ფიცრების დაწყობაა, ხოლო სტრუქტურული შემოწმებები, რომლებიც წყვეტს, გაუძლებს თუ არა რამე, რეალურ სამუშაოს წარმოადგენს. დიდი ბაზა ათასობით ობიექტია, თითოეული მეხსიერებაში ინახება და ყველა შემოერთებულ client-თან სინქრონიზდება.
• ეს Unity-ის თამაშია, რომელიც client-ისთვის შეიქმნა. Dedicated სერვერი თამაშია, რომლიდანაც renderer ამოღებულია და არა სპეციალურად შექმნილი მსუბუქი სერვერი. ბევრი რამ, რასაც client ინახავს, სერვერის მეხსიერებაშიც რჩება.

არცერთი ეს ხარვეზი არ არის. ეს უბრალოდ ამ თამაშის ფასია და ნიშნავს, რომ დაბალი მეხსიერების ტარიფები, რომლებიც Terraria-ს ან Valheim-ს შეეფერება, არასწორი საწყისი წერტილია. ამ მსჯელობის ზოგადი ვერსია - როგორ გავიგოთ, რაზე ხარჯავს თამაში მეხსიერებასა და CPU-ს - აღწერილია სტატიაში CPU vs RAM თამაშის სერვერებისთვის.

RAM და CPU მოთამაშეების რაოდენობის მიხედვით#

Endnight dedicated სერვერის აპარატურულ მოთხოვნებს არ აქვეყნებს, ამიტომ ქვემოთ მოცემული რიცხვები გეგმარებისთვისაა, სერვერის გაშვების გამოცდილებიდან, და არა ოფიციალური ცხრილი. ისინი მთელ სერვერის პროცესს ეხება და Linux-ზე Wine-ის ფენასაც მოიცავს.

რამდენიმე განმარტება ცხრილის წასაკითხად:

• მეხსიერებას სამყარო განსაზღვრავს უფრო, ვიდრე მოთამაშეების რაოდენობა. ორ მოთამაშეს უზარმაზარი ბაზით შეიძლება ექვს მოთამაშეზე მეტი მეხსიერება დასჭირდეს ახალგაზრდა სამყაროში. მოთამაშეების რაოდენობას მნიშვნელობა იმიტომ აქვს, რომ რაც მეტი ადამიანია კუნძულზე გაფანტული, მით მეტ ნაწილს აღვიძებს ერთდროულად, და ყოველი შემოერთებული მოთამაშე სამყაროს მეტ ნაწილს აქტიურ გამოყენებაში აქცევს.
• 8 GB მინიმუმია და არა კომფორტული შუალედი. ახალი სერვერი მასზე გაცილებით დაბლა მუშაობს უქმად, რაც ხალხს ნაკლების ყიდვაში ცდუნებს. დააკვირდი მას ერთი კვირის თამაშის შემდეგ და არა ერთი საათის შემდეგ.
• CPU ერთ thread-ს ეხება. მთავარი სიმულაციის ციკლი პრაქტიკულად single-threaded-ია, ამიტომ ერთი სწრაფი ბირთვი ოთხ ნელზე მეტს ღირს. დამატებითი ბირთვები ინახავენ სამყაროს, ამუშავებენ ქსელს და BlobSync-ის გადაცემას შემოერთებული მოთამაშეებისთვის, ამიტომაა ორი რეალური მინიმუმი, თუმცა თამაში „მხოლოდ" ერთს იყენებს. თამაშის სერვერის CPU-ს გამოყენების წაკითხვა განმარტავს, რატომ შეიძლება სერვერი ლიმიტზე იყოს, მაშინაც კი, როცა 40 პროცენტს აჩვენებს.
• დისკის სიჩქარე ორ მომენტში მნიშვნელოვანია: სამყაროს ჩატვირთვისას გაშვებისას და ყოველი შენახვისას ჩაწერისას. ინსტალაცია 10-15 GB-ის ფარგლებშია, ხოლო თითო save slot ათეულობით მეგაბაიტია, ამიტომ ტევადობა იშვიათად არის პრობლემა; პრობლემა დაყოვნებაა.

რვა მოთამაშის ლიმიტი თამაშშია ჩაშენებული, ამიტომ „16 მოთამაშის ტარიფზე" ფიქრი არ გჭირდება. თუ ფიქრობ, დაგეხმარება თუ არა უფრო დიდი ტარიფი სერვერს, რომელსაც უკვე აქვს რესურსის მარაგი, - არა, არ დაგეხმარება. ზოგადი არგუმენტისთვის იხილე რამდენი მოთამაშე ეტევა სერვერზე.

frame-rate-ის მიზნები: ActiveTargetFramerate და IdleTargetFramerate#

სერვერს ეკრანი არ აქვს, მაგრამ მაინც ამუშავებს თამაშის ციკლს, და ეს ორი გასაღები განსაზღვრავს, წამში რამდენჯერ ცდილობს ეს ციკლი შესრულებას. ისინი Sons of the Forest-ში tick rate-ის პარამეტრთან ყველაზე ახლოს მდგომია და CPU-ს გამოყენების მთავარი ბერკეტია.

{  "IdleDayCycleSpeed": 0.0,  "IdleTargetFramerate": 5,  "ActiveTargetFramerate": 60,  "SaveInterval": 600}

ყურადღება მიაქციე სახელებს. გზამკვლევები და ფორუმის პოსტები ზოგჯერ ამას „TargetFps"-ს ან „TargetFramerate"-ს ეძახიან; არცერთი ეს გასაღები ფაილში არ არსებობს. სერვერი კითხულობს ActiveTargetFramerate-ს და IdleTargetFramerate-ს, ხოლო JSON config-ში არასწორად დაწერილი გასაღები უგულებელყოფილია და არ უარყოფილია, ამიტომ აქ შეცდომა ზუსტად ისე გამოიყურება, როგორც პარამეტრი, რომელიც არაფერს აკეთებს.

რას აკეთებს უქმი მიზანი

როცა არავინ არის ონლაინ, სერვერი წამში ხუთ ციკლზე ეშვება. ამიტომ ცარიელი Sons of the Forest-ის სერვერი CPU-ს თითქმის არ ხარჯავს, და ამიტომ არის სერვერი, რომელიც ცხელდება, როცა არავინ არის შიგნით, სხვა რამის ნიშანი - მიმდინარე შენახვის, გაჭედილი პროცესის ან Linux-ზე Wine-ის არასწორი მუშაობის. IdleTargetFramerate დატოვე 5-ზე. მისი გაზრდა სარგებელს არ იძლევა: როცა IdleDayCycleSpeed არის 0.0, სამყაროს საათი ცარიელ დროს ისედაც გაყინულია და უფრო სწრაფ უქმ ციკლს არაფერი აქვს გასაკეთებელი.

რას აკეთებს აქტიური მიზანი

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

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

რამდენიმე ზოგადი წესი:

• 60-ზე მეტად ნუ გაზრდი. Client-ებს ამით სარგებელი არ აქვთ, სერვერი კი CPU-ს ხარჯავს, რომელიც ისედაც იშვიათად აქვს ზედმეტი.
• შეამცირე საფეხურებად - 60, შემდეგ 45, შემდეგ 30 - და ყოველ საფეხურზე ითამაშე ერთი სესია. ერთდროულად ერთს ცვლიდე, რომ იცოდე, რომელმა ცვლილებამ უშველა.
• შემცირება მეხსიერებას არ ზოგავს. სამყარო ნებისმიერ frame rate-ზე ერთი ზომისაა. თუ პრობლემა მეხსიერებაშია, ეს გასაღები გამოსავალი არ არის.
• მისი დაყენება command line-იდანაც შეიძლება როგორც -dedicatedserver.ActiveTargetFramerate "30", რაც ბევრ პანელს საშუალებას აძლევს, ფაილის რედაქტირების გარეშე გამოაჩინოს.

ზოგადი იდეა - რას ნიშნავს tick-ის ან frame-ის მიზანი სერვერისთვის და რატომ სჯობს სტაბილური სიხშირე მაღალს - აღწერილია სტატიაში რას ნიშნავს სინამდვილეში tick rate.

Autosave და შენახვის გაჭედვა#

ყოველ SaveInterval წამში - ნაგულისხმევად 600 - სერვერი სამყაროს სერიალიზებას უკეთებს და save slot-ში წერს. ახალგაზრდა სამყაროზე ეს წამებს არ იკავებს. დაძველებულ სამყაროზე დიდი ბაზით ეს შესამჩნევი გაჭედვაა: წამი ან მეტი, როცა სერვერზე ყველაფერი ჩერდება, რასაც მოჰყვება მცირე rubber-band, სანამ client-ები წაუსწრებენ.

ეს გაჭედვა Sons of the Forest-ის სერვერზე „შემთხვევითი lag"-ის ყველაზე გავრცელებული საჩივარია და მისი ნიშანი აქვს: ის რეგულარულია. თუ ხტუნვა ათ წუთში ერთხელ ხდება, საათის თითქმის ერთსა და იმავე წუთზე, ეს შენახვაა. დაადასტურე კონსოლზე იმ მომენტში, როცა ხალხი ჩივის, შენახვის ხაზზე დაკვირვებით.

რისი გაკეთებაც შეგიძლია:

• შეეგუე. ერთი წამის პაუზა ათ წუთში ერთხელ ფასია იმისა, რომ crash-ის დროს ათი წუთის სამუშაო არ დაიკარგოს. უმეტესი ჯგუფი, როცა ეუბნებიან, რა არის ეს, აღარ ამჩნევს.
• გაზარდე ინტერვალი 900-მდე ან 1200-მდე, თუ გაჭედვა მართლა ხელს გიშლის. გაჭედვის სიხშირეს განახევრებ და იმას, რისი დაკარგვაც არასწორი გაჩერებისას შეიძლება, ორმაგდება. ამ კომპრომისს აზრი მხოლოდ საიმედო backup-ებთან და სუფთა restart-ებთან ერთად აქვს.
• ნუ შეამცირებ უსაფრთხოებისთვის დიდ სამყაროზე. 300 სამყაროზე ხუთიათასელემენტიანი ბაზით ყოველ ხუთ წუთში შესამჩნევ პაუზას ნიშნავს.
• სწრაფი დისკი პაუზას ამცირებს, მაგრამ არ აქრობს; დროის დიდი ნაწილი მდგომარეობის შეგროვებასა და სერიალიზებაზე იხარჯება და არა თვითონ ჩაწერაზე. რას ცვლის სინამდვილეში NVMe პატიოსნად ამბობს, სად ეხმარება.

შენახვის ტაიმერების უფრო ფართო კომპრომისები, ამ თამაშისა და სხვებისთვის, აღწერილია სტატიაში თამაშის სერვერის autosave ინტერვალები.

მხოლოდ Windows-ის binary და რას ხარჯავს Wine#

Endnight dedicated სერვერს მხოლოდ Windows-ისთვის აწვდის. Linux-ზე, სადაც თამაშების ჰოსტინგის უმეტესობა მუშაობს, ის Wine-ით (ზოგჯერ Proton-ით) ეშვება, ჩვეულებრივ ვირტუალურ ეკრანთან, მაგალითად Xvfb-თან ერთად, რადგან Unity runtime მას ელის. გამართვა აღწერილია სტატიაში Wine და Proton მხოლოდ Windows-ზე მომუშავე სერვერებისთვის; ზომის შერჩევისას მნიშვნელოვანია ფასი.

• მეხსიერება: რამდენიმეასი მეგაბაიტით მეტი, ვიდრე იგივე სერვერი Windows-ზე გამოიყენებდა, Wine-ის სერვერის პროცესის, ჩატვირთული Windows ბიბლიოთეკებისა და ვირტუალური ეკრანის გამო. 12 GB ტარიფზე ეს უმნიშვნელოა; 8 GB ტარიფზე ეს ნაწილია იმისა, რატომაა 8 GB მინიმუმი.
• CPU: მცირე სტაბილური თამაშისას, რადგან თამაშის კოდი ნატიურად მუშაობს და მხოლოდ system call-ები ითარგმნება. უფრო შესამჩნევია ფაილებით დატვირთულ მომენტებში - გაშვება, სამყაროს ჩატვირთვა და შენახვა - რომლებიც ისედაც იჭედება.
• Log-ის ხმაური: Wine-ის საკუთარი დიაგნოსტიკური გამოტანა შეიძლება ბევრს წერდეს. გარემოში WINEDEBUG=-all-ის დაყენება მას ათიშებს და დატვირთულ სერვერზე CPU-სა და დისკს ცოტას ზოგავს.
• ვერსიებისადმი მგრძნობელობა: თამაშის patch-ს ზოგჯერ უფრო ახალი Wine სჭირდება. თუ სერვერი, რომელიც გლუვად მუშაობდა, განახლებისთანავე იწყებს გაჭედვას ან crash-ს და Windows ჰოსტები იგივეს არ აფიქსირებენ, პირველი ეჭვმიტანილი Wine-ის build-ია.

თვითონ Windows-ზე ეს არაფერი არ ეხება, მაგრამ Windows-ის სერვერი უქმად მეტ მეხსიერებას ხარჯავს, ვიდრე Linux პლუს Wine, ამიტომ Windows-ის მანქანაზე თვითჰოსტინგი ისეთი დანაზოგი არ არის, როგორიც ჩანს. Linux vs Windows თამაშის სერვერები უფრო ფართო შედარებას შეიცავს.

ხანგრძლივი სესიები: რატომ ნელდება სერვერი#

Sons of the Forest-ის სერვერები uptime-თან ერთად უარესდებიან. სერვერი, რომელიც ორშაბათ საღამოს გლუვად მუშაობს, ხუთშაბათისთვის შესამჩნევად უფრო ჭედავს იმავე მოთამაშეებითა და იმავე მოქმედებებით, restart კი მას აბრუნებს. რამდენიმე რამ ხელს უწყობს:

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

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

კარგი restart-ის თანმიმდევრობა:

1. გააფრთხილე მოთამაშეები, თუ შენი ჯგუფი უჩვეულო საათებში თამაშობს. სერვერის მხრიდან broadcast ბრძანება არ არსებობს, ამიტომ ეს Discord-ზე კეთდება.
2. დაანებე სერვერს სუფთად გაჩერება, რომ გასვლისას შეინახოს. არ მოკლა პროცესი.
3. გააკეთე შენახვის backup, როცა ის გაჩერდება, ან restart-მდე მაშინვე.
4. გაუშვი და დაადასტურე, რომ სამყარო მოსალოდნელი slot-იდან ჩაიტვირთა.

RE:NODE-ზე Schedules ტაბი ამას ახორციელებს დალაგებული ამოცანებით cron გამოსახულებაზე - backup, შემდეგ restart power action - backup-ებით, რომლებიც იმ მანქანის გარეთ ინახება, რომელსაც იცავენ. დროისა და სიხშირის არჩევის მიზეზები აღწერილია სტატიაში restart გრაფიკები, რომლებიც ეხმარება.

გრაფიკების წაკითხვა: მეხსიერება თუ CPU#

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

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

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

ნელი სერვერების პრობლემების მოგვარება#

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

ყველა ერთსა და იმავე მომენტში rubber-band-დება, ათ წუთში ერთხელ. ეს autosave-ია დიდ სამყაროზე. შეამოწმე კონსოლი, არის თუ არა შენახვის ხაზი იმ მომენტში, როცა ეს ხდება.

ერთი მოთამაშე ჭედავს და სხვა არავინ. ეს მისი კავშირი ან მისი მანქანაა და არა სერვერი. სერვერის პრობლემა ყველას ერთსა და იმავე ადგილას ერთსა და იმავე დროს ეხება. Latency, jitter და packet loss ეხმარება მათ გაარკვიონ, რომელია.

შემოერთებას რამდენიმე წუთი სჭირდება და სერვერი ჭედავს, სანამ ვინმე უერთდება. შემომავალი მოთამაშე სამყაროს მდგომარეობას BlobSync port-ით იღებს. დაძველებულ სამყაროზე ეს დიდი გადაცემაა და სერვერს მუშაობას ახარჯვინებს, სანამ მიმდინარეობს. ეს ნორმალურია და რაც უფრო დიდია ბაზა, მით უარესია.

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

Frame-ის მიზნის შეცვლამ არაფერი შეცვალა. შეამოწმე გასაღების მართლწერა და ის, რომ ფაილი სწორი JSON-ია. არასწორად აკრეფილი გასაღები ჩუმად უგულებელყოფილია, გაფუჭებული ფაილი კი სერვერს ნაგულისხმევი მნიშვნელობებით აწყებინებს. გაუშვი -verboseLogging-ით, რომ ნახო, რა წაიკითხა.

სერვერი თამაშის განახლებისთანავე გაცილებით ნელი გახდა. ან თვითონ განახლებაა უფრო მძიმე, რაც ხდება და პარამეტრებით ვერ გამოსწორდება, ან Linux-ზე Wine-ის build-ი ჩამორჩა. სანამ შენს მხარეს რამეს შეცვლი, სხვა სერვერის მფლობელებთან შეადარე გამოცდილება.

FAQ#

საკმარისია 8 GB Sons of the Forest-ის სერვერისთვის?

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

აზიანებს თუ არა ActiveTargetFramerate-ის შემცირება თამაშს?

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

რატომ არის ჩემი ცარიელი სერვერის CPU დატვირთვა თითქმის ნულოვანი?

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

ანელებს თუ არა Wine-ში გაშვება სერვერს?

მხოლოდ ოდნავ. თამაშის კოდი ნატიურად მუშაობს; Wine რამდენიმე ასეულ მეგაბაიტ მეხსიერებას და გარკვეულ დამატებით დატვირთვას ამატებს ფაილებით დატვირთულ სამუშაოზე, მაგალითად შენახვაზე. Wine-ზე მომუშავე სერვერზე lag თითქმის ყოველთვის თამაშის საკუთარი დატვირთვაა და არა თარგმანის ფენა.

რამდენად ხშირად უნდა გადავტვირთო Sons of the Forest-ის სერვერი?

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

გახდის თუ არა მეტი CPU ბირთვი სერვერს უფრო სწრაფს?

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