Minecraft Paper-ის ოპტიმიზაცია: კონფიგები, რომლებიც TPS-ს ასწორებს

Paper-ის ნაგულისხმევი მნიშვნელობები კარგია. ეს პირველია, რაც უნდა გაიგო, სანამ შენს სერვერში ვინმეს "ოპტიმიზებულ კონფიგებს" ჩააკოპირებ: ყუთიდან ამოღებულ მნიშვნელობებს ისინი ირჩევენ, ვინც Minecraft-ს პროფესიონალურად აპროფილებს, ინტერნეტში მოძრავი კონფიგ-პაკეტების უმეტესობა კი სამი ვერსიით ძველია და იმ ქცევას, რაც შენთვის მნიშვნელოვანია, tick-ის დროში ცვლის, რომელიც არც გჭირდება. რეალური და დიდი მოგება ცოტაა და ის ძირითადად დისტანციას ეხება: რა მანძილზე უგზავნის სერვერი chunk-ებს, რა მანძილზე ატიკებს მათ და რამდენ mob-ს ინახავს ცოცხლად ამ რადიუსში.

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

ხუთი ფაილი და რომელი რას განაგებს#

Paper სერვერი არის Bukkit Spigot-ის შიგნით Paper-ის შიგნით და თითოეულმა ფენამ საკუთარი კონფიგურაცია შეინარჩუნა. ისინი ამ თანმიმდევრობით იტვირთება, ამიტომ სადაც ემთხვევა, უფრო გვიანდელი ფაილი იმარჯვებს.

ნებისმიერ სამყაროს შეუძლია Paper-ის ნაგულისხმევების გადაფარვა საკუთარი <world>/paper-world.yml-ით, და spigot.yml-ში იგივე იდეაა world-settings.<name>-ის სახით world-settings.default-ის ქვეშ. გამოიყენე ეს, როცა Nether-ს Overworld-ისგან განსხვავებული რიცხვები სჭირდება, რაც ჩვეულებრივ არ სჭირდება.

ორი გაფრთხილება გზამკვლევების მიყოლაზე, ამის ჩათვლით. Paper ვერსიიდან ვერსიამდე გასაღებებს ამოძრავებს და სახელს უცვლის - ერთი paper.yml 1.19-ის ეპოქაში config/ საქაღალდე გახდა და ცალკეული პარამეტრები მას შემდეგაც გადაინაცვლა. ყოველთვის გახსენი შენი სერვერის მიერ შექმნილი ფაილი და გასაღები მოძებნე, ბლოკის ჩაკოპირების ნაცვლად. და paper-global.yml-ში unsupported-settings ამ სახელს უმიზეზოდ არ ატარებს; ამ გზამკვლევში მას არაფერი ეხება.

თუ არ წაგიკითხავს server.properties-ის ყველა გასაღები ახსნილი, იქიდან დაიწყე, რადგან სამი ყველაზე დიდი ბერკეტიდან ორი ამ ფაილშია და არა Paper-ისაში.

View distance და simulation distance#

ეს არის მთელი თამაში. ყველაფერი დანარჩენი ამ გზამკვლევში რამდენიმე პროცენტს ღირს; ეს ორი - მამრავლს.

view-distance=8simulation-distance=6

View distance არის, რამდენ chunk-ზე მოშორებით ტვირთავს სერვერი ყოველი მოთამაშის გარშემო, ინახავს მეხსიერებაში და უგზავნის ქსელით. ფართობი კვადრატულია, ამიტომ ფასი რიცხვის პროპორციული არ არის: 10-დან 8-ზე დაწევა თითო მოთამაშეზე ჩატვირთული chunk-ების დაახლოებით მესამედს აშორებს, 10-დან 6-ზე - თითქმის ორ მესამედს. ოცი ადამიანის მქონე სერვერზე, რომლებიც რუკაზე გაფანტულნი არიან, ეს განსხვავებაა 8,400 და 3,000 ჩატვირთულ chunk-ს შორის.

Simulation distance, რომელიც 1.18-ში view distance-იდან გამოიყო, არის მანძილი, სადაც chunk-ები მართლა tick-ავს - mob-ების AI, მოსავლის ზრდა, redstone, hopper-ები, ღუმელები, წყლის დინება. მისი შემცირება ორს შორის უფრო იაფია, რადგან მოთამაშეები ამას ვერ ხედავენ. ფასი ფერმებია: რაც ყველა ონლაინ მოთამაშის simulation distance-ის გარეთაა, ჩერდება, ამიტომ simulation-distance=4-ზე AFK თევზის ფერმა ისე გაფუჭდება, რომ შენი მოთამაშეები ამას bug-ად მოგახსენებენ.

