כמה RAM צריך שרת Minecraft?

מה באמת קובע כמה RAM אתה צריך

שני מנופים קובעים כמה זיכרון שרת Minecraft דורש. כל השאר הוא רעש לעומתם.

• מספר השחקנים מוסיף RAM בהדרגה. כל שחקן מחובר טוען את הצ'אנקים (chunks) שסביבו, ולכן יותר שחקנים — וערך view-distance גבוה יותר — משמעם שחלק גדול יותר מהעולם מוחזק בזיכרון בבת אחת. מעבר מ-4 שחקנים ל-20 הוא גידול אמיתי, אך כזה שאפשר להכיל.
• מודים ותוספים הם המנוף הגדול, בפער ניכר. Vanilla הוא קל. חופן תוספי Paper מוסיף מעט. אבל modpack הוא קטגוריה אחרת לגמרי: כל מוד טוען את הקוד, הפריטים, הבלוקים ויצירת העולם שלו לזיכרון עוד לפני שמצטרף שחקן אחד, ולכן חבילת CurseForge של 200 מודים עשויה לדרוש פי כמה RAM משרת vanilla עבור אותו מספר שחקנים.

זה כל המודל: vanilla גדל עם מספר השחקנים, ומודים גדלים עם מספר המודים. גם גודל העולם וגילו מעלים מעט את המספר — מפה ענפה בת שנים עם צ'אנקים טעונים רבים עולה יותר ממפה טרייה — אבל השחקנים והמודים הם מה שקובע את המידה. שמור דבר אחד בירכתי הראש בזמן שאתה קורא הלאה: RAM הוא רק אחד ממשאבי השרת, ומעבר לנקודה מסוימת הוא מפסיק להיות זה שחשוב (עוד על כך במדוע עוד RAM לא תמיד הוא הפתרון).

כמה RAM צריך שרת Minecraft, לפי סוג ההתקנה

הנה המידות שסביבן אנחנו בונים את החבילות — אותם מספרים שהיינו נותנים לחבר. "ה-RAM שאליו כדאי לכוון" הוא מה שמקצים לשרת עצמו, לא סך הזיכרון של המחשב שלך, שזקוק למרווח נוסף מעליו (ראה איך להקצות אותו).

מריץ modpack ולא בטוח לאיזו רצועה אתה שייך? גם גודל החבילה וגם מספר השחקנים דוחפים אותך מעלה בטבלה — המדריך לשרת Minecraft עם מודים מפרט את ה-loaders ואת גדלי החבילות לעומק.

איך להעניק לשרת שלך את ה-RAM הזה

לדעת את המספר זה חצי מהעבודה; החצי השני הוא למסור בפועל את הזיכרון הזה לשרת. זה עובד אחרת בהתאם למקום שבו השרת רץ.

אירוח עצמי: הדגלים -Xmx ו- -Xms

כשאתה מפעיל את קובץ ה-jar של השרת בעצמך, שני דגלים שולטים בזיכרון שלו. -Xmx קובע את ה-heap המרבי (התקרה), ו--Xms קובע את ה-heap ההתחלתי. עבור Minecraft העצה הנפוצה והבדוקה היטב היא להגדיר אותם שווים, כדי שה-JVM יתפוס את כל הזיכרון שלו מראש במקום לשנות את גודלו תחת עומס:

java -Xms4G -Xmx4G -jar server.jar nogui

השורה הזו מפעילה שרת עם 4 GB. כמה דברים שמכשילים אנשים:

• השתמש ב-Java בגרסת 64-bit. Java בגרסת 32-bit אינה יכולה לפנות ליותר מ-1.5 GB בערך, ולכן אם -Xmx4G מסרב לעלות, זו הסיבה בדרך כלל. כל בנייה עדכנית של Temurin או Java 25 היא 64-bit.
• לעולם אל תיתן לשרת את כל ה-RAM שלך. השאר לפחות 1-2 GB למערכת ההפעלה, ויותר אם אתה מריץ גם את לקוח Minecraft על אותו מחשב — המשחק זקוק לזיכרון משלו נוסף על זה של השרת.
• אחר כך כוונן עם הדגלים של Aikar. ברגע שהבסיס עובד, "הדגלים של Aikar" — סטנדרט הקהילה — מכווננים מחדש את אוסף הזבל G1 של Java לדפוס הזיכרון של Minecraft, ומחליפים פיסה זעירה של RAM בטיקים יציבים בהרבה. זהו הצעד הסטנדרטי הבא אחרי -Xmx/-Xms חשופים. המדריך המלא לאירוח עצמי — קובץ jar, EULA, העברת פורטים והכול — נמצא באיך מקימים שרת Minecraft.

