FiveM სერვერის RAM: ზომა რესურსების მიხედვით

FiveM სერვერს სჭირდება 2-დან 3 GB-მდე მეხსიერება freeroam, drift ან racing სერვერისთვის დაახლოებით 32 მოთამაშემდე და რესურსების მოკრძალებული სიით, 4-დან 6 GB-მდე ESX, QBCore ან Qbox roleplay სერვერისთვის 48-დან 64 სლოტამდე, და 8-დან 12 GB-მდე დიდი roleplay სერვერისთვის ასობით რესურსით და 64-ზე საგრძნობლად მეტი მოთამაშით. სლოტების რაოდენობა ამ წინადადებაში ყველაზე სუსტი მაჩვენებელია. FXServer-ის მეხსიერება მისდევს რესურსებს, რომლებსაც აყენებ, და მდგომარეობას, რომელსაც ისინი ინახავენ, ასე რომ ნახევრად ცარიელი სერვერი ორასი სკრიპტით მეტს იყენებს, ვიდრე სავსე სერვერი ორმოცით, ხოლო ერთ ცუდად დაწერილ სკრიპტს დღის ბოლოსთვის სერვერზე ყველაფერ დანარჩენის გადაჭარბება შეუძლია. ზომა შენი რესურსების საქაღალდის მიხედვით შეარჩიე, შემდეგ კი რიცხვებით დაამტკიცე.

რას ინახავს FXServer მეხსიერებაში#

FXServer არის სერვერის binary; თამაშის ლოგიკა, რომელსაც მასზე უშვებ, თითქმის მთლიანად რესურსებია. მეხსიერება ხუთი ადგილიდან მოდის:

• სერვერის ბირთვი. ქსელი, HTTP endpoint, რომელიც კლიენტებს ფაილებს აწვდის, და სერვერის მხარის თამაშის მდგომარეობა. თავისთავად პატარაა: სტანდარტული სერვერი ნაგულისხმევი რესურსებით უქმად რამდენიმე ასეულ მეგაბაიტში დგას.
• OneSync-ის მდგომარეობა. ჩართული OneSync-ით სერვერი აკვირდება ყოველ ქსელურ entity-ს - მოთამაშეებს, ტრანსპორტს, ped-ებს, ობიექტებს - და მათ მდგომარეობას. მეტი მოთამაშე და მეტი შექმნილი entity ნიშნავს მეტ მდგომარეობას, პოპულაციის პარამეტრები კი წყვეტს, რამდენი ფონური entity არსებობს.
• სკრიპტების runtime-ები. თითოეული რესურსის სერვერული სკრიპტები runtime-ში ეშვება: Lua (ნაგულისხმევი და ბევრად ყველაზე გავრცელებული), JavaScript ჩაშენებულ Node/V8 runtime-ზე, ან C# Mono-ზე. ყოველი რესურსი Lua სერვერული სკრიპტებით საკუთარ Lua state-ს იღებს საკუთარი heap-ით.
• რას ინახავენ სკრიპტები. Framework-ის მიერ დაქეშილი მოთამაშის ობიექტები, ინვენტარები, სამსახურის მონაცემები, ტრანსპორტის რეესტრები, ტელეფონის შეტყობინებები, საცხოვრებლის მონაცემები და ყველაფერი, რაც სკრიპტმა მონაცემთა ბაზიდან ჩატვირთა და შეინახა. აქ ცხოვრობს roleplay სერვერის მეხსიერების უმეტესი ნაწილი.
• Streaming asset-ების აღრიცხვა. საკუთარი ტრანსპორტი, რუკები, ტანსაცმელი და MLO ინტერიერები კლიენტებს სერვერის cache საქაღალდიდან მიეწოდება. მათი მოცულობა დისკზე და გადაცემაშია, მაგრამ სერვერი მათ გაშვებისას ინდექსირებს, ასე რომ ძალიან დიდი stream საქაღალდეები გაშვებას ახანგრძლივებს და ცოტა მეხსიერებას ამატებს.

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

RAM სერვერის ტიპის მიხედვით#

სამი რამ სერვერს ცხრილში უფრო სწრაფად აწევს, ვიდრე მოთამაშეები.

