Minecraft plugin-ები, რომლებიც ღირს დაყენება, და ისინი, რომლებიც ძვირი გიჯდება

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

რა ჯდება plugin სინამდვილეში#

Plugin-ები მეხსიერებაში იაფია და დროში ძვირი. ტიპური jar არის რამდენიმე მეგაბაიტი კლასი პლუს რასაც ქეშავს; ოცი მათგანი შენს მეხსიერების გრაფიკს ვერ დაძრავს. რისთვისაც ისინი ერთმანეთს ეჯიბრებიან, არის tick.

სერვერი ყველაფერს ერთ thread-ზე, თანმიმდევრობით აკეთებს: entity-ების მოძრაობა, redstone, ბლოკების განახლებები, შემდეგ ყოველი plugin-ის დაგეგმილი დავალება და ყოველი event handler, რომელიც გააქტიურდა. თუ ჯამი 50 ms-ს აჭარბებს, tick გადაჭარბდება და TPS ეცემა. Paper-ზე /mspt მიმდინარე ფასს პირდაპირ გიჩვენებს და ის TPS-ზე გაცილებით ადრეული გაფრთხილებაა - სერვერი, რომელიც 45 ms-ზე დგას, ისევ 20.0 TPS-ს აჩვენებს და ერთი მობ ფერმიდან არის თვალსაჩინო ლაგამდე.

სამი კონკრეტული ქცევა plugin-ს ძვირად აქცევს:

• განმეორებადი დავალებები მთავარ thread-ზე. plugin, რომელიც წამში ერთხელ ყველა ჩატვირთულ chunk-ს სკანირებს, აკეთებს სამუშაოს, რომელიც პროპორციულია შენი მოთამაშეების რაოდენობისა და view distance-ისა, ყოველ წამს, სამუდამოდ.
• სინქრონული ბაზის query-ები. მთავარ thread-ზე მოთხოვნა მთელ სერვერს ბლოკავს, სანამ არ დაბრუნდება. თუ query 200 ms გრძელდება, სერვერმა ოთხი tick დაკარგა. შესვლის handler-ები კლასიკური დამნაშავეებია.
• Event handler-ები ცხელ event-ებზე. BlockPhysicsEvent, EntityMoveEvent და chunk-load event-ები ძალიან ხშირად ირთვება. handler, რომელიც მათგან რომელიმეზე რამე არატრივიალურს აკეთებს, გადასახადია ყველაფერზე.

ამ ყველაფერს არ აქვს ის აზრი, რომ plugin-ები აარიდო. აქვს ის აზრი, რომ იცოდე, რისთვისაა თითოეული და მზად იყო, ერთი წაშალო.

ოთხი, რომელიც თითქმის ყველა სერვერს სჭირდება#

უფლებების plugin პირველია, რადგან ყველაფერს დანარჩენს არ აქვს გზა, ჰკითხოს, ვინ არის ვინმე. LuckPerms არის ნაგულისხმევი პასუხი და წლებია ასეა: ჯგუფები მემკვიდრეობით, კონტექსტები თითო სამყაროსა და თითო სერვერზე, track-ები დაწინაურებისთვის, ვებ რედაქტორი და - ფუნქცია, რომელიც რეალურად გიშველის - /lp verbose on, რომელიც ყოველ უფლების შემოწმებას ბეჭდავს, როგორც ხდება, ასე რომ ხედავ ზუსტად რომელ node-ს ითხოვს plugin და არ გამოიცნობ.

$ lp creategroup moderator$ lp group moderator parent add default$ lp group moderator permission set coreprotect.inspect true$ lp user Steve parent add moderator$ lp editor

ნაგულისხმევად ის H2 ფაილში ინახავს, ამიტომ დასაწყებად სხვა არაფერი გჭირდება, და მუშაობს Paper-ზე, Velocity-ზე, Fabric-სა და Forge-ზე, რაც მნიშვნელოვანია, თუ ოდესმე proxy ქსელამდე გაიზრდები. LuckPerms-ის გზამკვლევი კონტექსტებსა და მემკვიდრეობას ჯეროვნად ფარავს, ხოლო whitelist-ები და უფლებები მის ზემოთ არსებულ შრეს.

