რამდენი RAM სჭირდება Minecraft სერვერს?

პატიოსანი მოკლე პასუხი: 2 GB უშვებს vanilla ან Paper სერვერს დაახლოებით ხუთ მეგობრამდე, 4 GB ფარავს პატარა საჯარო სერვერს ათიდან ოც მოთამაშემდე, 6 GB ფარავს მსუბუქ modpack-ს ან ოცდაათ მოთამაშეს Paper-ზე, 8-დან 10 GB-მდე ფარავს სერიოზულ modpack-ს პატარა ჯგუფისთვის, ხოლო დაახლოებით 12 GB-ს იქით თითქმის ყოველთვის არასწორ პრობლემას არასწორი რესურსით წყვეტ. მეხსიერება ყველაზე მარტივად საყიდელი რამაა და ყველაზე ნაკლებად სავარაუდოდ გაფუჭებული. ეს პოსტი განმარტავს, რისგან შედგება ეს რიცხვი სინამდვილეში, სად ცხოვრობს ორი პარამეტრი, რომელიც მას ამოძრავებს, და როგორ გაიგო ხუთ წუთში, მეხსიერებაა შენი ვიწრო ადგილი თუ ფულს არაფერში ხარჯავ.

რას ინახავს Minecraft სერვერი მეხსიერებაში#

Minecraft სერვერი world-ს არ ტვირთავს. ის ტვირთავს world-ის იმ ნაწილებს, რომელთა გვერდითაც ვინმე დგას, დანარჩენს კი აგდებს. მეხსიერება ამიტომ იზრდება იმასთან ერთად, რამდენი world არის ერთდროულად რეზიდენტული, რაც დაახლოებით მოთამაშეების რაოდენობაა გამრავლებული იმ ფართობზე, რომელსაც თითოეული ჩატვირთულს ინახავს, და თითქმის არ არის დამოკიდებული იმაზე, რამდენად დიდია world დისკზე. 40 GB-იანი world სამი ონლაინ მოთამაშით იაფია. 2 GB-იანი world ოცდაათი მოთამაშით, რომლებიც ოთხ განზომილებაში არიან გაფანტული, - არა.

Java heap-ის შიგნით მსხვილი მომხმარებლები არის:

• ჩატვირთული chunk-ები. chunk არის ბლოკების 16 x 16 სვეტი world-ის იატაკიდან build-ის ზღვრამდე, რომელიც ინახება ბლოკის მდგომარეობების palette-ებისა და განათების მონაცემების სახით. view-distance=10-ზე ერთი მოთამაშე 21 x 21 chunk-ის კვადრატს ინახავს ჩატვირთულს, ანუ 441 chunk-ს. 8-ზე ის 289-ია. 6-ზე - 169.
• Entity-ები და block entity-ები. მობები, დაგდებული ნივთები, minecart-ები, armour stand-ები და ჩატვირთულ chunk-ში ყველა chest, hopper, ნიშანი და shulker box. აქ აზიანებენ ფერმები და მეგროვნეთა ბაზები: chunk, რომელიც 400 hopper-ს შეიცავს, ცარიელზე ბევრად მეტი ჯდება.
• მოთამაშის მონაცემები და ინვენტარები, რომლებიც პატარაა, პლუს თითოეული კავშირის უკან მდგომი ქსელური ბუფერები, რომლებიც ოცდაათ მოთამაშეზე არაფერი არ არის.
• Plugin-ის ან მოდის მდგომარეობა. region-ის cache-ები, უფლებების ხეები, ბლოკების ლოგირების რიგები, web რუკის tile cache, pathfinding გრაფი. ზოგი plugin უფრო მეტს ინახავს, ვიდრე world.

