რატომ ეცემა Minecraft-ის TPS და როგორ გამოასწორო სწორი თანმიმდევრობით

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

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

TPS, MSPT და რომელს უყურო#

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

ეს ორ რიცხვს იძლევა, და ისინი თანაბრად სასარგებლო არ არის:

• TPS არის tick-ები წამში, 20-ზე შეზღუდული. Paper-ის tps ბეჭდავს საშუალოებს ერთი, ხუთი და თხუთმეტი წუთის განმავლობაში. ეს ჩამორჩენილი ინდიკატორია - როცა ის იცვლება, პრობლემა უკვე გარკვეული ხანია ხდება.
• MSPT არის მილიწამები tick-ზე, რეალური გაზომვა. Paper-ის mspt ბეჭდავს საშუალოს, მინიმუმსა და მაქსიმუმს ბოლო ხუთი წამის, ათი წამისა და წუთის განმავლობაში.

სერვერი, რომელიც 20.0 TPS-ს და 47 MSPT-ს აჩვენებს, ერთი mob farm-იდან არის უბედურებამდე. სერვერი, რომელიც 20.0 TPS-ს და 12 MSPT-ს აჩვენებს, ზრდის სივრცეს ფლობს. TPS ამ ორს ვერ არჩევს; MSPT - შეუძლია. უყურე MSPT-ს და ყველაფერი, რაც სტაბილურად დაახლოებით 35-ს აღემატება, გაფრთხილებად ჩათვალე, მაშინაც კი, როცა ჯერ არაფერი ჩანს გაფუჭებული.

როცა MSPT მართლა 50-ს სცდება, ყველაფერი, რაც თამაშის დროზეა მიბმული, ერთად ნელდება: მოსავალი ნელა იზრდება, ღუმელები ნელა ადნობენ, მობები ნაბიჯებით მოძრაობენ. მოთამაშეები ამას აღწერენ როგორც rubber-banding ან როგორც ბლოკები, რომლებიც გატეხვის შემდეგ ისევ ჩნდება, რაც კლიენტია, რომელიც სამყაროს წინასწარმეტყველებს, სანამ სერვერი დაეწევა. რას ნიშნავს tick rate სინამდვილეში განმარტავს, რატომ ამუშავებენ სხვადასხვა თამაშები ამას სხვადასხვანაირად.

ლაგი, რომელიც საერთოდ TPS არ არის#

entity-ების ლიმიტებზე საღამოს დახარჯვამდე დარწმუნდი, რომ TPS არის პრობლემა. ოთხი გავრცელებული საჩივარი ასე არ არის:

• კლიენტის კადრების სიხშირე. ერთი ადამიანი, რომელიც იჭედება მაშინ, როცა ყველა დანარჩენი კარგადაა, გრაფიკის პრობლემაა, ჩვეულებრივ render distance ან shader-ები. კონსოლში tps ერთ ხაზში წყვეტს.
• Ping და packet loss. მაღალი latency გამოიყურება როგორც დაგვიანება მოქმედებასა და შედეგს შორის, მაგრამ სამყარო გლუვად მოძრაობს. თუ MSPT ჯანმრთელია და სამყაროს ერთი რეგიონის მოთამაშეები ყველა უჩივიან, ეს ქსელია - latency, jitter და packet loss განმარტავს, როგორ გაარჩიო სამიდან რომელი გაქვს.
• Chunk-ების ჩატვირთვა კლიენტზე. რელიეფი, რომელიც ნელა ჩნდება, როცა მოთამაშე დაფრინავს, ხშირად გამტარუნარიანობა და კლიენტის მხარეა და არა სერვერის tick-ები.
• გაჯერებული CPU წილი. container, რომელიც თავის გამოყოფამდეა შეზღუდული, ნელია და არა გატეხილი. RE:NODE-ზე CPU ლიმიტი მკაცრი შეზღუდვაა იმ წილზე, რომელიც იყიდე, ერთი container თითო სერვერზე, და 100%-ზე მდგარი სერვერი არასოდეს არის შეჩერების საფუძველი - მაგრამ უფრო სწრაფადაც არ იმუშავებს. გაზიარებული CPU და ხმაურიანი მეზობლები ამის უფრო ფართო ვერსიაა.

რა ხარჯავს ორმოცდაათ მილიწამს#

ერთი tick-ის შიგნით სერვერი block entity-ებს tick-ს უკეთებს, შემდეგ entity-ებს, შემდეგ ამუშავებს chunk-ების ჩატვირთვას, შემდეგ უშვებს იმას, რაც plugin-ებმა ამ tick-ისთვის დაგეგმეს, და პერიოდულად ინახავს. თითოეულს დამახასიათებელი ჩავარდნის რეჟიმი აქვს.