მიწის დაცვა აჩერებს საზოგადოების დაშლის ყველაზე გავრცელებულ მიზეზს. მისი ორი ფორმა არსებობს და უმეტეს სერვერს ორივე უნდა:

• Claim-ზე დაფუძნებული - GriefPrevention არის სტანდარტი. მოთამაშეები ოქროს ნიჩბით აცხადებენ ტერიტორიას, დროთა განმავლობაში იღებენ claim ბლოკებს და წვდომას მართავენ /trust, /containertrust და /accesstrust-ით. თითო claim-ზე ადმინის სამუშაო არ არის, რაც მთელი აზრია.
• რეგიონზე დაფუძნებული - WorldGuard, რომელსაც გვერდით WorldEdit სჭირდება. ადმინი ირჩევს ტერიტორიას და აყენებს flag-ებს: /rg define spawn, შემდეგ /rg flag spawn pvp deny. ასე იცავ spawn-ს, მაღაზიებს და event-ის არენებს.

ბლოკების ლოგირება rollback-ით „ვიღაცამ ქალაქი დაწვა“-ს კატასტროფიდან ბრძანებად აქცევს. CoreProtect არის ის: /co inspect რეჟიმს რთავს, სადაც ბლოკზე დაწკაპუნება მის ისტორიას ბეჭდავს, /co lookup u:Steve t:3d r:10 ეძებს, /co rollback u:Steve t:2h r:20 კი აუქმებს. ნაგულისხმევად ის SQLite ფაილში წერს. გრიფინგისგან დაცვა და ანტიჩიტი ამ ინსტრუმენტთა ნაკრების დანარჩენ ნაწილს განიხილავს.

Profiler, რომ როცა სერვერი ნელდება, შეგეძლოს გიპასუხო რატომ და არა გამოიცნო. spark არის ის, ის უფასოა და ერთნაირად მუშაობს Paper-ზე, Fabric-ზე, Forge-სა და Velocity-ზე.

/spark profiler start... play for five minutes .../spark profiler stop/spark health/spark heapsummary

profiler stop ბეჭდავს ბმულს flame graph-ზე, რომელიც ასახელებს plugin-ს, mod-ს ან სისტემას, რომელიც tick-ს ჭამს. health ბეჭდავს TPS-ს, MSPT-სა და მეხსიერებას ერთად. heapsummary გეუბნება, რომელი კლასები ინახავენ heap-ს, ასე იჭერ plugin-ის ქეშს, რომელიც მარტიდან იზრდება. spark-ის ანგარიშის კითხვა განმარტავს, რას უყურებ.

Profiler კამათს იმაზე, რომელი plugin არის ნელი, სქრინშოტად აქცევს.

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

Plugin-ების დაყენება, განახლება და წაშლა#

მექანიკა მარტივია და შეცდომები მუდმივი.

