streamalism.org

1. סקירה כללית

במדריך מהיר זה נחקור את האפשרויות המוכרות ביותר בהן ניתן להשתמש כדי להגדיר את מכונת ה- Java Virtual.

2. זיכרון ערימה מפורש - אפשרויות Xms ו- Xmx

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

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

-Xms [יחידה] -Xmx [יחידה]

פה, יחידה מציין את היחידה בה הזיכרון (מסומן על ידי גודל הערימה) צריך להיות מאותחל. ניתן לסמן יחידות כמו 'G' עבור GB, 'M' עבור MB ו- 'K' עבור KB.

לדוגמא, אם ברצוננו להקצות מינימום 2 ג'יגה-בייט ומקסימום 5 ג'יגה-בייט ל- JVM, עלינו לכתוב:

-Xms2G -Xmx5G

החל מ- Java 8, הגודל של מטספייס אינו מוגדר. ברגע שהוא מגיע למגבלה הגלובלית, JVM מגדיל אותו באופן אוטומטי. עם זאת, כדי להתגבר על כל חוסר יציבות מיותרת, אנו יכולים לקבוע מטאספייס גודל עם:

-XX: MaxMetaspaceSize = [יחידה]

פה, גודל metaspace מציין את כמות הזיכרון שאנו רוצים להקצות מטאספייס.

בהתאם להנחיות אורקל, לאחר הזיכרון הכולל הזמין, הגורם השני המשפיע ביותר הוא שיעור הערימה השמור לדור הצעיר. כברירת מחדל, הגודל המינימלי של ה- YG הוא 1310 MB, והגודל המרבי הוא ללא הגבלה.

אנו יכולים להקצות אותם במפורש:

-XX: NewSize = [יחידה] -XX: MaxNewSize = [יחידה]

3. איסוף זבל

ליציבות טובה יותר של היישום, בחירה באלגוריתם הנכון של איסוף אשפה היא קריטית.

ל- JVM יש ארבעה סוגים של GC יישומים:

• אספן אשפה סדרתי
• אספן אשפה מקביל
• אספן אשפה של CMS
• אספן אשפה G1

ניתן להכריז על יישומים אלה באמצעות הפרמטרים הבאים:

-XX: + UseSerialGC -XX: + UseParallelGC -XX: + USeParNewGC -XX: + UseG1GC

פרטים נוספים על איסוף זבל יישומים ניתן למצוא כאן.

4. רישום GC

כדי לעקוב בקפדנות אחר תקינות היישום, עלינו לבדוק את מכשיר ה- JVM איסוף זבל ביצועים. הדרך הקלה ביותר לעשות זאת היא לרשום את GC פעילות במתכונת קריאה אנושית.

באמצעות הפרמטרים הבאים, אנו יכולים לרשום את ה- GC פעילות:

-XX: + השתמשGCLogFileRotation -XX: NumberOfGCLogFiles = -XX: GCLogFileSize = [יחידה] -Xloggc: /path/to/gc.log

השתמש ב- GCLogFileRotation מציין את מדיניות גלגול קובצי היומן, בדומה ל log4j, s4lj וכו '. NumberOfGCLogFiles מציין את המספר המרבי של קבצי יומן שניתן לכתוב למחזור חיים יחיד של היישום. GCLogFileSize מציין את הגודל המרבי של הקובץ. סוף כל סוף, loggc מציין את מיקומו.

נקודה לציין כאן היא כי ישנם שני פרמטרים נוספים של JVM זמינים (-XX: + PrintGCTimeStamps ו -XX: + PrintGCDateStamps) שניתן להשתמש בהם כדי להדפיס חותמת זמן בתאריך GC עֵץ.

לדוגמא, אם אנו רוצים להקצות מקסימום 100 GC קבצי יומן, שלכל אחד מהם גודל מרבי של 50 מגה בייט ורוצים לאחסן אותם ב '/ בית / משתמש / יומן / ' אנו יכולים להשתמש בתחביר הבא:

-XX: + UseGCLogFileRotation -XX: NumberOfGCLogFiles = 10 -XX: GCLogFileSize = 50M -Xloggc: /home/user/log/gc.log

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

5. טיפול בזיכרון

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

זו הסיבה ש- JVM מגיע עם כמה פרמטרים המשליכים זיכרון ערימה לקובץ פיזי שניתן להשתמש בו מאוחר יותר לגילוי דליפות:

-XX: + HeapDumpOnOutOfMemoryError -XX: HeapDumpPath =. / Java_pid.hprof -XX: OnOutOfMemoryError = ";" -XX: + השתמש ב- GCOverheadLimit