heap-ის გარეთ JVM-ს თავად სჭირდება მეხსიერება, რომელსაც heap-ის პარამეტრი არ ფარავს: metaspace ჩატვირთული კლასებისთვის, JIT კოდის cache, თითო thread-ზე დაჯავშნილი ერთი stack და Netty-ის პირდაპირი byte ბუფერები. სამასი მოდის მქონე მოდიფიცირებულ სერვერს მარტო metaspace-ში 400-დან 600 MB-მდე შეუძლია ჩადოს. ეს უფსკრული "heap"-სა და "რაც container-ს სჭირდება" შორის ზომის შერჩევის ყველაზე გავრცელებული შეცდომაა და მას ქვემოთ საკუთარი განყოფილება აქვს.

RAM მოთამაშეების რაოდენობისა და სერვერის ტიპის მიხედვით#

ესენია სამუშაო რიცხვები სერვერისთვის, რომელიც დარეგულირებულია და ნაგულისხმევებზე არ დარჩენილა, view-distance 8-ზე და simulation-distance 6-ზე. დაამატე დონე, თუ web რუკას, მძიმე ბლოკების ლოგირებას ან სამ განზომილებას იყენებ, რომლებსაც ხალხი ნამდვილად იყენებს.

ორი რამ, რომელიც ცხრილში არ არის, რადგან პასუხს მოთამაშეების რაოდენობაზე მეტად ცვლის. პირველი, განზომილებები: Nether და End ცალკე world-ებია საკუთარი ჩატვირთული chunk-ებით, ამიტომ ჯგუფი, რომელიც End-ის სამუშაოებზე გადავიდა, ორ-სამჯერ მეტ ფართობს ტვირთავს, ვიდრე პირველ კვირას. მეორე, გაფანტულობა: ათი მოთამაშე ერთ ქალაქში იმის მცირე ნაწილს ტვირთავს, რასაც ათი მოთამაშე, რომლებიც ათ მიმართულებით იკვლევენ, და მეორე ჯგუფი ამასობაში ახალ რელიეფსაც აგენერირებს, რაც სერვერის ყველაზე ძვირი საქმეა. World border-ები და pregeneration ორივეს გამოსწორებაა და უფასოა.

Heap, container და უფსკრული, რომელიც უნდა დატოვო#

თუ სერვერს თვითონ უშვებ, heap-ს ორი flag-ით აყენებ:

$ java -Xms3G -Xmx3G -jar paper.jar --nogui

-Xmx მაქსიმალური heap-ია. -Xms საწყისი heap-ია და Minecraft-ის დიდი ხნის რჩევაა, რომ ისინი ტოლი დააყენო, რათა JVM-მა არ დახარჯოს დრო heap-ის გაზრდასა და შემცირებაზე, რომელსაც მაინც შეავსებს. panel-ზე დაფუძნებულ ჰოსტზე ამ ხაზს არ აკრეფ - მნიშვნელობა Startup ჩანართზე ველია და panel ბრძანებას აგებს.

ხაფანგია -Xmx-ის container-ის მთელ ლიმიტზე დაყენება. 4 GB გეგმაზე -Xmx4G Java-ს ეუბნება, რომ container-ის ყველა ბაიტის გამოყენება შეუძლია, და შემდეგ metaspace, thread stack-ები და Netty ბუფერები პროცესს ლიმიტს გადააცილებს. რა მოხდება შემდეგ, ჰოსტზეა დამოკიდებული და არასოდეს არის სუფთა Java შეცდომა: kernel პროცესს აჩერებს, ლოგი უბრალოდ წყდება და წასაკითხი crash report არ არსებობს. დატოვე სივრცე:

დაახლოებით: დატოვე 25% ან 512 MB, რომელიც მეტია, და მეტისკენ გადაიხარე ძლიერ მოდიფიცირებულ სერვერზე, რადგან metaspace იზრდება მოდების რაოდენობასთან ერთად და არა მოთამაშეების.

View distance და simulation distance#

1.18-დან server.properties-ში ორი distance პარამეტრია და მათი აღრევა ფულსაც აკარგვინებს და tick-ის დროსაც.

