Minecraft-ის ლაგის დიაგნოსტიკა spark-ით: MSPT, TPS და მიზეზები

Minecraft სერვერზე ლაგი ბიუჯეტის პრობლემაა. ყოველ tick-ს ორმოცდაათი მილიწამი აქვს მთელი სამყაროს სიმულაციისთვის, და როცა სამუშაო არ ეტევა, tick ჭიანურდება და საათი ჩამორჩება. spark არსებობს იმისთვის, რომ სახელით გითხრას, სად წავიდა ეს ორმოცდაათი მილიწამი: ეს plugin, ეს მეთოდი, ეს entity-ის ტიპი, ეს chunk-ის ჩატვირთვა. პროფაილერთან ათი წუთი კვირას სჯობს, რომელსაც plugin-ებს სათითაოდ იღებ, და კამათს აჩერებს ბმულით და არა აზრით. ქვემოთ არის, როგორ გადაიღო ანგარიში, რომლის კითხვაც ღირს, და როგორ წაიკითხო.

MSPT არის მნიშვნელოვანი რიცხვი და არა TPS#

TPS - tick-ები წამში - რიცხვია, რომელსაც ყველა ასახელებს, და ორიდან ნაკლებად სასარგებლოა. ის 20-ზეა შეზღუდული, რადგან სერვერი თამაშის საათზე სწრაფად არასოდეს იმუშავებს. MSPT, მილიწამები tick-ზე, არის რეალური გაზომვა: რამდენ ხანს გაგრძელდა სამუშაო tick-ში. კავშირი მარტივია. სანამ MSPT 50-ს ქვემოთ რჩება, TPS 20.0-ს აჩვენებს. როგორც კი MSPT 50-ს გადაკვეთს, TPS პროპორციულად ეცემა.

ეს ზღვარი არის მიზეზი, რატომაც TPS ისტორიის საინტერესო ნაწილს მალავს. სერვერი 20.0 TPS-ზე საშუალო MSPT-ით 45 ჯანმრთელი არ არის; ის ერთი დიდი ფერმის, ერთი ახალი plugin-ის ან ერთი დატვირთული შაბათის დაშორებით არის ჩამორჩენისგან, და რიცხვის ნაკარნახევზე უარესად იგრძნობა, რადგან ნახტომები უკვე 50-ს აჭარბებს, თუნდაც საშუალო არა.

საშუალო მეორე ხაფანგია. მოთამაშეები საშუალოს არ ამჩნევენ, მათ ის მომენტი ამჩნევენ, როცა სერვერი წამის მესამედით ჩერდება, სანამ main thread-ზე chunk იტვირთება. ამიტომ შეხედე მაქსიმუმსა და განაწილებას და არა მხოლოდ საშუალოს, და ანგარიში ორ ცალკე კითხვად განიხილე: სერვერი მუდმივად ბიუჯეტს აჭარბებს თუ ნახტომების გარდა კარგადაა? პასუხი წყვეტს, რომელ ინსტრუმენტს მიმართავ. რას ნიშნავს სინამდვილეში tick rate უფრო გრძელად ხსნის, რატომ ხდის ფიქსირებული tick ამას ასეთ დაუნდობელს.

კიდევ ერთი განსხვავება, რომელიც ადრევე ღირს გქონდეს. სერვერის მხარის ლაგი ყველას ერთდროულად აჩერებს, ბლოკები ირღვევა და ბრუნდება, მობები ტელეპორტირდება. კლიენტის მხარის ლაგი ან ცუდი მარშრუტი ერთ მოთამაშესა და სერვერს შორის ერთ ადამიანს ეხება, სხვები კი კარგად არიან. spark სერვერს ზომავს. თუ შენი TPS 20.0-ია, MSPT 15-ია და ვიღაც მაინც უჩივის, არასწორ ადგილას ეძებ - ამის ნაცვლად წაიკითხე latency, jitter და packet loss.

spark-ის დაყენება და სამი ბრძანება, რომლებიც პროფაილინგამდე უნდა გაუშვა#

