FiveM სერვერის წარმადობა resmon-ით

როცა FiveM სერვერი ლაგავს, მიზეზი თითქმის ყოველთვის ერთი ან ორი resource-ია, და მათ სამი ხელსაწყოთი პოულობ: resmon 1 კლიენტის F8 კონსოლში, რომ ნახო, რა უჯდება სკრიპტები თითოეული მოთამაშის მანქანას, profiler record სერვერის კონსოლში, რომ ნახო, რა უჯდება ისინი სერვერის მთავარ thread-ს, და hitch-ის გაფრთხილებები და txAdmin-ის tick-ის გრაფიკი, რომლებიც გეუბნება, როდის ხდება ეს. მეტი მეხსიერება იშვიათად ცვლის რამეს, მეტი ბირთვი კი - ცოტას, რადგან მნიშვნელოვანი სამუშაო ერთ thread-ზე სრულდება. ეს გზამკვლევი ხსნის, როგორ წაიკითხო თითოეული ხელსაწყო, რას ნიშნავს რიცხვები, კოდის რომელი ნიმუშები ჩნდება შედეგებში ისევ და ისევ და რა თანმიმდევრობით იმუშაო, რომ მიზეზი გაასწორო და არა ფულით აუარო გვერდი.

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

მოთამაშეები "სერვერი ლაგავს"-ს ორ სხვადასხვა პრობლემაზე ამბობენ, და მათ სხვადასხვა ხელსაწყო სჭირდება.

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

სერვერის მხარის ხარჯი არის დრო FXServer-ის მთავარ thread-ზე. სერვერის სკრიპტები, event handler-ები და ტაიმერები იქ რიგრიგობით სრულდება, ამიტომ ერთი ნელი handler აყოვნებს ყველაფერს, რაც მის უკან რიგშია - მათ შორის იმ დამუშავებასაც, რომელიც მოთამაშეებს სინქრონიზებულს ინახავს. სიმპტომები: rubber-banding, მანქანების ხტუნვა, კარები და ინვენტარები, რომლებიც დაგვიანებით რეაგირებს, / ბრძანებები, რომლებსაც პასუხს წამი სჭირდება, და ყველა ერთდროულად დაზარალებული. FPS კარგია.

არის მესამე რამ, რომელიც ორივეს ჰგავს და არცერთი არ არის: ქსელი. პაკეტების დაკარგვა ერთ მოთამაშესა და სერვერს შორის ამ მოთამაშეს rubber-banding-ს აძლევს, დანარჩენები კი კმაყოფილები არიან. თუ მხოლოდ ერთი ადამიანი ჩივის, დაიწყე latency-ით, jitter-ით და პაკეტების დაკარგვით და არა შენი სკრიპტებით.

resmon: რა უჯდება თითოეული resource კლიენტს#

გახსენი F8 კონსოლი თამაშში და აკრიფე:

resmon 1

resmon 0 მას ისევ ხურავს. overlay ჩამოთვლის ყველა გაშვებულ resource-ს CPU-ს დროით, რომელიც მან ერთ კადრზე გამოიყენა მილიწამებში, და მეხსიერებით, რომელსაც ის კლიენტზე იკავებს. დაალაგე CPU-ს დროით და ერთი წუთი უყურე, სანამ ჩვეულებრივ რამეებს აკეთებ - დადიხარ, მანქანაში ჯდები, ინვენტარს ხსნი - რადგან ხარჯი ხშირად იმაზეა დამოკიდებული, რას აკეთებს მოთამაშე.