view-distance=8simulation-distance=6entity-broadcast-range-percentage=100network-compression-threshold=256max-tick-time=60000

პირველი ორი განსაზღვრავს შენს ზომას:

• `view-distance` (ნაგულისხმევი 10) არის, თუ რამდენ chunk-ზე შორს ინახავს სერვერი თითოეული მოთამაშისგან ჩატვირთულს და უგზავნის კლიენტს. ეს მეხსიერებისა და გამტარუნარიანობის ბერკეტია. 10-დან 8-ზე გადასვლა მოთამაშეზე ჩატვირთულ კვადრატს 441 chunk-იდან 289-მდე ამცირებს, 34%-ით, და survival-ში თითქმის არავინ ამჩნევს.
• `simulation-distance` (ნაგულისხმევი 10) არის, თუ რამდენად შორს tick-ავს chunk-ები რეალურად: მობები მოძრაობენ, მოსავალი იზრდება, redstone მუშაობს, hopper-ები იღებენ. ეს CPU-ს ბერკეტია. უმეტეს სერვერს შეუძლია 6-ზე იჯდეს ჩივილების გარეშე და ამ რადიუსის გარეთ ფერმები უბრალოდ ჩერდება, სანამ ვინმე არ დაბრუნდება.

10-ისა და 10-ის ნაგულისხმევი წყვილი ერთი მოთამაშის ზომის world-ისთვის გულუხვია და სერვერისთვის ფლანგვა. სტანდარტული დარეგულირებაა view-distance=8 და simulation-distance=6: მოთამაშეები მაინც ხედავენ გონივრულ ჰორიზონტს და სერვერი მხოლოდ იმას ასიმულირებს, რაც საკმარისად ახლოა, რომ მნიშვნელობა ჰქონდეს. Paper-ს ასევე შეუძლია ორივე თითო world-ზე config/paper-world-defaults.yml-ში დააყენოს, რითაც lobby-ს 4-ის distance-ს აძლევ და survival world-ს 8-ს. Paper-ის ოპტიმიზაცია ამ ფაილების დანარჩენს მოიცავს, ხოლო `server.properties`-ის ყველა key - იმათ, რომლებსაც ეს პოსტი გამოტოვებს.

კიდევ ერთი, რომელიც დატვირთულ სერვერს მეხსიერებაზე შეხების გარეშე ეხმარება: entity-broadcast-range-percentage. ნაგულისხმევ 100-ზე სერვერი თითოეულ კლიენტს entity-ებზე მისი მთელი view distance-ის განმავლობაში ატყობინებს. მისი 50-მდე დაწევა გამავალ entity პაკეტებს დაახლოებით განახევრებს, რაც საჯარო სერვერზე ორმოც მოთამაშესთან ბევრად უფრო მნიშვნელოვანია, ვიდრე heap-ის დამატებითი გიგაბაიტი.

რატომ წყვეტს დიდი heap დახმარებას#

Java არ იყენებს მეხსიერებას, რომელიც არ მოუთხოვიათ, ამიტომ უქმე სერვერი 14 GB გეგმაზე იმავე სერვერზე უკეთ არ მუშაობს, ვიდრე 6 GB-ზე. უარესი, დიდი heap თითოეულ garbage collection-ს უფრო ხანგრძლივად აპაუზებს და არა უფრო მოკლედ, რადგან მისასვლელი მეტია. ოცმოთამაშიანი Paper სერვერი, რომელსაც 16 GB მიეცა, ჩვეულებრივ იგივე საშუალო tick rate-ს იძლევა, რასაც იგივე სერვერი 6 GB-ზე, ხოლო შესამჩნევად უარესი ჭედვებით, როცა collector მუშაობს.