spark ერთი jar-ია plugins/-ში Paper-სა და Spigot-ზე და mod-ია mods/-ში Fabric-ზე, Forge-სა და NeoForge-ზე. ის ასევე მუშაობს Velocity-სა და BungeeCord-ზე, სადაც backend-ის ნაცვლად proxy-ს აპროფილებს. ზოგიერთ სერვერის პროგრამას ის უკვე მოჰყვება, ამიტომ სანამ რამეს ატვირთავ, აკრიფე /spark კონსოლში. თუ დახმარების შეტყობინება დაგიბრუნდა, ის არის.

ბრძანებებს სჭირდება op ან spark უფლება, კონსოლს კი ის ყოველთვის აქვს. Sampling ასინქრონულია და იაფია - ნორმალურ სერვერზე ბირთვის რამდენიმე პროცენტი - მაგრამ უფასო არ არის და ის ისეთი არ არის, რომ კვირით გაუშვებელი დატოვო.

პროფილის აღებამდე მიიღე პრობლემის ფორმის სურათი:

$ spark tps$ spark health --memory$ spark tickmonitor --threshold 200

თითოეული განსხვავებულ კითხვას პასუხობს.

• /spark tps ბეჭდავს TPS-ს რამდენიმე ფანჯარაზე (5 წამიდან 15 წუთამდე), MSPT-ს ბოლო 10 წამისა და ბოლო წუთისთვის და - ნაწილი, რომელიც გამოგრჩება - CPU-ს გამოყენებას როგორც სისტემისთვის, ასევე ამ სერვერის პროცესისთვის. container-ზე მკაცრი CPU ლიმიტით, პროცესი, რომელიც თავის წილზეა მიჭედებული, მთელი დიაგნოზია: სერვერი ნელ plugin-ს კი არ ელოდება, ბირთვს ელოდება. სერვერი თავისი წილის 100%-ზე ნელია და არა გატეხილი.
• /spark health --memory ამატებს heap-ის გამოყენებას, garbage collection-ის სტატისტიკასა და დისკის ადგილს. ის ერთ ეკრანზე პასუხობს "ეს მეხსიერების პრობლემაა?"-ს.
• /spark tickmonitor --threshold 200 ბეჭდავს ხაზს ყოველი tick-ისთვის, რომელიც საშუალოზე ორჯერ მეტს გრძელდება. დატოვე რამდენიმე წუთით გაშვებული და გაიგებ, ნახტომები რეგულარულია (დაგეგმილი ამოცანა, autosave) თუ დაკავშირებულია იმასთან, რაც მოთამაშემ გააკეთა.

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

პროფილი, რომლის კითხვაც ღირს#

ნაგულისხმევი სტაბილური პრობლემისთვის კარგია:

$ spark profiler start --timeout 300

ის main server thread-ს ხუთი წუთით sample-ს უკეთებს და მერე თავისით ჩერდება, რაც უკეთესია, ვიდრე დაიწყო და დაივიწყო. ხუთი წუთი ონლაინ მოთამაშეებთან სჯობს ოცდაათ წამს ცარიელ სერვერზე; ანგარიში მხოლოდ იმ სამუშაოს შეიცავს, რაც მისი მუშაობისას მოხდა, ამიტომ სერვერი იმ მდგომარეობაში დააპროფილე, რომელზეც ადამიანები უჩივიან.

flag-ები, რომლებიც პასუხს ცვლის:

--only-ticks-over არის ის, რომელიც თავის ადგილს იმსახურებს. ყველა tick-იდან აგებულ ანგარიშში ჭარბობს ჩვეულებრივი სამუშაო, რომელსაც სერვერი წამში 20-ჯერ აკეთებს, და 300 ms გაყინვა, რომელიც რეალურად გაინტერესებს, sample-ების 0.5%-ია. გაუშვი ხელახლა როგორც /spark profiler start --only-ticks-over 100 --timeout 600 და ანგარიში მხოლოდ ცუდ tick-ებს შეიცავს, ამიტომ რაც მათ იწვევდა, უცებ ზევით არის.

