Minecraft सर्वर को कितनी RAM चाहिए?

आप 8 GB RAM वाले PC पर दोस्तों के लिए सर्वर चला रहे हैं। स्टार्टअप फ़ाइल में -Xmx8G लिखना आसान है: RAM 8 है, तो Java भी 8 इस्तेमाल कर ले। फिर आपको Windows, ब्राउज़र और, अगर आप उसी PC पर खेलेंगे, तो Minecraft client भी याद आता है। अभी किसी ने लॉग इन भी नहीं किया होता और सिस्टम मेमोरी बाँटने के लिए जगह नहीं ढूँढ पाता। कभी-कभी समस्या सर्वर में नहीं, बल्कि उसी एक लाइन में होती है।

कैलकुलेटर में “अनुशंसित Java heap” और “आवश्यक कुल RAM” के नतीजों को अलग-अलग देखें। पहला -Xmx के लिए इस्तेमाल होता है। दूसरा बताता है कि आपके PC या किराए के सर्वर में कुल कितनी RAM होनी चाहिए। इन दोनों को अलग किए बिना मैं “8 GB पर्याप्त है” नहीं कहूँगा। केवल खिलाड़ियों की संख्या इस जवाब के लिए पर्याप्त नहीं है।

दस खिलाड़ी हमेशा एक जैसा लोड नहीं बनाते

Spawn पर इकट्ठा होना बनाम पूरे मैप में फैल जाना

खिलाड़ियों की संख्या में पंजीकृत खातों की संख्या नहीं, बल्कि एक ही समय पर गेम में आने वाले लोगों की संख्या डालें। जब 10 खिलाड़ी spawn के आसपास base बनाते हैं, तो वे ज्यादातर उन्हीं chunks को देखते हैं। लेकिन जब वे Elytra से अलग-अलग दिशाओं में फैलते हैं, तो स्थिति बदल जाती है। सर्वर एक तरफ नए क्षेत्रों को लोड करता है और दूसरी तरफ ऐसी terrain भी generate करता है जिसे किसी ने अभी तक देखा नहीं है। शाम की शुरुआत के 10 खिलाड़ी और अंत के वही 10 खिलाड़ी जरूरी नहीं कि समान RAM लोड पैदा करें।

गणना करते समय मैं देखता हूँ कि समूह किस तरह खेलता है। अगर सभी लोग एक साझा क्षेत्र में रहते हैं, तो “ज्यादातर एक ही क्षेत्र में” विकल्प उचित है। अगर Survival दुनिया में हर कोई अपने-अपने base में फैल जाता है, तो “अलग-अलग क्षेत्रों में / पता नहीं” अधिक उपयुक्त है। अगर exploration भी बहुत है, तो उसे अलग से चुनें। कैलकुलेटर chunk लोड में 25 प्रतिशत जोड़ता है। केवल सुरक्षित रहने के लिए खिलाड़ियों की संख्या मन से बढ़ाकर बीस कर देना इस बात को छिपा देता है कि अंतर वास्तव में कहाँ से आ रहा है।

View distance और simulation distance को भी server.properties फ़ाइल में जाँचें। View distance वह क्षेत्र है जो आप खिलाड़ी को भेजते हैं। Simulation distance वह दायरा है जहाँ mobs और game events सक्रिय रहते हैं। फ़ॉर्म पहली बार खुलने पर 8 और 6 chunks दिखाता है। आधुनिक संस्करणों की गणना में दोनों में से बड़ी दूरी निर्णायक होती है। अगर view distance 8 है और simulation distance को 6 से 7 करते हैं, तो RAM का परिणाम वही रह सकता है। लेकिन tick लोड के बारे में ऐसा नहीं कहा जा सकता। “1.17 और पुराने” प्रोफ़ाइल में टूल simulation distance को गणना में शामिल नहीं करता।

केवल plugins की संख्या भी पर्याप्त नहीं है

Paper, Purpur और Spigot के लिए आप plugins की संख्या और उनका औसत लोड दर्ज करते हैं। Fabric, Forge और NeoForge में mods की संख्या गणना में आती है। Vanilla में कैलकुलेटर इन पुराने इनपुट्स में से किसी का उपयोग नहीं करता। “हल्का / मध्यम / भारी” विकल्पों को अलग-अलग plugins की मापी गई RAM खपत न समझें। 10 छोटे permission plugins और background में मैप render करने वाला एक plugin एक समान नहीं हैं।

Modpack इंस्टॉल करते समय मैं पहले उस heap recommendation को ढूँढता हूँ जो पैक server के लिए देता है। अगर वह मिले, तो उसे “Modpack की RAM recommendation इस्तेमाल करें” वाले हिस्से में दर्ज करें। टूल उस संख्या से नीचे नहीं जाएगा। Client के लिए दी गई recommendation को यहाँ न डालें। हम दो अलग-अलग game processes की बात कर रहे हैं। अगर आप पैक का लोड नहीं आँक सकते, तो “मध्यम” और “भारी” नतीजों को साथ-साथ देखें। उनके बीच का अंतर केवल mods की संख्या की तुलना में यह तय करने में अधिक उपयोगी है कि बड़ी hosting योजना की जरूरत है या नहीं।