ორს რიცხვები ეკუთვნის. Entity-ები ჩვეულებრივი პასუხია: mob farm, რომელიც ორ ათას მტრულ მობს ინახავს, ყოველ tick-ზე AI-ს, pathfinding-სა და collision შემოწმებებს ჯდება, ხოლო დაგდებული ნივთები თითო entity-ზე იმაზე უარესია, ვიდრე ხალხი ელის, რადგან ისინი ერწყმიან, ქრებიან და ქვემოთ hopper-ს ამოწმებენ. Chunk-ების გენერაცია კი სერვერის ყველაზე ძვირი ოპერაციაა - ერთი მოთამაშე elytra-ზე წამში დაახლოებით ორმოც ახალ chunk-ს ითხოვს, სწორედ ამიტომაა სამყაროს საზღვარი და წინასწარი გენერაცია ქვემოთ მოცემულ გამოსწორებების სიაში და არა რჩევების ცალკე სამყაროში.

გაზომე, ნუ გამოიცნობ#

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

ინსტრუმენტია spark. ბოლო Paper build-ებს ის მოჰყვება; სხვა შემთხვევაში ეს jar-ია plugins/-ში. გაუშვი spark კონსოლში, რომ ნახო, რომელი გაქვს. ხუთი ბრძანება თითქმის ყველაფერს ფარავს:

spark tpsspark healthreportspark profiler start --timeout 300spark profiler start --timeout 300 --only-ticks-over 100spark heapsummary

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

• spark tps გაძლევს TPS-სა და MSPT პროცენტილებს ერთად, პლუს პროცესის CPU მოხმარებას, რაც არჩევს "სერვერი დაკავებულია" და "მანქანა დაკავებულია".
• spark healthreport არის ერთი გაშვების მიმოხილვა: TPS, MSPT, მეხსიერება, დისკი და თითო სამყაროზე entity-ების, chunk-ებისა და block entity-ების რაოდენობა. აქედან დაიწყე.
• spark profiler start --timeout 300 ხუთი წუთის განმავლობაში იღებს ნიმუშებს და შემდეგ viewer-ის ბმულს აქვეყნებს. დაუშვი, რომ ის მაშინ იმუშაოს, როცა სერვერი მართლა ცუდად იქცევა; მშვიდი სერვერის პროფილი არაფერს გეუბნება.
• --only-ticks-over 100 პიკების საძიებო ვერსიაა: ის მხოლოდ იმ tick-ებს წერს, რომლებიც 100 ms-ზე მეტს გაგრძელდა, რომ ანგარიში ნორმალურ სამუშაოში არ დაიხრჩოს.
• spark heapsummary ჩამოთვლის, რა იკავებს მეხსიერებას class-ების მიხედვით, რითიც გაჟონვას პოულობენ.

viewer-ში დაალაგე self time-ით და წაიკითხე ქვევით, სანამ არ იხილავ რაღაცას, რაც სერვერის საკუთარი კოდი არ არის. plugin-ის package-ის სახელი სიის თავში დიდი self time-ით არის შენი პასუხი. თუ ზედა ჩანაწერები ყველა entity-ების tick-ია ან chunk-ების სამუშაო, პასუხი plugin არ არის და ქვემოთ მოცემული გამოსწორებები გამოიყენება. spark ანგარიშის წაკითხვა რეალურს ხაზ-ხაზ გადის.

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

გამოსწორებები, ყველაზე იაფიდან#