כמה נקודות שיש לציין כאן:

• HeapDumpOnOutOfMemoryError מורה ל- JVM להשליך ערימה לתיק פיזי במקרה של OutOfMemoryError
• HeapDumpPath מציין את הנתיב שבו יש לכתוב את הקובץ; ניתן לתת כל שם קובץ; עם זאת, אם JVM ימצא א תג שם, מזהה התהליך של התהליך הנוכחי שגורם לשגיאת הזיכרון יצורף לשם הקובץ עם .hprof פוּרמָט
• OnOutOfMemoryError משמש להוצאת פקודות חירום לביצוע במקרה של שגיאת זיכרון; יש להשתמש בפקודה נכונה בחלל טיעוני cmd. לדוגמא, אם ברצוננו להפעיל מחדש את השרת ברגע שלא נוצר זיכרון, אנו יכולים להגדיר את הפרמטר:

-XX: OnOutOfMemoryError = "כיבוי -r"

• השתמש ב- GCOverheadLimit היא מדיניות המגבילה את חלק הזמן של ה- VM שמושקע ב- GC לפני OutOfMemory שגיאה נזרקת

6. 32/64 ביט

בסביבת מערכת ההפעלה שבה מותקנות גם חבילות 32 וגם 64 סיביות, ה- JVM בוחר אוטומטית חבילות סביבתיות של 32 סיביות.

אם אנו רוצים להגדיר את הסביבה ל- 64 סיביות באופן ידני, אנו יכולים לעשות זאת באמצעות הפרמטר הבא:

-ד

מערכת ההפעלה יכולה להיות גם 32 אוֹ 64. מידע נוסף על כך ניתן למצוא כאן.

7. שונות

• -שרת: מאפשר “VM Hotspot Server”; פרמטר זה משמש כברירת מחדל ב- JVM של 64 סיביות
• -XX: + UseStringDeduplication: ג'אווה 8u20 הציג פרמטר JVM זה להפחתת השימוש המיותר בזיכרון על ידי יצירת יותר מדי מופעים מאותו הדבר חוּט; זה מייעל את זיכרון הערימה על ידי צמצום כפילויות חוּט ערכים למערך char [] גלובלי יחיד
• -XX: + השתמש ב- LWPS סינכרון: סטים LWP (תהליך משקל קל) - מדיניות סנכרון מבוססת במקום סנכרון מבוסס חוט
• -XX: LargePageSizeInBytes: מגדיר את גודל העמוד הגדול המשמש לערימת Java; זה לוקח את הטיעון ב- GB / MB / KB; עם גדלי עמודים גדולים יותר אנו יכולים לנצל טוב יותר את משאבי חומרת הזיכרון הווירטואליים; עם זאת, הדבר עלול לגרום לגדלי שטח גדולים יותר עבור פרמגן, אשר בתורו יכול לאלץ להפחית את גודל שטח הערימה של Java
• -XX: MaxHeapFreeRatio: מגדיר את האחוז המרבי של הערימה לאחר GC כדי למנוע התכווצות.
• -XX: MinHeapFreeRatio: מגדיר את האחוז המינימלי של הערימה לאחר GC כדי למנוע הרחבה; כדי לפקח על השימוש בערימה אתה יכול להשתמש ב- VisualVM שנשלח עם JDK.
• -XX: SurvivorRatio: יחס של עֵדֶן/גודל שטח הניצולים - לדוגמה, -XX: SurvivorRatio = 6 קובע את היחס בין כל אחד מרחב ניצולים ו חלל עדן להיות 1: 6,
• -XX: + UseLargePages: השתמש בזיכרון העמודים הגדול אם הוא נתמך על ידי המערכת; שים לב ש OpenJDK 7 נוטה לקרוס אם משתמשים בפרמטר JVM זה

• -XX: + UseStringCache: מאפשר אחסון במטמון של מחרוזות המוקצות בדרך כלל חוּט בריכה

• -XX: + UseCompressedStrings: תשתמש ב בתים [] הקלד עבור חוּט אובייקטים שניתן לייצג בפורמט ASCII טהור
• -XX: + OptimizeStringConcat: זה מייעל חוּט פעולות שרשור במידת האפשר

8. מסקנה

במאמר מהיר זה למדנו על כמה פרמטרים חשובים של JVM - באמצעותם ניתן לכוון ולשפר את ביצועי היישום הכלליים.

בחלקם ניתן להשתמש גם לצורך איתור באגים.

אם ברצונך לבחון את פרמטרי ההתייחסות ביתר פירוט, תוכל להתחיל כאן.