გონივრული წყვილები იმის მიხედვით, რამდენად დატვირთულია სერვერი:

• წყნარი სერვერი, ათზე ნაკლები მოთამაშე: view-distance=10, simulation-distance=8. ნაგულისხმევს ხელი არ ახლო.
• ჩვეულებრივი SMP, ათიდან ოცდახუთამდე მოთამაშე: view-distance=8, simulation-distance=6.
• დატვირთული სერვერი, ოცდაათი ან მეტი: view-distance=6, simulation-distance=5. ამაზე დაბლა ნისლი და უეცარი გამოჩენა გატეხილს გავს.
• მინი-თამაშის ან lobby სერვერი: view-distance=5 ან ნაკლები, simulation-distance=4. lobby-ში არავინ ფერმერობს.

Paper-ს ორივეს გადაფარვა თითო სამყაროზე spigot.yml-ში შეუძლია, სადაც view-distance და simulation-distance ყუთიდან მნიშვნელობას default იღებს. lobby სამყარო 4-ზე და survival სამყარო 8-ზე ერთსა და იმავე სერვერზე - კანონიერი და ეფექტური მოწყობაა.

ერთი დაკავშირებული პარამეტრი: entity-broadcast-range-percentage server.properties-ში, ნაგულისხმევად 100. ის განსაზღვრავს, რა მანძილზე იგზავნება entity-ები კლიენტებზე, view distance-ის პროცენტად. 75-მდე დაწევა გადატვირთულ სერვერზე entity-ების packet ტრაფიკს შესამჩნევად ამცირებს, სანაცვლოდ mob-ები და დაგდებული ნივთები გვიან ჩნდება, როცა უახლოვდები. ეს უფრო გამტარუნარიანობისა და კლიენტის მხარის მოგებაა, ვიდრე tick-ის დროის.

Mob-ების spawn, რაც დანარჩენის უმეტესობაა#

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

spawn-limits:  monsters: 70  animals: 10  water-animals: 5  water-ambient: 20  water-underground-creature: 5  axolotls: 5  ambient: 15ticks-per:  animal-spawns: 400  monster-spawns: 1  water-spawns: 1  ambient-spawns: 1  autosave: 6000

ეს ნაგულისხმევია. მათ შეცვლამდე უნდა იცოდე, რომ Paper-ის per-player-mob-spawns ნაგულისხმევად ჩართულია და ის რიცხვების მნიშვნელობას ცვლის: ლიმიტები სამყაროზე კი არა, თითო მოთამაშეზე ხდება. ეს გაცილებით უკეთესი სისტემაა - გამოქვაბულში მყოფი ერთი მოთამაშე რუკის დანარჩენ ნაწილს spawn-ებს აღარ ართმევს - მაგრამ ეს ნიშნავს, რომ monsters: 70 სამყაროს 70-იანი ჭერი არ არის, ეს ბიუჯეტია, რომელსაც თითო მოთამაშე ატარებს. ოცდაათმოთამაშიან სერვერზე ეს ბევრი ზომბია.

რისი შეცვლა ღირს:

• monsters: 70 დაწიე 40-მდე ან 50-მდე სერვერზე, სადაც ოცზე მეტი მოთამაშეა. mob ფერმები ნაკლებს გამოიმუშავებს; tick-ის დრო პროპორციულად დაეცემა.
• ticks-per.monster-spawns: 1 აწიე 2-მდე. ეს ნახევრად ამცირებს, რამდენად ხშირად სრულდება spawn-ის მცდელობა. ეს ერთ-ერთი ყველაზე იაფი მოგებაა და თამაშში განსხვავება ძნელი შესამჩნევია.
• ticks-per.autosave: 6000 ხუთი წუთია. დატოვე, თუ პერიოდულ ნახტომს არ ხედავ; ამ შემთხვევაში იხილე chunk-ების განყოფილება ქვემოთ და ინტერვალს ნუ გაზრდი - გრძელი ინტერვალი უფრო დიდ ჩავარდნას და ავარიისას უფრო მეტ დაკარგულ სამუშაოს ნიშნავს.

