BeamMP-ის მაქსიმუმი: მოთამაშეების ლიმიტი, MaxCars და lag

BeamMP სერვერს საკუთარი მკაცრი ლიმიტი მოთამაშეების რაოდენობაზე არ აქვს. MaxPlayers იღებს ნებისმიერ რიცხვს 1-დან ზემოთ და სერვერის პროგრამა იმდენ ადამიანს მოემსახურება, რამდენსაც შეუშვებ. ლიმიტს, რომელსაც რეალურად აწყდები, სხვაგან უნდა ეძებო: ყველა მოთამაშის კომპიუტერი სერვერზე არსებულ ყველა მანქანას ახდენს სიმულაციას, ამიტომ რეალური ჭერი მანქანების საერთო რაოდენობაა, ანუ MaxPlayers გამრავლებული MaxCars-ზე, და ის სესიაში ყველაზე სუსტ კომპიუტერს ადარებ. შერეული, საჯარო აუდიტორიისთვის ეს დაახლოებით 10-12 მოთამაშეს ნიშნავს, თითოს 1-2 მანქანით. ძლიერი პროცესორების მქონე მეგობრების ჯგუფს შეუძლია 20 ან მეტი მოთამაშის გაშვება, თითო მანქანით. ერთსა და იმავე ადგილას დაახლოებით 30 ავტომობილის შემდეგ თითქმის არავის აპარატი ინარჩუნებს ფიზიკას რეალურ დროში.

თვითონ სერვერი ყველაზე იაფი ნაწილია. ის ცოტა CPU-ს და მეხსიერებას მოიხმარს, ხოლო მისი ღირებულება იზრდება ტრაფიკთან ერთად, რომელიც მოთამაშეთა რაოდენობის კვადრატით მატულობს. ეს პოსტი განმარტავს, საიდან მოდის თითოეული ლიმიტი, როგორ შეაფასო ტრაფიკი, რა იწვევს ე.წ. lag-ად წოდებულ ჭიდილს და ტელეპორტაციას და როგორ შეარჩიო MaxPlayers და MaxCars იმ სერვერისთვის, რომლის გაშვებასაც აპირებ. ინსტალაციისთვის, auth key-სთვის და ServerConfig.toml-ის დანარჩენი ნაწილისთვის დაიწყე BeamMP სერვერის გზამკვლევით.

რატომ არის ლიმიტი მოთამაშეების კომპიუტერებზე#

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

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

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

ორი შედეგი პირდაპირ უნდა ითქვას:

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

MaxPlayers და MaxCars: რას აკეთებენ სინამდვილეში#

ორივე პარამეტრი ServerConfig.toml-ის [General] სექციაშია. სერვერის მიმდინარე ვერსიების მიერ ჩაწერილი ნაგულისხმევი მნიშვნელობები ფრთხილია:

[General]MaxPlayers = 8MaxCars = 1Private = true

MaxCars თითო მოთამაშეზეა და არა სერვერზე. სერვერის მასშტაბით ავტომობილების ჩაშენებული ზღვარი არ არსებობს, ამიტომ უარესი შემთხვევა ყოველთვის ორი რიცხვის ნამრავლია. სერვერი MaxPlayers = 20-ით და MaxCars = 3-ით 60 ავტომობილს უშვებს და დატვირთულ საღამოს ამ რიცხვს მიუახლოვდება.

რამდენიმე დეტალი ხშირად ყველას აკვირვებს:

• ყველაფერი, რასაც მოთამაშე ქმნის, ავტომობილია. ტრეილერები, საგნები და კლიენტიდან გამოძახებული AI ტრაფიკი თითოეული MaxCars-ის ერთ ადგილს იკავებს. ასევე, უმეტეს ვერსიაში, ფეხით სიარულის რეჟიმი (უნიციკლი), სწორედ ამიტომ შეიძლება MaxCars = 1 სერვერზე მოთამაშემ, რომელიც ფეხით წასასვლელად გადმოვიდა, თავისი მანქანა დაკარგული დახვდეს. თუ შენი სერვერი ტრეილერებზე ან ბუქსირზეა აგებული, MaxCars = 2 პრაქტიკული მინიმუმია.
• გამოჩენა ძვირი მომენტია. როცა ავტომობილი ჩნდება ან რედაქტირდება, ყველა კლიენტმა უნდა ჩატვირთოს და ააგოს ის, და ამ დროს BeamNG მოკლედ იყინება. დატვირთულ სერვერზე მოთამაშეების მანქანის გადატვირთვა ან შეცვლა ყველა დანარჩენისთვის პატარა შეფერხებების ნაკადს ქმნის. BeamMP-ის კლიენტს მულტიპლეერის პარამეტრებში აქვს რიგი, რომელიც დისტანციურ გამოჩენებსა და რედაქტირებებს მოსახერხებელ მომენტამდე აჩერებს. პარამეტრების სახელები კლიენტის ვერსიებს შორის შეიცვალა, ამიტომ შენსაში ეძებე თამაშის პარამეტრების Multiplayer განყოფილება.
• ლიმიტები სავალდებულოა და არა სარეკომენდაციო. MaxCars-ის ზღვარს გადაცილებული ავტომობილი თავაზიანი უარის ნაცვლად იშლება, ხოლო MaxPlayers-ზე მეტი მოთამაშე კარებთანვე უკან ბრუნდება.

თუ გინდა "N თითო მოთამაშეზე"-ზე ჭკვიანი წესები - სერვერის მასშტაბით ზღვარი, სხვადასხვა ლიმიტი პერსონალისთვის, მძიმე სატვირთოების აკრძალვა მოთამაშეთა გარკვეული რაოდენობის შემდეგ - ეს Lua პლაგინია და ქვემოთაა განხილული.

ტრაფიკი თითო მოთამაშეზე და როგორ იზრდება ის#

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

ამის გამო სერვერის გამავალი ტრაფიკი კვადრატულ ფორმას იღებს:

outbound ≈ players × (players - 1) × cars per player × per-vehicle streaminbound  ≈ players × cars per player × per-vehicle stream

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

გადასვლა 8-დან 16 მოთამაშეზე თითო მანქანით ოთხჯერ მეტი ატვირთვა ჯდება, ხოლო 30 მოთამაშე თითო ორი მანქანით ნაგულისხმევ კონფიგურაციაზე ოცდაათჯერ მეტს ითხოვს. შემომავალი ტრაფიკი წრფივი და მცირე რჩება; თითქმის ყველა თამაშის მსგავსად, ივსება გამავალი მხარე. თამაშის სერვერის ტრაფიკი თითო მოთამაშეზე ამ ასიმეტრიას სხვადასხვა თამაშებისთვის განიხილავს და ხსნის, რატომ არის მდგრადი ტრაფიკი იშვიათად რეალური პრობლემა.

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

შენს საკუთარ Linux აპარატზე რეალური რიცხვების სანახავად ყველაზე სწრაფი გზა სესიის მიმდინარეობისას პორტის თვალყურის დევნებაა:

$ sudo iftop -i eth0 -f "port 30814"$ vnstat -l -i eth0

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

სახლის ჰოსტისთვის კედელი ატვირთვის სიჩქარეა. საცხოვრებელი ხაზი 20-40 Mbit/s ატვირთვით კარგია პატარა ჯგუფისთვის და ცხრილის ზედა ნაწილში სწრაფად ამოიწურება, განსაკუთრებით მაშინ, როცა ვინმე მოდებს ჩამოტვირთავს. მონაცემთა ცენტრის არხს ნებისმიერი რეალისტური BeamMP სერვერისთვის მარაგი აქვს, მაგრამ unmetered არ ნიშნავს შეუზღუდავს, და საჯარო სერვერი, რომელიც უცნობებს მთელი დღე რამდენიმე გიგაბაიტიან პაკეტს აგზავნის, სწორედ იმ ტიპის ტრაფიკია, რომელზეც ეს კითხვა დგას.