1. ჩამოტვირთე plugin-ის საკუთარი გვერდიდან. Hangar, SpigotMC, Modrinth ან პროექტის GitHub releases. Plugin არის თვითნებური კოდი შენს სერვერზე, მის ფაილებსა და ბაზის credential-ებზე სრული წვდომით. აგრეგატორ საიტზე ხელახლა ატვირთული ასლი რისკს არ ღირს - მოდიფიცირებული სერვერის სისუფთავე ამ არგუმენტის უფრო გრძელი ვერსიაა.
2. შეამოწმე ვერსია, რომელსაც ის ითხოვს. 1.20-ისთვის აგებული plugin შეიძლება 1.21-ზე არ ჩაიტვირთოს. ჩამოტვირთვის გვერდი მხარდაჭერილ დიაპაზონს ამბობს; მას დაუჯერე და არ იმედოვნო.
3. jar ჩააგდე `plugins/`-ში და გადატვირთე. პანელზე ეს ფაილ მენეჯერი ან SFTP-ა, შემდეგ Restart ღილაკი.
4. `/reload` არ გამოიყენო. ის ტოვებს ნახევრად გამოტვირთულ კლასებს, რომლებიც ობიექტებზე მიუთითებენ, რომლებიც აღარ არსებობს, და ქმნის ბაგებს, რომლებიც ყველაფერს ჰგავს, გარდა იმისა, რაც სინამდვილეში არის. Plugin მენეჯერები, რომლებიც jar-ების ცხელ ჩანაცვლებას აცხადებენ, იგივე პრობლემა აქვთ უფრო ლამაზი ინტერფეისის უკან. სერვერი გადატვირთე.
5. წაიკითხე გენერირებული კონფიგურაცია. პირველი გაშვება ქმნის plugins/<Name>/config.yml-ს. უმეტესი plugin ნაგულისხმევებით მოდის, რომლებიც დიდი საჯარო სერვერისთვისაა მორგებული, შენგან კი უმეტესობა ასეთს არ უშვებ.
6. წასაშლელად გააჩერე სერვერი, წაშალე jar და გადაწყვიტე მონაცემთა საქაღალდეზე. plugins/<Name>/-ის დატოვება არაფერი ღირს და გაძლევს საშუალებას, აზრი შეიცვალო. მისი წაშლა მუდმივია და CoreProtect-ის მსგავსზე ეს შენი მთელი ისტორიაა.

/plugins ჩამოთვლის, რა არის ჩატვირთული; წითლად დაბეჭდილი ყველაფერი ვერ ჩაირთო და მიზეზი გაშვების დროს კონსოლშია. კონსოლის კითხვა განიხილავს, სხვა რა ღირს იქ შესამჩნევად.

შემდეგი ექვსი, როცა მოთამაშეები გეყოლება#

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

EssentialsX არის მხარდაჭერილი fork; ორიგინალი Essentials წლებია მიტოვებულია და გზამკვლევები, რომლებიც მასზე ბმულობენ, ძველია. დააყენე core პლუს მხოლოდ მოდულები, რომლებიც გინდა - EssentialsXChat და EssentialsXSpawn ჩვეული წყვილია. მისი დაცვის მოდულები WorldGuard-სა და GriefPrevention-ს ემთხვევა და ორი დაცვის სისტემის გაშვება კამათს წარმოშობს, რომელსაც არცერთი იგებს. EssentialsX, Vault და ეკონომიკები ფულის მხარეს ფარავს, და თუ რამის გაყიდვას გეგმავ, წაიკითხე მონეტიზაცია წესების ფარგლებში, სანამ ფასს დააწესებ.

Chunky სიაში ყველაზე მაღალი ღირებულების plugin-ია დაყენების წუთზე, რადგან წინასწარ არაგენერირებული რელიეფი survival სერვერზე „შემთხვევითი“ ლაგის მწვერვალების უდიდესი მიზეზია. დააყენე საზღვარი, წინასწარ გააგენერირე მის შიგნით და მწვერვალები ქრება:

/chunky world world/chunky center 0 0/chunky radius 5000/chunky quiet 30/chunky start

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

ვებ რუკები არის plugin კატეგორია, რომელიც ყველაზე ხშირად უკვირს ხალხს დისკისა და I/O-ის ანგარიშით. Dynmap ქმნის ფილების სურათებს და ნაგულისხმევად 8123 პორტზე ემსახურება; BlueMap აგებს 3D მოდელს, ემსახურება 8100-ზე და საწყისი რენდერისას ძვირია, მერე იაფი; squaremap არის მსუბუქი 2D ვარიანტი. ყველას მეორე პორტის გამოყოფა სჭირდება, რაც ამ პანელზე Network ჩანართზე რამდენიმე დაწკაპუნებაა, რადგან Minecraft გეგმები ერთს მოიცავს. Dynmap, BlueMap და squaremap შედარებით დეტალებია.