spigot.yml-ში mob-spawn-range ნაგულისხმევად 8 chunk-ია. ის არასოდეს უნდა აღემატებოდეს შენს simulation distance-ს, რადგან ticking რადიუსის გარეთ დასპავნილი mob-ები უაზროა. მისი simulation-distance-ზე ერთით ნაკლებზე დაყენება spawn-ს იქ კონცენტრირებს, სადაც მოთამაშეები მართლა არიან.

spigot.yml-ში nerf-spawner-mobs: false spawner-ებიდან გამოსულ mob-ებს AI-ს გარეშე entity-ებად აქცევს - ისინი არსებობენ, მათ დაზიანება და მოკვლა შეიძლება და არც გზას ეძებენ, არც ფიქრობენ. grinder-ებით სავსე სერვერზე ეს რეალური დანაზოგია და grinder-ების მუშაობას თვალსაჩინოდ ცვლის, ამიტომ გადაწყვიტე მოთამაშეებთან ერთად და არა მათ მაგივრად.

და ბოლოს, entities.spawning.despawn-ranges paper-world-defaults.yml-ში აკონტროლებს vanilla-ს რბილ და მკაცრ despawn მანძილებს, ნაგულისხმევად 32 და 128 ბლოკი. მკაცრი დიაპაზონის დაახლოებით 96-მდე დაწევა იმ mob-ებს აშორებს, რომელთა გვერდითაც მოთამაშე არ არის. ეს ეხმიანება ფერმების დიზაინებს, რომლებიც mob-ების შენარჩუნებას ემყარება, ამიტომ გამოსცადე.

Entity-ების activation და tracking range#

ეს ორი spigot.yml-შია და მუდმივად ერთმანეთში ერევა.

entity-activation-range:  animals: 32  monsters: 32  raiders: 48  misc: 16  water: 16  villagers: 32  flying-monsters: 32entity-tracking-range:  players: 48  animals: 48  monsters: 48  misc: 32  other: 64  display: 128

Activation range არის, რამდენად ახლოს უნდა იყოს მოთამაშე, რომ entity საერთოდ tick-ავდეს. მის გარეთ entity არსებობს, მაგრამ არ მოძრაობს, გზას არ ეძებს და არ ფიქრობს. Tracking range არის, რამდენად ახლოს უნდა იყოს მოთამაშე, რომ entity საერთოდ გაუგზავნო - კლიენტის მხარისა და გამტარუნარიანობის საკითხია.

CPU-ს სწორედ activation range ზოგავს. animals-ისა და monsters-ის 24-მდე, ხოლო misc-ის 12-მდე დაწევა დატვირთულ სერვერზე გავრცელებული და უსაფრთხო მორგებაა. თვალსაჩინო შედეგია, რომ mob-ები "იღვიძებენ", როცა უახლოვდები და არა უკვე მოძრაობაში არიან, რაც თამაშის დროს ძირითადად უხილავია და ძალიან თვალშისაცემია, თუ mob ფერმას შორიდან უყურებ. raiders ნუ დაწევ - raid-ები შორიდან უნდა მოგიახლოვდნენ და დაბალი მნიშვნელობა მათ ტეხს.

Tracking range ძირითადად გამტარუნარიანობას ხარჯავს და არა tick-ის დროს. თუ შენი სერვერი CPU-ზე კარგადაა, მაგრამ მოთამაშეები ბორძიკზე უჩივიან, როცა ეკრანზე ბევრი entity არის, animals-ისა და monsters-ის 32-მდე დაწევა მათ შენზე მეტად ეხმარება.

ორი დაკავშირებული პუნქტი იმავე ფაილში: merge-radius (ნაგულისხმევი item: 2.5, exp: 3.0) განსაზღვრავს, რამდენად აგრესიულად ერწყმის დაგდებული ნივთები და გამოცდილების ორბები ერთ entity-დ. item-ის 4.0-მდე აწევა დიდი ფერმების მქონე სერვერზე entity-ების რაოდენობას მნიშვნელოვნად ამცირებს, გვერდითი ეფექტია, რომ რამდენიმე ბლოკზე გაფანტული ნივთები ერთმანეთს ეკვრის, რაც ოდნავ უცნაურად გამოიყურება. და item-despawn-rate: 6000 ხუთი წუთია tick-ებში; alt-item-despawn-rate paper-world-defaults.yml-ში საშუალებას გაძლევს ქვაფენილი და სხვა ნაგავი დანარჩენზე სწრაფად despawn-ო, რაც ზუსტად სწორი ხელსაწყოა სამაღაროვო სერვერისთვის.

