איך לתקן לאג בשרת Minecraft

לאג של השרת, של הרשת או של הלקוח?

הבדיקה המהירה ביותר היא לשאול אם כולם מלגלגים באותו רגע. שרת שלא עומד בקצב מקפיא את כל השחקנים יחד; חיבור גרוע או מחשב איטי פוגעים רק בבעלים שלהם. שאר המדריך עוסק בלאג של השרת.

קודם מודדים: TPS, MSPT ו-spark

שרת Minecraft רץ ב-20 ticks לשנייה, כך שלכל tick יש 50 ms להסתיים. שני מספרים מתארים איך הוא מתמודד:

• TPS (ticks לשנייה): 20 אומר שהשרת עומד בקצב; מתחת ל-20 העולם מאט.
• MSPT (מילישניות ל-tick): כמה זמן לוקח כל tick. מתחת ל-50 ms יש זמן פנוי; מעל 50 ms השרת מפגר.

ב-Paper יש /tps ו-/mspt, אבל התיעוד שלו עצמו מפנה ל-spark, שמובנה ב-Paper מאז 1.21 וזמין כמוד ל-Fabric, Forge ו-NeoForge:

/spark tps
/spark health
/spark ping

/spark tps מציג את ה-TPS בשניות ובדקות האחרונות, ומה שמועיל יותר — את משכי ה-tick כמינימום, חציון, אחוזון 95 ומקסימום. /spark ping מציג את הפינג של השחקנים, וזה מכריע את השאלה "שרת או רשת". /spark health מוסיף CPU, זיכרון ודיסק.

מוצאים את הסיבה עם פרופיל של spark

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

/spark profiler start --timeout 300

כשהוא מסתיים, spark מפרסם קישור לצופה האינטרנטי שלו. שם:

1. פתחו את Server thread — ה-thread הראשי שמריץ את העולם. שם הלאג נמצא.
2. הרחיבו את הרשומות עם האחוזים הגבוהים ביותר: לשם הולך זמן ה-tick.
3. עברו לתצוגת Sources כדי לראות את הזמן מחולק לפי פלאגין או מוד. פלאגין או מוד אחד שלוקח נתח גדול מה-thread הראשי הוא בדרך כלל התשובה.

עוד שני כלים עוזרים בלאג שבא והולך: /spark tickmonitor מדווח על כל tick שמתארך, ו-/spark profiler start --only-ticks-over 100 מתעד רק את ה-ticks האיטיים, כדי שקפיצה נדירה לא תיבלע בממוצע.

התיקונים שחשובים, לפי הסדר

1. מרחק ראייה ומרחק סימולציה

ב-server.properties, simulation-distance קובע עד כמה רחוק מהשחקנים העולם באמת מסומלץ — מובים, יבולים, רדסטון — ו-view-distance עד כמה רחוק נשלחים chunks לשחקנים. ברירת המחדל של שניהם היא 10. הורדת simulation-distance היא לרוב השיפור הגדול ביותר: נסו 6 עד 8, והשאירו את view-distance קצת גבוה יותר כדי שהעולם עדיין ייראה פתוח. אלה נקודות התחלה, לא ערכים רשמיים; מדדו לפני ואחרי.

2. ייצור מוקדם של העולם

יצירת chunks חדשים היא אחת הפעולות היקרות ביותר שהשרת עושה, ושחקנים שחוקרים לכיוונים שונים גורמים לו לעשות זאת כל הזמן. הפלאגין (או המוד) Chunky מייצר את המפה מראש:

chunky radius 5000
chunky start
chunky pause
chunky continue

הריצו אותו כשאף אחד לא משחק — ייצור מוקדם שרץ גורם לשרת לדווח "Can't keep up" מעצם טבעו — והשהו אותו כששחקנים מצטרפים.

3. ישויות וחוות