1. რესურსების რაოდენობა და ხარისხი. ოთხმოცი კარგად დაწერილი რესურსის შერჩეულმა სიამ თანამედროვე framework-ზე შეიძლება ნაკლები გამოიყენოს, ვიდრე ორმოცმა ძველმა, ფორუმებიდან გადმოწერილმა. მეხსიერება თითო რესურსზე ასჯერ განსხვავდება.
2. რას აქეშებს framework. Framework-ები ყოველი მიერთებული მოთამაშის მონაცემებს მეხსიერებაში ინახავენ, ზოგი რესურსი კი ოდესმე შექმნილი ყოველი პერსონაჟის მონაცემებს ინახავს, გაშვებისას ერთხელ ჩატვირთულს. სერვერი, რომლის მონაცემთა ბაზაში ათი ათასი პერსონაჟია, შეიძლება ყველას ფულს იხდიდეს.
3. Uptime. Lua heap-ები და cache-ები დღის განმავლობაში იზრდება. სერვერი, რომელიც 3 GB-ით იწყება, რვა საათის შემდეგ შეიძლება 5 GB-ზე იყოს, და ეს ნორმალური ზრდაა თუ გაჟონვა, ერთ-ერთი შემდეგი განყოფილების თემაა.

FiveM-ის framework-ები: ESX, QBCore და Qbox თავად framework-ებს ადარებს; ზომის შერჩევისთვის ისინი მსგავსად იქცევიან, შედეგს კი მათ გარშემო არსებული დამატებითი რესურსები წყვეტს.

სლოტები, OneSync და პოპულაცია#

სლოტები sv_maxclients-ით ყენდება, 32-ზე მეტს კი OneSync სჭირდება. OneSync entity-ების ფლობასა და მდგომარეობას სერვერზე გადაიტანს, რაც დიდ სერვერებს შესაძლებელს ხდის და რის გამოც სერვერის მეხსიერება entity-ების რაოდენობას მისდევს.

set onesync onsv_maxclients 64sv_entityLockdown strictensure oxmysqlensure qb-coreensure [qb]ensure [standalone]

რა არის აქ მნიშვნელოვანი მეხსიერებისთვის:

• ყოველი ქსელური entity მდგომარეობა ჯდება. მოთამაშეები, მათი ტრანსპორტი, ფონური მოძრაობა და ფეხით მოსიარულეები, სკრიპტების მიერ შექმნილი prop-ები და ყველაფერი, რასაც კლიენტები ქმნიან. სერვერი ორმოცდაათი მოთამაშით, რომელთაგან თითოეული მანქანას იძახებს და ტოვებს, მეტი ჯდება, ვიდრე ისეთი, სადაც ტრანსპორტი ავტოფარეხებში ინახება.
• `sv_entityLockdown` აკონტროლებს, შეუძლიათ თუ არა კლიენტებს თავად შექმნან ქსელური entity-ები. strict კლიენტის მხარეს შექმნას მთლიანად ბლოკავს, რაც ხურავს ბოროტად გამოყენების კლასიკურ გზას, როცა მოდიფიცირებული კლიენტი entity-ებს spam-ავს, სანამ სერვერი მათით არ გაივსება. ეს ძირითადად უსაფრთხოების პარამეტრია, მაგრამ დატვირთულ სერვერზე მეხსიერებისაც. მას შეუძლია ძველი სკრიპტების გატეხვა, რომლებიც entity-ებს კლიენტის მხარეს ქმნიან, ამიტომ გატესტე.
• პოპულაცია. ფონური მოძრაობა და ped-ებიც ქსელური entity-ებია. ბევრი roleplay სერვერი პოპულაციის სიმჭიდროვეს რესურსის მეშვეობით ამცირებს, როგორც წარმადობის, ისე გეიმფლეის გამო; შედეგად სერვერი ნაკლებ entity-ს ინახავს.

OneSync და მოთამაშეების სლოტები entity-ების მხარეს უფრო ღრმად განიხილავს, server.cfg-ის ახსნა კი ამათ გარშემო ყოველ ხაზს ფარავს.

გამჟონი სკრიპტები: ჩვეული დამნაშავე#

FiveM სერვერების უმეტესობა, რომლებსაც მეხსიერება ეწურებათ, ზედმეტად პატარა არ არის. მათ აქვთ რესურსი, რომლის მეხსიერებაც მხოლოდ იზრდება. ნიმუში თითქმის ყოველთვის ერთია: მოთამაშის მიხედვით დაკლავებული ცხრილი, რომელიც ვინმეს შემოსვლისას ივსება და გასვლისას არასოდეს სუფთავდება, cache, რომელიც ტვირთავს ყოველ რიგს, რაც ოდესმე უნახავს, ან ციკლი, რომელიც closure-ებს ან ტაიმერებს უფრო სწრაფად ქმნის, ვიდრე ისინი სრულდება.

კლასიკური გამოსწორება ერთი handler-ია:

local playerCache = {}AddEventHandler('playerDropped', function()    playerCache[source] = nilend)

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

იმის გასარკვევად, რომელი რესურსი იზრდება, გაზომე თითოეული რესურსის Lua heap შიგნიდან. ამისთვის საკმარისია პატარა debug რესურსი ან დროებითი ხაზი საეჭვო სკრიპტში:

CreateThread(function()    while true do        Wait(60000)        local mb = collectgarbage('count') / 1024        print(('[%s] Lua heap: %.1f MB'):format(GetCurrentResourceName(), mb))    endend)