1. გაასუფთავე entity-ების დაგროვება და შეზღუდე ის, რაც მას ქმნის. იპოვე paper entity list-ით, შემდეგ წყაროს მიხედე. kill @e[type=item] გაასუფთავებს დაგდებულ ნივთებს; არასოდეს უბრალო kill @e, რომელიც item frame-ებს, ნახატებს, armour stand-ებს და ყველაფერს, რაც უძრავად დგას, წაიღებს.
2. შეამცირე view და simulation distance ერთით ან ორით. თითქმის არავინ ამჩნევს; სერვერი მაშინვე ამჩნევს. ეს უმეტეს სერვერზე ყველაზე მაღალი ღირებულების ერთი ცვლილებაა.
3. გაამკაცრე entity-ების activation range-ები და mob cap-ები. მობები activation range-ის გარეთ AI-ს გაშვებას წყვეტენ გაქრობის გარეშე, რაც ქცევის მცირე ცვლილებაზე დიდი ეკონომიაა.
4. მიხედე hopper-ებსა და redstone-ს. ორივეს აქვს Paper-ის პარამეტრები, რომლებიც მათ ფასს ამცირებს იმის შეცვლის გარეშე, რისი აშენებაც მოთამაშეებს შეუძლიათ.
5. ამოიღე ან ჩაანაცვლე plugin, რომელიც profiler-მა დაასახელა. თუ ეს ფუნქცია გჭირდება, ჯერ ახალი build შეამოწმე - შესრულების ბაგები სწორდება.
6. დააყენე სამყაროს საზღვარი და წინასწარ დააგენერირე მის შიგნით, რომ კვლევამ პიკის საათებში რელიეფის გენერაცია შეწყვიტოს.
7. heap სწორად დააყენე. მეტი მეხსიერება უფრო სწრაფი არ არის; ძალიან დიდი heap garbage-collection პაუზებს ახანგრძლივებს. container-ში heap-ის გარეთ დაახლოებით 1 GB დატოვე JVM-ისა და ოპერაციული სისტემისთვის. JVM flag-ები და Java ვერსიები flag-ებს შეიცავს, ხოლო რამდენი RAM სჭირდება Minecraft სერვერს - ზომების არჩევას.
8. შემდეგ და მხოლოდ შემდეგ განიხილე უფრო სწრაფი მანქანა. Minecraft-ის tick ციკლი უმეტესად ერთ thread-ზეა, ამიტომ ეხმარება უფრო სწრაფი ბირთვი და არა მეტი ბირთვი - CPU თუ RAM გეიმ სერვერებისთვის არგუმენტს სრულად გადმოსცემს, ხოლო როდის გადახვიდე უფრო დიდ გეგმაზე გვიჩვენებს, როგორ გაიგო, რომ პროგრამული გამოსწორებები ამოგეწურა.

პარამეტრები, რომლებსაც მნიშვნელობა აქვს, ნაგულისხმევებით#

ორი distance პარამეტრი ზუსტად უნდა გაარჩიო, რადგან ხალხი არასწორს ცვლის. view-distance არის, რამდენი chunk იგზავნება თითოეულ კლიენტს - ის გამტარუნარიანობასა და მეხსიერებას ჯდება და მისი შემცირება შესვლას აჩქარებს. simulation-distance არის, რამდენი chunk თითოეული მოთამაშის გარშემო ნამდვილად იღებს tick-ს, და სწორედ ის ჯდება CPU-ში. simulation distance-ის ძალიან შემცირება farm-ებს აჩერებს, როცა მათი მფლობელი კონტროლთან დგას, ამიტომ 5 ან 6 უმეტესი survival სერვერისთვის ქვედა ზღვარია და არა მიზანი.

თანამედროვე Paper build-ზე თითო მოთამაშეზე მობების გაჩენა ნაგულისხმევია, რაც ნიშნავს, რომ mob cap მთელ სამყაროზე კი არა, თითოეული მოთამაშის გარშემო გამოიყენება. ეს ბევრად უკეთ იქცევა გაფანტულ community-სთან და ღირს დადასტურება, სანამ cap-ების შემცირებას დაიწყებ. ამ ფაილების დანარჩენი ნაწილი, key-ბით key-ზე, არის Paper-ის ოპტიმიზაციის გზამკვლევი.

გაშლილი მაგალითი#

Survival სერვერი 6 GB-ზე, თვრამეტი მუდმივი მოთამაშე, ოთხი თვის. საჩივრები ბლოკების გატეხვის შეუძლებლობაზე. tps აჩვენებდა 13.4-ს ერთი წუთის განმავლობაში; mspt საშუალოდ 74-ს და მაქსიმუმს 300-ზე მეტს.

spark healthreport ამბობდა დაახლოებით 11,000 entity-ს overworld-ში, რაც თვრამეტი მოთამაშისთვის იმაზე ოთხ-ხუთჯერ მეტია, რაც უნდა იყოს. paper entity list-მა მათგან 2,100 ორ chunk-ში დაადგინა: ზომბების farm გადავსებული შეგროვების ზონით, პლუს ყველა ნივთი, რაც ის ოდესმე დაუგდია, რადგან hopper კვირების წინ გატყდა და ვერავინ შეამჩნია.

farm-ის გამოსწორებას ათი წუთი დასჭირდა და MSPT 41-მდე ჩამოიყვანა - უკეთესი, მაგრამ არა კარგი. --only-ticks-over 100-ით ხუთწუთიანმა პროფილმა შემდეგ აჩვენა, რომ დარჩენილი პიკები entity-ები კი არა, chunk-ების ჩატვირთვა იყო: ორი მოთამაშე გარე სამყაროს ხაზავდა და რელიეფს განუწყვეტლივ აგენერირებდა. view-distance 10-დან 8-ზე ჩამოვიდა, simulation-distance 10-დან 6-ზე, და საზღვარი 6,000-ზე დაისვა ღამის Chunky გაშვებით მის შიგნით.

