הקטנת simulation-distance אינה זהה להקטנת view-distance. האחת משנה את האזור סביב השחקן שהשרת מדמה; השנייה שולטת בכמות נתוני השטח שהוא שולח לשחקנים. נוף רחוק יכול להישאר גלוי גם אם חווה שנמצאת שם כבר לא מתנהגת כפי שבעליה מצפה.
ההבחנה הזו חשובה יותר ממציאת הגדרה שמסומנת כ“מותאמת”. שרת שקט יותר אינו שיפור גדול אם כפריים מפסיקים לחדש מלאי או שנקודת AFK ותיקה כבר לא עובדת. המטרה היא להסיר עבודה שהקהילה שלכם יכולה בלעדיה, ואז לבדוק שהמשחק שרציתם לשמור עדיין עובד.
המדריך הזה מכסה שרתי Minecraft Java Edition מודרניים. הגדרות המרחק חלות על Vanilla, Spigot ו-Paper; פקודות פלאגין והגדרות YAML מסומנות בנפרד. זה אינו מתכון אוניברסלי ל-Bedrock, לחבילות מודים או ל-Folia. בדקו את התיעוד מול הגרסה המדויקת של השרת שלכם: מקורות עדכניים יכולים לתאר גרסאות חדשות יותר, וגם ברירות המחדל וגם מבנה הקבצים אינם קבועים לנצח.
1. מדדו את הבעיה בזמן שהיא מתרחשת
רשמו את גרסת Minecraft, תוכנת השרת והבילד, מספר השחקנים ומה השחקנים עושים כשההאטה מתרחשת. אולם מסחר עמוס וקבוצה שחוקרת שטח חדש הם עומסי עבודה שונים. פרופיילינג של שרת ריק לא יסביר אף אחד מהם; התיעוד של Paper דורש במפורש שהבעיה תתרחש בזמן איסוף הנתונים.
ב-Paper, spark מצורף מאז גרסה 1.21. ב-Spigot, התקינו תחילה פלאגין spark standalone תואם; הפקודות הבאות אינן מובנות בשרת Vanilla לא ערוך.
הריצו אותן במשחק עם ההרשאות הנדרשות:
/spark tps
/spark profiler start --timeout 600
פקודת הפרופיילר מקליטה במשך עשר דקות ומחזירה כתובת URL של דוח. שמרו את הדוח הזה יחד עם ההגדרות והערות עומס העבודה שלכם.
בקצב ה-tick הרגיל, Minecraft שואף ל-20 TPS, מה שמותיר 50 אלפיות שנייה לכל tick. MSPT מתאר כמה זמן נמשכים ה-ticks, ולכן הוא חושף לחץ שקריאת TPS לבדה עלולה להסתיר. השוו בין MSPT חציוני ל-MSPT באחוזון ה-95: האחרון עוזר לחשוף ticks איטיים החוזרים על עצמם, אבל עלול לפספס זינוקים נדירים. בדקו גם את הערך המרבי, ואל תתייחסו לאחוזון תקין כהוכחה שדבר לא נתקע.
לבעיות לסירוגין, ה-tick monitor של spark יכול לסמן ticks החורגים מהתקציב הזה:
/spark tickmonitor --threshold-tick 50
רשמו מה קרה באותו רגע. אם זמני ה-tick נשארים תקינים בזמן התלונה, בדקו את קצב הפריימים של הלקוח או את תנאי הרשת לפני שאתם מקריבים משחקיות בשרת.
2. גבו ואתרו אילו הגדרות באמת חלות
לפני העריכה, עצרו את השרת בצורה נקייה וגבו את העולמות, קובצי ההגדרות ונתוני הפלאגינים. שמרו את הגיבוי מחוץ לתיקיית השרת הפעיל ובדקו שאתם יכולים לשחזר אותו. עותק של ההגדרות מקל על החזרה אחורה; גיבוי עולם מגן על העבודה שמאחוריו.
השתמשו בעורך טקסט, שמרו על הזחת YAML ושנו דבר אחד בכל ניסוי. הפעילו את השרת כרגיל לאחר מכן ובדקו את יומן ההפעלה לשגיאות הגדרות. אל תשתמשו ב-/reload או במטעין פלאגינים חם כקיצור דרך; טעינה מחדש של פלאגינים עלולה להשאיר תלויות ומצב לא עקביים.
ב-Vanilla, התחילו ב-server.properties. ב-Spigot וב-Paper, בדקו גם את spigot.yml: הגדרות מרחק לכל עולם יכולות לדרוס את קובץ ה-properties.
הקטע הזה מראה ירושה, לא פריסט ביצועים:
world-settings:
default:
view-distance: default
simulation-distance: default
כאן, default אומר לאפשרויות האלה להשתמש ב-server.properties. מזגו את המפתחות לתוך הקטע הקיים; אל תחליפו את כל הקובץ ואל תוסיפו בלוק world-settings שני. בדקו גם קטעי עולמות בעלי שם, כי ערך ספציפי לעולם יכול לדרוס את ההגדרה המשותפת.
אם אתם מחליפים דריסות מספריות בירושה, התייחסו לכך כאל שינוי נפרד ורשמו baseline חדש. אחרת, ייתכן שתשנו כמה מרחקים אפקטיביים לפני הניסוי המבוקר הראשון שלכם.
3. הפרידו בין נראות השטח לבין הסימולציה
שני המרחקים נמדדים ב-chunks סביב השחקן, לא בבלוקים ולא כקוטר.
- view-distance שולט בכמות נתוני העולם הנשלחים ללקוח. הקטנתו מחליפה נראות של שטח רחוק בפחות עבודה הקשורה לשמירה על התצוגה הזו זמינה.
- simulation-distance שולט באזור ה-ticking סביב השחקן. הקטנתו יכולה להפחית עבודת סימולציה, אך גם משנה את האזור שבו חוות וישויות סמוכות פועלות.
מרחק התצוגה אינו חינמי רק משום ששטח מסוים נמצא מחוץ למרחק הסימולציה. באותה מידה, הקטנתו אינה תחליף לתיקון פלאגין יקר. בחרו את הניסוי הראשון לפי הפרופיל ולפי הפשרה במשחקיות שאתם מוכנים לקבל.
נסו שינוי מרחק אחד
נניח שה-server.properties הקיים שלכם מכיל:
view-distance=10
simulation-distance=10
אם הפרופיל מצביע על עבודת ticking באזורים טעונים, ניסוי אחד הוא להשאיר את מרחק התצוגה ללא שינוי ולהקטין מעט את מרחק הסימולציה:
view-distance=10
simulation-distance=8
המספרים האלה להמחשה בלבד, ואינם ברירות מחדל אוניברסליות או פריסט של SharpHeberg שנבדק. אם מרחק התצוגה הקיים שלכם שונה, השאירו את הערך שלכם כפי שהוא. הפעילו מחדש בצורה נקייה, שחזרו את עומס העבודה המקורי ואספו דוח נוסף לפני שתמשיכו להקטין.
אם הפרופיל מרמז דווקא שהבעיה היא תחזוקה או שליחה של שטח רחוק, בדקו את מרחק התצוגה בנפרד. אל תקטינו את שתי ההגדרות יחד ואז תנסו לנחש מה עזר.
מרחק הסימולציה אינו ספר חוקים שלם לחוות. כרטיסי chunk, ששומרים chunks טעונים מסיבות מסוימות, ודרישות הקרבה לשחקן שונים בין מנגנונים וגרסאות. “טעון” אינו מבטיח שהספאונינג, צמיחת היבולים, הישויות ו-block entities כולם מתנהגים באותו אופן. בדקו את הדרישות של החווה הספציפית שלכם במקום להניח שמרחק יחיד מבטיח פעולה.
לספאונינג ולדספאונינג טבעיים יש גם כללי מרחק משלהם; mob-spawn-range של Spigot והגדרות הדספאון של Paper מוסיפים בקרות נוספות. אם חווה מפסיקה לעבוד אחרי הניסוי, החזירו תחילה את המרחק הקודם. אל תנסו מיד לפצות בשינוי של כמה הגדרות ספאון.
4. ב-Spigot או ב-Paper, בדקו את עבודת הישויות לפני שמקצצים בטווחים
אם הפרופיל מצביע על עיבוד ישויות, בדקו את האזור המושפע. חפשו פריטים שנופלים וצוברים, דירים צפופים מדי או אולם מסחר שעושה עבודה מיותרת. תאמו עם הבעלים לפני שמשנים בניות. קל יותר להעריך הפחתה של מקור מזוהה לעבודה עודפת מאשר החלשת התנהגות הישויות בכל מקום.
שתי אפשרויות בעלות שמות דומים ב-spigot.yml משרתות מטרות שונות:
| הגדרה | יחידה | מה היא שולטת |
|---|---|---|
entity-activation-range |
בלוקים | עד כמה קרובות ישויות צריכות להיות לשחקנים כדי לבצע tick כרגיל; ההתנהגות מחוץ לטווח מוגבלת. |
entity-tracking-range |
בלוקים | עד כמה רחוק ישויות נשלחות לשחקנים, מה שמשפיע על מתי הן הופכות גלויות. |
אלה בקרות ישויות, ולא המרחקים מבוססי ה-chunks שלמעלה. טווח מעקב נמוך יותר יכול לגרום למובס להופיע בפתאומיות; הוא אינו שקול להפחתת עומס ה-AI שלהם.
שינויי activation דורשים זהירות מיוחדת סביב חוות ברזל וכפריים. הנחיות הקהילה מתעדות חוות שבורות ובעיות חידוש מלאי כתוצאה מ-activation אגרסיבי מדי או משינויים בכפריים לא פעילים. השאירו את ההגדרות האלה כפי שהן אלא אם הפרופיילינג מצדיק את הפשרה, ואז בדקו את קטגוריית הישויות המושפעת במקום להעתיק פריסט שלם.
אותה זהירות חלה על nerf-spawner-mobs, על תזמון hoppers ועל שינויי מיזוג פריטים: הם משנים התנהגות, ולא רק צריכת משאבים. אל תקצצו באופן גורף ב-mob caps ואל תתקינו מחיקת ישויות מתוזמנת כתגובה הראשונה ל-lag.
5. התייחסו להגדרות Paper כאל בקרות התלויות בגרסה
ל-Paper יש שכבות הגדרות נוספות. המבנה המתועד שלו כולל את config/paper-global.yml להגדרות גלובליות ואת config/paper-world-defaults.yml להגדרות עולם משותפות. הקובץ paper-world.yml של עולם יכול לדרוס את ברירות המחדל של העולם.
אתרו את קובץ הדריסה הזה לפי התיעוד של הבילד שלכם. מבני תיקיות של עולמות וממדים משתנים; העתקת נתיב ממדריך ישן יכולה להפנות אתכם למקום הלא נכון. העתיקו רק את ההגדרות שאתם מתכוונים לדרוס, לא את קובץ ברירות המחדל כולו.
Paper חושף בקרות לספאונינג, לדספאונינג, להתנגשויות ולהתנהגות hoppers. אלה אפשרויות לבעיה מזוהה, ולא רשימת בדיקה להשלמה. לדוגמה, ביטול אירוע ההזזה של hopper יכול לשבור פלאגיני הגנה שתלויים בו. שיפור קטן בתזמון לא יצדיק עקיפה שקטה של כלל שרת.
מדריך ה-spigot.yml המצוטט מתוחזק על ידי Paper וכולל התנהגות ייחודית ל-Paper. אל תניחו שכל אפשרות מקוננת שהוא מתעד קיימת או מתנהגת באופן זהה ב-Spigot טהור. עיינו בהגדרות שנוצרו עבור המימוש והגרסה שלכם לפני שתוסיפו מפתח.
6. עקבו אחר הפרופיל מעבר להגדרות המרחק
בדקו את עבודת הפלאגינים
אם הדוח מצביע על משימה של פלאגין, שמרו את הדוח ובדקו את ההגדרות, התאימות והערות השחרור של אותו פלאגין. Paper ממליצה במפורש לשתף דוח spark רלוונטי עם מפתחי פלאגינים בעת בדיקת בעיות ביצועים.
שחזרו את הבעיה בעותק בדיקה מגובה במידת האפשר. שנו תכונה או פלאגין אחד בכל פעם, תוך כיבוד התלויות, ואז חזרו על אותה פעילות. הימנעו מכיבוי פלאגיני הגנה או כלכלה בשרת החי רק כדי לראות אם ה-TPS עולה.
גם כוונון של Java וזיכרון צריך להתבסס על ראיות. בדקו את התנהגות איסוף האשפה (garbage collection) ואת דרישות ה-Java של הבילד המדויק של השרת שלכם לפני שתשנו אפשרויות הפעלה. אוסף מועתק של דגלי GC אינו צעד אופטימיזציה אוניברסלי.
בצעו pregeneration רק כשהיצירה היא הבעיה
כשההאטה חופפת לחקירה, השוו נסיעה בשטח קיים לנסיעה לשטח חדש. אם הפרופיילינג תומך בכך שיצירת chunks היא צוואר הבקבוק, pregeneration מקדים את עבודת היצירה הזו לפני המשחק הרגיל. Chunky מספק כלים למטרה זו.
בחרו את האזור והממדים הרצויים, בדקו את נפח הדיסק והגיבוי ותזמנו את העבודה מחוץ לשעות העומס. בדקו תחילה אזור מוגבל. Pregeneration אינו מסיר את עלות הטעינה או השליחה של chunks קיימים, או את הרצת החוות בתוכם.
מדריכי קהילה חלוקים בשאלה עד כמה רחב יש להמליץ על pregeneration לשרתים מודרניים. התייחסו אליו כתגובה ללחץ יצירה שנמדד, ולא כתחזוקה חובה לכל התקנת Paper.
7. בדקו את המשחקיות לפני ששומרים את השינוי
חזרו על עומס העבודה המקורי עם מספר שחקנים ופיזור דומים. שמרו יחד את דוחות spark לפני ואחרי, את הפרש ההגדרות ואת ההערות. חזרו על ההשוואה אם התנאים השתנו באופן משמעותי.
לאחר מכן בדקו את השרת כפי שהשחקנים משתמשים בו:
- הריצו חוות חשובות מעמדות ה-AFK הרגילות שלהן, כולל איסוף והובלה.
- בדקו עסקאות כפריים וחידוש מלאי לאורך מחזור עבודה רגיל.
- הריצו מיינני hoppers ושעונים מספיק זמן כדי לחשוף פריטים שהוחמצו או תזמון ששונה.
- בדקו את הנראות וההתנהגות של מובס במהלך נסיעה, ובדקו כל עולם מושפע.
שמרו שינוי רק אם השיפור שנמדד שימושי והפשרה במשחקיות מקובלת. אם התועלת אינה ברורה, החזירו את הערך הקודם. לעולם אל תכבו שמירה כדי שגרף הביצועים ייראה טוב יותר.
אם צוואר הבקבוק שנותר נראה כקיבולת אחסון, השתמשו בדוח כדי להנחות את השיחה הזו. תוכלו לעיין באחסון Minecraft של SharpHeberg לצד עומס העבודה והדרישות שלכם. גם בחירות אחסון וגם שינויי הגדרות ראויים לאותה בדיקה: האם השרת רץ טוב יותר תוך שמירה על הדרך שבה הקהילה שלכם משחקת?
קריאה קשורה: העלות האמיתית של שרת Minecraft בעל ביצועים גבוהים ב-2025. התייחסו לכל תמחור במאמר הישן יותר הזה כהיסטורי, ולא כתעריפים נוכחיים.
מקורות
Minecraft optimization — community guide