როცა Garry's Mod-ის სერვერი ლაგავს, მიზეზი თითქმის ყოველთვის Lua-ა - ერთი addon, რომელიც ყოველ tick-ზე ზედმეტ სამუშაოს აკეთებს, ან ყოველ tick-ზე შეცდომას ისვრის - ან ფიზიკა, ერთმანეთს მიკრული ზედმეტად ბევრი prop-ის გამო. იშვიათად არის აპარატურის ბრალი და თითქმის არასოდეს სწორდება მხოლოდ უფრო დიდი გეგმით. მომუშავე მეთოდი მოკლეა: კონსოლში მოძებნე განმეორებადი Lua-ს შეცდომები და გაასწორე ან მოაშორე addon, რომელიც მათ ისვრის, გაზომე სერვერის frame time stats-ით, სანამ ლაგი მიმდინარეობს, დააპროფილე hook-ები profiler addon-ით, რომ ძვირი იპოვო, და როცა სხვა არაფერი ასახელებს დამნაშავეს, ტესტ ასლზე addon-ების სია შუაზე ჰყავი. შემდეგ დააყენე გონივრული tickrate, prop-ების ლიმიტები და ღამის გადატვირთვა, რომ გასწორებული დარჩეს. ეს გზამკვლევი თითოეულ ნაბიჯს ბრძანებებით გადის.
სად იხარჯება დრო Garry's Mod-ის სერვერზე#
Garry's Mod-ის სერვერი თამაშის სიმულაციას ერთ thread-ზე უშვებს. ყოველ tick-ზე - წამში 66-ჯერ -tickrate 66-ზე, 33-ჯერ -tickrate 33-ზე - ის უშვებს ფიზიკას, ობიექტების ლოგიკას და ყოველ Lua hook-ს, რომელიც gamemode-მა და addon-ებმა დაარეგისტრირეს, შემდეგ კი მოთამაშეებს განახლებებს უგზავნის. თუ ერთი tick-ის სამუშაოს tick-ის ინტერვალზე მეტი დრო სჭირდება (15 ms 66 tick-ზე), სერვერი ჩამორჩება და მოთამაშეები ამას rubber-banding-ად, დაგვიანებულ გასროლებად და ათრთოლებულ prop-ებად გრძნობენ.
| ხარჯის წყარო | ტიპური სიმპტომი | სად ვეძებოთ |
|---|---|---|
| Lua hook, რომელიც ყოველ tick-ზე მძიმე სამუშაოს აკეთებს | ლაგი, რომელიც მოთამაშეების რაოდენობასთან ერთად იზრდება | Profiler, addon-ების განახევრება |
| Lua-ს შეცდომა hook-ის შიგნით | კონსოლის spam, მუდმივი მსუბუქი ლაგი | კონსოლი, შეცდომების ლოგი |
| ფიზიკა: ბევრი prop კონტაქტში | ლაგი, როცა ვინმე აშენებს ან გროვა ინგრევა | prop-ების რაოდენობა, ფიზიკის პარამეტრები |
| Net შეტყობინებები: ერთდროულად ზედმეტად ბევრი | მოთამაშეები overflow შეცდომებით ითიშებიან | კლიენტის კონსოლი, addon-ების განახევრება |
| ბაზის query-ები მთავარ thread-ზე | ნახტომები შესვლისას, სიკვდილისას ან რაუნდის ბოლოს | SQL-ის მომხმარებელი addon-ები, sv.db-ის ზომა |
| მეხსიერების წნეხი | ავარია საათების ან დღეების შემდეგ | მეხსიერების გრაფიკი, 32-ბიტიანი თუ 64-ბიტიანი |
რიგს მნიშვნელობა აქვს. Lua-ს შეცდომები ყველაზე იაფად იპოვება და ყველაზე ხშირია, ამიტომ იქიდან დაიწყე. Garry's Mod-ის სერვერის აწყობა საბაზო ინსტალაციას და დიაგნოსტიკის პირველ გავლას ხსნის; ეს სტატია უფრო ღრმად მიდის.
Lua-ს შეცდომების კითხვა#
Lua-ს შეცდომა სერვერის კონსოლში ფაილით, ხაზით და stack trace-ით იბეჭდება:
[ERROR] addons/coolhud/lua/autorun/server/sv_hud.lua:42: attempt to index a nil value 1. fn - addons/coolhud/lua/autorun/server/sv_hud.lua:42 2. unknown - lua/includes/modules/hook.lua:96ზემოდან წაიკითხე. პირველი ხაზი ამბობს, რომელი ფაილი და ხაზი ჩავარდა და რატომ; გზა addon-ს ასახელებს (აქ coolhud, ან Workshop addon-ის სათაური Workshop კონტენტისთვის). stack აჩვენებს, რამ გამოიძახა - hook.lua ნიშნავს, რომ hook-იდან გაეშვა, რაც ნიშნავს, რომ შემდეგ tick-ზეც გაეშვება, და მომდევნოზეც.
ხშირი შეტყობინებები და რას ნიშნავს ისინი ჩვეულებრივ:
| შეტყობინება | ჩვეული მიზეზი |
|---|---|
attempt to index a nil value | კოდმა ივარაუდა, რომ მოთამაშე, ობიექტი ან ცხრილი არსებობდა, და არ არსებობდა |
attempt to call a nil value | სხვა addon-ის ფუნქცია ან წაშლილი API აკლია |
attempt to compare number with nil | კონფიგის მნიშვნელობა ან ქსელური ცვლადი არასოდეს დაყენებულა |
Tried to use a NULL entity! | ობიექტი წაიშალა, სანამ კოდი ჯერ კიდევ იყენებდა |
bad argument #1 to ... | გადაეცა არასწორი ტიპი, ხშირად მას შემდეგ, რაც Garry's Mod-ის განახლებამ რამე შეცვალა |
stack overflow | უსასრულო რეკურსია, ხშირად ორი addon, რომლებიც ერთმანეთს hook-ავენ |
წარმადობისთვის ყველაზე მნიშვნელოვანი შეცდომაა ის, რაც ყოველ tick-ზე გაშვებული hook-ის შიგნით ხდება. თავად შეცდომის დამმუშავებელი დროს ხარჯავს, კონსოლი spam-ით ივსება და ლოგი იზრდება. ერთ გაფუჭებულ HUD addon-ს, რომელიც Think hook-ში ყოველი მოთამაშისთვის შეცდომას ისვრის, შეიძლება დანარჩენ addon-ების სიაზე ერთად მეტი დაჯდეს.
შეცდომები, რომელთა წაკითხვაც მოგვიანებით შეიძლება
დატვირთულ სერვერზე ცოცხალი კონსოლი ზედმეტად სწრაფად ტრიალებს საკითხავად. ორი პარამეტრი გეხმარება:
con_logfile "console.log"lua_log_sv 1con_logfile ყველაფერს, რასაც კონსოლი ბეჭდავს, ფაილში წერს garrysmod/-ის ქვეშ, ხოლო lua_log_sv 1 სერვერს სთხოვს, თავისი Lua-ს შეცდომებიც დალოგოს. ორივე ფაილი იზრდება; კვირაში ერთხელ წაშალე ან დაატრიალე. კონსოლის კითხვა ხსნის, რომელ ხაზებს აქვს მნიშვნელობა და რომელია ხმაური.
კლიენტის მხარის შეცდომები - HUD-ებში, მენიუებში და ეფექტებში - ყოველი მოთამაშის მანქანაზე ხდება და მათ კონსოლში ჩანს და არა შენსაში. თუ მოთამაშეები აცხადებენ შეცდომებს, რომლებსაც ვერასოდეს ხედავ, სთხოვე მათი კონსოლის სქრინშოტი lua_log_cl 1-ის აკრეფის შემდეგ; შეცდომაში გზა მაინც addon-ს ასახელებს.
შეცდომიანი addon-ის გასწორება ან მოშორება#
როცა კონსოლი addon-ს დაასახელებს, ოთხი ვარიანტია, უპირატესობის რიგით:
- განაახლე. ბევრი შეცდომა ჩნდება მას შემდეგ, რაც Garry's Mod-ის განახლებამ API შეცვალა, და ავტორს უკვე გაუსწორებია. Workshop addon-ები გადატვირთვისას თავად ახლდება; legacy addon-ები
garrysmod/addons/-ში - არა. - შეამოწმე კონფლიქტი. addon, რომელიც მარტო მუშაობს და სხვასთან ერთად ვარდება, ჩვეულებრივ ნიშნავს, რომ ორივე ერთსა და იმავე ფუნქციას ან hook-ის სახელს გადაფარავს. მოაშორე მეორე და გამოცადე.
- თავად გაასწორე. თუ Lua-ს კითხულობ, ფაილიც და ხაზიც იქვეა. nil-ის შემოწმება (
if not IsValid(ent) then return end) რეალური შეცდომების დიდ ნაწილს ასწორებს. - მოაშორე. მიტოვებული addon, რომელიც ყოველ tick-ზე შეცდომებს ისვრის, შენახვად არ ღირს. გააუქმე მისი გამოწერა კოლექციიდან ან წაშალე მისი საქაღალდე.
ნუ ჩააჩუმებ შეცდომებს ყველგან pcall-ში შეფუთვით. ეს შეცდომას მალავს და ხარჯს ტოვებს.
გაზომვა: stats, status და profiler#
ლაგს, რომელიც არ გაგიზომავს, ვერ გაასწორებ. სამი ინსტრუმენტი, ყველაზე იაფიდან ყველაზე დეტალურამდე.
stats სერვერის კონსოლში ბეჭდავს CPU-ის მოხმარებას, შემომავალ და გამავალ ტრაფიკს, uptime-ს, რუკის შეცვლების რაოდენობას და სერვერის frame rate-ს. გაუშვი ლაგის დროს. თუ frame rate tickrate-ზე დაბალია, სერვერი ვერ ასწრებს - სერვერის პრობლემაა. თუ tickrate-ზეა და მოთამაშეები მაინც ჩივიან, ამის ნაცვლად მათ კავშირს და net შეტყობინებებს შეხედე.
status მოთამაშეებს მათი ping-ით და loss-ით ჩამოთვლის. ერთი მოთამაშე 400 ms-ით და loss-ით იმ მოთამაშის მარშრუტია; ყველა 400 ms-ზე სერვერია. latency, jitter და packet loss განსხვავებას ხსნის.
profiler აჩვენებს, რომელი Lua ფუნქციები ხარჯავს დროს. FProfiler Garry's Mod-ის პროფილირების დიდი ხნის addon-ია: დააყენე, დაიწყე ჩაწერა, სანამ სერვერი დატვირთულია, შეაჩერე წუთის შემდეგ, და ის ყველაზე ძვირ hook-ებს და ფუნქციებს მათი ჯამური და საშუალო დროით ჩამოთვლის. ეს სია ჩვეულებრივ გადამწყვეტია - ერთი addon-ის ერთი hook თავში, ნებისმიერ სხვაზე ათჯერ მეტი ხარჯით.
სწრაფი შემოწმებები lua_run-ით სერვერის კონსოლიდან ასევე სასარგებლოა:
lua_run print(#ents.GetAll())lua_run print(#player.GetAll())lua_run print(collectgarbage("count"))პირველი ობიექტების რაოდენობას ბეჭდავს, რაც sandbox ან DarkRP სერვერზე გეუბნება, გროვდება თუ არა prop-ები. ბოლო Lua-ს მეხსიერებას ბეჭდავს კილობაიტებში; თუ ის საათების განმავლობაში სტაბილურად იზრდება და არასოდეს ეცემა, addon ცხრილებს ჟონავს.
addon-ის ფასი: რა ხდის addon-ს ძვირს#
ზოგი ნიმუში საიმედოდ ძვირია, და მათი profiler-ის შედეგში ამოცნობა დროს ზოგავს:
- ყოველ tick-ზე ციკლები მოთამაშეებზე ან ობიექტებზე.
ThinkანTickhook, რომელიც იძახებსplayer.GetAll()-ს ანents.FindInSphere-ს და ყოველ შედეგზე სამუშაოს აკეთებს. 10 მოთამაშეზე იაფი, 60-ზე ძვირი. - ტაიმერები პაწაწინა ინტერვალებით.
timer.Create0ან0.01დაყოვნებით, სამუდამოდ განმეორებადი. ფაქტობრივად კიდევ ერთი ყოველ tick-ზე გაშვებული hook. - ქსელი hook-ებში. net შეტყობინებების გაგზავნა ყველა მოთამაშისთვის ყოველ tick-ზე, ან დიდი ცხრილების გადაცემა. გამტარუნარიანობასაც ხარჯავს და CPU-საც და overflow გათიშვებს იწვევს.
- ფაილებსა და SQL-ზე წვდომა hook-ებში. ფაილების კითხვა ან წერა, ან
sql.Query-ის გაშვება ლოკალურ SQLite ბაზაზე ხშირ hook-ში. ორივე თამაშის thread-ს ბლოკავს. - ფიზიკით დატვირთული ობიექტები. მანქანები, თოკები, wire კონსტრუქციები და ყველაფერი, რაც ბევრ ფიზიკურ ობიექტს აჩენს.
როცა არაფერი აშკარა არ ჩანს, ჰყავი შუაზე. გააკეთე სერვერის ასლი ტესტ ინსტანციაზე, მოაშორე addon-ების ნახევარი და იმავე დატვირთვაზე გაზომე. განაგრძე განახევრება, სანამ ლაგი ერთ addon-ს არ მიჰყვება. ეს მოსაწყენია, და ეს ერთადერთი მეთოდია, რომელიც ყოველთვის მუშაობს.
ტიპური შემთხვევა, თავიდან ბოლომდე
roleplay სერვერი ოც მოთამაშეზე კარგად მუშაობს და ორმოცზე ფეხს ითრევს. კონსოლში არაფერია. stats პიკის დროს აჩვენებს, რომ სერვერის frame rate ოცის დაბალ ნიშნულამდე ეცემა 33-იან tickrate-თან შედარებით, ასე რომ სერვერი მართლა ჩამორჩება. ერთწუთიანი profiler-ის ჩანაწერი თავში ერთ ფუნქციას აყენებს: HUD-თან ახლოს მდგომი addon-ის hook-ს, რომელიც ყოველ tick-ზე ყველა მოთამაშეს გადაუვლის და თითოეულისთვის ყველა ობიექტს, რომ უახლოესი კარი იპოვოს. ორმოცი მოთამაშე გამრავლებული რამდენიმე ათას ობიექტზე, წამში 33-ჯერ.
ამ hook-ში არაფერი იყო გაფუჭებული. ის მუშაობდა, შეცდომებს არ ისროდა და ოც მოთამაშეზე tick-ზე მილიწამი ჯდებოდა. ორმოც მოთამაშეზე ფასი ოთხჯერ გაიზარდა, რადგან ორივე სია გაორმაგდა. გამოსავალი იყო იგივე შემოწმების გაშვება წამში ერთხელ ყოველი tick-ის ნაცვლად, რასაც addon-ის კონფიგი იძლეოდა და არავის შეუხედავს. frame rate tickrate-ს დაუბრუნდა, გეგმა კი არ შეცვლილა.
ეს არის Garry's Mod-ის წარმადობის პრობლემების უმეტესობის ფორმა: არა ბაგი, არამედ სამუშაო, რომელიც მოთამაშეები გამრავლებული ობიექტებით იზრდება, დამალული addon-ში, რომელიც გაშვებისას უვნებლად გამოიყურებოდა. profiler მას წუთებში პოულობს; გამოცნობას კვირები სჭირდება.
ფიზიკა, prop-ები და ლიმიტები#
ფიზიკაც ყოველ tick-ზე მუშაობს და არაწრფივად ძვირდება: ასი უძრავად მწოლიარე prop იაფია; ასი prop, ერთად დაგროვილი და ერთმანეთს მიკრული - არა, რადგან ყოველი კონტაქტი ყოველ tick-ზე გამოითვლება. sandbox და roleplay სერვერებზე ყველაზე ცუდი ლაგი ჩვეულებრივ ერთი მოთამაშის კონსტრუქციიდან ან შეგნებული prop-ების გროვიდან მოდის.
sbox_maxprops 150sbox_maxragdolls 5sbox_maxvehicles 2sbox_maxeffects 50sbox_maxballoons 10sbox_maxthrusters 20sbox_noclip 1ეს ლიმიტები თითო მოთამაშეზეა. შეინარჩუნე ისინი იმდენად დაბლა, რამდენადაც შენი gamemode იძლევა; sandbox სერვერს sbox_maxprops 1000-ით და ოცდაათი მოთამაშით თეორიულად ოცდაათი ათასი prop-ის დატევა შეუძლია. დაამატე prop-ების გასუფთავება გათიშვისას შენს ადმინის მოდში ან გასუფთავების addon-ით, და განიხილე anti-crash addon, რომელიც prop-ებს ყინავს, როცა ერთდროულად ზედმეტად ბევრი ეჯახება. TTT და სხვა რაუნდებზე დაფუძნებული რეჟიმები ყოველ რაუნდზე სუფთავდება და ამის გაცილებით ნაკლები სჭირდებათ. TTT სერვერის გზამკვლევი სპეციალურად ამ gamemode-ს ხსნის.
Tickrate, ჰიბერნაცია და მეხსიერება#
-tickrate გაშვების ხაზში განსაზღვრავს, რამდენ tick-ს უშვებს სერვერი წამში. 66 უფრო გლუვია; 33 tick-ზე ხარჯს ანახევრებს და მაინც კარგია roleplay-სა და sandbox-ისთვის, სადაც ზუსტი დამიზნება ნაკლებად მნიშვნელოვანია. დააყენე ის ცხადად და ნუ დაეყრდნობი ნაგულისხმევს.
| Gamemode | გონივრული tickrate | რატომ |
|---|---|---|
| Sandbox, DarkRP, roleplay | 33 | ბევრი ობიექტი, დამიზნება ნაკლებად მნიშვნელოვანია |
| TTT, Murder, Prop Hunt | 33-66 | რაუნდებზე დაფუძნებული, ობიექტების ზომიერი რაოდენობა |
| ბრძოლაზე ორიენტირებული gamemode-ები | 66 | დამიზნება და hit registration მნიშვნელოვანია |
tickrate-ის აწევა tick-ზე CPU-ის ხარჯს დაახლოებით აორმაგებს და სერვერისთვის, რომელიც უკვე ჩამორჩება, არაფერს ცვლის. ჯერ ხარჯი გაასწორე, შემდეგ კი აწიე სიხშირე, თუ მარაგი გაქვს. რას ნიშნავს სინამდვილეში tick rate უფრო ვრცელ არგუმენტს გთავაზობს.
ცარიელი Garry's Mod-ის სერვერი ნაგულისხმევად ჰიბერნაციაში გადადის და CPU-ს თითქმის არ ხარჯავს. sv_hibernate_think 1 ცარიელსაც მუშაობის რეჟიმში ინახავს, რაც ზოგ addon-ს სჭირდება; თუ შენი უმოქმედო სერვერი სტაბილურ CPU მოხმარებას აჩვენებს, შეამოწმე, დაყენებულია თუ არა ეს, ან ხომ არ უშვებს რომელიმე addon ტაიმერს მიუხედავად ამისა.
მეხსიერების პრობლემები სხვანაირად გამოიყურება. სტანდარტული Garry's Mod-ის სერვერი 32-ბიტიანი პროცესია, ამიტომ მხოლოდ დაახლოებით 4 GB-ის მიმართვა შეუძლია, რამდენიც არ უნდა ჰქონდეს გეგმას; დიდი კოლექციები ამ ჭერს ეჯახება და out-of-memory შეცდომებით ვარდება, მაშინ როცა გრაფიკი კარგად გამოიყურება. x86-64 beta branch ამ ლიმიტს ხსნის, იმის ფასად, რომ ნებისმიერ ბინარულ მოდულს 64-ბიტიანი build სჭირდება. ლოკალური SQLite ბაზა, garrysmod/sv.db, კიდევ ერთი ნელი ჟონვაა: ზოგი addon მასში მუდმივად წერს, და ასობით მეგაბაიტის ფაილი ყოველ query-ს ანელებს. პერიოდულად შეამოწმე მისი ზომა და გაასუფთავე ან გადაიტანე მონაცემები, რომლებსაც addon-ები იქ ინახავს.
გადატვირთვები, ავარიები და გასწორებულის შენარჩუნება#
კარგად მორგებული Garry's Mod-ის სერვერიც კი დღეების განმავლობაში აგროვებს ობიექტებს, ტაიმერებს და Lua-ს მეხსიერებას. ღამის გადატვირთვა ცარიელ საათზე frame time-ს თანაბრად ინარჩუნებს და არაფერი ჯდება. RE:NODE-ზე Schedules ჩანართი მას cron გამოსახულებით უშვებს, რამდენიმე წუთით ადრე არჩევითი გამაფრთხილებელი ბრძანებით. გადატვირთვის განრიგები, რომლებიც მართლა გეხმარება დროის შერჩევას ხსნის.
ავარიები ლაგისგან ცალკე პრობლემაა. Lua-ს შეცდომა სერვერს არ ავარდნის; ავარია მოდის ბინარული მოდულიდან, ფიზიკის აფეთქებიდან, 32-ბიტიანი მეხსიერების ჭერიდან ან პროცესის გაჩერებიდან გეგმის მეხსიერების ლიმიტზე. RE:NODE-ზე სერვერი, რომელიც მეხსიერების ლიმიტს აღწევს, ჩერდება და სუფთად ეშვება და swap-ზე არ რჩება, ხოლო დამკვირვებელი მოულოდნელ გადატვირთვებს ითვლის - სამი საათში სერვერის გვერდზე გაფრთხილებას აჩენს და ტიკეტს ავტომატურად ხსნის, ასე რომ ავარიების ციკლი შეუმჩნეველი არ რჩება. რატომ გადაიტვირთება შენი თამაშის სერვერი სულ ამ შემთხვევების გარჩევაში გეხმარება.
პრობლემების მოგვარება#
კონსოლი ერთი და იმავე Lua-ს შეცდომითაა სავსე. ერთი addon hook-ში. წაიკითხე გზა პირველ ხაზში, განაახლე ან მოაშორე ეს addon და გადატვირთე.
ლაგი მხოლოდ მაშინ, როცა სერვერი სავსეა. თითო მოთამაშის ხარჯი. დააპროფილე პიკზე; ეძებე hook-ები, რომლებიც მოთამაშეებს გადაუვლის.
ლაგის ნახტომები, როცა ვინმე შემოდის. addon-ები, რომლებიც PlayerInitialSpawn-ზე ბაზასთან ან ფაილებთან მუშაობენ, ან დიდი sv.db. დააპროფილე შესვლა.
მოთამაშეები "reliable channel overflowed"-ით ითიშებიან. addon ერთბაშად ზედმეტს აგზავნის, ჩვეულებრივ spawn-ზე. მოაშორე addon-ები, სანამ არ შეწყდება; კლიენტის კონსოლი ბოლო მიღებულ შეტყობინებას აჩვენებს.
სერვერი საათების შემდეგ ვარდება, თუმცა მეხსიერება თავისუფალია. 32-ბიტიანი მისამართების სივრცე. შეამცირე addon-ები ან გადადი 64-ბიტიან branch-ზე შესაბამისი მოდულებით.
უმოქმედო სერვერი CPU-ს ხარჯავს. sv_hibernate_think 1, ან addon-ის ტაიმერი, რომელიც მოთამაშეების გარეშე მუშაობს.
FAQ#
Lua-ს შეცდომები ლაგს იწვევს?
შეცდომას, რომელიც ერთხელ ხდება, მნიშვნელობა არ აქვს. შეცდომას hook-ის შიგნით, რომელიც ყოველ tick-ზე მუშაობს, აქვს, რადგან შეცდომის დამმუშავებელი ყოველ ჯერზე ეშვება, კონსოლი და ლოგი კი ივსება. ჯერ განმეორებადი შეცდომები გაასწორე.
რა tickrate უნდა გამოიყენოს Garry's Mod-ის სერვერმა?
33 sandbox-ისა და roleplay-სთვის, 33-დან 66-მდე რაუნდებზე დაფუძნებული რეჟიმებისთვის, 66 ბრძოლაზე ორიენტირებული gamemode-ებისთვის. ჩაწერე ის გაშვების ხაზში ცხადად და აწიე მხოლოდ მაშინ, როცა სერვერს პიკზე CPU-ის მარაგი აქვს.
უფრო დიდი გეგმა ჩემს ლაგს გაასწორებს?
მხოლოდ თუ სერვერს addon-ების პრობლემების გასწორების შემდეგ მართლა აკლია CPU ან მეხსიერება. ერთი ძვირი hook ან ერთმანეთს მიჯახებული prop-ების გროვა ნებისმიერ აპარატურაზე ილაგებს. ჯერ გაზომე, შემდეგ ზომა შეარჩიე.
როგორ ვიპოვო, რომელი addon იწვევს ლაგს?
კონსოლში მოძებნე განმეორებადი შეცდომები, შემდეგ გამოიყენე profiler, მაგალითად FProfiler, სანამ სერვერი დატვირთულია. თუ არცერთი არ ასახელებს დამნაშავეს, ტესტ ასლზე addon-ების ნახევარი მოაშორე და გაზომე, და გაიმეორე, სანამ ლაგი ერთ addon-ს არ მიჰყვება.
64-ბიტიანი Garry's Mod-ის სერვერი უნდა გავუშვა?
თუ შენი სერვერი მეხსიერების შეცდომებით ვარდება, მაშინ როცა გეგმას მეხსიერება ჭარბად აქვს, კი. ჯერ შეამოწმე, რომ ყოველ ბინარულ მოდულს, რომელსაც იყენებ, 64-ბიტიანი build აქვს.
კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.