कैलकुलेटर में कौन-सी संख्या कहाँ डालनी चाहिए?

अगर आप नया सर्वर बना रहे हैं, तो “RAM आवश्यकता की गणना करें” चुनें। अगर आप अपने मौजूदा PC को जाँचना चाहते हैं, तो “मेरे कंप्यूटर की जाँच करें” विकल्प चुनें। दोनों रास्तों में सर्वर की गणना समान है। यहाँ सबसे आसानी से छूटने वाली चीज़ फ़ॉर्म के शुरुआती मान हैं: Paper और 10 plugins पहले से चुने हुए आते हैं। अगर आपके सेटअप में कोई plugin नहीं है, तो 10 को शून्य कर दें। फिर version, view distance और जरूरत होने पर simulation distance को अपने वास्तविक सर्वर के अनुसार दर्ज करें। अगर आप भारी farm, redstone, web map या अतिरिक्त दुनिया इस्तेमाल करने की योजना बना रहे हैं, तो advanced settings खोलें। वरना केवल इसलिए विकल्प न चुनें कि उसका checkbox दिखाई दे रहा है।

Workload margin शुरुआत में 25 प्रतिशत होता है। Advanced settings में इसे 10 से 100 प्रतिशत के बीच बदल सकते हैं। जैसे ही आप उन settings को बंद करते हैं, अतिरिक्त लोड गणना से हट जाता है और margin फिर 25 प्रतिशत हो जाता है। अगर एक परीक्षण में 6 GiB और दूसरे में 9 GiB दिखाई देता है, तो पहले देखें कि कौन-कौन से switches चालू थे। परिणाम के साथ इस्तेमाल किए गए inputs भी लिख लें। फिर अंतर खोजते समय आपको शुरुआत से दोबारा नहीं करना पड़ेगा।

8 GB लगभग 7.45 GiB के बराबर होता है। अगर hosting विज्ञापन में GB लिखा है, तो फ़ॉर्म में GB ही दर्ज करें। अगर virtual machine या container केवल physical RAM का कुछ हिस्सा इस्तेमाल कर सकता है, तो उपलब्ध सीमा के रूप में वही हिस्सा दर्ज करें। “मैंने 8 डाला और 8 आया” देखकर निश्चिंत होना आसान है। लेकिन अगर दोनों तरफ अलग-अलग units चुनी गई हैं, तो तुलना शुरू से ही गलत हो सकती है, खासकर जब नतीजा आधे GiB की सीमा के पास हो।

स्क्रीन पर दिखने वाले दो RAM परिणाम

Heap की संख्या को मशीन की कुल क्षमता न समझें

Java heap वह अधिकतम सीमा है जिसे सर्वर Java objects के लिए इस्तेमाल कर सकता है। कुल RAM में operating system और Java द्वारा heap के बाहर उपयोग की जाने वाली memory के लिए भी जगह शामिल होती है। कैलकुलेटर इस अतिरिक्त Java usage के लिए कम से कम 1 GiB रखता है। अगर heap का 15 प्रतिशत इससे अधिक है, तो वही मान लिया जाता है, और फिर परिणाम को अगले आधे GiB तक ऊपर round किया जाता है। अगर स्क्रीन पर heap 3.5 GiB है, तो उत्पन्न -Xmx3584M भी उसी के बराबर है। Hosting package चुनते समय -Xmx संख्या को package की कुल RAM न समझें।

इस सेटअप से कोशिश करें: 10 खिलाड़ियों वाला Paper, आधुनिक version, 8 chunks view distance, 6 chunks simulation distance और मध्यम लोड वाले 10 plugins। Advanced settings और Chunky बंद होने पर टूल 3.5 GiB heap और 6.5 GiB कुल RAM देता है। बिना desktop वाले Linux पर चलने वाली 8 GiB मशीन में, अगर आप अन्य applications के लिए अतिरिक्त memory अलग नहीं रखते, तो यह memory requirement फिट हो जाती है। अब उसी PC पर Windows और Minecraft client को भी जोड़ें। अगर अन्य applications के लिए 1 GiB और client के लिए 4 GiB दर्ज करें, तो कुल आवश्यकता बढ़कर 13.5 GiB हो जाती है। यहाँ 8 GiB मशीन पर्याप्त नहीं है। हमने Paper में एक भी plugin नहीं जोड़ा। RAM बाकी processes खा रहे हैं।