ზომების ცხრილი: მოთამაშეები, მანქანები და სერვერის რესურსები#

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

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

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

ახლა სერვერი. რელე მსუბუქია და მეხსიერება ძირითადად პროგრამას, Lua-ს მდგომარეობას და მოდების მიმდინარე გადაცემების ბუფერებს მიდის:

სერვერზე CPU უმეტესად ერთი ნაკადის სამუშაოა. თუ ის მაღალია მოთამაშეების მცირე რაოდენობით, მიზეზი თითქმის ყოველთვის Lua პლაგინია, რომელიც სწრაფ ტაიმერს უშვებს ან spawn handler-ში მძიმე JSON სამუშაოს აკეთებს, და არა მოთამაშეების რაოდენობა. BeamMP Lua პლაგინები და რბოლები გვიჩვენებს, როგორ გავზომოთ handler-ები Util.DebugExecutionTime()-ით. დისკი არის იმდენი, რამდენსაც შენი მოდების პაკეტი იწონის და ცოტა მეტი; ზოგადი სურათისთვის იხილე რამდენი ადგილი სჭირდება თამაშის სერვერს.

RE:NODE-ზე BeamMP პლანები იწყება 2 GB-ით და ერთი vCPU-თი და აღწევს 8 GB-მდე სამი vCPU-თი, NVMe-ზე, და CPU მკაცრი წილია და არა burst. BeamMP-ისთვის ქვედა ტარიფები თითქმის ყველა სერვერს ფარავს, რადგან ძვირი ნაწილი მოთამაშეების მანქანებზე სრულდება; უფრო დიდი პლანი ღირს დიდი მოდების პაკეტის დისკის სივრცისთვის ან პლაგინებისთვის, რომლებიც რეალურ სამუშაოს აკეთებენ, და არა MaxPlayers-ის ასამაღლებლად.

რა იწვევს lag-ს და desync-ს#

"Lag" BeamMP სერვერზე სულ მცირე ხუთ სხვადასხვა პრობლემას მოიცავს და თითოეულს სხვადასხვა გამოსწორება სჭირდება. მათ გარჩევას სწორი კითხვების დასმა ერთ წუთს ართმევს.

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

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

შეჯახებები, რომლებიც ერთმანეთს არ ემთხვევა. ორი მოთამაშე ეჯახება და თითოეული განსხვავებულ შედეგს ხედავს. ეს არქიტექტურაშია ჩაშენებული: თითოეული მანქანის მფლობელი თავისი ფიზიკის ავტორიტეტია, ხოლო მეორე მანქანა მის ეკრანზე ოდნავ ძველ მონაცემებზე დაფუძნებული პროგნოზია. ორ მოთამაშეს შორის 100 ms შეყოვნებისას 100 km/h სიჩქარით მოძრავი მანქანა თითქმის სამი მეტრით შორსაა იქიდან, სადაც მეორე მოთამაშე ფიქრობს, რომ არის. BeamMP-ზე კონტაქტური რბოლა საუკეთესოდ მუშაობს იმ მოთამაშეებს შორის, რომლებსაც ერთ სერვერამდე დაბალი ping აქვთ, და ეს არის რეალური არგუმენტი სერვერის მოთამაშეებთან ახლოს გასაშვებად. ზოგი სერვერი საჯარო სეირნობისთვის შეჯახებებს სწორედ ამ მიზეზით თიშავს, პლაგინით ან კლიენტის მოდით; შეამოწმე, რას გთავაზობს შენი ვერსია.

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

