חיפוש נקודות חמות במסד הנתונים

במאמר הזה מוסבר איך להשתמש בלוח הבקרה של תובנות לגבי נקודות חמות כדי לזהות נקודות חמות במסד הנתונים של Spanner.

סקירה כללית של תובנות לגבי נקודות אינטרנט

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

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

התובנות לגבי אזורים חמים זמינות בהגדרות של אזור יחיד, כמה אזורים ואזור כפול.

תמחור

התובנות לגבי נקודות לשיתוף אינטרנט לא כרוכות בתשלום נוסף.

שמירת נתונים

מדיניות שמירת הנתונים של התרשימים של תובנות לגבי אזורים חמים ושל הטבלה של פיצולי TopN מבוססת על טבלאות הבסיס SPANNER_SYS.SPLIT_STATS_TOP_*. לגבי מדיניות שמירה ספציפית, אפשר לעיין במאמר שמירת נתונים סטטיסטיים של פיצול חם.

התפקידים הנדרשים

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

משתמש בניהול זהויות והרשאות גישה (IAM)

כדי לקבל את ההרשאות שנדרשות לצפייה בדף Hotspot insights, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים במופע:

• הכול:
  • Cloud Spanner Viewer ‏ (roles/spanner.viewer)

  • Cloud Spanner Database Reader (roles/spanner.databaseReader)

כדי לצפות בדף Hotspot insights, נדרשות ההרשאות הבאות בתפקיד Cloud Spanner Database Reader‏ (roles/spanner.databaseReader):

• spanner.databases.beginReadOnlyTransaction
• spanner.databases.select
• spanner.sessions.create

משתמש עם בקרת גישה פרטנית

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

• צריך להיות לכם Cloud Spanner Viewer (roles/spanner.viewer)
• יש להם הרשאות בקרת גישה פרטניות, והם קיבלו את spanner_sys_readerתפקיד המערכת או אחד מתפקידי החברים שלו.
• בדף סקירה כללית של מסד הנתונים, בוחרים את spanner_sys_reader או תפקיד של חבר בתור התפקיד הנוכחי במערכת.

הערה: אם כבר יש לכם הרשאה ברמת מסד הנתונים ב-IAM, כמו spanner.databases.select, המסוף Google Cloud מניח שאתם משתמשים ב-IAM. אי אפשר לבחור את התפקיד spanner_sys_reader או תפקיד של חבר

בדף הסקירה הכללית של מסד הנתונים כמשתמש IAM.

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

פתיחת מרכז הבקרה Hotspot insights

בלוח הבקרה Hotspot insights מוצג אחוז השימוש המפוצל במעבד בשיא. המדד הזה הוא אחוז מופשט מ-0 עד 100 שמשקף את כמות השימוש במעבד כשניגשים לשורות בפיצול.

כדי לראות את לוח הבקרה Hotspot insights של מסד נתונים:

1. פותחים את הדף Spanner במסוף Google Cloud .

   כניסה ל-Spanner

2. בוחרים מופע מהרשימה.

3. בתפריט הניווט, לוחצים על הכרטיסייה Hotspot insights (תובנות לגבי אזורים חמים).

4. בשדה database (מסד נתונים), בוחרים מסד נתונים מהרשימה. לוח הבקרה מציג את הציון של השימוש המקסימלי במעבד שפועל במקביל למסד הנתונים.

לוח הבקרה כולל את הרכיבים הבאים:

• תרשים הציון של שיא השימוש במעבד (CPU): ציון גבוה יותר של שימוש במעבד (למשל, קרוב ל-100) מצביע על כך שהפיצול חם וסביר מאוד שהוא גורם לנקודה חמה בשרת, בהשוואה לציונים נמוכים יותר.
• שדה מסד נתונים: מסנן את המידע על פיצולים פעילים במסד נתונים ספציפי או בכל מסדי הנתונים.
• מסנן טווח הזמן: מסנן את השימוש במעבד לפי פיצולים של שיא השימוש במרווחי זמן של דקה אחת, עד ל-6 שעות בסך הכול.
• טבלת פיצולים TopN: מוצגת רשימה של הפיצולים המובילים שממוינים לפי ציוני השימוש במעבד של הפיצול.

הסבר על הנתונים בטבלה TopN Splits: הנתונים בטבלה TopN splits מאוכלסים מתוך טבלאות SPANNER_SYS.SPLIT_STATS_TOP_* הבסיסיות בהתאם לטווח הזמן שבוחרים. מידע נוסף זמין במאמר בנושא שמירת נתונים סטטיסטיים של פיצול חם.

הסבר על השורות בטבלאות 10MINUTE או HOUR: השורות שמקורן בטבלאות SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE או SPANNER_SYS.SPLIT_STATS_TOP_HOUR מייצגות נתונים מצטברים על פני המרווחים המתאימים. כפי שמתואר במאמר בנושא צבירת אירועים בטבלה, הערך CPU_USAGE_SCORE בשורות האלה הוא הציון המקסימלי שנצפה במרווח משנה של דקה אחת, והערך UNSPLITTABLE_REASONS הוא איחוד של הסיבות.

קביעה אם יש צורך בהתערבות בנקודות חמות

אם אתם רואים עלייה חדה או עלייה בתרשים שמתאימה לזמן האחזור הכולל ולציון גבוה מתמשך של שימוש ב-CPU, כדאי להמשיך לבדוק.

כדאי לעיין בתרשים כדי לקבל תשובות לשאלות הבאות:

• באיזה מסד נתונים יש ירידה בביצועים של זמן האחזור? בוחרים מסדי נתונים שונים מהרשימה Databases כדי למצוא את מסדי הנתונים עם זמן האחזור הכי גבוה. כדי לגלות איזו מסד נתונים נמצא בעומס הכי גבוה, אפשר גם לעיין בתרשים ההשהיה של מסדי נתונים במסוף Google Cloud .

  

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

• האם הניקוד הגבוה של השימוש ב-CPU בזמן השיא הוא 100%? האם יש קפיצות בתרשים או שהערכים עולים לאורך זמן? אם לא רואים אחוזים של שימוש במעבד בפיצול של 100% בשיא באופן קבוע במשך 10 דקות לפחות, יכול להיות שהנקודות החמות לא מהוות בעיה. אם אחוז השימוש המפוצל ב-CPU בשיא גבוה יותר מ-10 דקות, כדאי לבדוק אם מסד הנתונים כולל רמות זמן אחזור גבוהות מהצפוי.

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

זיהוי פיצולים חמים בעייתיים

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

בטבלה TopN splits מוצגת סקירה כללית של הפיצולים שעשויים להיות פופולריים בחלון הזמן שנבחר, ממוינים מהעדכני ביותר למוקדם ביותר. מספר הפיצולים של TopN מוגבל ל-100.

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

הטבלה מציגה את המאפיינים הבאים:

• סוף פרק הזמן: התאריך והשעה שבהם מסתיים השימוש הגבוה ב-CPU.
• פיצול התחלה: מפתח ההתחלה של טווח השורות בפיצול. אם תאריך ההתחלה של הפיצול הוא <begin>, זה מציין את ההתחלה של טווח המפתחות במסד הנתונים.
• Split limit: מפתח ההגבלה של טווח השורות בפיצול. אם מפתח ההגבלה הוא <end>, זה מציין את סוף טווח המפתחות של מסד הנתונים.
• ציון פיצול השימוש במעבד: ציון מופשט בין 0 ל-100 שמשקף את כמות השימוש במעבד בגישה לשורות בפיצול בשרת יחיד. אפשר להשתמש בציון השימוש במעבד כדי להעריך אם יש נקודות חמות.
• הטבלאות המושפעות: הטבלאות שהשורות שלהן עשויות להיות בפיצול.
• סיבות שלא ניתן לפצל: מערך של סיבות לכך ש-Spanner לא יכול לפצל עוד יותר פיצול פעיל. אם יש כאן ערכים, זה מצביע על כך שפיצול מבוסס עומס לא יכול לצמצם את הנקודה החמה מהסיבות שמפורטות כאן. מידע נוסף זמין במאמר בנושא סוגי UNSPLITTABLE_REASONS.

ניתוח סיבות שלא ניתן לפצל

בטבלה TopN splits אפשר לבצע חיתוך לפי which specific splits כדי לראות אילו מהם מושפעים מהסיבות האלה בזמנים מסוימים, כמו שמוצג בעמודה Unsplittable reasons.

דוגמה לתהליך אבחון

זהו תהליך עבודה אופייני לניפוי באגים בנקודות חמות באמצעות לוח הבקרה:

1. לזהות את בעיית הביצועים: שימו לב לזמן אחזור ארוך יותר או לשגיאות באפליקציה.
2. פותחים את לוח הבקרה Hotspot insights: עוברים ללוח הבקרה Hotspot insights במסוף Google Cloud של מסד הנתונים הרלוונטי ב-Spanner. בוחרים את טווח הזמן שבו הבעיה התרחשה.
3. בדיקת הגרף:
   • כדאי לבדוק את התרשים Peak split CPU usage score כדי לראות אם יש ערכים גבוהים לאורך זמן, למשל >50%, במיוחד אם הערכים מתקרבים ל-100% למשך 10 דקות לפחות.
4. זיהוי הפיצולים המושפעים והשוואת הממצאים: אם השימוש ב-CPU גבוה, עוברים לטבלה TopN splits. אפשר לסנן או למיין כדי למצוא את הפיצולים עם ציון השימוש הגבוה ביותר במעבד לפי פיצול במהלך תקופת ההשפעה. בודקים את העמודה UNSPLITTABLE_REASONS כדי לראות את הפיצולים המובילים האלה:
   • ציון גבוה של שימוש במעבד בפיצול וסיבות שלא מאפשרות פיצול: זהו אות חזק לכך שבעיית הביצועים קשורה לנקודות חמות ש-Spanner לא יכול לפתור באופן אוטומטי. סוג הסיבה, כמו HOT_ROW או MOVING_HOT_SPOT, מספק רמז חשוב.
   • ציון גבוה של שימוש במעבד מפוצל ואין סיבות לאי פיצול: יכול להיות שהאזור הפעיל חדש, ו-Spanner עדיין בתהליך של פיצול. לחלופין, יכול להיות שהבעיה היא תגובה לשינויים בעומס העבודה, ולא נדרשת פעולה מצדכם.
5. מבינים את הסיבות: שימו לב לקודים הספציפיים במערך [UNSPLITTABLE_REASONS].
6. הפחתת הסיכון: בהתבסס על הסיבות שזוהו, אפשר לעיין בסוגים של UNSPLITTABLE_REASONS כדי לקבל הסברים מפורטים ואסטרטגיות מומלצות להפחתת הסיכון. בדרך כלל האסטרטגיות האלה כוללות שינויים בעיצוב הסכימה או התאמות בעומס העבודה.

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

• מידע על נתונים סטטיסטיים של נקודות לשיתוף אינטרנט