როგორ წაიკითხო რიცხვები: 60 FPS-ზე თამაშს კადრის შესაქმნელად დაახლოებით 16.7 ms აქვს, და ამის უმეტესი ნაწილი თავად თამაშს სჭირდება. უმოქმედო resource - ეკრანზე არაფერი, მოთამაშე მის ფუნქციასთან ახლოსაც არ არის - უნდა აჩვენებდეს 0.00-ს ან 0.01 ms-ს. HUD-ი, მინირუკა ან ხმოვანი resource, რომელიც მართლაც ყოველ კადრს ხატავს, შეიძლება რამდენიმე მეასედზე იყოს. ყველაფერი, რაც უმოქმედოდ დაახლოებით 0.10 ms-ზე მეტს აჩვენებს, აკეთებს სამუშაოს, რომელიც არ სჭირდება, ხოლო ყველაფერი, რაც რეგულარულად 0.5 ms-ს აღემატება, თავისთავად სერიოზული პრობლემაა. ათი resource თითო 0.2 ms-ით არის ყოველი კადრის ორი მილიწამი, დაკარგული მანამ, სანამ მოთამაშეს რამე გაუკეთებია.

მეხსიერება resmon-ში თითოეული resource-ის Lua heap-ია. მნიშვნელობა, რომელიც ნახევარი საათის განმავლობაში სტაბილურად იზრდება და არასოდეს ეცემა, გაჟონვაა - ცხრილები, რომლებსაც ემატება და არასოდეს სუფთავდება, ჩვეულებრივ ქეში, რომლის გასაღებიც გამუდმებით იცვლება. დიდი, მაგრამ სტაბილური რიცხვი უბრალოდ resource-ია, რომელიც ბევრ მონაცემს ინახავს, და ნაკლებად საინტერესოა.

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

სერვერის მხარე: hitch-ის გაფრთხილებები და profiler#

FXServer ბეჭდავს გაფრთხილებას, როცა მისი რომელიმე thread-ი tick-ებს შორის გაცილებით მეტ დროს ხარჯავს, ვიდრე უნდა:

[ citizen-server-impl] server thread hitch warning: timer interval of 412 milliseconds[ citizen-server-impl] sync thread hitch warning: timer interval of 187 milliseconds[ citizen-server-impl] network thread hitch warning: timer interval of 158 milliseconds

წაიკითხე ისინი thread-ის მიხედვით. server thread არის ადგილი, სადაც შენი Lua, JavaScript და C# resource-ები მუშაობს; იქ hitch-ები თითქმის ყოველთვის სკრიპტია. sync thread ამუშავებს OneSync-ის მდგომარეობას - ობიექტებს, მათ პოზიციებს და ვის ეკუთვნის ისინი - და იქ hitch-ები ჩვეულებრივ ნიშნავს ზედმეტად ბევრ ობიექტს ან რაღაცას, რაც მდგომარეობის ცვლილებებს უსასრულოდ აგზავნის. network thread აგზავნის და იღებს პაკეტებს; იქ hitch-ები ჰოსტზე, რომელიც სხვა მხრივ წესრიგშია, მიუთითებს ძალიან დიდ event payload-ებზე ან გადატვირთულ მანქანაზე.

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

იმის გასარკვევად, რომელმა resource-მა გამოიწვია ისინი, სერვერის კონსოლიდან ჩაშენებული profiler გამოიყენე:

profiler record 500

ეს სერვერის მომდევნო 500 tick-ს იწერს. როცა დასრულდება, გაუშვი profiler view და FXServer დაბეჭდავს ბმულს, რომელიც ჩანაწერს Chrome-ზე დაფუძნებულ timeline-ის მნახველში ხსნის. profiler save ამის ნაცვლად ჩანაწერს ფაილში წერს, რაც გამოსადეგია, როცა კონსოლი დისტანციურია და მისი მოგვიანებით ნახვა ან resource-ის ავტორისთვის გაგზავნა გინდა. იგივე profiler ბრძანებები კლიენტის F8 კონსოლშიც მუშაობს, და ასე ჩადიხარ resmon-ზე ღრმად ერთ კლიენტზე.