Hopper-ები, redstone და chunk-ების მუშაობა#

Hopper-ები plugin პროფილებში ყველაზე გადაჭარბებით წარმოდგენილი ლაგის წყაროა, რადგან ყოველი hopper გრაფიკით ამოწმებს ნივთებს, იქ რამე იყოს თუ არა.

ticks-per:  hopper-transfer: 8  hopper-check: 1

hopper-check: 1 ნიშნავს, რომ ყოველი hopper ყოველ tick-ზე ეძებს ნივთებს, რომლებიც ზემოთ მდებარე კონტეინერიდან უნდა გამოიღოს. მისი 8-ზე დაყენება, გადატანის სიხშირესთან შესაბამისობაში, ამ მუშაობას რვაჯერ ამცირებს და hopper-ები ნივთებს ოდნავ ნაკლები მონდომებით იღებენ. ნივთების დამახარისხებელი სისტემების მქონე სერვერზე ეს ერთ-ერთი უდიდესი ცალკეული ცვლილებაა.

paper-world-defaults.yml-ში hopper.disable-move-event: true Paper-ს უშლის ხელს, hopper-ების გადატანებისთვის Bukkit-ის inventory move event გააშვოს. ბევრი hopper-ის მქონე სერვერზე ეს დიდი მოგებაა და ტეხავს ნებისმიერ plugin-ს, რომელიც ამ event-ს უსმენს - მათ შორის ზოგ shop, logging და anti-dupe plugin-ს. ჩართვამდე შეამოწმე შენი plugin-ების სია.

Redstone-ს საკუთარი იმპლემენტაციის პარამეტრი აქვს, misc.redstone-implementation paper-world-defaults.yml-ში, ნაგულისხმევად vanilla. alternate-current არის გადაწერილი მტვრის განახლების ალგორითმი, რომელიც დიდ redstone ნაგებობებზე დრამატულად უფრო სწრაფია და პრაქტიკულად ყველა რეალურ წრედში იდენტურად იქცევა. eigencraft უფრო ძველი ალტერნატივაა. ტექნიკურ სერვერზე alternate-current თითქმის უფასო მოგებაა; vanilla-პურისტულ სერვერზე დატოვე.

Chunk-ების მუშაობა მეორე პერიოდული ხარჯია. paper-world-defaults.yml-ში:

• chunks.max-auto-save-chunks-per-tick ნაგულისხმევად 24-ია. 8-მდე დაწევა autosave-ს მეტ tick-ზე ანაწილებს და ერთ თვალსაჩინო ჩავარდნას უფრო პატარა, უფრო გრძელ ფონურ ხარჯად აქცევს. ეს არის სწორი გამოსავალი პრობლემისთვის "სერვერი ყოველ ხუთ წუთში ბორძიკობს".
• chunks.entity-per-chunk-save-limit ზღუდავს, მოცემული ტიპის რამდენი entity ინახება თითო chunk-ზე. experience_orb-ის, arrow-ისა და snowball-ის 50-ის მსგავს მნიშვნელობაზე დაყენება იცავს სერვერს გაყინვისგან, როცა chunk, რომელმაც ათი ათასი ორბი დააგროვა, იტვირთება.
• chunks.delay-chunk-unloads-by ნაგულისხმევად 10s-ია და chunk-ებს უშლის გადმოტვირთვასა და ხელახლა ჩატვირთვას, როცა მოთამაშე საზღვარზე წინ და უკან დადის. დატოვე.

paper-global.yml-ში chunk-loading-basic.player-max-chunk-generate-rate ნაგულისხმევად შეუზღუდავია. მისი დაახლოებით წამში 10 chunk-ზე დაყენება იცავს სიტუაციას, როცა ერთი მოთამაშე elytra-თი ახალ რელიეფზე მთელ chunk generation ბიუჯეტს ხარჯავს, სანამ ყველა დანარჩენის სამყარო ჩერდება. თუ ახალი რელიეფის შესწავლა რეგულარული საჩივარია, ეს არის პარამეტრი. კიდევ უკეთესია, რელიეფი წინასწარ დააგენერირო - სამყაროს საზღვრები და წინასწარი გენერაცია ამას ერთხელ ხელსაწყოთი აკეთებს და არა განუწყვეტლივ მოთამაშეების ხარჯზე.

Anti-xray და რა ღირს ის#

