אופטימיזציה של הביצועים של Hyperdisk

אחרי שמקצים נפחי אחסון של Google Cloud Hyperdisk, יכול להיות שיהיה צורך לבצע כוונון של הביצועים באפליקציה ובמערכת ההפעלה כדי לעמוד בדרישות הביצועים.

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

לסקירה כללית על הביצועים של Google Cloud Hyperdisk, אפשר לעיין במאמר מידע על הביצועים של Hyperdisk.

שימוש בעומק תור גבוה של קלט/פלט

לנפחי Hyperdisk יש זמן אחזור גבוה יותר מאשר לדיסקים שמצורפים באופן מקומי, כמו SSD מקומי, כי הם מכשירים שמצורפים לרשת. הם יכולים לספק IOPS וקצב העברת נתונים גבוהים מאוד, אבל צריך לוודא שמבצעים מספיק בקשות קלט/פלט במקביל. מספר בקשות הקלט/פלט שמתבצעות במקביל נקרא עומק תור הקלט/פלט.

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

Desired IOPS עומק התור
500 1
1,000 2
2,000 4
4,000 8
8,000 16
16,000 32
32,000 64
64,000 128
100,000 200
200,000 400
320,000 640
התפוקה הרצויה (MB לשנייה) עומק התור
8 1
16 2
32 4
64 8
128 16
256 32
512 64
1,000 128
1,200 153

מוודאים שיש מעבדים פנויים

קריאה וכתיבה בכרכים של Hyperdisk דורשות מחזורי CPU מהמכונה הווירטואלית. אם למכונה הווירטואלית אין מספיק משאבי CPU, האפליקציה לא תוכל לנהל את פעולות הקלט/פלט שמתוארות למעלה. כדי להגיע לרמות גבוהות ועקביות מאוד של IOPS, צריך לוודא שיש מעבדים פנויים לעיבוד קלט/פלט.

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

מכיוון ש-Google Cloud Hyperdisk מספק הגנה מובנית מפני כתיבה קרועה, אתם יכולים להשבית את תכונות ההגנה ברמת מסד הנתונים כדי לצמצם את התקורה של קלט/פלט ולהגדיל את קצב העברת הנתונים של כתיבה למסד הנתונים בעד 25%. מידע נוסף על התכונה הזו זמין במאמר הגנה מפני כתיבה חלקית בדף הסקירה הכללית של Hyperdisk.

דרישות להגדרת הסביבה

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

אפשרות 1: יישור השכבות לגבולות של בלוקים בגודל 16 KiB (מומלץ ל-MySQL ול-PostgreSQL)

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

  • מערכת קבצים: שימוש במערכת קבצים מסוג ext4. צריך ליצור את מערכת הקבצים עם האפשרות bigalloc ולהגדיר את גודל האשכול של מערכת הקבצים ל-16 KiB ‏ (16,384 בייט) או לכפולה גדולה יותר של 16 KiB שהיא חזקה של 2:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<var>DEVICE_NAME</var>

    מחליפים את DEVICE_NAME בשם של מכשיר האחסון.

  • הגדרות שלא נתמכות: כדאי להימנע מהגדרות שעלולות לגרום לכתיבות חלקיות מעל שכבת אחסון הבלוקים (block storage), כמו ההגדרות הבאות:

    • הפעלת מסדי נתונים בקונטיינרים ב-Google Kubernetes Engine או ב-Kubernetes באירוח עצמי.
    • אחסון קבצים של מסד נתונים במערכת קבצים xfs, שבדרך כלל לא תומכת בגודלי בלוק מספיקים ברוב הפצות ה-Linux.
    • שימוש במערכים יתירים של דיסקים עצמאיים (RAID) או במנהלי נפחים לוגיים (LVM) שמסירים קלט/פלט.
    • שימוש ב-Hyperdisk עם מטמון SSD מקומי, כולל lvmcache,‏ dm-cache או bcache.
    • שימוש בווירטואליזציה מקוננת עבור מכונת ה-VM של מסד הנתונים.

אפשרות 2: שימוש בקלט/פלט אטומי של בלוקים ב-Linux (מומלץ ל-MariaDB)

אם מסד הנתונים או האפליקציה תומכים ב-I/O אטומי של בלוקים ב-Linux וניגשים לקבצים באמצעות I/O ישיר (O_DIRECT), אפשר לעקוף את כללי ההגדרה שמפורטים באפשרות 1, בתנאי שמתקיימים התנאים הבאים:

  • הדגל RWF_ATOMIC: האפליקציה צריכה להשתמש בקריאת המערכת pwritev2() עם הדגל RWF_ATOMIC. כשמשתמשים בדגל הזה, ליבת Linux מוודאת שפעולת כתיבה מעובדת כבלוק רציף יחיד על ידי מכשיר Hyperdisk הבסיסי. אם ליבת המערכת לא יכולה להבטיח אטומיות, קריאת הכתיבה תיכשל באופן מיידי כדי למנוע פגיעה בנתונים.
  • מערכת הפעלה: צריך להשתמש בגרסה 6.11 של ליבת Linux או בגרסה חדשה יותר.
  • מערכת קבצים: צריכה להיות ext4 או xfs בגרסה 6.13 של ליבת Linux ואילך.
  • גישה לקבצים: האפליקציה צריכה לפתוח קובצי מסד נתונים באמצעות קלט/פלט ישיר (O_DIRECT).
  • מסדי נתונים נתמכים: אנחנו ממליצים על האפשרות הזו רק ל-MariaDB גרסה 11.x ואילך (לתמיכה כללית ב-Linux RWF_ATOMIC). ‫MySQL ו-PostgreSQL לא תומכים בתכונה הזו.

הוראות מפורטות לאופטימיזציה של מסד נתונים ספציפי מופיעות במאמר בנושא הגדרת MySQL ב-Compute Engine.

בדיקת מדדי הביצועים של Hyperdisk

אפשר לעיין במדדי הביצועים של הדיסק ב-Cloud Monitoring, פתרון המעקב המשולב שלGoogle Cloud. אפשר להשתמש במדדים האלה כדי לבחון את הביצועים של הדיסקים ושל משאבים אחרים של מכונות וירטואליות בעומסי עבודה שונים של אפליקציות.

מידע נוסף זמין במאמר בדיקת מדדי הביצועים של הדיסק.

אפשר גם להשתמש בדף Observability במסוף כדי לראות את מדדי הביצועים של הדיסק.

המאמרים הבאים