დაგლეჯა, რომელიც მოდის დამატების შემდეგ დაიწყო. ზოგი ავტომობილისა და რუკის მოდი სტანდარტულ კონტენტზე ბევრად მძიმეა ან BeamNG-ის მიმდინარე ვერსიისთვის გაფუჭებულია და ყოველ კადრზე შეცდომებს აგდებს. შეამოწმე მოდის Resources/Client-იდან გადატანით და გადატვირთვით. თუ პრობლემა რუკის მოდია, ფასს ყველა მოთამაშე იხდის მთელი სესიის განმავლობაში.

ავტომობილების რაოდენობის კონტროლი Lua პლაგინით#

MaxCars უხეში ინსტრუმენტია. პლაგინს შეუძლია მთელი სერვერისთვის საერთო ზღვარი დააწესოს, და სწორედ ეს არის რიცხვი, რომელიც კლიენტებისთვის ნამდვილად მნიშვნელოვანია. onVehicleSpawn ეშვება ავტომობილის მიღებამდე და 1-ის დაბრუნება მას აუქმებს:

local SERVER_CAP = 24local function countVehicles()    local total = 0    for id, _ in pairs(MP.GetPlayers() or {}) do        local vehicles = MP.GetPlayerVehicles(id)        if vehicles then            for _ in pairs(vehicles) do total = total + 1 end        end    end    return totalendfunction capSpawn(playerID, vehicleID, data)    if countVehicles() >= SERVER_CAP then        MP.SendChatMessage(playerID, "Server vehicle limit reached. Remove a car first.")        return 1    endendMP.RegisterEvent("onVehicleSpawn", "capSpawn")

ამის არსებობისას შეგიძლია MaxCars = 3 დააყენო, რომ მოთამაშეებს ტრეილერისთვის ადგილი ჰქონდეთ, და მაინც დარწმუნებული იყო, რომ სერვერი კლიენტს არასდროს სთხოვს 24 ავტომობილზე მეტის გაშვებას. იმავე handler-ში შეგიძლია კონკრეტული მძიმე მოდელების უარყოფა ან პერსონალისთვის უფრო მაღალი რაოდენობის დაშვება beammp იდენტიფიკატორის შემოწმებით. ნებისმიერი პლაგინი ჯერ შენი სერვერის ვერსიაზე გამოსცადე - API მსხვილ გამოშვებებს შორის შეიცვალა, და Lua პლაგინების გზამკვლევი მოვლენების სიგნატურებს დეტალურად განმარტავს.

ასეთი handler-ები იაფი გახადე. spawn handler, რომელიც რამდენიმე ათეულ ავტომობილს გადის, არაფერი ღირს; ის, რომელიც ყოველ გამოჩენაზე ყოველი ავტომობილის სრულ კონფიგურაციის JSON-ს დეკოდირებს, დატვირთულ ღამეს სერვერის CPU-ზე ჩანს.

ლიმიტის უსაფრთხოდ ამაღლება#

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

1. ჯერ `MaxCars` შეამცირე. 2-დან 1-ზე გადასვლა კლიენტის დატვირთვასაც და ტრაფიკსაც განახევრებს. თუ ხალხს ტრეილერები სჭირდება, დაამატე პლაგინის ზღვარი.
2. დიდი ბრბოსთვის უფრო დიდი რუკა აირჩიე. ერთმანეთისგან შორს მდგომი მანქანები ერთსა და იმავე გზაჯვარედინზე მდგომთაზე იაფია და ნაკლებ შეჯახებას ქმნის, რომელზეც უთანხმოება შეიძლება. Gridmap და პატარა არენები პატარა ჯგუფებისთვისაა.
3. მოდების პაკეტი შეამცირე. ყოველი მძიმე ავტომობილის მოდი ყველა კლიენტზე ზრდის თითო ავტომობილის ფასს, ხოლო პაკეტის ზომა განსაზღვრავს, რამდენად მტკივნეულია შემოსვლა.
4. მოლოდინები სერვერის აღწერაში დააფიქსირე. "რეკომენდებულია: 6-ბირთვიანი CPU" Description-ში ან შენს Discord-ზე გიცავს მოთამაშეებისგან, რომლებიც შემოდიან, ნახევარი სიჩქარით მუშაობენ და ჰოსტს ადანაშაულებენ.
5. `MaxPlayers` მცირე ნაბიჯებით ასწიე. 10-იდან 14-ზე გადადი, ერთი სრული საღამო უყურე, შემდეგ გადაწყვიტე. დააკვირდი იმას, რომ მოთამაშეები შენელებულ მოძრაობაზე იტყვიან და არა მხოლოდ სერვერის საკუთარ მაჩვენებლებს.
6. მხოლოდ ამის შემდეგ შეხედე პლანს. თუ სერვერის CPU ნამდვილად მაღალია, ჯერ პლაგინი იპოვე. თუ სახლში ატვირთვა არის ზღვარი, მონაცემთა ცენტრის ჰოსტი ამას ასწორებს.