חוות מובים, אולמות כפריים וערימות חפצים הם העומס הקבוע הנפוץ ביותר. ב-Paper וב-Spigot, entity-activation-range ב-spigot.yml קובע כמה קרוב שחקן צריך להיות כדי שישות תעבור tick מלא, ו-merge-radius ממזג חפצים שנפלו וכדורי ניסיון. הגבילו חוות מובים עם פלאגין או כלל, ונקו ערימות חפצים שנשכחו.

4. משפכים ורדסטון

שרשראות משפכים גדולות הן יקרות. ב-spigot.yml, ticks-per.hopper-transfer קובע באיזו תדירות הם מעבירים חפצים, ו-hopper.disable-move-event של Paper מאיץ אותם מאוד — אבל שובר פלאגיני הגנה שמסתמכים על האירוע הזה. לרדסטון, misc.redstone-implementation: ALTERNATE_CURRENT של Paper יכול להפחית מאוד את הלאג מאבקת רדסטון, אבל הוא משנה את התנהגות האבקה, אז בדקו קודם את המתקנים שלכם.

5. הפלאגין או המוד שבפרופיל

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

"TPS הוא 20 אבל עדיין יש לאג"

זה המקרה המבלבל ביותר, וכמעט תמיד מדובר בתקיעת tick: רוב ה-ticks מהירים, אבל מדי פעם אחד לוקח מאות מילישניות. הממוצע נשאר 20, ובכל זאת כולם מרגישים קפיאה.

• בדקו את זמן ה-tick המקסימלי ב-/spark tps, או הריצו /spark tickmonitor. קפיצות של כמה מאות מילישניות מאשרות את זה.
• הסיבה הרגילה היא פלאגין שממתין על ה-thread הראשי — מוריד סקינים או ראשים של שחקנים מהאינטרנט, שולח ל-webhook, בודק עדכונים או רישיון, או שומר קובץ או מסד נתונים באופן סינכרוני. השרת לא עושה כלום בזמן שהוא ממתין.
• תעדו את ההמתנה, לא רק את החישוב. פרופיל רגיל מציג עבודת CPU; thread שממתין נראה בטל. השתמשו ב-/spark profiler start --thread * כדי לתעד לאן הולך הזמן כולל המתנות, וחפשו קריאות רשת או קבצים ב-Server thread.

התיקון נמצא בפלאגין — קריאות אסינכרוניות, או פלאגין אחר. יותר RAM, CPU מהיר יותר או חיבור טוב יותר לא יעזרו, כי לשרת לא חסר כלום; הוא ממתין.

מתי התשובה באמת היא RAM או CPU

Minecraft מסמלץ את העולם על thread ראשי אחד. יש לכך שתי השלכות:

• מהירות ה-CPU לליבה היא הכי חשובה. אם spark מראה ש-Server thread עסוק בעבודת עולם רגילה — ישויות, chunks, ticks של בלוקים — ו-MSPT גבוה, CPU מהיר יותר עוזר במקום שבו יותר ליבות לא היו עוזרות.
• RAM עוזר רק כשחסר לכם. סימנים: השרת מופעל מחדש כשהוא מגיע למגבלת הזיכרון, או שהשהיות garbage collection שולטות בפרופיל. מעבר למה שהעולם והמודים צריכים, עוד RAM לא עושה כלום למהירות ה-tick — ו-heap גדול מדי ולא מכוונן יכול להאריך את השהיות ה-garbage collection.

כמה RAM שרת צריך, ודגלי ההפעלה ששומרים על garbage collection קצר, מוסברים בכמה RAM צריך שרת Minecraft. הבחירה בין Paper, Purpur והשאר נמצאת בתוכנת שרת Minecraft הטובה ביותר.

לאג והשרת שלכם ב-HytHost

כל חבילות Minecraft של HytHost רצות על אותה חומרה: מעבדי Ryzen 7 ו-Intel i9 עם boost של עד 5.0 GHz, זיכרון DDR4 ואחסון NVMe — מהירות ה-thread הבודד ש-Minecraft תלוי בה. spark כבר חלק מ-Paper, כך שאפשר לבצע פרופיל מהקונסול מיד.

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