timeline-ში ყოველი tick ბლოკია, და მის შიგნით ხედავ, რომელმა resource-მა და რომელმა ფუნქციამ გამოიყენა დრო. შენ ეძებ განიერ ზოლებს: ერთი resource-ის handler-ს, რომელიც ათობით მილიწამს ხარჯავს, როცა დანარჩენი ყველაფერი მილიწამის ნაწილებს. ჩაწერე მაშინ, როცა პრობლემა ხდება - მშვიდი სერვერის პროფილი დილის 4 საათზე არაფერს ამტკიცებს. თუ ლაგი პიკებად მოდის, მეტი tick ჩაწერე, რომ პიკი ფანჯარაში მოხვდეს.

txAdmin-ის წარმადობის გრაფიკი#

txAdmin FXServer-ის thread-ების tick-ის დროების მიმდინარე ჰისტოგრამას ინახავს და მას თავის dashboard-ზე ხატავს. ახალ ვერსიებში შეგიძლია გადართო main, sync და network thread-ებს შორის. ყოველი სვეტი დროის მონაკვეთია; ფერები აჩვენებს, tick-ების რა წილი მოხვდა ხანგრძლივობის თითოეულ კალათაში.

ჯანმრთელი სერვერი თავისი tick-ების თითქმის ყველას უსწრაფეს კალათაში ატარებს, მთელი დღე. შენ ეძებ კუდს: ნელი tick-ების პატარა, სტაბილურ წილს, რომელიც გარკვეულ საათებში ან გარკვეული uptime-ის შემდეგ ჩნდება. სწორედ ეს ფორმაა, რასაც მოთამაშეები პერიოდულ შეფერხებად გრძნობენ და არა მუდმივ ლაგად, და ის profiler-ის გახსნის გარეშე ორ სასარგებლო რამეს გეუბნება - როდის ხდება (შეადარე მოთამაშეების რაოდენობას და იმას, რა ხდებოდა თამაშში) და უარესდება თუ არა uptime-თან ერთად, რაც მიუთითებს გაჟონვაზე ან ობიექტების დაგროვებაზე და არა ერთ ძვირ handler-ზე.

txAdmin ასევე გადატვირთავს სერვერს, რომლის მთავარი thread-ი საერთოდ წყვეტს პასუხს. თუ ეს გამუდმებით ხდება, შემდეგი ნაბიჯი profiler-ია; hang timeout-ის გაზრდა მხოლოდ ახანგრძლივებს გათიშვას. txAdmin-ის ზოგადი დაყენება აღწერილია FiveM სერვერის დაყენებაში txAdmin-ით.

კოდის ნიმუშები, რომლებიც ყოველ ჯერზე ჩნდება#

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

ციკლები, რომლებიც უმიზეზოდ ყოველ კადრზე ეშვება

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