Computer check बिना desktop वाले Linux के लिए 2 GiB, desktop वाले Linux के लिए 3 GiB और Windows तथा macOS के लिए 4 GiB system allowance रखता है। Container में host machine के operating system का हिस्सा नहीं जोड़ा जाता। अगर container के अंदर अन्य services चल रही हैं, तो उनकी RAM “अन्य applications” वाले हिस्से में दर्ज करनी होगी। जब मशीन पर्याप्त नहीं होती, तो कैलकुलेटर heap को अपने आप कम नहीं करता। वह कमी को स्पष्ट रूप से दिखाता है।

Vanilla से modpack पर जाना

फिर से 10 खिलाड़ी और 8/6 chunk settings लें। Vanilla में 3 GiB heap और 6 GiB कुल RAM मिलता है। Paper में मध्यम लोड वाले 10 plugins जोड़ने पर यह 3.5 और 6.5 GiB हो जाता है। मध्यम लोड वाले 50 mods के Fabric उदाहरण में 5 और 8 GiB, जबकि Forge उदाहरण में 6 और 9 GiB दिखाई देता है। मैं इन नतीजों का मतलब यह नहीं निकालूँगा कि “Fabric हर स्थिति में Forge से हल्का है।” पैक के अंदर mods बदलते ही तुलना भी बदल जाती है। ये संख्याएँ केवल यह दिखाती हैं कि समान inputs पर कैलकुलेटर कैसे व्यवहार करता है।

Paper उदाहरण में अगर खिलाड़ी एक ही क्षेत्र में रहते हैं, तो आपको 3 GiB heap और 6 GiB कुल RAM दिखाई देगा। अगर वे फैलते हैं और नई terrain explore करते हैं, तो यह 4 और 7 GiB हो जाता है। दोनों स्थितियों में खिलाड़ियों की संख्या 10 ही है। इसलिए मैं केवल “प्रति खिलाड़ी इतनी RAM” जैसी सलाह पर भरोसा नहीं करता। अगर आप भारी farm, web map, custom world generation और दो अतिरिक्त active worlds जोड़ते हैं, तो यही गणना 6 GiB heap और 9 GiB कुल RAM तक पहुँच जाती है। यहाँ चारों switches एक साथ चालू करके केवल अंतिम परिणाम देखने के बजाय उन्हें एक-एक करके आज़माएँ। तब पता चलेगा कि कौन-सा load गणना को सबसे अधिक बढ़ा रहा है।

Chunky गणना और चल रहे सर्वर की माप

Chunky में पहले world का नाम, center, shape और radius चुनते हैं। Square में area 4 × radius² होता है, जबकि circle में π × radius² होता है। क्योंकि एक chunk 16 × 16 blocks का क्षेत्र घेरता है, कैलकुलेटर area को 256 से विभाजित करता है। अगर center 0, 0 है और square radius 3000 blocks है, तो परिणाम 140,625 chunks होता है। अगर उनमें से आधे पहले से generate हो चुके हैं, तो 70,313 बाकी रहते हैं। Radius को 6000 करने पर 562,500 chunks हो जाते हैं। केवल 3000 blocks जोड़ने का मतलब काम दोगुना होना नहीं है; area चार गुना हो जाता है। Radius box में दी गई संख्या को एक बार फिर जाँचें।

Chunky चालू करने पर उदाहरण वाले Paper server की heap recommendation बढ़कर 4 GiB और कुल RAM 7 GiB हो जाती है। Disk और समय के लिए आप एक छोटा test generation चला सकते हैं। अगर आप 10,000 नए chunks, 256 MiB folder growth और 300 seconds दर्ज करते हैं, तो बाकी 140,625 chunks के लिए लगभग 3.52 GiB disk और 1.17 घंटे का अनुमान दिखाई देगा। World generation के दौरान speed स्थिर नहीं रह सकती। Measurement में backups या web map files शामिल न करें। Command भेजने से पहले world का नाम और radius भी दोबारा पढ़ें। एक अतिरिक्त zero समय और disk दोनों पर असर डाल देगा।

आपने सर्वर चालू किया, खिलाड़ी फैल गए और TPS गिर गया। तुरंत -Xmx न बढ़ाएँ। TPS प्रति सेकंड game updates की संख्या है, जबकि MSPT बताता है कि एक update में कितने milliseconds लगते हैं। /spark tps से दोनों देखें। भारी load के समय Spark profile लेने पर आप समझ सकते हैं कि समय world generation में जा रहा है या किसी plugin में। Garbage Collection का दबाव GC data से अलग से देखें। अगर सर्वर OOM error के कारण बंद हो रहा है, तो RAM limit और -Xmx सबसे पहले जाँचने वाली चीजें हैं। अगर memory खाली होने के बावजूद TPS गिरता है, तो मैं पहले profiler output खोलूँगा। नई RAM योजना के बारे में बाद में सोचूँगा।