არსებობს რეალური ზღურბლი, რომელიც უნდა იცოდე. დაახლოებით 12 GB-ს ქვემოთ G1 (ნაგულისხმევი collector, რაზეც community-ის სტანდარტული flag ნაკრებია მორგებული) კარგად იქცევა 200 ms პაუზის სამიზნით. მის ზემოთ დარეგულირება იცვლება - ფართოდ გამოყენებული flag ნაკრები გეუბნება, დიდი heap-ებისთვის გაზარდო G1NewSizePercent და G1HeapRegionSize, ხოლო ზოგი დიდი მოდიფიცირებული სერვერი Java 21-ზე Shenandoah-ზე ან generational ZGC-ზე გადადის. არცერთი ეს არ არის მიზეზი, რომ იყიდო დიდი heap, რომელიც არ გჭირდება; ეს გაფრთხილებაა, რომ დიდი heap კონფიგურაციის პროექტია და არა შესყიდვა. JVM flag-ები და Java ვერსიები შეიცავს რეალურ flag ნაკრებებს.

ამიტომ არასასიამოვნო წესი: თუ სერვერი ჭედავს და მეხსიერების გრაფიკი ლიმიტზე ბევრად დაბლა დგას, მეხსიერება შენი პრობლემა არ არის და მისი დამატება ვერაფერს შეცვლის. რაც გაქვს, არის CPU პრობლემა, distance პარამეტრი, chunk-ების გენერირების პრობლემა ან ერთი ცუდად მოქცეული plugin. CPU თუ RAM გეიმ სერვერებისთვის ამ არგუმენტის ზოგადი ვერსიაა; რატომ ეცემა TPS - Minecraft-ისთვის სპეციფიკური.

როგორ დაამტკიცო, რომ პრობლემა მეხსიერებაა#

ხუთი წუთის მტკიცებულება ნახევარი დღის გამოცნობას სჯობს. თანმიმდევრობით:

1. უყურე მეხსიერების გრაფიკს, სანამ ხალხი თამაშობს. ჯანმრთელი Java სერვერი ხერხივით მუშაობს: ადის, collector ეშვება, ბრუნდება. თუ ლიმიტამდე ადის და მის წინააღმდეგ ბრტყლად რჩება, გაკლია. თუ 60%-ზე პიკს აღწევს და იქ რჩება, არ გაკლია.
2. გაუშვი profiler. spark სტანდარტია: /spark profiler start, რამდენიმე წუთი ითამაშე, /spark profiler stop და წაიკითხე link, რომელსაც დაბეჭდავს. ის ასახელებს plugin-ს, მოდს ან სისტემას, რომელიც tick-ს ჭამს. /spark health TPS-სა და მეხსიერებას ერთად ბეჭდავს, ხოლო /spark heapsummary გეუბნება, რომელი კლასები იკავებს heap-ს - თუ ზედა ჩანაწერი plugin-ის საკუთარი cache-ია, შენი პასუხი იპოვე და ის გეგმის გაზრდა არ არის.
3. წაიკითხე MSPT და არა TPS. Paper-ზე /mspt აჩვენებს მილიწამებს tick-ზე. tick-ს 50 ms აქვს. 45 ms-ზე ერთი entity ფერმა გაშორებს თვალსაჩინო lag-იდან, მაშინ როცა TPS ჯერ კიდევ 20.0-ს აჩვენებს, ამიტომ MSPT უფრო ადრე გაფრთხილებს.
4. დაწიე `view-distance` ორით და გადატვირთე. უფასოა, შექცევადია და დატვირთულ სერვერზე ყველაზე დიდი ერთეული ბერკეტია. თუ ეს ასწორებს, distance პრობლემა გქონდა და არა მეხსიერების.
5. შეამოწმე garbage collector და არა საშუალო. სერვერს, რომელსაც 20 TPS აქვს და ყოველ ათ წუთში 3-წამიანი გაყინვა, GC პრობლემა აქვს - ჩვეულებრივ გადაჭარბებული heap ან plugin, რომელიც ციკლში აქტიურად ანაწილებს. /spark gcmonitor პაუზებს ისე ატყობინებს, როგორც ისინი ხდება.