გამოიყენე --thread *, როცა main thread უდანაშაულოდ გამოიყურება: chunk-ის გენერაცია, chunk-ის შენახვა და plugin-ის async ამოცანები სხვაგან ცხოვრობს, და plugin, რომელიც "ფონურ" სამუშაოს ასრულებს და დისკს ძირავს, სხვაგან არსად გამოჩნდება. გამოიყენე --alloc, როცა მეხსიერება სწრაფად იზრდება და garbage collection ხილული სიმპტომია, რადგან ეს ანგარიში ასახელებს კოდს, რომელიც ობიექტებს ქმნის და არა კოდს, რომელიც CPU-ს იყენებს.

როცა პროფილი ჩერდება, spark მას ტვირთავს და ბეჭდავს ბმულს მის ვებ viewer-ზე. გაუშვი /spark profiler არგუმენტების გარეშე, რომ ნახო, მხარს უჭერს თუ არა შენი build ფაილში შენახვას - ღირს ცოდნად, თუ ანგარიშში plugin-ებისა და სამყაროების სახელები ისეთია, რომლის გამოქვეყნებაც არ გირჩევნია. ბმული unlisted-ია და არა საიდუმლო.

ანგარიშის კითხვა: sources, flat და call tree#

viewer იხსნება call tree-ზე, რომელიც დასაწყისისთვის ყველაზე ნაკლებად სასარგებლო ხედია. ხედები ამ რიგით გადართე.

Sources დროს მიაწერს plugin-ს ან mod-ს, საიდანაც ის მოვიდა. ეს ხედი პასუხობს კითხვას, რომელიც რეალურად გაქვს. ის აერთიანებს ყველაფერს, რასაც plugin აკეთებს - მისი event handler-ები, დაგეგმილი ამოცანები, სამუშაო, რომელსაც სერვერის შიგნით იწვევს - ერთ პროცენტში. თუ ერთ plugin-ს main thread-ის 35% აქვს, დასრულდა; წადი და წაიკითხე მისი კონფიგურაცია. თუ ზედა ჩანაწერია "Minecraft" ან თავად სერვერი, plugin დამნაშავე არ არის და პრობლემა სამყაროა.

Flat მეთოდებს ალაგებს საკუთარი დროით: რამდენი დრო დაიხარჯა თავად მეთოდში და არა იმაში, რასაც ის იძახებდა. ეს პოულობს კონკრეტულ ცხელ ციკლს. ეს არის ადგილი, სადაც გაიგებ, რომ ფასი საერთოდ "entity-ები" კი არა, pathfinding-ია, ან არა "shop plugin", არამედ ერთი ბაზის query.

All არის სრული ხე და ღირს გახსნად, როგორც კი ეჭვმიტანილი გაქვს, რადგან ის აჩვენებს გზას, რომლითაც სამუშაო იქამდე მივიდა. plugin-ის listener ვანილის მეთოდის ქვეშ გეუბნება, რომ plugin რეაგირებს იმაზე, რასაც სამყარო ხშირად აკეთებს, რაც განსხვავებული გამოსწორებაა, ვიდრე plugin, რომელიც ტაიმერზე საკუთარ საქმეს აკეთებს.

ორი ჩვევა ანგარიშებს კითხვადს ხდის. პირველი, თანამედროვე Paper Mojang-ის საკუთარი mappings-ით მუშაობს, ამიტომ კლასები ჩნდება როგორც ServerLevel და HopperBlockEntity და არა ძველ Spigot build-ებზე არსებული დაბინდული aab.a(); თუ შენი ანგარიში ერთი-ორასოიანი კლასის სახელების კედელია, ამიტომ. მეორე, ანგარიშში პროცენტები დაპროფილებული ფანჯრის პროცენტია და არა tick-ის ბიუჯეტის. thread-ის ორმოცი პროცენტი, რომელიც მხოლოდ 30% იყო დაკავებული, საგანგებო სიტუაცია არ არის.

ხუთი რამ, რასაც ანგარიში ჩვეულებრივ ასახელებს#

თითქმის ყველა ანგარიში ნორმალურ survival სერვერზე ერთ-ერთზე ჩერდება.