anticheat.anti-xray paper-world-defaults.yml-ში ნაგულისხმევად გამორთულია. ის მადნებს მალავს კლიენტებისგან, რათა x-ray texture pack-მა ან mod-მა არაფერი გამოსადეგი დაინახოს.

anticheat:  anti-xray:    enabled: true    engine-mode: 1    max-block-height: 64    update-radius: 2

Engine mode 1 დამალულ ბლოკებს კლიენტებზე გაგზავნილ packet-ებში ქვით ანაცვლებს, რაც იაფია. Engine mode 2 ყალბ მადნებსაც აგზავნის, რაც უფრო დახვეწილ cheat-ებს ამარცხებს და შესამჩნევად მეტ CPU-ს და გამტარუნარიანობას ხარჯავს, რადგან chunk packet-ები გაცილებით ნაკლებად იკუმშება. max-block-height: 64 ობფუსკაციას y-დონე 64-ის ქვემოთ ზღუდავს, სადაც მადნებია, და სწორედ ეს ინარჩუნებს ფასს გონივრულს.

ღირს თუ არა, სერვერზეა დამოკიდებული. კერძო whitelist-იან SMP-ზე - არა. საჯარო survival სერვერზე, სადაც ეკონომიკა ბრილიანტის იშვიათობაზეა დამოკიდებული - კი, engine mode 1-ზე. ეს უფრო დიდი კითხვის ერთი ნაწილია, რომელიც გრიფის დაცვასა და anti-cheat-ში არის განხილული.

გაზომე, შეცვალე ერთი რამ, კვლავ გაზომე#

გაზომვის გარეშე მორგება გამოცნობაა და ზემოთ ყველა პარამეტრს ფასიც აქვს და სარგებელიც.

• /tps გაძლევს tick-ებს წამში ერთი, ხუთი და თხუთმეტი წუთის განმავლობაში. ოცი მაქსიმუმია და სერვერი მას ვერასოდეს გადააჭარბებს, ამიტომ 20.0 ნიშნავს ჯანსაღს და სხვა არაფერს.
• /mspt უკეთესი რიცხვია: მილიწამები tick-ზე, მედიანით და 95-ე პროცენტილით ბოლო ხუთი წამის, ათი წამისა და ერთი წუთის განმავლობაში. tick-ის ბიუჯეტი 50 ms-ია. სერვერი, რომლის საშუალოც 30 ms-ია და 95-ე პროცენტილი 48 ms, თავის ზღვარზეა, მიუხედავად იმისა, რომ /tps 20.0-ს ამბობს. რას ნიშნავს tick rate სინამდვილეში ხსნის, რატომ.
• spark არის პროფაილერი. /spark profiler start, ითამაშე რამდენიმე წუთი რეალური დატვირთვით, /spark profiler stop და ბმულს მიიღებ call tree-ზე, რომელიც ასახელებს plugin-ს, entity-ის ტიპს ან chunk-ს, რომელიც სამუშაოს აკეთებს. Paper-ის ახალი build-ები მას მოიცავს; თუ /spark შენს სერვერზე ბრძანება არ არის, ჩააგდე plugin-ის jar plugins/-ში. Paper-ის ძველი Timings სისტემა მის სასარგებლოდ გაუქმდა. spark-ის ანგარიშის კითხვა არის how-to.

შეცვალე ერთი პარამეტრი, გადატვირთე და უყურე /mspt-ს იმავე დატვირთვაზე. თუ ექვს რამეს ერთდროულად შეცვლი, ვერასოდეს გაიგებ, რომელმა დაგეხმარა, და ერთ-ერთი ფერმას დაგიმტვრევს.

RE:NODE-ზე panel-ის კონსოლი გაძლევს გაუფილტრავ გამოსავალს ბრძანებების ისტორიითა და tab-დასრულებით, ამიტომ /mspt და /spark ერთი კლავიშის დაჭერითაა ხელმისაწვდომი, ხოლო მეხსიერების, CPU-სა და დისკის გრაფიკები გეგმის რეალურ ლიმიტებთან გაზომილია და არა ჰოსტისასთან. სერვერი, რომელიც 100% CPU-ზე დგას, ნელია და არა გატეხილი, და ამის გამო არასოდეს ჩერდება - მაგრამ ეს ასევე ყველაზე მკაფიო სიგნალია, რომ პრობლემა tick-შია და არა მეხსიერებაში. სერვერის დატვირთვის გრაფიკის კითხვა ხსნის, რას ნიშნავს ფორმები.

