Palworld სერვერი ნელდება მაშინ, როცა მისი ბაზები იზრდება, და არა მაშინ, როცა მოთამაშეების რაოდენობა იზრდება. ყოველი მომუშავე pal ყოველ ბაზის ბანაკში გამუდმებით სიმულირდება, ახლოს ვინმეა თუ არა, და თითოეული გზას ეძებს, მუშაობს, ჭამს, სძინავს და დროდადრო იჭედება. ბერკეტები, რომლებსაც მნიშვნელობა აქვს, PalWorldSettings.ini-შია: BaseCampMaxNumInGuild და BaseCampWorkerMaxNum (რამდენი pal მუშაობს), BaseCampMaxNum (ბანაკების ჯამი მთელ სერვერზე), PalSpawnNumRate (ველური pal-ები) და DropItemMaxNum (მიწაზე დაყრილი ნივთები). სანამ რამეს შეცვლი, გაზომე - REST API სერვერის frame rate-ს აჩვენებს - და ყოველდღე გადატვირთე, რადგან დიდხანს მომუშავე Palworld სერვერი თავისით უარესდება. ეს არის მოკლე შინაარსი. ქვემოთ არის მსჯელობა, რიცხვები და lag, რომელსაც პარამეტრები ვერ გამოასწორებს.
იმავე ამბის მეხსიერების მხარე - რამდენი გიგაბაიტი სჭირდება მოცემულ სამყაროს - აღწერილია Palworld სერვერის მეხსიერებაში. ეს პოსტი იმაზეა, როცა სერვერი ნელად იგრძნობა: pal-ები rubber-band-ობენ, ქმედებები გვიან ჩადის, ბაზები ჩერდება.
რა არის სინამდვილეში lag Palworld სერვერზე#
მოთამაშეები "lag"-ს სამ სხვადასხვა პრობლემას ეძახიან და მათგან მხოლოდ ერთია სერვერი.
| სიმპტომი | სავარაუდო მიზეზი | სად ვეძებოთ |
|---|---|---|
| ყველაფერი ყველასთვის იგვიანებს, pal-ები ტელეპორტირდება, კარები გვიან იღება | სერვერის frame rate დაეცა | REST API-ის მეტრიკები, CPU-ის გრაფიკი |
| ერთი მოთამაშე rubber-band-ობს, დანარჩენებს ყველაფერი რიგზე აქვთ | ამ მოთამაშის კავშირი | მისი ping და packet loss |
| დროდადრო ყველასთვის შეფერხება, შემდეგ ნორმა | autosave Level.sav-ს წერს | AutoSaveSpan, save-ის ზომა |
| სერვერი ჩერდება და log-ში არაფერია | მეხსიერება ამოიწურა | მეხსიერების გრაფიკი დღეების მანძილზე |
სერვერი სიმულაციის ციკლს ატრიალებს. ციკლის ყოველ გავლაზე - frame-ზე - ის ანახლებს ყოველ აქტიურ pal-ს, ყოველ მოთამაშეს, ყოველ ჭურვს და ბაზის ყოველ ამოცანას, შემდეგ კი შედეგებს კლიენტებს უგზავნის. როცა სამუშაო იმაზე მეტია, ვიდრე frame-ში ეტევა, frame-ები გრძელდება და სერვერის frame rate ეცემა. კლიენტები განახლებებს უფრო იშვიათად იღებენ და შუალედში გამოცნობა უწევთ, რაც არის სწორედ ის ტელეპორტაცია და rubber-banding, რასაც ყველა ამჩნევს. ეს სერვერის lag-ია სწორი გაგებით და მას თითქმის ყოველთვის სიმულირებული სამყაროს მოცულობა იწვევს და არა ქსელი.
ერთი მოთამაშის ცუდი კავშირი მისი მხრიდან მსგავსად გამოიყურება, მაგრამ სხვებისთვის უხილავია. Latency, jitter და packet loss არის გზამკვლევი მათ გასარჩევად; თუ მხოლოდ ერთი ადამიანი ჩივის, იქიდან დაიწყე.
სერვერის frame rate-ის გაზომვა#
შეგრძნებით ნუ ააწყობ. REST API-ს აქვს მეტრიკების endpoint, რომელიც სერვერის მიმდინარე frame rate-სა და frame time-ს აბრუნებს მოთამაშეების რაოდენობასთან და uptime-თან ერთად:
$ curl -s -u admin:YOUR_ADMIN_PASSWORD http://203.0.113.10:8212/v1/api/metrics{ "serverfps": 58, "currentplayernum": 7, "serverframetime": 17.2, "maxplayernum": 16, "uptime": 41820}ველები, რომლებიც გაინტერესებს, არის serverfps და serverframetime (მილიწამებში). მოგვიანებით build-ებმა მეტი ველი დაამატა; ძირითადი ველები სტაბილური დარჩა. REST API უნდა ჩაირთოს RESTAPIEnabled=True-ით და უსმენს RESTAPIPort-ს, ნაგულისხმევად 8212 - Palworld-ის ადმინის ბრძანებები და RCON განიხილავს მის ჩართვასა და პრივატულად შენახვას.
მნიშვნელობა აბსოლუტურ რიცხვს კი არა, მის მოძრაობას აქვს. ჩაინიშნე frame rate მშვიდ საღამოს ახალ სამყაროზე, შემდეგ ისევ, როცა ყველა ონლაინაა, შემდეგ კი კვირის შემდეგ იმავე დროს. სერვერი, რომელიც მთელი ჯგუფის ონლაინ ყოფნისას ჩვეულ rate-ს ინარჩუნებს, ჯანმრთელია. სერვერი, რომლის rate-იც ყოველ კვირას ეცემა ბაზების ზრდასთან ერთად, ზუსტად გეუბნება, სად არის პრობლემა. frame rate, რომელიც მკვეთრად ეცემა, როცა ხალხი ერთ ბაზაზე იკრიბება, და აღდგება, როცა მიდიან, ამ ბაზაზე მიუთითებს.
შეუთავსე ეს CPU-ის გრაფიკს. სერვერი CPU-ის ლიმიტზე, როცა frame rate ეცემა, CPU-ზეა შეზღუდული; მეტი CPU ან ნაკლები სიმულაცია უშველის. სერვერი თავისუფალი CPU-ით და დაბალი frame rate-ით შეზღუდულია მთავარი thread-ით, რაც უფრო გავრცელებული შემთხვევაა - ციკლის უმეტესი ნაწილი ერთ thread-ზე მუშაობს, ამიტომ უფრო სწრაფი ბირთვი შველის, მეტი ბირთვი კი - არა. CPU vs RAM სათამაშო სერვერებისთვის და სერვერის დატვირთვის გრაფიკის კითხვა ხსნის, როგორ წაიკითხო ეს.
ბაზის ბანაკები და მუშები: მთავარი ხარჯი#
ბაზის ბანაკი არის ტერიტორია palbox-ით. მასზე მიმაგრებული pal-ები მუშაობენ - მოპოვება, ხის ჭრა, craft-ი, ზიდვა, მიწათმოქმედება - და ეს სამუშაო გამუდმებით სიმულირდება. სამი პარამეტრი ადგენს, რამდენი არსებობს მისგან.
| პარამეტრი | ნაგულისხმევი | რას ზღუდავს |
|---|---|---|
BaseCampMaxNum | 128 | ბაზის ბანაკებს მთელ სერვერზე |
BaseCampMaxNumInGuild | 4 | ბაზის ბანაკებს თითო გილდიაზე |
BaseCampWorkerMaxNum | 15 | მომუშავე pal-ებს თითო ბაზის ბანაკზე |
GuildPlayerMaxNum | 20 | მოთამაშეებს თითო გილდიაზე |
ნაგულისხმევი მნიშვნელობები ვერსიებს შორის იცვლებოდა და BaseCampWorkerMaxNum-ის დასაშვები მაქსიმუმი დროთა განმავლობაში გაიზარდა. ავტორიტეტული სია შენს ინსტალაციაში არსებული DefaultPalWorldSettings.ini-ია.
არითმეტიკა მთელი არგუმენტია. სერვერზე მომუშავე pal-ების რაოდენობა დაახლოებით ასეა: გილდიები გამრავლებული ბანაკებზე თითო გილდიაში, გამრავლებული მუშებზე თითო ბანაკში:
| გილდიები | ბანაკი თითოს | მუშა თითოს | მომუშავე pal-ები |
|---|---|---|---|
| 1 (მეგობრები) | 3 | 15 | 45 |
| 1 (მეგობრები) | 4 | 20 | 80 |
| 4 (პატარა საჯარო) | 4 | 15 | 240 |
| 4 (პატარა საჯარო) | 3 | 12 | 144 |
| 10 (საჯარო, სოლო გილდიები) | 4 | 15 | 600 |
სერვერი 600 მომუშავე pal-ით ყოველ frame-ზე უზარმაზარ სამუშაოს ასრულებს, რამდენიც არ უნდა იყოს ონლაინ. საჯარო სერვერისთვის ყველაზე სწრაფი გაუმჯობესება ჩვეულებრივ არის BaseCampMaxNumInGuild=3 და BaseCampWorkerMaxNum=12: თითქმის არავინ ამჩნევს, სიმულირებული pal-ების რაოდენობა კი მესამედზე მეტით მცირდება.
BaseCampWorkerMaxNum-ის გაზრდა ყველაზე ხშირი თხოვნაა, რასაც მიიღებ, და პატარა პრივატულ სერვერზე ეს ნორმალურია - ერთი გილდია 20 ან 25 მუშით თითო ბანაკზე კარგად ეტევა იმაში, რასაც სერვერი უძლებს. საჯარო სერვერზე ყოველი გილდია ერთსა და იმავე ლიმიტს იღებს, ამიტომ იფიქრე ჯამებით და არა თითო გილდიით.
რატომ ჯდება ზოგი ბაზა სხვებზე ძვირი#
ორ ბაზას pal-ების ერთნაირი რაოდენობით შეიძლება სრულიად განსხვავებული ხარჯი ჰქონდეს. Palworld-ში pal-ები სამუშაომდე გზას ეძებენ და გზის ძებნის ხარჯი ბაზის ფორმაზეა დამოკიდებული.
- მრავალსართულიანი ბაზები კიბეებით, პანდუსებით და ვიწრო დერეფნებით გზის ძებნას ძვირს ხდის და გაჭედილ pal-ებს ჩვეულებრივს. გაჭედილი pal ისევ და ისევ ცდის, ყოველ frame-ზე.
- სამუშაო სადგურები, რომლებიც ბანაკის რადიუსში შორს არის ერთმანეთისგან, ნიშნავს გრძელ სიარულს გზის მრავალჯერადი გადათვლით.
- ბაზები უსწორმასწორო მიწაზე ქმნის pal-ებს, რომლებიც კიდეებიდან ცვივა და დაბრუნებას ძლივს ახერხებს.
- გადაფარული ან გადატვირთული ბანაკები, სადაც სხვადასხვა ბაზის pal-ები ერთმანეთს ხელს უშლის.
თუ frame rate ეცემა, როცა მოთამაშეები ერთ კონკრეტულ ბაზაზე იკრიბებიან, ეს ბაზა კანდიდატია. სთხოვე მის მფლობელს განლაგების გამარტივება: სამუშაო სადგურები ერთ დონეზე, სადაც შესაძლებელია, ფართო გზები, კიბეები პანდუსებით ჩანაცვლებული და palbox ცენტრთან ახლოს. ეს ნებისმიერ პარამეტრზე უკეთესი გამოსავალია და მოთამაშეები ჩვეულებრივ სიამოვნებით აკეთებენ, როგორც კი ხვდებიან, რატომ იჭედება მათი pal-ებიც გამუდმებით.
ველური pal-ები, ნივთები და დანარჩენი სამყარო#
ბაზები ჩამოყალიბებულ სერვერზე ყველაზე დიდი ხარჯია, მაგრამ არა ერთადერთი.
ველური pal-ების spawn-ები. PalSpawnNumRate ადგენს, რამდენ ველურ pal-ს ქმნის სამყარო; ნაგულისხმევია 1.0. დაახლოებით 0.8-მდე შემცირება ამცირებს pal-ების რაოდენობას, რომლებსაც სერვერი აქტიურ ზონებში სიმულირებს. გაზრდა სამყაროს უფრო ცოცხლად აგრძნობინებს და პროპორციულად ჯდება. ეს დაჭერასა და farming-ზეც მოქმედებს, ამიტომ შეცვლამდე მოთამაშეებს უთხარი.
დაგდებული ნივთები. DropItemMaxNum ზღუდავს, რამდენი ნივთი შეიძლება ერთდროულად ეგდოს მიწაზე, ხოლო DropItemAliveMaxHours ადგენს, რამდენ ხანს ძლებს თითოეული. დატვირთულ სერვერზე დაგდებული ნივთები სწრაფად გროვდება - სიკვდილებიდან, სავსე ინვენტარებიდან, pal-ებიდან - და თითოეული ობიექტია. ლიმიტის განახევრება იშვიათად ვინმეზე მოქმედებს და თითქმის უფასო წარმადობაა.
raid-ები. bEnableInvaderEnemy ბაზებზე raid-ებს რთავს ან თიშავს. raid ბაზაზე მტრების ჯგუფს ქმნის და დამატებითი სიმულაციის მოკლე აფეთქებაა. სერვერზე, სადაც რამდენიმე ბაზას ერთდროულად ესხმიან თავს, ეს ვარდნად ჩანს. ჯგუფების უმეტესობა raid-ებს ჩართულს ტოვებს, რადგან ისინი თამაშის ნაწილია; გათიშვა ვარიანტია, თუ სერვერი ძლივს უძლებს.
ხედვის მანძილი. მოგვიანებით build-ებმა დაამატა ServerReplicatePawnCullDistance, რომელიც აკონტროლებს, რა მანძილიდან უგზავნის სერვერი თითოეულ კლიენტს სხვა მოთამაშეებსა და pal-ებს. შემცირება ქსელისა და რეპლიკაციის სამუშაოს ამცირებს; გაზრდა შორეულ ობიექტებს უფრო ადრე ხილულს ხდის. დამატებამდე შეამოწმე, აქვს თუ არა ის შენს ვერსიას.
ნაგებობების რაოდენობა. ბოლო build-ებს აქვთ ნაგებობების შეზღუდვის პარამეტრი (მოძებნე MaxBuildingLimitNum შენი ვერსიის ნაგულისხმევ მნიშვნელობებში). ყოველი კედელი, იატაკი და ზანდუკი ობიექტია save-ში და მეხსიერებაში; ლიმიტი ყველაზე უხეში გზაა, რომ საჯარო სამყარო მეგა-ბაზების შეჯიბრად არ იქცეს.
გადატვირთვები და ნელი დეგრადაცია#
Palworld სერვერი, რომელიც ყოველდღე გადაიტვირთება, უკეთ მუშაობს, ვიდრე კვირით ჩართული დატოვებული, თუნდაც იმავე სამყაროთი. ხანგრძლივი uptime-ის განმავლობაში მეხსიერება იზრდება, სიმულაციის წვრილმანი პრობლემები გროვდება (კედლებში გაჭედილი pal-ები, ნივთები, რომლებიც არასოდეს გაქრა) და frame rate თანდათან ეცემა. გადატვირთვა ამ ყველაფერს ასუფთავებს; სამყარო ბოლო save-იდან თავიდან იტვირთება და ყველაფერი სუფთად იწყება.
ყოველდღიური გადატვირთვა იმ საათზე, როცა არავინ თამაშობს, Palworld-ისთვის ჩვეულებრივი პრაქტიკაა. ჯერ მოთამაშეები Broadcast-ით გააფრთხილე, შეინახე Save-ით, შემდეგ გადატვირთე. RE:NODE-ზე Schedules ჩანართი ამ თანმიმდევრობას cron გამოსახულებით ასრულებს - გაფრთხილება, ლოდინი, შენახვა, backup და გადატვირთვა - დალაგებული ამოცანების სახით, ასე რომ გახსენება არავის სჭირდება. გადატვირთვის განრიგები, რომლებიც შველის დროის შერჩევას განიხილავს, ხოლო Palworld-ის backup-ები და სამყაროს reset - backup-ის იმავე განრიგში ჩასმას.
თუ სერვერს თამაშვარგისად დარჩენისთვის დღეში ერთზე მეტი გადატვირთვა სჭირდება, სამყარო სერვერისთვის ძალიან დიდია. ეს არჩევანია მეტ რესურსსა და ნაკლებ სამყაროს შორის და არა მიზეზი ყოველ ექვს საათში გადატვირთვისთვის.
autosave-ის შეფერხებები#
AutoSaveSpan ადგენს, რამდენად ხშირად ჩაიწერება სამყარო Level.sav-ში, წამებში. დიდი save-ის ჩაწერას დრო სჭირდება და მომწიფებულ სამყაროზე ხილულ შეფერხებას იწვევს. ნაგულისხმევი მოკლეა - ოცდაათი წამი - რაც ზღუდავს, რამდენი დაიკარგება ქრაშისას, მაგრამ დიდ სამყაროზე ხშირ შეფერხებებს ნიშნავს. 180-მდე ან 300-მდე გაზრდა თამაშს არბილებს; ფასი არის ამდენამდე წამის დაკარგვა, თუ სერვერი უწესრიგოდ გაჩერდება. სტაბილურ სერვერზე უფრო გრძელი ინტერვალი ჩვეულებრივ უკეთესი გარიგებაა.
სწრაფი საცავი შეფერხებას ამოკლებს, მაგრამ არ აქრობს, რადგან ხარჯი ნაწილობრივ სამყაროს სერიალიზაციაა და არა მხოლოდ ჩაწერა. RE:NODE მთლიანად NVMe-ზე მუშაობს, რაც ჩაწერის ნახევარში შველის.
მორგების რიგი, რომელიც მუშაობს#
როცა სერვერი ნელია, შეცვალე რამეები ამ რიგით და თითოეულის შემდეგ გაზომე:
- გადატვირთე. თუ წარმადობა ნორმას უბრუნდება და დღეების მანძილზე ისევ უარესდება, დაამატე ყოველდღიური გადატვირთვა და იქვე გაჩერდი.
- შეამოწმე მეხსიერება. სერვერი, რომელიც ლიმიტთან ახლოსაა, ცუდად იქცევა, სანამ ამოიწურება. თუ პრობლემა მეხსიერებაა, წაიკითხე Palworld სერვერის მეხსიერება.
- დათვალე ბაზები და მუშები. იკითხე, რამდენი ბანაკი და მუშა არსებობს. თუ ასეულებშია, შეამცირე
BaseCampMaxNumInGuildდაBaseCampWorkerMaxNum. - იპოვე ძვირი ბაზა. უყურე frame rate-ს, როცა მოთამაშეები მოძრაობენ. გაამარტივე ბაზა, რომელიც მას ქვევით ექაჩება.
- შეამცირე სამყარო.
DropItemMaxNum,PalSpawnNumRate,AutoResetGuildNoOnlinePlayersმიტოვებული გილდიებისთვის. - შემდეგ შეხედე რესურსებს. თუ ამ ყველაფრის შემდეგ სერვერი მუდმივად CPU-ის ლიმიტზეა, მას მეტი CPU სჭირდება. RE:NODE-ზე გეგმის შეცვლა იმავე სერვერზე ლიმიტს ზრდის ხელახლა აგების გარეშე - იხილე როდის განაახლო გეგმა.
პრობლემების მოგვარება#
pal-ები ტელეპორტირდება და კარები ყველასთვის გვიან იღება. სერვერის frame rate. შეამოწმე მეტრიკების endpoint და CPU-ის გრაფიკი, შემდეგ მორგების რიგი გაიარე.
წარმადობა კვირების განმავლობაში კარგი იყო და ნელ-ნელა გაუარესდა. სამყაროს ზრდა. მეტი ბაზა, მეტი მუშა, უფრო დიდი save. გადატვირთე ყოველდღე და შეამცირე ლიმიტები.
ერთ ბაზაზე თამაში შეუძლებელია, დანარჩენი სამყარო რიგზეა. ამ ბაზის განლაგება. გაამარტივე და შეამოწმე გაჭედილი pal-ები.
შეფერხება ყოველ ოცდაათ წამში. AutoSaveSpan ნაგულისხმევ მნიშვნელობაზე დიდ სამყაროში. გაზარდე.
სერვერი გადატვირთვის შემდეგ სწრაფია, საღამოსთვის კი ნელი. uptime-ით გამოწვეული დეგრადაცია. ყოველდღიური გადატვირთვები და შეამოწმე მეხსიერების ზრდა დღის განმავლობაში.
ლიმიტების შემცირებამ არაფერი შეცვალა. არსებული ბანაკები და მუშები ახალ ლიმიტებზე მეტი რჩება, სანამ არ მოიშლება. ეფექტი იზრდება, როცა ძველი ბაზები ქრება.
FAQ#
რამდენ ბაზის ბანაკს უძლებს Palworld სერვერი?
ეს დამოკიდებულია მუშებზე თითო ბანაკში და სერვერის CPU-ზე. იფიქრე მომუშავე pal-ების ჯამით და არა ბანაკებით: ასი ან ორასი საშუალო ზომის სერვერზე კომფორტულია, რამდენიმე ასეული კი ის ზღვარია, სადაც frame rate-ები ზარალდება.
შლის თუ არა BaseCampWorkerMaxNum-ის შემცირება არსებულ pal-ებს?
არა. უკვე მომუშავე pal-ები რჩება; ლიმიტს ზემოთ ახლის მიმაგრება არავის შეუძლია. სრული ეფექტი ჩნდება, როცა ბაზები თავიდან შენდება ან მიტოვებულია.
რატომ ლაგავს ჩემი Palworld სერვერი სულ რამდენიმე მოთამაშით?
იმიტომ, რომ ხარჯი სამყაროა და არა მოთამაშეები. რამდენიმე მოთამაშეს ბევრი დიდი ბაზით შეუძლია სერვერი უფრო მეტად დატვირთოს, ვიდრე ახალი მოთამაშეებით სავსე სერვერს.
გახდის თუ არა მეტი CPU ბირთვი Palworld სერვერს უფრო სწრაფს?
მხოლოდ გარკვეულ ზღვრამდე. სიმულაციის უმეტესი ნაწილი ერთ მთავარ thread-ზე მუშაობს, ამიტომ უფრო სწრაფი ბირთვი დამატებით ბირთვებზე მეტად შველის. multithreading-ის გაშვების flag-ები გეხმარება გამოიყენო ის დამატებითი ბირთვები, რაც არის.
რამდენად ხშირად უნდა გადავტვირთო Palworld სერვერი?
ყოველდღე ნორმალურია. ეს ასუფთავებს დაგროვილ პრობლემებს და მეხსიერების ზრდას. თუ სერვერს თამაშვარგისად დარჩენისთვის უფრო ხშირი გადატვირთვა სჭირდება, ის სამყაროსთვის მცირე ზომისაა.




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