• Entity-ების ticking. ეძებე ServerLevel.tickNonPassenger მობების კლასებით და goal ან navigation მეთოდებით ქვეშ. ეს არის მობების ფერმა, სოფლელებით სავსე chunk ან რამდენიმე ასეული ნივთი იატაკზე. Pathfinding ძვირი ნაწილია და უარესდება შეზღუდულ სივრცეებში, სადაც მობს გზა ვერ პოულობს.
• Chunk-ის ჩატვირთვა main thread-ზე. რელიეფი, რომელიც არასოდეს გენერირებულა, გენერირდება, როცა ვინმე მასში შედის, და მიუხედავად იმისა, რომ Paper ამ სამუშაოს დიდ ნაწილს tick-იდან გადააქვს, ჩატვირთვა და განათება მაინც ჯდება. ნიშანი არის ნახტომები, რომლებიც მოთამაშეს მიჰყვება და არა სტაბილური ფასი, ხშირად, როცა ვიღაც elytra-თი დაფრინავს ან ახალი nether პორტალი უკავშირდება. ახალ Paper-ზე /paper syncloadinfo ასახელებს, რა აიძულებს chunk-ს სინქრონულად ჩაიტვირთოს, ხშირად plugin.
• Block entity-ები. Hopper-ები tick-ავენ, მოძრაობს რამე თუ არა, და მათი კედელი, რომელშიც არაფერია, მაინც ჯდება. HopperBlockEntity flat ხედის ზედა ნაწილში ნიშნავს, რომ საცავის სისტემა უნდა გადაიგეგმოს ან შეიზღუდოს.
• Redstone. დიდი საათები და update-ებით მძიმე მექანიზმები ჩნდება როგორც მეზობელი update-ისა და მავთულის მეთოდები. ერთი მოთამაშის ფერმას ბიუჯეტის მეათედი შეიძლება ეკუთვნოდეს.
• დამბლოკავი სამუშაო plugin-ის შიგნით. ყველაზე ცუდი აღმოჩენა და გამოსასწორებლად ყველაზე ადვილი. socket-ის წაკითხვა, ფაილის წაკითხვა ან ვებ მოთხოვნა plugin-ის event handler-ის ქვეშ ნიშნავს, რომ მთელი სერვერი გაჩერდა, სანამ ეს გამოძახება ელოდებოდა. ეკონომიკისა და სტატისტიკის plugin-ები, რომლებიც join-ზე query-ს აკეთებენ, კლასიკური მაგალითია. თამაშში არაფერია არასწორი; plugin არის.

თუ ანგარიში plugin-ს ასახელებს, რომელსაც ვერ ცვლი, მაინც იღებ რამეს: ანგარიშის ბმული სწორედ ის არის, რაც ავტორს გამოსასწორებლად სჭირდება, და ბევრად უფრო დამარწმუნებელია, ვიდრე "შენი plugin ლაგავს".

მეხსიერება, garbage collection და heap-ის შეჯამებები#

მეხსიერების პრობლემები ლაგს ჰგავს, მაგრამ ნელი კოდი არ იწვევს. ნიშანია რეგულარული ნახტომები აშკარა წყაროს გარეშე, პლუს garbage collection-ის დრო health ანგარიშში.

$ spark health --memory$ spark gcmonitor$ spark heapsummary

/spark gcmonitor ბეჭდავს ყოველ collection-ს, როგორც ხდება. მოკლე young-generation პაუზები, ერთნიშნიდან ათეულამდე მილიწამი, ნორმალურია და გარდაუვალი. განმეორებადი გრძელი პაუზები ან heap, რომელიც ჭერთან ზის და collection-ის შემდეგ არასოდეს ეშვება, ნიშნავს, რომ heap სამყაროსთვის პატარაა ან რაღაც ინახავს მითითებებს, რასაც არ უნდა ინახავდეს. /spark heapsummary ჩამოთვლის ცოცხალ ობიექტებს კლასების მიხედვით რაოდენობით, ასე აღმოაჩენ, რომ რეალური პრობლემა 400,000 დაგდებული ნივთია ან plugin, რომელიც ბოლო restart-იდან ყოველ დადებულ ბლოკზე ერთ ობიექტს აგროვებს.