-- Costs CPU on every frame, everywhere on the mapCreateThread(function()    while true do        Wait(0)        local coords = GetEntityCoords(PlayerPedId())        if #(coords - shopCoords) < 2.0 then            DrawText3D(shopCoords, "[E] Open shop")        end    endend)

გამოსწორება არის მანძილის პროპორციული ლოდინი და ყოველ კადრზე გადასვლა მხოლოდ მაშინ, როცა მოთამაშე საკმარისად ახლოსაა, რომ ამას მნიშვნელობა ჰქონდეს:

CreateThread(function()    while true do        local sleep = 1000        local coords = GetEntityCoords(PlayerPedId())        local dist = #(coords - shopCoords)        if dist < 20.0 then            sleep = 0            if dist < 2.0 then                DrawText3D(shopCoords, "[E] Open shop")            end        end        Wait(sleep)    endend)

ეს ერთი ცვლილება resource-ს მუდმივი 0.1-0.3 ms-იდან 0.00-მდე ჩამოიყვანს ყველასთვის, ვინც მაღაზიასთან ახლოს არ დგას. ბიბლიოთეკები, როგორიცაა ox_lib, გაძლევს point-ისა და zone-ის დამხმარეებს, რომლებიც ამას შენ ნაცვლად აკეთებს; მათი გამოყენება ჯობია, ვიდრე ერთი და იგივე ციკლის ხელით დაწერა ორმოც resource-ში.

მანძილის შემოწმება ნელი გზით

#(a - b) ორ vector3 მნიშვნელობაზე სუფთა Lua-ს გამოთვლაა და ძალიან იაფია. GetDistanceBetweenCoords არის native გამოძახება marshalling-ის ხარჯით, და ძველი resource-ები მას კადრში ასობითჯერ იძახებს. მისი ჩანაცვლება მექანიკური ცვლილებაა გაზომვადი შედეგით.

სერვერის handler-ები, რომლებიც ზედმეტს აკეთებს

სერვერზე ეკვივალენტური შეცდომებია ციკლი ყველა მოთამაშეზე, რომლის შიგნითაც მონაცემთა ბაზის მოთხოვნაა, SetTimeout-ის ჯაჭვი, რომელიც უფრო ხშირად ეშვება, ვიდრე ის მდგომარეობა იცვლება, რომელსაც ასახავს, და handler-ები, რომლებიც ყოველ გამოძახებაზე დიდ ცხრილს json.encode-ით აკეთებს. oxmysql ასინქრონულია, ამიტომ ნელი მოთხოვნა თავისთავად thread-ს არ ყინავს, მაგრამ handler, რომელიც ერთ event-ზე ორმოცდაათს გასცემს, გაყინავს - და მოგვიანებით დაბრუნებული callback-ების რიგიც მთავარ thread-ზე ხვდება. mysql_slow_query_warning-ის დაყენება oxmysql-ს აიძულებს, დაბეჭდოს ყოველი მოთხოვნა, რომელიც ზღვარს აღემატება; მონაცემთა ბაზის მხარე აღწერილია FiveM-ის მონაცემთა ბაზებსა და oxmysql-ში.

ზედმეტი მაუწყებლობა

TriggerClientEvent('name', -1, data) ყველა მოთამაშეს უგზავნის. ამის გაკეთება წამში ერთხელ დიდი ცხრილით - სამუშაოს სრული სია, ყველა მოთამაშის ფული - ხარჯავს network thread-ის დროს და კლიენტის დროს ყოველ მანქანაზე. გაგზავნე მხოლოდ ის, რაც შეიცვალა, მხოლოდ იმ მოთამაშეებს, ვისაც სჭირდება, და იმ მნიშვნელობებისთვის, რომლებსაც ბევრი კლიენტი კითხულობს, მაგრამ ცოტა წერს, state bag-ები არჩიე.

სამუშაო პროცესი, რომელიც მიზეზს ერთ საღამოში პოულობს#

1. დაადასტურე ფენა. ჰკითხე სამ მოთამაშეს, დაეცა თუ არა მათი FPS, თუ რაღაცებს rubber-banding ჰქონდა. შეამოწმე კონსოლში hitch-ის გაფრთხილებები იმ დროს, რომელსაც ისინი ასახელებენ.
2. კლიენტის მხარე: სთხოვე ერთ მოთამაშეს, გაუშვას resmon 1 და გადაიღოს სქრინშოტი, როცა ქალაქში უმოქმედოდ დგას, და კიდევ ერთხელ იმ ადგილას, სადაც ლაგავს. ჩაიწერე ყველა resource, რომელიც 0.1 ms-ს აღემატება.
3. სერვერის მხარე: გაუშვი profiler record 500 პიკის საათებში, სანამ ლაგი არსებობს, შემდეგ profiler view. ჩაიწერე ყველაზე განიერი resource-ები.
4. გაყავი შუაზე ის, რასაც ვერ კითხულობ. თუ პროფილი მიუთითებს framework-ის ბირთვზე, რომელსაც ათობით resource იძახებს, გააჩერე არაარსებითი resource-ების ნახევარი (stop name კონსოლში), თხუთმეტი წუთი უყურე hitch-ებს და txAdmin-ის გრაფიკს, შემდეგ დააბრუნე. გაიმეორე იმ ნახევარზე, რომელსაც მნიშვნელობა ჰქონდა.
5. გაასწორე ან ჩაანაცვლე. გამოსწორებების უმეტესობა ზემოთ აღწერილი ციკლების ნიმუშებია. escrow-ით დაცული resource-ები, რომელთა რედაქტირებაც არ შეგიძლია, ავტორს უბრუნდება შენი პროფილით, ან იცვლება.
6. ხელახლა გაზომე. იგივე პირობები, იგივე ბრძანებები. თუ რიცხვი არ შეიცვალა, ცვლილებას მნიშვნელობა არ ჰქონია, რაც არ უნდა ჰპირდებოდეს ფორუმის პოსტი.

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

რა შემოაქვს მანქანას#

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

• CPU-ს წილი. სერვერის სამუშაოში მთავარი thread დომინირებს, ამიტომ სიხშირე ბირთვების რაოდენობაზე მნიშვნელოვანია. მეორე ბირთვი მაინც გეხმარება: sync და network thread-ები, asset-ების მიწოდება და მონაცემთა ბაზის კლიენტი სხვაგან მუშაობს. თუ CPU-ს გრაფიკი პიკისას გეგმის ჭერზე ზის, tick-ები იწელება და hitch-ის გაფრთხილებებიც მოჰყვება.
• მეხსიერება. მეხსიერება resource-ების რაოდენობასა და იმას მისდევს, რასაც ისინი ინახავს, და არა მოთამაშეების რაოდენობას. ის იშვიათად არის ლაგის მიზეზი; როცა ამოიწურება, სერვერი ჩერდება, და ეს სხვა პრობლემაა.
• ობიექტები. OneSync-ით ყოველი მანქანა, ped და ობიექტი, რომელსაც სერვერი ადევნებს თვალს, სინქრონიზაციის დროს ხარჯავს. გარემოს მოსახლეობა, მიტოვებული მანქანები, რომლებსაც არავინ შლის, და სკრიპტების მიერ შექმნილი და არასოდეს გასუფთავებული prop-ები - ყველაფერი გროვდება. OneSync და მოთამაშის სლოტები ხსნის მოსახლეობის პარამეტრებსა და culling-ს.
• stream-ით მიწოდებული asset-ები. მანქანებისა და რუკების დიდი პაკეტები დისკს, გამტარუნარიანობასა და კლიენტის მეხსიერებას ხარჯავს და არა სერვერის CPU-ს. ნელი პირველი შესვლა ჩამოტვირთვის პრობლემაა; მას MLO-ები, რუკები და streaming asset-ები ეხება.

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

uptime, გაჟონვები და დაგეგმილი გადატვირთვები#

FXServer და მასზე მომუშავე framework-ები ხანგრძლივი uptime-ისას უარესდება. Lua heap-ები იზრდება, ობიექტების რაოდენობა თანდათან მატულობს, ქეშები ივსება. სერვერი, რომელიც პირველ ექვს საათს კარგად მუშაობს და მეორე საღამოსთვის ფერხდება, დაგროვებას აჩვენებს და არა ერთ ძვირ handler-ს, და profiler აჩვენებს ბევრ resource-ს, თითოეულს ოდნავ უფრო ნელს, და არა ერთ განიერ ზოლს.

პატიოსანი გამოსწორებაა იპოვო resource, რომლის მეხსიერებაც resmon-ში ან მის საკუთარ ლოგებში იზრდება, და ძებნის პარალელურად განრიგით გადატვირთო. გადატვირთვა ყოველ ექვს-თორმეტ საათში, თამაშში რამდენიმე წუთით ადრე გამოცხადებული, roleplay სერვერებზე ჩვეულებრივი პრაქტიკაა; txAdmin-ის scheduler აკეთებს გამოცხადებასაც და გადატვირთვასაც, ხოლო საათის არჩევის ლოგიკა აღწერილია გადატვირთვის განრიგებში, რომლებიც გეხმარება. ყოველი დაგეგმილი გადატვირთვის წინ ასევე სწორი მომენტია მონაცემთა ბაზის backup-ისთვის, რადგან პერსონაჟები და ფული იქ ინახება.

გადატვირთვა გაჟონვის გამოსწორება არ არის. ის ჭერია იმისთვის, რამდენად ცუდად შეიძლება წავიდეს გაჟონვა. resource-ის ძებნა განაგრძე.

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

resmon ძვირს არაფერს აჩვენებს, მაგრამ მოთამაშეებს მაინც აქვთ rubber-banding. ეს სერვერია ან ქსელი. შეამოწმე hitch-ის გაფრთხილებები ჩივილების დროს და გაუშვი profiler.

profiler აჩვენებს, რომ ერთი framework-ის resource დროის უმეტესობას იყენებს. framework ჩვეულებრივ სხვა resource-ების სახელით მუშაობს - callback-ები, ნივთების გამოყენება, მოთამაშის მონაცემების ძებნა. timeline-ში ერთი დონით ქვემოთ ჩაიხედე, რომელი handler-ები იძახებს მას, ან შუაზე გაყავი მასზე დამოკიდებული resource-ები.

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

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

ლაგი ყოველდღე უარესდება გადატვირთვამდე. გაჟონვა ან ობიექტების დაგროვება. uptime-ის განმავლობაში resmon-ის მეხსიერებას და sync thread-ს უყურე.

ერთი resource ძვირია და escrow-ით დაცული. მისი რედაქტირება არ შეგიძლია. გაუგზავნე ავტორს შენი პროფილი და resmon-ის სქრინშოტი. თუ არ გაასწორა, მისი ჩანაცვლება უფრო იაფია, ვიდრე სერვერის მის გარშემო აწყობა.

FAQ#

რა არის კარგი resmon-ის მნიშვნელობა FiveM-ის resource-ისთვის?

უმოქმედოდ 0.00-დან 0.02 ms-მდე. resource-ები, რომლებიც ყოველ კადრს ხატავს, მაგალითად HUD-ები, გონივრულად შეიძლება ცოტა მაღლა იყოს. resource, რომელიც უმოქმედოდ 0.1 ms-ზე მეტს აჩვენებს, კადრის დროს ფლანგავს, ხოლო ის, რომელიც რეგულარულად 0.5 ms-ს სცდება, თავისთავად პრობლემაა.

აჩვენებს resmon სერვერის მხარის წარმადობას?

არა. resmon ზომავს კლიენტის სკრიპტებს იმ მანქანაზე, სადაც მას უშვებ. სერვერისთვის გამოიყენე hitch-ის გაფრთხილებები კონსოლში, profiler record და profiler view, და txAdmin-ის tick-ის გრაფიკი.

უფრო დიდი გეგმა გამოასწორებს FiveM-ის ლაგს?

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

რას ნიშნავს "server thread hitch warning"?

სერვერის მთავარმა thread-მა, სადაც resource-ები მუშაობს, tick-ებს შორის ჩვეულებრივზე გაცილებით მეტი დრო დახარჯა - რიცხვი ამ დროის ხანგრძლივობაა. რამდენიმე გაშვებისას უვნებელია; სტაბილური ნაკადი, სანამ ხალხი თამაშობს, ნიშნავს, რომ რომელიღაც resource thread-ს ბლოკავს და ის profiler-ით უნდა იპოვო.

რატომ ნელდება ჩემი სერვერი, რაც უფრო დიდხანს მუშაობს?

ჩვეულებრივ, მეხსიერება იზრდება გაჟონვის მქონე resource-ში, ან ობიექტები გროვდება გასუფთავების გარეშე. დაგეგმილი გადატვირთვები ზიანს ზღუდავს, მაგრამ მიზეზი რჩება; მის საპოვნელად დროთა განმავლობაში თითოეული resource-ის მეხსიერებას უყურე.

Wait(0) ყოველთვის ცუდია?

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