მომდევნო საღამოს იგივე თვრამეტი მოთამაშე 19.9 TPS-ზე და 28 MSPT-ზე იყო. არაფერი ყიდულა, არაფერი ამოღებულა და ერთადერთი plugin ცვლილება საერთოდ არავითარი იყო - რაც ჩვეულებრივი შედეგია, როცა profiler-ს სიტყვას ჩეკის წიგნაკამდე აძლევ.

თვალყური, რომ მოთამაშეებზე ადრე შეამჩნიო#

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

რამდენიმე ჩვევა დაფაზე მეტად ფასობს:

• კვირაში ერთხელ გაუშვი spark healthreport და შეინახე რიცხვები. entity-ების რაოდენობის თვის განმავლობაში ზრდა ყველაზე ადრეული გაფრთხილებაა.
• Restart დაგეგმე. ის გაჟონვას არ ასწორებს, მაგრამ მის ზიანს ზღუდავს და chunk-ების მდგომარეობას მოწესრიგებულს ინახავს - restart-ის გრაფიკები, რომლებიც გვეხმარება დროს აღწერს.
• გააკეთე profiling მაშინ, როცა სერვერი ცუდადაა და არა გამოჯანმრთელების შემდეგ. თვის ყველაზე ცუდი საღამოს შენახული ხუთწუთიანი პროფილი ორშაბათს მშვიდ დროს გადაღებულ ათს სჯობს.
• თუ სერვერი ნელდება კი არა, განუწყვეტლივ ჩერდება, ეს სხვა პრობლემაა: მეხსიერება. მეხსიერების ლიმიტზე container ჩერდება და სუფთად თავიდან ირთვება და არა swap-ში რჩება, ხოლო განმეორებადი restart-ები გაფრთხილებას და ავტომატურ ტიკეტს აჩენს. რატომ ირთვება შენი გეიმ სერვერი განუწყვეტლივ თავიდან ამ პრობლემის პოსტია.

FAQ#

რა არის კარგი MSPT?

30-ზე ნაკლები კომფორტულია, 30-დან 45-მდე სერვერია, რომელსაც სივრცე აღარ დარჩა, და 50-ზე მეტი მოთამაშეებისთვის ხილულია, რადგან tick-ები ახლა იმაზე მეტს გრძელდება, რასაც tick-ს უფლება აქვს. საშუალო ნაკლებად მნიშვნელოვანია, ვიდრე მაქსიმუმი - რეგულარული პიკები 200 ms-მდე უარესად იგრძნობა, ვიდრე სტაბილური 40.

აგვარებს მეტი RAM დაბალ TPS-ს?

თითქმის არასოდეს. მეხსიერება ჩავარდნებს და garbage-collection-ის გრძელ პაუზებს ასწორებს; entity-ებისა და chunk-ების სამუშაოზე, რაც CPU-ა, არაფერს აკეთებს. ზედმეტად დიდმა heap-მა შეიძლება ყველაფერი გააუარესოს, რადგან ყოველ collection-ს ახანგრძლივებს. სანამ რამეს დახარჯავ, MSPT მეხსიერების მოხმარებასთან შეადარე.

დაეხმარება ნაკლები plugin?

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

რატომ არის TPS 20, მაგრამ სერვერი მაინც ლაგავს?

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

აგვარებს restart TPS-ს?

ის entity-ების დაგროვებას ასუფთავებს, chunk-ებს გადმოტვირთავს და მოჟონავ heap-ს განულებს, ამიტომ ჩვეულებრივ გარკვეული ხნით ეხმარება. თუ TPS რამდენიმე დღეში პროგნოზირებადად უარესდება, ღამის restart გონივრული საშუალებაა, მაგრამ ის, რაც უარესდება, ისევ იქაა და ღირს მისი პოვნა.

შეუძლია ერთ მოთამაშეს დაბალი TPS გამოიწვიოს?

ადვილად. ერთ ადამიანს, რომელიც გენერირებადი რელიეფისკენ დაფრინავს, ან საკუთარ farm-ში დგას, მთელი სერვერის დაწევა შეუძლია. ეს ერთ-ერთი ყველაზე სასარგებლო რამაა, რასაც paper entity list და იმ დროს გადაღებული პროფილი გაჩვენებს.