Modpack-ები არითმეტიკას ცვლის#

modpack სხვა ტიპის დატვირთვაა და ზემოთ მოცემული ზომის რჩევა სამი კონკრეტული გზით იცვლება.

კლასების ჩატვირთვა რეალური მეხსიერებაა. სამასი მოდი ათიათასობით კლასს ნიშნავს და metaspace heap-ის გარეთ ცხოვრობს. ამიტომ modpack, რომელიც "6 GB-ში უნდა ეტეოდეს", 6 GB container-ზე -Xmx6G-ით კვდება: heap კარგად იყო და პროცესმა მაინც გადააჭარბა. იმავე პაკეტს იმავე გეგმაზე -Xmx4500M მიეცი და ის ხშირად მუშაობს.

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

Worldgen მოდები ყველაფერს ამრავლებენ. პაკეტი დიდი biome მოდით უფრო მრავალფეროვან, სტრუქტურებით უფრო მკვრივ რელიეფს აგენერირებს, რაც ჩასატევად მეხსიერებას და შესანახად დისკს ჯდება. Chunky-ით pregeneration მანამ, სანამ ვინმე შემოვა, არაპროგნოზირებადი lag-ის აფეთქებებს ერთ გრძელ მოსაწყენ საქმედ აქცევს, რომლის დაგეგმვაც ღამით შეგიძლია.

პრაქტიკული მოდიფიცირებული რიცხვები: 30-დან 80 მოდამდე Fabric-ზე ჩვეულებრივი performance ნაკრებით სიამოვნებით მუშაობს 6 GB-ში. 150-ზე მეტი მოდის Forge ან NeoForge პაკეტს 8-დან 10 GB-მდე უნდა. 1.12-ის ეპოქის "სამზარეულოს ნიჟარის" პაკეტს ასობით მანქანით 10 GB და Java 8 უნდა, რაც თავისთავად ხაფანგია - იხილე მოდიფიცირებული Minecraft crash-ების გარეშე Java ვერსიების მატრიცისა და იმ crash report-ის წაკითხვისთვის, რომელიც მართლა მეხსიერებას ეხება.

რა ხდება ლიმიტთან მისვლისას#

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

• `java.lang.OutOfMemoryError: Java heap space`. JVM-მა საკუთარ heap-ში სივრცე მოითხოვა და ვერ მიიღო. მიიღებ stack trace-ს, ჩვეულებრივ crash report-ს და ხშირად სერვერს, რომელიც ჯერ ცოტა ხანს კოჭლობს. გაზარდე -Xmx, თუ container-ის ლიმიტის ქვეშ ადგილია; სხვა შემთხვევაში დონე გაზარდე ან დატვირთვა შეამცირე.
• `OutOfMemoryError: Metaspace` ან `GC overhead limit exceeded`. პირველი კლასების ჩატვირთვის წნეხია, მეორე ნიშნავს, რომ collector განუწყვეტლივ მუშაობს და თითქმის არაფერს გამოათავისუფლებს. ორივე ჩვეულებრივ ნიშნავს modpack-ს, რომელიც თავისი გეგმისთვის ერთი ზომით პატარაა.
• ლოგი უბრალოდ წყდება. exception არ არის, crash report არ არის. პროცესი გარედან გააჩერეს, რადგან container მეხსიერების ლიმიტს გადასცდა. RE:NODE-ზე ეს განზრახია: ლიმიტთან სერვერი ჩერდება და სუფთად გადაიტვირთება, swap-ში დატოვების ნაცვლად, რადგან swap-ში მყოფი Minecraft სერვერი გადატვირთვადზე უარესია. ფასი არის ყველაფერი, რაც world-მა ჯერ არ შეინახა, რის გამოც მოკლე autosave ინტერვალი და რეალური backup-ები მნიშვნელოვანია. crash watcher-ი ასევე ამჩნევს განმეორებით გადატვირთვებს - საათში სამი სერვერის გვერდზე გაფრთხილებას ბადებს და ტიკეტს ავტომატურად ხსნის, რაც ჩვეულებრივ პირველი შემთხვევაა, როცა ვინმე ხვდება, რომ -Xmx გეგმის მთელ მოცულობაზე იყო დაყენებული.

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