კონტრინტუიციური ნაწილი: უფრო დიდი heap ავტომატურად უკეთესი არ არის. ძალიან დიდი heap ყოველ collection-ს გრძელს ხდის და გაჟონვას მალავს, ნაცვლად იმისა, რომ ამხილოს. heap-ის ზომა სამყაროსა და plugin-ების სიას მიუსადაგე, მინიმუმი მაქსიმუმის ტოლი დააყენე და heap-ის გარეთ დატოვე მარაგი თავად JVM-ისთვის - Minecraft-ის JVM flag-ები და Java ვერსიები რიცხვებს ფარავს, რამდენი RAM სჭირდება Minecraft სერვერს კი ზომის შერჩევას. გახსოვდეს, რომ container-ის მეხსიერების ლიმიტი მთელ პროცესს ეხება და არა მხოლოდ heap-ს, ამიტომ -Xmx შენი გეგმის მეხსიერების ტოლი არის ის, როგორც სერვერები ჩერდება.

chunk-ის ან entity-ის პოვნა რიცხვების უკან#

ანგარიში ამბობს "entity ticking შენი tick-ის 30%-ია". ის არ ამბობს "x 1180, z -2044-ზე". Paper-ის საკუთარი ბრძანებები ამ ხარვეზს ავსებს:

$ paper entity list$ paper mobcaps$ minecraft:debug start$ minecraft:debug stop

/paper entity list ბეჭდავს entity-ების რაოდენობას ტიპების მიხედვით chunk-ის კოორდინატებით, ამიტომ შეგიძლია დაალაგო ყველაზე ცუდი chunk-ის მიხედვით და წახვიდე გადასახედად. ზუსტი სინტაქსი და ფილტრები Paper-ის ვერსიის მიხედვით იცვლება, ამიტომ ჯერ გაუშვი არგუმენტების გარეშე. /paper mobcaps აჩვენებს, რამდენად ახლოსაა თითოეული spawn კატეგორია თავის ლიმიტთან, რაც გეუბნება, ფერმა მთელი სერვერისთვის ბუნებრივი spawn-ის ლიმიტს ატყვევებს თუ არა.

ვანილის საკუთარი პროფაილერიც ისევ არის. /minecraft:debug start და /minecraft:debug stop წერს ანგარიშს debug საქაღალდეში თამაშის შიდა სექციებად დაყოფილი tick-ის დროებით, და ის უკეთესი ინსტრუმენტია datapack-ებითა და ბრძანებებით მძიმე სერვერებისთვის, რადგან დროს ფუნქციებზე ანაწილებს. გაითვალისწინე minecraft: პრეფიქსი: Bukkit-ზე დაფუძნებულ სერვერზე უბრალო /debug შეიძლება სულ სხვა რამეზე გადაწყდეს.

როგორც კი chunk-ი იცი, გამოსწორება ჩვეულებრივ ფიზიკურია. დაზღუდე ფერმა, გაწმინდე ნივთების დაგროვება, გააჭირე hopper-ების ჯაჭვი ან სთხოვე მოთამაშეს ხელახლა აშენება. entity-ების მოცილება უხეში clear-all ბრძანებით მუშაობს და ხალხს აღიზიანებს, ამიტომ წინასწარ გააფრთხილე.

რა შეცვალო და რა რიგით#

ჯერ ყველაზე იაფი, და ყოველი ცვლილების შემდეგ გაზომე და არა ხუთი რამ ერთბაშად შეცვალე და გამარჯვება გამოაცხადე.