ანტიჩიტს გაფრთხილება ეკუთვნის და არა რეკომენდაცია. პაკეტებზე დაფუძნებული ანტიჩიტი მართლა CPU-ს ჭამს, CPU კი გეიმ გეგმაზე მკაცრი წილია და არა burst. ის ასევე ცრუ დადებითს იძლევა მაღალი latency-ის მოთამაშეებზე და Bedrock მოთამაშეებზე, რომლებიც Geyser-ით შემოდიან, რადგან მათი მოძრაობის წესები იგივე არ არის. თუ ერთს უშვებ, ჯერ ლოგირების რეჟიმში გაუშვი და კვირის განმავლობაში წაიკითხე, რას გააკეთებდა, სანამ ვინმეს გაგდების საშუალებას მისცემ.

Backup, რომელიც მართლა თანმიმდევრულია#

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

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

კატეგორიები, რომლებიც ძვირი გიჯდება#

ამათგან ზოგი ცალ-ცალკე დასაცავია. ყველა გავრცელებულია და ყველა ეჭვის ღირსია.

• ყველაფერი, რაც ტაიმერზე სკანირებს. Entity-ების მთვლელები, chunk-ების გამწმენდები, „ლაგის შემამცირებლები“. ისინი შენს სამყაროზე პროპორციულ სამუშაოს აკეთებენ ყოველ რამდენიმე წამში, იცვლება რამე თუ არა.
• Entity-ების გამწმენდები. ClearLag-ის ნიმუში - ყოველ ხუთ წუთში ყველა დაგდებული ნივთის წაშლა - პრობლემას მალავს და მოთამაშეების ნივთებს შლის. რეალური გამოსავალია ფერმის ან კარიერის პოვნა, რომელიც მათ აწარმოებს. Paper-ს უკვე შეუძლია ნივთების გაერთიანება და გაჩენის შეზღუდვა spigot.yml-სა და config/paper-world-defaults.yml-ში plugin-ის გარეშე.
• ნაგულისხმევზე დარჩენილი ბლოკის ლოგერები. CoreProtect ღირს, მაგრამ დატვირთულ სერვერზე ყველა კონტეინერისა და ნივთის ტრანზაქციის ლოგირება ჩაწერის დიდი მოცულობაა. გამორთე კატეგორიები, რომლებსაც არასოდეს მოძებნი, და გაუშვი /co purge t:30d განრიგით.
• ყველაფერი-ერთში plugin-ები. jar, რომელიც ორმოც ფუნქციას აერთიანებს, რომ სამს გამოიყენებ, არის ოცდაჩვიდმეტი ფუნქციის event handler-ები, რომლებიც არ გითხოვია.
• მიტოვებული plugin-ები. ყველაზე საშიში კატეგორიაა, რადგან ჩვეულებრივ მუშაობს, სანამ აღარ იმუშავებს. plugin, რომელიც შენი ვერსიისთვის არ განახლებულა, შეიძლება ჩაიტვირთოს, კარგად ჩანდეს და მერე კონკრეტულ event-ზე გატყდეს ან ჩუმად დააზიანოს მონაცემები. შეამოწმე ბოლო release-ის თარიღი დაყენებამდე და შეამოწმე მთელი შენი სია ვერსიის განახლებამდე.
• ბევრი plugin ერთი საქმისთვის. ორი დაცვის plugin, ორი ჩატის ფორმატერი, ორი ეკონომიკა Vault-ის უკან. რომელიც მეორე ჩაიტვირთება, ჩვეულებრივ იმარჯვებს, არათანმიმდევრულად.
• დამატებით ჩატვირთული სამყაროები. Multiverse კარგია, მაგრამ ყოველი ჩატვირთული სამყარო საკუთარ spawn chunk-ებს რეზიდენტულად ინახავს, არის თუ არა იქ ვინმე.

იმის დამტკიცება, რომელი plugin არის ნელი#

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