FAQ#

საკმარისია 2 GB Minecraft სერვერისთვის?

დაახლოებით ხუთ მოთამაშემდე vanilla ან Paper-ზე view-distance=8-ით, დიახ, კომფორტულად. -Xmx დააყენე დაახლოებით 1500M-ზე, რომ JVM-ის heap-ს გარეთა გამოყენებაც ეტეოდეს, plugin-ების სია მოკლე გქონდეს და მასზე web რუკა არ გაუშვა. 2 GB არც ერთი modpack-ისთვის არ არის საკმარისი.

უფრო დიდ world-ს მეტი RAM სჭირდება?

თითქმის არა. მხოლოდ ჩატვირთული chunk-ებია რეზიდენტული, ამიტომ world-ის ზომა დისკის მოხმარებას განსაზღვრავს და არა მეხსიერებას. რასაც დიდი world ცვლის, არის გენერირება: მოთამაშეები, რომლებიც არაგენერირებულ რელიეფს იკვლევენ, უმეტეს სერვერზე ყველაზე ცუდ lag-ის აფეთქებებს ქმნიან, და world border პლუს pregeneration ამას მეტი მეხსიერების გარეშე ასწორებს.

უნდა იყოს -Xms და -Xmx ერთნაირი?

dedicated გეიმ სერვერზე, დიახ. heap ყოველ სესიაზე დაახლოებით ერთსა და იმავე დონემდე შეივსება, ამიტომ JVM-ისთვის მისი გაზრდისა და შემცირების ნებართვა მხოლოდ სამუშაოს ამატებს. ტოლი მნიშვნელობები მეხსიერების გრაფიკს უფრო მარტივად წასაკითხს ხდის, რადგან ზედა ბრტყელ ხაზს მაშინ აზრი აქვს.

რატომ იყენებს ჩემი სერვერი მთელ RAM-ს, რასაც მას ვაძლევ?

იმიტომ, რომ ასე მუშაობს generational collector: ის young generation-ს ავსებს, აგროვებს და ისევ ავსებს. მაღალი მოხმარება ნაკლებობა არ არის. სიგნალი, რომელსაც უნდა ეძებო, არის მოხმარება, რომელიც ლიმიტზეა მიჭედებული და collection-ის შემდეგ არ ეცემა, პლუს მზარდი MSPT.

მეტი plugin მეტ RAM-ს ნიშნავს?

ნაკლებს, ვიდრე ხალხს ჰგონია. ტიპური plugin რამდენიმე მეგაბაიტ კლასს ჯდება და რასაც cache-ავს. რასაც plugin-ები ნამდვილად ჯდება, არის მთავარი thread-ის დრო, რაც მეხსიერებად კი არა tick rate-ად ჩანს. გამონაკლისები, რომლებიც heap-ს ნამდვილად ჭამს, არის web რუკები, ბლოკების ლოგერები დიდი მეხსიერებაში რიგებით და ყველაფერი, რაც region-ებს ან chunk-ის მონაცემებს cache-ავს.

რამდენი RAM სჭირდება მოდიფიცირებულ სერვერს მოთამაშეზე?

მოდიფიცირებულისთვის არასწორი კითხვაა. პაკეტის საკუთარი ზომა - მოდის კლასები, registry-ები, worldgen - ბატონობს და ის იხდება, ონლაინ ერთი ადამიანია თუ რვა. ჯერ პაკეტისთვის გათვალე და შემდეგ დაამატე დაახლოებით 250-დან 500 MB-მდე თითო თანადროულ მოთამაშეზე პირველი რამდენიმეს მიღმა.