1. გაწმინდე დაგროვება, რაც იპოვე, და დაზღუდე, რამაც შექმნა. იატაკზე ნივთების პრობლემა დიზაინის პრობლემაა და არა ჰოსტინგის.
2. დაწიე view-distance და შემდეგ simulation-distance ერთით ან ორით server.properties-ში. ამას ვერავინ ამჩნევს; სერვერი კი ამჩნევს. ეს ყველაზე მაღალი ღირებულების ცვლილებაა უმეტეს პატარა სერვერზე და დეტალურადაა განხილული Paper-ის ოპტიმიზაციის გიდში.
3. გამოასწორე ან ამოიღე plugin, რომელიც ანგარიშმა დაასახელა. ჯერ კონფიგურაცია - მძიმე plugin-ების უმეტესობას აქვს სკანირების ინტერვალი ან რადიუსი, რომლის შემცირებაც შეგიძლია - მერე ამოღება.
4. წინასწარ დააგენერირე სამყარო და დააყენე საზღვარი, რომ კვლევამ თამაშისას რელიეფის გენერაცია შეწყვიტოს. იხილე world border და pregeneration.
5. დაამატე restart განრიგი მხოლოდ იმ შემთხვევაში, თუ მეხსიერება ან MSPT წუთების და არა დღეების განმავლობაში იზრდება. Restart განრიგები, რომლებიც გვეხმარება ხსნის განსხვავებას სასარგებლო restart-სა და ცრურწმენას შორის.
6. მხოლოდ მერე იყიდე მეტი CPU. ეს ყველაზე ძვირი გამოსწორებაა და ყველაზე ნაკლებად სავარაუდოდ ეხმარება, თუ პასუხი plugin იყო, რადგან თამაშის მთავარი ციკლი ერთნაკადიანია და ბირთვებზე არ ნაწილდება.

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

FAQ#

თავად spark იწვევს ლაგს?

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

ჩემი TPS 20-ია, მაგრამ სერვერი მაინც ცუდად გრძნობა. რა ვქნა?

შეხედე მაქსიმალურ MSPT-ს და არა საშუალოს და გაუშვი /spark tickmonitor. სერვერი, რომლის საშუალოც 20 ms-ია და წუთში ორჯერ 400 ms-მდე ნახტება, იდეალურად გამოიყურება და ცუდად თამაშდება. თუ MSPT მართლა თანაბარი და დაბალია, პრობლემა ქსელის გზაა ან კლიენტი და არა სერვერი.

spark უკეთესია, ვიდრე Timings?

ის მეტ კითხვას პასუხობს. Timings გეუბნებოდა, რომელი handler-ები იყო ძვირი; spark რეალურ JVM-ს აპროფილებს, ამიტომ ხედავს garbage collection-საც, დამბლოკავ გამოძახებებს, სხვა thread-ებზე სამუშაოს და ვანილის შიდა ნაწილებს. Paper-ის საკუთარი რჩევა spark-ზე გადავიდა და Timings აღარ არის რეკომენდებული ინსტრუმენტი.

რა არის ნორმალური MSPT პატარა survival სერვერზე?

რამდენიმე მოთამაშით, წინასწარ გენერირებული სამყაროთი და plugin-ების მოკლე სიით ტიპურია 5-დან 20 ms-მდე. ოცდაათიდან ორმოცამდე დატვირთული სერვერია, რომელიც მაინც მუშაობს. ყველაფერი, რაც მუდმივად 50-ს ზემოთაა, რეალურ დროს ჩამორჩება და მოთამაშეები ამას გრძნობენ.

შემიძლია proxy ქსელის დაპროფილება?

დიახ, მაგრამ სწორი პროცესი დააპროფილე. spark Velocity-სა და BungeeCord-ზე proxy-ს ზომავს, რომელიც თითქმის არასოდეს არის tick-ის ლაგის მიზეზი, რადგან სამყაროს არ ასიმულირებს. დააპროფილე backend, რომელზეც მოთამაშეები იყვნენ, როცა გაჭედა. Velocity proxy ქსელები ფარავს, როგორ ერგება ნაწილები ერთმანეთს.

რატომ იზრდება მეხსიერება მაშინაც კი, როცა TPS კარგია?

გარკვეულ ზღვრამდე ეს ნორმალურია: მეტი ჩატვირთული chunk და მეტი გამოკვლეული სამყარო ნიშნავს მეტს შესანახს. ის, რაც ნორმალური არ არის, heap-ია, რომელიც collection-ის შემდეგ არასოდეს ეშვება. გაუშვი /spark heapsummary და შეხედე, რომელ კლასს აქვს დაუჯერებელი რაოდენობის ეგზემპლარი.