אירוח מנוהל: בחר מידה, שדרג במקום

בשרת מנוהל אין דגלים לערוך. אתה בוחר את ה-RAM בעזרת מחוון בעת ההזמנה, והחבילה מוקצית באותה מידה — דגלי האתחול (כולל אלה של Aikar) כבר מכווננים עבורך.

היתרון האמיתי מתגלה כשאתה גדל מעבר לניחוש הראשון שלך: בעמוד אירוח ה-Minecraft אתה מזיז את המחוון מעלה וה-RAM הנוספת חלה על אותו שרת, כשהעולם וההגדרות נשארים שלמים — בלי התקנה מחדש, בלי הגירה, תוך כדקה. זו בדיוק הסיבה שכלל האצבע למעלה הוא "התחל בקטן": בחבילה מאורחת, הוספת RAM בהמשך עולה לא יותר מדקה.

סימנים שהשרת שלך זקוק לעוד RAM

אתה לא צריך לנחש אם השרת שלך מורעב. הוא אומר לך זאת, בכמה דרכים שקל לזהות:

• הטיקים נשארים מאחור. המסוף מדפיס Can't keep up! Is the server overloaded? Running Xms behind, skipping Xs tick(s), ובתוך המשחק זה מתבטא ב-rubber-banding, מפלצות שקופאות, ובלוקים שלוקח להם רגע להישבר.
• שמירת העולם מגמגמת. קפיאה קצרה כל כמה דקות, המסתנכרנת עם השמירה האוטומטית, פירושה לרוב שהשרת נאבק על זיכרון.
• הוא קורס לחלוטין. האות הברור מכולם הוא קריסה שהלוג שלה מכיל java.lang.OutOfMemoryError: Java heap space — השרת ביקש יותר זיכרון ממה שתקרת ה--Xmx שלו הרשתה.

כדי לדעת במה מדובר, הפרופיילר החינמי spark (הרץ /spark health או /spark profiler) מציג את תזמוני הטיקים ואת השימוש בזיכרון, ולוח בקרה מאורח משרטט את ה-RAM בזמן אמת על גרף. אם הזיכרון נצמד סמוך לתקרה, הגדל את המידה. אם יש לזיכרון מקום אבל הטיקים עדיין מפגרים, קרא קודם את החלק הבא.

מדוע עוד RAM לא תמיד הוא הפתרון

זה החלק שרוב עצות קביעת הגודל מדלגות עליו. Minecraft מריץ את לולאת המשחק הראשית — ה-"tick" שמזיז מפלצות, מגדל יבולים ומעבד redstone — בעיקר על תהליכון מעבד יחיד. הזיכרון מחזיק את העולם; ליבה אחת עושה את החשיבה. ברגע שלשרת יש מספיק RAM כדי להחזיק הכול, תוספת נוספת אינה הופכת את הליבה הזו למהירה יותר.

שתי מסקנות שכדאי להפנים:

• אם הטיקים מפגרים בזמן של-RAM יש מרווח, צוואר הבקבוק הוא המעבד, לא הזיכרון. לזרוק 32 GB על שרת שתקוע על ליבה אחת לא משנה דבר. זו טעות קביעת הגודל הנפוצה ביותר שאנשים עושים.
• יותר מדי RAM עלול אפילו להזיק. heap גדול מאוד נותן לאוסף הזבל של Java יותר לטאטא בבת אחת, וזה עלול להפוך להשהיות-גמגום ארוכות יותר — עוד סיבה שכלל "התחל קטן יותר" נכון.

מה שבאמת מזיז את המחט כשהמעבד הוא הגבול הוא תדר שעון גבוה. לכן HytHost מריצה את Minecraft על מעבדי Ryzen ו-Intel i9 בתדר גבוה במקום על ליבות איטיות רבות — ל-Minecraft חשוב כמה מהירה ליבה אחת, לא כמה יש. בצד התוכנה אתה יכול להקל על עומס הליבה הזו בהנמכת view-distance ו-simulation-distance, ביצירה מוקדמת של צ'אנקי העולם שלך, בהרצת Paper במקום vanilla, או בהוספת מודי ביצועים כמו Lithium בהתקנת מודים. RAM טוען את העולם שלך; המעבד ובחירות התוכנה שלך קובעים כמה חלק הוא רץ.