1. ჯერ `/mspt`. თუ ის კომფორტულად 50-ზე ქვემოთაა, შენი პრობლემა უწყვეტი დატვირთვა არ არის - ეს პერიოდული მწვერვალია და მე-3 ნაბიჯი მას იპოვის.
2. `/spark profiler start`, ითამაშე ცუდ ქცევაზე, `/spark profiler stop`. წაიკითხე flame graph ყველაზე ფართო ზოლიდან ქვევით. Plugin-ების სახელები საკუთარ package-ად ჩანს, ამიტომ დამნაშავე ჩვეულებრივ ოცდაათ წამში ცხადია.
3. `/spark profiler start --timeout 60`, თუ პრობლემა ტაიმერზე ხდება და გჭირდება ნიმუში, რომელიც თავად ჩერდება და იტვირთება.
4. `/spark heapsummary`, თუ სიმპტომი მეხსიერებაა. plugin, რომელიც ასობით მეგაბაიტ ქეშირებულ ობიექტს ინახავს, აქ ჩანს და სხვაგან არსად.
5. მხოლოდ მერე დაიწყე წაშლა, ერთდროულად ერთი, თითოს შორის გადატვირთვით. ხუთის ერთდროულად წაშლა არაფერს გეუბნება.

გახსოვდეს, რომ ყველა შენელება plugin არ არის. View distance, არაგენერირებული რელიეფი, entity ფერმა და უბრალოდ ძალიან პატარა CPU წილი ყველა ლაგს ჰგავს. რატომ ეცემა TPS და რა გააკეთო plugin-ისგან განსხვავებულ მიზეზებს გადის, ხოლო სერვერი, რომელიც თავის CPU ლიმიტზეა მიჯაჭვული, ნელია და არა გატეხილი.

FAQ#

რამდენი plugin არის ძალიან ბევრი?

რიცხვი არ არსებობს. ოცდაათმა მსუბუქმა plugin-მა შეიძლება სამ მძიმეზე ნაკლები დაგიჯდეს. მნიშვნელოვანი გაზომვა MSPT-ია: თუ ის დაახლოებით 35-ზე ქვემოთაა შენი ჩვეული მოთამაშეების რაოდენობით, სივრცე გაქვს. თუ 50-თან ახლოსაა, არ გაქვს, საქაღალდეში რამდენი jar არ უნდა იყოს.

იყენებენ plugin-ები ბევრ RAM-ს?

იშვიათად. უმეტესი რამდენიმე მეგაბაიტ კლასს პლუს თავის ქეშებს ხარჯავს. გამონაკლისებია ვებ რუკები, ბლოკის ლოგერები დიდი მეხსიერებაში რიგებით და ყველაფერი, რაც region ან chunk მონაცემებს ქეშავს. რასაც plugin-ები მართლა ხარჯავენ, არის მთავარი thread-ის დრო.

შემიძლია plugin-ების დაყენება გადატვირთვის გარეშე?

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

იმუშავებს plugin-ები Fabric-ის ან Forge-ის სერვერზე?

არა. Plugin-ები Bukkit-ისა და Paper-ის API-ს იყენებენ, რომელსაც mod loader-ები არ ახორციელებენ. ზოგ ნაცნობ ინსტრუმენტს ცალკე mod ვერსია აქვს - მათ შორის LuckPerms-ს და spark-ს - მაგრამ ეკოსისტემა არ გადადის. Paper, Fabric თუ vanilla ამ გადაწყვეტილებას ფარავს.

რომელი plugin დავაყენო პირველი?

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

მჭირდება backup plugin?

არა, თუ შენი ჰოსტი backup-ებს მანქანის გარეთ აკეთებს. plugin, რომელიც არქივებს იმავე დისკზე წერს, იცავს დაზიანებული სამყაროს ფაილისგან და სხვა არაფრისგან - არა წაშლილი სერვერისგან, არა ცუდი აღდგენისგან, არა ფაილ მენეჯერში შეცდომისგან. გამოიყენე პანელის backup-ები და მათ წინ დაგეგმე save-all flush.