collectgarbage('count') აბრუნებს ამ რესურსის მიმდინარე Lua heap-ს კილობაიტებში. დატოვე გაშვებული ნორმალური თამაშის რამდენიმე საათის განმავლობაში. რესურსი, რომლის რიცხვიც იზრდება და ეცემა, ჯანსაღია; ის, რომლისაც მხოლოდ იზრდება, ჟონავს. შემდეგ debug ხაზი მოაშორე.

გაზომვა ყიდვამდე#

ოთხი ხელსაწყო, იმ თანმიმდევრობით, რომლითაც უნდა გამოიყენო.

1. მეხსიერების გრაფიკი სრული დღის განმავლობაში. FiveM სერვერი გაშვების შემდეგ იზრდება, როცა მოთამაშეები შემოდიან და cache-ები ივსება, შემდეგ კი სწორდება. ხაზი, რომელიც შემდეგ restart-მდე იზრდება, გაჟონვაა. ხაზი, რომელიც ლიმიტთან ახლოს სწორდება, ნამდვილად ზედმეტად პატარა სერვერია.
2. `resmon` კლიენტზე. დააჭირე F8-ს და გაუშვი resmon 1. ის აჩვენებს თითოეული რესურსის CPU-ს დროსა და მეხსიერებას ამ კლიენტზე. სერვერის მხარის ხარჯს არ აჩვენებს, მაგრამ რესურსები, რომლებიც კლიენტზე მძიმეა, ჩვეულებრივ სერვერზეც მძიმეა, კლიენტის მხარის გაბერილობა კი იმის ნახევარია, რასაც მოთამაშეები გრძნობენ.
3. სერვერის profiler-ი. profiler record 500 სერვერის კონსოლში 500 კადრს იჭერს, შემდეგ profiler view შედეგს ხსნის. ეს CPU-ს ხელსაწყოა და არა მეხსიერების, მაგრამ რესურსი, რომელიც profile-ში დომინირებს, ხშირად იგივეა, რაც მეხსიერებაში დომინირებს. FiveM სერვერის წარმადობა და resmon მის წაკითხვას ნაბიჯ-ნაბიჯ განიხილავს.
4. Lua heap თითო რესურსზე, ზემოთ მოცემული ფრაგმენტით, იმ საეჭვოებისთვის, რომლებიც პირველმა სამმა გამოავლინა.

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

Restart-ები და რატომ გეგმავენ მათ roleplay სერვერები#

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

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

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

დეველოპმენტის სერვერები და ორი ასლის შენახვა#

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

დეველოპმენტის სერვერს ცოტა მოთამაშე ჰყავს, ხშირად მხოლოდ დეველოპერები, ამიტომ მას არ სჭირდება ცოცხალი სერვერის მარაგი სრული საღამოსთვის. მაგრამ მას იგივე რესურსების სიის ჩატვირთვა სჭირდება, და რადგან FiveM-ის მეხსიერებას რესურსები განსაზღვრავს და არა მოთამაშეები, dev სერვერი სრული სიით უქმად ცოცხალზე ბევრად დაბლა არ დგას. 2 GB-იანი გეგმა, რომელიც ცოცხალი რესურსების საქაღალდის გაშვებასაც კი ვერ ახერხებს, მის გასატესტად გამოუსადეგარია.

სასარგებლო მიდგომა:

1. Dev სერვერის ზომა მინიმუმისთვის შეარჩიე და არა პიკისთვის. გაუშვი ცოცხალი რესურსების სია ისე, რომ ონლაინ არავინ იყოს, და ჩაიწერე მეხსიერება მას შემდეგ, რაც ყველა რესურსი გაეშვება. Dev სერვერს ეს სჭირდება პლუს მარაგი, ჩვეულებრივ ცოცხალ სერვერზე ერთი დონით დაბლა.
2. ახალი რესურსები ჯერ იქ გატესტე, გაშვებული Lua heap-ის ფრაგმენტით. გამჟონი სკრიპტი თავს ტესტირების ერთ ნაშუადღევში გამოავლენს და არა საღამოს, როცა მოთამაშეებს თიშავს.
3. მონაცემთა ბაზა ცალკე შეინახე. Dev სერვერი მის საკუთარ მონაცემთა ბაზაზე მიმართე, არასოდეს ცოცხალზე. სატესტო სკრიპტმა, რომელიც ცხრილს წაშლის, სატესტო ცხრილი უნდა წაშალოს.
4. გამოიყენე იგივე სერვერის artifact. მეხსიერება და ქცევა FXServer-ის build-ებს შორის იცვლება, ასე რომ სხვა build-ზე ტესტირება იმაზე ნაკლებს ამტკიცებს, ვიდრე ჩანს.

