סקירה כללית של תיעוד הביצועים ב-Cloud SQL

‫MySQL   |  PostgreSQL   |  SQL Server

התכונה 'תיעוד הביצועים של Cloud SQL ל-MySQL' עוזרת לכם לאבחן ולפתור בעיות מורכבות וחולפות בביצועים של מסד הנתונים של MySQL, שנגרמות כתוצאה משינויים בביקוש למערכת. ככל שעומסי העבודה של האפליקציות גדלים והתשתית שמסביב הופכת למורכבת יותר, הדרישות ממסדי הנתונים גדלות וקשה יותר לצפות אותן. הלחצים האלה ממערכות חיצוניות עלולים לגרום להאטה או לעצירה של מסד הנתונים.

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

תרחישים לדוגמה

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

תרחיש שימוש	תנאי ההפעלה	תובנות מהאבחון
האטה במערכת כולה בגלל הצטברות של יומן הביטול	אורך רשימת ההיסטוריה	מזהה מקרים שבהם תהליך הניקוי של InnoDB מפגר בגלל קריאות ארוכות או פעולות גדולות של שפת טיפול בנתונים (DML). העיכוב עלול להוביל לעומס על האחסון ולפגיעה בביצועים.
השהיה במסד הנתונים נגרמת בגלל התנגשות פנימית במנוע	המתנה לסמפור	הוא יכול לעזור באבחון של מסד נתונים שלא מגיב. הטריגר הזה יכול לזהות מחלוקת על mutex או על נעילת קריאה-כתיבה במנוע האחסון InnoDB, כמו מחלוקת על אינדקס גיבוב אדפטיבי (AHI) או על מאגר נתונים זמני.
התנגשות נעילה ברמת האפליקציה או שאילתות לא מאונדקסות	המתנות של נעילת עסקאות	ההתראה מופעלת כשמספר גדול של עסקאות נמצאות במצב LOCK WAIT, מה שמצביע על תחרות ברמת השורה או על עסקאות סרק שפועלות במשך זמן רב.
עומס יתר על מופע כתוצאה ממיון או צבירה מורכבים	ניצול גבוה של המעבד	מצב תיעוד במהלך שימוש גבוה במעבד של קונטיינר, שנגרם בדרך כלל משאילתות לא יעילות או מעליות חדות בבו-זמניות.
סיכון להפעלה מחדש של OOM (חוסר בזיכרון)	שימוש גבוה בזיכרון	הכלי עוזר לאבחן בעיות כמו מאגרי נתונים זמניים גדולים מדי לכל שרשור או דליפות זיכרון לפני שהן גורמות לקריסת מופע.
עליות פתאומיות בתנועת הגולשים או צווארי בקבוק באפליקציות לקוח	הפעלת שרשורים	אינדיקטור כללי של עומס המופע, שימושי לזיהוי עליות פתאומיות במספר החיבורים הפעילים בו-זמנית.
נתונים מיושנים בעותק המשוכפל בגלל עומסי עבודה כבדים של כתיבה	שניות אחרי המקור	עוקב אחרי השהיית הרפליקציה בעותקי קריאה כדי לאבחן עיכובים בסנכרון הנתונים מהמופע הראשי.
שאילתות ממושכות שחוסמות מחיקה	עסקאות ממושכות	זיהוי עסקאות שנשארו פתוחות יותר מדי זמן ושעלולות להחזיק נעילות קריטיות. בנוסף, אפשר לסיים באופן אוטומטי טרנזקציות שפועלות במשך זמן רב.

איך נתוני הביצועים מתועדים

הלכידה של הביצועים פועלת כשירות מבוסס-סוכן שמנטר את המופע שלכם. כשמפעילים את התכונה 'תיעוד ביצועים', המכונה של Cloud SQL מבצעת את הפעולות הבאות כדי לתעד את נתוני הביצועים:

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

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

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

   אם מוגדרים כמה תנאי טריגר, Cloud SQL יתחיל ללכוד נתונים אם אחד מהתנאים מתקיים.

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

4. המידע שנאסף מעוצב כרשומות ביומן ונשלח ישירות אל Cloud Logging של הפרויקט עבור מכונת Cloud SQL, במסגרת זרם יומן ספציפי בשם mysql-performance-capture.log.

תקופות צינון והשהיה דינמית

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

תקופת צינון רגילה

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

השהיה דינמית והשהיה חוזרת

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

במסגרת המנגנון הזה:

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

טריגרים לתיעוד ביצועים

בקטע הזה מפורטים הטריגרים שזמינים לתיעוד הביצועים של MySQL. כל הטריגרים שמפורטים בטבלה, אלא אם צוין אחרת, משתמשים בערכי ההגדרות של הבדיקה probingIntervalSeconds ו-probeThreshold כדי לאמת תנאי טריגר מתמשכים.