რას არ უნდა აკეთებდე#

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

ნუ დააყენებ entity-ების გამწმენდ plugin-ს გამოსწორების ნაცვლად. plugin, რომელიც ყოველ ხუთ წუთში ყველა დაგდებულ ნივთს შლის, პრობლემას მალავს და მოთამაშეების ნივთებს ანადგურებს. თუ პრობლემა entity-ების რაოდენობაა, მიზეზი გამოასწორე: merge radius, despawn სიხშირეები, თითო chunk-ის შენახვის ლიმიტები და ფერმის დიზაინი, რომელიც წუთში ათ ათას ნივთს გამოიმუშავებს.

ნუ გაზრდი view distance-ს იმიტომ, რომ მეხსიერება ზედმეტი გაქვს. მეხსიერება შეზღუდვა არ არის; შეზღუდვაა chunk-ებისა და entity-ების მუშაობის tick-ზე ფასი. 12 GB-იანი სერვერი view-distance=16-ზე უარესად tick-ავს, ვიდრე იგივე სერვერი 8-ზე.

ნუ გამორთავ watchdog-ს სამუდამოდ. max-tick-time=-1 server.properties-ში ნიშნავს, რომ გაჭედილი სერვერი სამუდამოდ ჩერდება იმ thread trace-ის გამოტანის ნაცვლად, რომელიც გეტყვის, რატომ.

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

ბოლო, რაც ითქმის: Paper ერთადერთი fork არ არის. Pufferfish და Purpur მასზე დამატებით ოპტიმიზაციებსა და ქცევის გადამრთველებს აშენებენ, vanilla-სგან უფრო შორს გადახვევის ფასად. მათი გაშვება jar-ის ატვირთვისა და სერვერის მისკენ მიმართვის საქმეა და ამ გზამკვლევში ყველაფერი ისევ მოქმედებს, რადგან ისინი Paper-ის კონფიგურაციის ფაილებს იღებენ და საკუთარებს ამატებენ. ღირს თუ არა დამატებითი რამდენიმე პროცენტი კიდევ ერთი განსხვავების ფენად, გადასაწყვეტია; უმეტესი სერვერისთვის სწორად კონფიგურირებული Paper სწორი heap-ით უკვე უფრო სწრაფია, ვიდრე ის აპარატურა, რომელზეც ეშვება.

FAQ#

რომელია ყველაზე ეფექტური Paper პარამეტრი?

view-distance, server.properties-ში. არაფერი ახლოსაც არ მოდის, რადგან ის chunk-ების, entity-ებისა და ქსელური ტრაფიკის ფასს ერთდროულად ამრავლებს. simulation-distance მეორეა.

რატომ მაქვს TPS 20, როცა სერვერი აშკარად ლაგავს?

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

ტეხავს თუ არა simulation distance-ის შემცირება ფერმებს?

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

უნდა გამოვიყენო Paper-ის anti-xray?

საჯარო survival სერვერზე engine mode 1 ჩვეულებრივ ღირს. Engine mode 2 რეალურ CPU-ს და გამტარუნარიანობას ხარჯავს და ღირს მხოლოდ მაშინ, თუ x-ray-ი ეკონომიკას აქტიურად აზიანებს. whitelist-იან სერვერზე - არცერთი.

ჩემი სერვერი ყოველ ხუთ წუთში ბორძიკობს. რა არის ეს?

Autosave. დაწიე chunks.max-auto-save-chunks-per-tick paper-world-defaults.yml-ში 24-დან დაახლოებით 8-მდე, რომ სამუშაო მეტ tick-ზე გადანაწილდეს. ნუ გაზრდი autosave ინტერვალს ამის ნაცვლად - ეს ნახტომს ზრდის და მეტი პროგრესის დაკარგვის რისკს ქმნის.

Paper უფრო სწრაფია, ვიდრე Fabric ოპტიმიზაციის mod-ებით?

ისინი იმ გზით არ შედარდება, როგორც კითხვა ვარაუდობს. Paper სერვერს ოპტიმიზებს და plugin ეკოსისტემას ინარჩუნებს; Fabric წარმადობის mod-ებით mod-იან სერვერს ოპტიმიზებს და კლიენტებისგან შესაბამისობას მოითხოვს. თუ შენი მოთამაშეები შეუცვლელი launcher-ით შემოდიან, არჩევანი უკვე გაკეთებულია. Paper, Fabric თუ vanilla გარიგებას სწორად განიხილავს.