RE:NODE-ზე ყოველ სერვერს საკუთარი ლიმიტები, საკუთარი პანელი და საკუთარი backup-ები აქვს, ასე რომ dev სერვერი უბრალოდ მეორე, უფრო პატარა გეგმაა. Subuser-ები დეველოპერებს dev სერვერის კონსოლსა და ფაილებთან წვდომას აძლევს ცოცხალზე წვდომის გარეშე.

მონაცემთა ბაზა და დისკი#

Roleplay framework-ები პერსონაჟებისთვის, ინვენტარებისთვის, ტრანსპორტისა და ქონებისთვის მონაცემთა ბაზას ეყრდნობა. მონაცემთა ბაზა ცალკე პროცესია საკუთარი მეხსიერების მოთხოვნებით, და ითვლება თუ არა ის შენი თამაშის სერვერის ლიმიტში, დამოკიდებულია იმაზე, სად მუშაობს. პატარა roleplay მონაცემთა ბაზა რამდენიმე ასეულ მეგაბაიტში კომფორტულად გრძნობს თავს; დიდი, ლოგების ცხრილებით, რომლებსაც არავინ ასუფთავებს, უსაზღვროდ იზრდება. FiveM-ის მონაცემთა ბაზა და oxmysql აღწერს connection string-ს, ნელ query-ებს და ცხრილებს, რომელთა გასუფთავებაც ღირს.

დისკზე streaming asset-ები ცხოვრობს. სერვერს ასი საკუთარი ტრანსპორტით, ათიოდე MLO ინტერიერითა და ტანსაცმლის პაკეტით შეიძლება 10-დან 20 GB-მდე რესურსების საქაღალდე ჰქონდეს, პლუს cache საქაღალდე, რომელსაც FXServer მისგან აწყობს. დატოვე ადგილი ორივესთვის და rollback-ისთვის შენახული რამდენიმე სერვერის artifact-ისთვის. MLO რუკები და streaming asset-ები აღწერს stream-ის ლიმიტებს და რატომ აზიანებს ზედმეტად დიდი asset-ები კლიენტებს უფრო მეტად, ვიდრე სერვერებს.

CPU: კითხვის მეორე ნახევარი#

მეხსიერება იშვიათად არის ის, რასაც მოთამაშეები პირველად გრძნობენ. FXServer სკრიპტებს ერთ მთავარ thread-ზე უშვებს, ასე რომ რესურსი, რომელიც ყოველ კადრზე ძვირ სამუშაოს აკეთებს, ყველაფერ დანარჩენს აყოვნებს, და ეს desync-ისა და rubber-banding-ის სახით ჩნდება, როცა მეხსიერება ლიმიტთან ახლოსაც არ არის. სერვერის კონსოლი hitch-ის გაფრთხილებას ბეჭდავს, როცა სერვერის კადრი ზედმეტად დიდხანს გრძელდება, და ეს პირველია, რასაც უნდა მოძებნო, როცა მოთამაშეები ჩივიან. ერთი სწრაფი ბირთვი მთავარი thread-ისთვის პლუს მეორე ქსელისა და asset-ების მიწოდებისთვის roleplay-ისთვის რეალისტური მინიმუმია. CPU თუ RAM: რომელი აფერხებს შენს სერვერს ამ ორის ერთმანეთისგან გარჩევის ზოგადი მეთოდია.

FiveM-ის გეგმები RE:NODE-ზე 2 GB-დან 12 GB-მდეა, თვეში $9-დან, ორი პორტის გამოყოფით და ხელმისაწვდომი txAdmin-ით. შენი Cfx.re გასაღები Setup ჩანართზე შეგყავს, რადგან ის შენს ანგარიშზეა გაცემული, დონის აწევა კი ლიმიტებს უკვე არსებულ სერვერზე ზრდის.

FAQ#

საკმარისია თუ არა 4 GB FiveM roleplay სერვერისთვის?

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

იყენებს თუ არა FiveM მეტ RAM-ს მეტი მოთამაშით?

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

რატომ იზრდება ჩემი FiveM სერვერის მეხსიერება გამუდმებით?

ჩვეულებრივ, რესურსი მონაცემებს თითო მოთამაშეზე აქეშებს და არასოდეს ასუფთავებს, ან დროთა განმავლობაში მონაცემთა ბაზიდან სულ უფრო მეტს ტვირთავს. გაზომე თითოეული საეჭვოს Lua heap collectgarbage('count')-ით, ან გადატვირთე რესურსები სათითაოდ და უყურე, რომლის გადატვირთვა ათავისუფლებს ყველაზე მეტ მეხსიერებას.

იყენებენ თუ არა საკუთარი მანქანები და MLO-ები სერვერის RAM-ს?

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

რამდენად ხშირად უნდა გააკეთოს FiveM სერვერმა restart?

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