დიდ სესიამდე გადატვირთვა კარგი ჩვევაა და არა წარმადობის გამოსწორება: ის ასუფთავებს ჩაჭედილ ავტომობილის მდგომარეობას და ყველას ერთსა და იმავე სერვერის ვერსიაზე იწყებინებს. გადატვირთვის გრაფიკები, რომლებიც გვეხმარება განმარტავს, როდის დაგეგმო ის. RE:NODE-ზე Schedules tab-ს შეუძლია ეს გადატვირთვა და მის წინ backup cron გამოსახულებით გაუშვას.

ხარვეზების აღმოფხვრა#

მოთამაშეები შენელებულ მოძრაობაზე ჩივიან, როგორც კი სერვერი ივსება. ავტომობილები მათი პროცესორებისთვის ძალიან ბევრია. შეამცირე MaxCars ან MaxPlayers; უფრო დიდი სერვერის პლანი ამას ვერ შეცვლის.

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

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

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

სერვერის CPU 100%-ზეა რამდენიმე მოთამაშით. პლაგინი. ამოიღე პლაგინები Resources/Server-იდან სათითაოდ ან გაზომე მათი handler-ები.

სერვერი სავსეა, მაგრამ სიაში თავისუფალი ადგილები ჩანს. სია დაგვიანებით ახლდება. მისამართით დაკავშირებულ მოთამაშეებს რეალური პასუხი ეძლევათ.

FAQ#

რა არის BeamMP სერვერზე მოთამაშეების მაქსიმალური რაოდენობა?

სერვერში ფიქსირებული მაქსიმუმი არ არსებობს; MaxPlayers იღებს ნებისმიერ დადებით რიცხვს. სამუშაო ლიმიტი კლიენტის წარმადობაა: დატვირთული საჯარო სერვერები ჩვეულებრივ 10-20 მოთამაშით მუშაობენ, ხოლო ძალიან დიდ ღონისძიებებს თითო მანქანა და ძლიერი პროცესორების მქონე მოთამაშეები სჭირდება.

MaxPlayers უნდა ავწიო თუ MaxCars?

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

ამცირებს თუ არა სერვერის უკეთესი პლანი BeamMP lag-ს?

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

ითვლება თუ არა ფეხით მოსიარულე უნიციკლი მანქანად?

BeamMP-ის უმეტეს ვერსიაზე - დიახ, ის ავტომობილად ჩნდება და MaxCars-ში ითვლება. თუ ელოდები, რომ ხალხი გადმოვა და ფეხით ივლის, ყოველ მოთამაშეს მინიმუმ ორი მანქანა დაუშვი.

რამდენი ატვირთვა სჭირდება BeamMP სერვერს?

ის მოთამაშეთა რაოდენობის კვადრატით იზრდება, ამიტომ გაზომე ცნობილი დატვირთვისას და იქიდან მასშტაბირე. პატარა ჯგუფი სახლის კავშირზე ეტევა; ოცი მოთამაშე თითო ორი მანქანით, მოდების ჩამოტვირთვებთან ერთად, მონაცემთა ცენტრის არხს საჭიროებს.