‫Trigger ‫condition ‫name	שם ה-API	תיאור	ערך ברירת מחדל	הגדרת טווח
ניצול גבוה של המעבד	cpuUtilizationThresholdPercent	הפעלת תיעוד כששיעור השימוש הכולל במעבד (CPU) של מופע מסד הנתונים חורג באופן עקבי מהאחוז הזה. המידע הזה עוזר לזהות עומס יתר על המופע, שלרוב נגרם כתוצאה משאילתות לא יעילות עם מיון וצבירה נרחבים, מאינדקס לא מספיק או מריבוי משימות בו-זמניות. כדי להימנע מתיעוד של עליות קלות, צריך להגדיר את ברירת המחדל כך שתהיה בטווח האחוזים הגבוה יותר של המופע.	0 (מושבת)	0 או 10-99 (%)
שימוש בנפח גדול מהזיכרון	memoryUsageThresholdPercent	הפעלת צילום כששימוש הזיכרון של מאגר הנתונים חורג באופן עקבי מהאחוז הזה של הזיכרון שהוקצה למופע. הטריגר הזה יכול לעזור לאבחן בעיות פוטנציאליות של חוסר זיכרון, דליפות זיכרון או הגדרת זיכרון לא יעילה. כדי למנוע תיעוד של עליות קטנות, צריך להגדיר את ברירת המחדל בקצה הגבוה של הטווח עבור המופע.	0 (מושבת)	0 או 10-99 (%)
שימוש בקבצים בטמפרטורה גבוהה	לא ניתן להגדרה. הטריגר הזה מופעל באופן אוטומטי ב-MySQL מגרסה 8.0 ואילך.	הפעולה הזו מפעילה באופן אוטומטי צילום כשמתרחשת עלייה משמעותית בשימוש בדיסק מקבצים זמניים שנוצרו על ידי תהליך MySQL. לעתים קרובות קבצים זמניים נמחקים אבל עדיין נשארים פתוחים בתהליך של MySQL. הסף להפעלת הטריגר הזה מבוסס על מודל של עלייה הדרגתית בספי ההבדלים. הנפח מתחיל ב-100GB‎ ומוכפל ברצף ל-200GB‎, ל-400GB‎ ועד ל-1.6TB‎ אחרי כל תקופת צינון. שימוש במודל הדרגתי של העברת בעיות לטיפול ברמה גבוהה יותר, מאפשר ללכוד את הביצועים רק אם ההבדל בשימוש בקובץ הזמני גדל ברמה גבוהה.	מופעל	לא רלוונטי
אורך רשימת ההיסטוריה	historyListLengthThresholdCount	הפעלת צילום כשגודל רשימת ההיסטוריה (HLL) של InnoDB גדל מעבר לערך שהוגדר. ערך גבוה באופן עקבי של HLL מצביע על כך שתהליך הניקוי של InnoDB לא מצליח לעמוד בקצב, וספירת העסקאות שלא נוקו עולה, לרוב בגלל עסקאות שפועלות במשך זמן רב. המספר הגבוה הזה עלול להוביל לצריכת נפח אחסון מוגברת ולבעיות בביצועים. הסף הזה תלוי בעומס העבודה. חלק מהמקרים יכולים לפעול בצורה מספקת גם עם HLL גבוה באופן עקבי. עם זאת, עדיין אפשר להשתמש בטריגר הזה כדי להדגיש בעיות פוטנציאליות כמו קריאות ארוכות, הצהרות גדולות של שפת טיפול בנתונים (DML) או צווארי בקבוק של שרשור ניקוי.	0 (מושבת)	‫0 או ‫10000-10000000
עסקאות ממושכות	transactionDurationThreshold	עסקה נרשמת ביומן אם היא נמשכת יותר מפרק הזמן שהוגדר בשניות. הטריגר הזה שימושי לזיהוי פעולות שעשויות להחזיק נעילות לתקופות ממושכות מדי או לצרוך משאבים למשך זמן ארוך מדי. עסקאות שחורגות מ- transactionDurationThreshold נבדקות אחרי כל מרווח זמן שצוין בהגדרות probingIntervalSeconds (ברירת מחדל: 30 שניות). עם זאת, כדי לנהל את נפח היומן, הפרטים של עד 10 מהעסקאות הארוכות האלה נשלחים אל Cloud Logging לכל היותר פעם אחת בכל תקופת צינון (30 דקות). טקסט השאילתה המלא באורך של עד 1,024 בייט מ-INFORMATION_SCHEMA.INNODB_TRX נכלל בכל רשומה ביומן עבור 10 העסקאות המובילות.	‫3600 (שניות)	60 או יותר
שגיאה בשרשור SQL/IO של העותק	לא ניתן להגדרה. הטריגר הזה מופעל כברירת מחדל באופן אוטומטי בכל מופעי הרפליקה, ואי אפשר להשבית אותו.	הפקודה מפעילה לכידה באופן מיידי אם השרשור של SQL או השרשור של קלט/פלט בשכפול במכונת רפליקה נתקל בשגיאה כלשהי ומפסיק. הטריגר הזה קריטי לשמירה על שלמות העותק ולזיהוי כשלים בשכפול. הטריגר הזה לא משתמש בהגדרות של בקשה לבדיקת תקינות (probe) כמו probingIntervalseconds או probeThreshold כדי לאמת את התנאים של לכידת הביצועים.	מופעל	לא רלוונטי
הפעלת שרשורים	runningThreadsThreshold	הטריגר מפעיל לכידה כשמספר השרשורים הפעילים שפועלים על סמך משתנה הסטטוס threads_running חורג מהערך שצוין. לדוגמה, אפשר להגדיר את הסף להפעלת לכידת הביצועים אם מספר השרשורים הפעילים שפועלים גבוה מ-100. הטריגר הזה נדרש כדי לתעד את הביצועים. אם לא מגדירים את הטריגר הזה באופן מפורש, ערך ברירת המחדל מחושב על סמך מספר ליבות ה-CPU הווירטואליות ששייכות למופע.	MIN(600, cpuCount * 20)	10 או יותר
שניות אחרי המקור	secondsBehindSourceThreshold	ההגדרה מפעילה לכידה כשזמן ההשהיה של השכפול במופע של העותק לקריאה, שנמדד בשניות, חורג מהערך שצוין. אתם יכולים להשתמש בטריגר הזה כדי לעקוב אחרי עיכובים בשכפול ולאבחן אותם. הטריגר הזה מופעל באופן אוטומטי עבור מופעי העתקה. אם לא מגדירים את הטריגר באופן מפורש, ברירת המחדל היא 900 שניות. מומלץ להגדיר את הערך בקצה הגבוה כדי להימנע מאיסוף נתונים מוגזם ומזמני השהיה ארוכים מדי.	‫900 (שניות)	1 או יותר
המתנה לסמפור	semaphoreWaitThresholdCount	הטריגר מופעל כשהמספר של השרשורים שממתינים לסמפורים פנימיים של InnoDB חורג מהערך המוגדר של הטריגר הזה. מדד מתקדם שמציין התנגשות, באמצעות mutex או נעילת קריאה-כתיבה, במנוע האחסון InnoDB עצמו. הבעיות הנפוצות שרואים הן בעיות שקשורות ל-Adaptive Hash Index‏ (AHI), ל-buffer pool ול-disk IO. הפעלה של צילום מתרחשת גם אם זמן ההמתנה המקסימלי של סמפור יחיד חורג מ-200 שניות, ללא קשר לערך המוגדר של ההפעלה הזו.	0 (מושבת)	‫0 או ‫10-10000
המתנה של נעילת עסקה	transactionLockWaitThresholdCount	הפעולה תופעל כשהמספר של העסקאות במצב LOCK WAIT יעלה על המספר שהוגדר. מספר קטן של טרנזקציות במצב המתנה לנעילה יכול להיות נורמלי במערכת עמוסה, אבל מספר גבוה באופן עקבי של המתנות לנעילה הוא אינדיקטור חזק לבעיות של תחרות על נעילה ברמת האפליקציה, ל-DMLs לא מאונדקסים, לטרנזקציות ארוכות במצב המתנה ולתחרות גבוהה על תוכן שורות, שיכולות לפגוע באופן משמעותי בביצועים ובקצב העברת הנתונים.	0 (מושבת)	‫0 או ‫10-10000

תמחור

התכונה 'תיעוד ביצועים' זמינה בכל האזורים של Cloud SQL ללא עלות נוספת. חיובים רגילים חלים רק על משאבי מסד הנתונים הבסיסיים. הנתונים של ביצועי המערכת נשמרים ביומנים ב-Cloud Logging, ולכן יכול להיות שיהיו עלויות נוספות על אחסון ב-Cloud Logging.

מידע נוסף על התמחור של אחסון יומנים ב-Logging זמין במאמר בנושא תמחור.

מגבלות

• כדי להשתמש בתיעוד הביצועים, צריך להפעיל את התובנות לגבי שאילתות. אם משביתים את התובנות לגבי שאילתות, גם איסוף נתוני הביצועים מושבת.
• התכונה 'תיעוד ביצועים' זמינה רק ב-Cloud SQL ל-MySQL 5.7 ואילך.

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

• הגדרת איסוף נתוני ביצועים
• צפייה ביומנים של תיעוד הביצועים
• מעקב אחרי מופעים