בדף הזה מוסבר איך משתמשים בלוח הבקרה של תובנות לגבי שאילתות כדי לזהות ולנתח בעיות בביצועים. במאמר סקירה כללית על תובנות לגבי שאילתות יש סקירה כללית של התכונה.
אתם יכולים להשתמש ב-Gemini Cloud Assist כדי לעקוב אחרי משאבי AlloyDB ולפתור בעיות שקשורות אליהם. מידע נוסף זמין במאמר בנושא מעקב ופתרון בעיות בעזרת Gemini.
מגבלות
אם המופע שלכם משתמש ב-PostgreSQL 18 (גרסת Preview) ולשאילתה שלכם יש תגי הערות לפני תחילת הצהרת ה-SQL, יכול להיות שתגי האפליקציה לא יישמרו כשמשתמשים בתובנות לגבי שאילתות.
לפני שמתחילים
אם אתם או משתמשים אחרים צריכים להציג את תוכנית השאילתה או לבצע מעקב מקצה לקצה, אתם צריכים הרשאות ספציפיות של ניהול זהויות והרשאות גישה (IAM). אתם יכולים ליצור תפקיד בהתאמה אישית ולהוסיף לו את הרשאות ה-IAM הנדרשות. אחר כך תוכלו להוסיף את התפקיד הזה לכל חשבון משתמש שמשתמש בתובנות לגבי שאילתות כדי לפתור בעיה. רוצים לדעת איך יוצרים תפקיד בהתאמה אישית?
לתפקיד המותאם אישית צריכה להיות הרשאת ה-IAM הבאה: cloudtrace.traces.get.
פתיחת מרכז הבקרה של תובנות לגבי שאילתות
כדי לפתוח את מרכז הבקרה של תובנות לגבי שאילתות:
- ברשימת האשכולות והמכונות, לוחצים על מכונה.
- אפשר ללחוץ על Go to Query insights for more in-depth info on queries and performance (מעבר לתובנות לגבי שאילתות לקבלת מידע מעמיק יותר על שאילתות וביצועים) מתחת לתרשים המדדים בדף הסקירה הכללית של האשכול, או לבחור בכרטיסייה Query insights (תובנות לגבי שאילתות) בחלונית הניווט הימנית.
בדף הבא, אפשר להשתמש באפשרויות הבאות כדי לסנן את התוצאות:
- בורר המופעים. מאפשר לבחור את המופע הראשי או את המופעים של מאגר הקריאה באשכול. כברירת מחדל, המופע הראשי נבחר. הפרטים שמוצגים הם נתונים מצטברים של כל המופעים של מאגר הקריאה המחובר והצמתים שלהם.
- מסד נתונים. מסננים את עומס השאילתות במסד נתונים ספציפי או בכל מסדי הנתונים.
- משתמש. מסננים את עומס השאילתות מחשבונות משתמשים ספציפיים.
- כתובת הלקוח. סינון עומס שאילתות מכתובת IP ספציפית.
- טווח תאריכים. המסננים מאפשרים לטעון שאילתות לפי טווחי זמן, כמו שעה, יום, שבוע או טווח מותאם אישית.
עריכת ההגדרות של תובנות לגבי שאילתות
התובנות לגבי שאילתות מופעלות כברירת מחדל במופעי AlloyDB. אפשר לערוך את הגדרות ברירת המחדל של תובנות לגבי שאילתות.
כדי לערוך את ההגדרה של תובנות לגבי שאילתות במופע AlloyDB, פועלים לפי השלבים הבאים:
המסוף
נכנסים לדף Clusters במסוף Google Cloud .
לוחצים על אשכול בעמודה שם המשאב.
בחלונית הניווט הימנית, לוחצים על תובנות לגבי שאילתות.
בוחרים באפשרות Primary או Read pool מהרשימה Query insights ואז לוחצים על Edit.
עורכים את השדות תובנות לגבי שאילתות:
כדי לשנות את מגבלת ברירת המחדל של 1,024 בייטים על אורכי שאילתות לניתוח ב-AlloyDB, בשדה אורכי שאילתות, מזינים מספר בין 256 ל-4,500.
המכונה מופעלת מחדש אחרי שאתם עורכים את השדה הזה.
הערה: הגדלת המגבלה על אורך השאילתה דורשת יותר זיכרון.
כדי להתאים אישית את קבוצות התכונות של התובנות לגבי שאילתות, משנים את האפשרויות הבאות:
דגימה של תוכנית שאילתה: מסמנים את התיבה הזו כדי להציג באופן חזותי את הפעולות שמשמשות להשלמת דגימה של שאילתה. שיעור הדגימה קובע את המספר המקסימלי של שאילתות ש-AlloyDB יכול לדגום בדקה עבור המופע לכל צומת.
בשדה שיעור הדגימה המקסימלי, מזינים מספר בין 1 ל-20. כברירת מחדל, קצב הדגימה מוגדר ל-5. כדי להשבית את הדגימה, מבטלים את הסימון בתיבת הסימון Query plan sampling.
שמירת כתובות ה-IP של הלקוחות: מסמנים את התיבה הזו כדי לדעת מאיפה מגיעות השאילתות שלכם, וכדי לקבץ את המידע הזה להפעלת מדדים.
שמירת תגי אפליקציות: מסמנים את התיבה הזו כדי לדעת אילו אפליקציות מתויגות שולחות בקשות, וכדי לקבץ את המידע הזה להפעלת מדדים. מידע נוסף על תגי אפליקציות זמין במפרט.
לוחצים על עדכון המופע.
gcloud
כדי להפעיל את התכונה 'תובנות לגבי שאילתות' במופע AlloyDB באמצעות פקודות Google Cloud CLI, מבצעים את הפעולות הבאות:
- התקינו את ה-CLI של Google Cloud.
- כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:
gcloud init
אם אתם משתמשים במעטפת מקומית, אתם צריכים ליצור פרטי כניסה מקומיים לאימות עבור חשבון המשתמש:
gcloud auth application-default login
אם אתם משתמשים ב-Cloud Shell, אין צורך לבצע את הפעולה הזו.
מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
הנה דוגמה:
gcloud alloydb instances update INSTANCE \
--cluster=CLUSTER \
--project=PROJECT \
--region=REGION \
--insights-config-query-string-length=QUERY_LENGTH \
--insights-config-query-plans-per-minute=QUERY_PLANS \
--insights-config-record-application-tags \
--insights-config-record-client-addressמחליפים את מה שכתוב בשדות הבאים:
-
INSTANCE: המזהה של המכונה שרוצים לעדכן -
CLUSTER: המזהה של האשכול של המכונה -
PROJECT: מזהה הפרויקט של האשכול -
REGION: האזור של האשכול – לדוגמה,us-central1 -
QUERY_LENGTH: אורך השאילתה, בין 256 ל-4,500 -
QUERY_PLANS: מספר תוכניות השאילתות שיוגדרו לדקה.
אפשר גם להשתמש באחד או יותר מהדגלים האופציונליים הבאים:
-
--insights-config-query-string-length: מגדיר את מגבלת אורך השאילתה שמוגדרת כברירת מחדל לערך שצוין בין 256 ל-4,500 בייטים. אורך השאילתה שמוגדר כברירת מחדל הוא 1,024 בייטים. אורך שאילתה גדול יותר שימושי יותר לשאילתות אנליטיות, אבל הוא גם דורש יותר זיכרון. כדי לשנות את אורך השאילתה, צריך להפעיל מחדש את המופע. עדיין אפשר להוסיף תגים לשאילתות שחורגות ממגבלת האורך. -
--insights-config-query-plans-per-minute: כברירת מחדל, נשמרות עד חמש דגימות של תוכניות שאילתות שהופעלו בכל דקה בכל מסדי הנתונים במופע. צריך לשנות את הערך הזה למספר בין 1 ל-20. כדי להשבית את הדגימה, מזינים 0. הגדלת קצב הדגימה כנראה תספק לכם יותר נקודות נתונים, אבל יכול להיות שתתווסף תקורה של ביצועים. -
--insights-config-record-client-address: מאחסן את כתובות ה-IP של הלקוחות שמהן מגיעות השאילתות, ועוזר לקבץ את הנתונים האלה כדי להריץ עליהם מדדים. השאילתות מגיעות מיותר ממארח אחד. בדיקת הגרפים של שאילתות מכתובות IP של לקוחות יכולה לעזור לזהות את מקור הבעיה. אם אתם לא רוצים לאחסן כתובות IP של לקוחות, צריך להשתמש ב---no-insights-config-record-client-address. -
--insights-config-record-application-tags: מאחסן תגי אפליקציה שעוזרים לכם לקבוע את ממשקי ה-API ואת המסלולים של בקר התצוגה של המודל (MVC) שמבצעים בקשות, ומקבץ את הנתונים כדי להריץ מדדים על בסיסם. כדי להשתמש באפשרות הזו, צריך להוסיף תגובות לשאילתות עם קבוצה ספציפית של תגים. אם לא רוצים לאחסן תגי אפליקציה, צריך להשתמש ב---no-insights-config-record-application-tags.
Terraform
כדי להשתמש ב-Terraform להגדרת התובנות לגבי שאילתות, משתמשים במשאב google_alloydb_instance.
הנה דוגמה:
query_insights_config {
query_string_length = QUERY_STRING_LENGTH_VALUE
record_application_tags = RECORD_APPLICATION_TAG_VALUE
record_client_address = RECORD_CLIENT_ADDRESS_VALUE
query_plans_per_minute = QUERY_PLANS_PER_MINUTE_VALUE5
}
מחליפים את מה שכתוב בשדות הבאים:
-
QUERY_STRING_LENGTH_VALUE: אורך מחרוזת השאילתה. ערך ברירת המחדל הוא1024. כל מספר שלם בין 256 ל-4,500 הוא ערך תקין. -
RECORD_APPLICATION_TAG_VALUE: הקלטת תג אפליקציה עבור מופע. ערך ברירת המחדל הואtrue. -
RECORD_CLIENT_ADDRESS_VALUE: תיעוד של כתובת הלקוח עבור מופע. ערך ברירת המחדל הואtrue.
QUERY_PLANS_PER_MINUTE_VALUE: מספר תוכניות ההפעלה של השאילתות שנאספו על ידי התובנות בכל דקה לכל השאילתות יחד. ערך ברירת המחדל הוא5. כל מספר שלם בין 0 ל-20 הוא ערך תקין.כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.
הגדרת המופע לדוגמה עם הגדרת התובנות לגבי שאילתות שנוספה אמורה להופיע כך:
resource "google_alloydb_instance" "instance_name" { provider = "google-beta" cluster = google_alloydb_cluster.default.name instance_id = "instance_id" instance_type = "PRIMARY" machine_config { cpu_count = 8 } query_insights_config { query_string_length = 1024 record_application_tags = false record_client_address = false query_plans_per_minute = 5 } depends_on = [google_alloydb_instance.default] }
REST v1
בדוגמה הזו מוגדרות הגדרות של יכולת מעקב במופע AlloyDB. רשימה מלאה של הפרמטרים של הקריאה הזו מופיעה במאמר Method: projects.locations.clusters.instances.patch.
כדי להגדיר את ההגדרות של התובנות לגבי שאילתות, משנים את השדות האופציונליים לפי הצורך. רשימה מלאה של השדות בקריאה הזו מופיעה במאמר QueryInsightsInstanceConfig.
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
-
CLUSTER_ID: המזהה של האשכול שיוצרים. הוא צריך להתחיל באות קטנה באנגלית ויכול לכלול אותיות קטנות, ספרות ומקפים. -
PROJECT_ID: מזהה הפרויקט שבו רוצים למקם את האשכול. -
LOCATION_ID: המזהה של האזור של האשכול. -
INSTANCE_ID: השם של המופע הראשי שרוצים ליצור.
כדי לשנות את הגדרות המכונה, משתמשים בבקשה הבאה PATCH:
PATCH https://alloydb.googleapis.com/v1beta/{instance.name=projects/PROJECT_ID/locations/LOCATION_ID/clusters/CLUSTER_ID/instances/INSTANCE_ID?updateMask=observabilityConfig.enabled}
תוכן בקשת JSON שקובע את ההגדרות של כל שדות הניטור נראה כך:
{
"queryStringLength": integer,
"recordApplicationTags": boolean,
"recordClientAddress": boolean,
"queryPlansPerMinute": integer
}
שיפור ביצועי השאילתות
התכונה 'תובנות לגבי שאילתות' פותרת בעיות בשאילתות של AlloyDB כדי לחפש בעיות בביצועים. במרכז הבקרה של תובנות לגבי שאילתות מוצג עומס השאילתות על סמך גורמים שאתם בוחרים. עומס השאילתות הוא מדד של העבודה הכוללת של כל השאילתות במופע בטווח הזמן שנבחר.
תובנות לגבי שאילתות עוזרות לכם לזהות ולנתח בעיות בביצועים של שאילתות. כדי לפתור בעיות בשאילתות באמצעות תובנות לגבי שאילתות, פועלים לפי השלבים הבאים:
- צפייה בעומס על מסד הנתונים לכל השאילתות.
- מזהים שאילתה או תג בעייתיים.
- בודקים את השאילתה או התג כדי לזהות בעיות.
- בדיקת מעקב שנוצר על ידי שאילתה לדוגמה
הצגת העומס על מסד הנתונים לכל השאילתות
לוח הבקרה של תובנות לגבי שאילתות ברמה העליונה מציג את הגרף עומס על מסד הנתונים – כל השאילתות המובילות באמצעות נתונים מסוננים. עומס השאילתות במסד הנתונים הוא מדד של העבודה (בשניות של מעבד) שמתבצעת על ידי השאילתות שהופעלו במסד הנתונים שנבחר לאורך זמן. כל שאילתה שמופעלת משתמשת במשאבי CPU, במשאבי קלט/פלט או במשאבי נעילה, או ממתינה להם. עומס שאילתות במסד הנתונים הוא היחס בין משך הזמן שנדרש לכל השאילתות שהושלמו בחלון זמן נתון לבין הזמן שחלף בפועל.
הקווים הצבעוניים בתרשים מציגים את עומס השאילתות, שמחולק לארבע קטגוריות:
- קיבולת המעבד: מספר המעבדים שזמינים במופע.
CPU ו-CPU Wait: היחס בין הזמן שלוקח לשאילתות במצב פעיל לבין הזמן שחלף בפועל. המתנות של קלט/פלט ונעילה לא חוסמות שאילתות שנמצאות במצב פעיל. יכול להיות שהמדד הזה מצביע על כך שהשאילתה משתמשת במעבד או ממתינה לתזמן של Linux כדי לתזמן את תהליך השרת שמריץ את השאילתה, בזמן שתהליכים אחרים משתמשים במעבד.
הערה: עומס המעבד כולל גם את זמן הריצה וגם את הזמן שבו המערכת ממתינה לתזמון של תהליך השרת שפועל על ידי מתזמן Linux. כתוצאה מכך, עומס המעבד יכול לחרוג מהקו המקסימלי של הליבה.
המתנה לקלט/פלט: היחס בין הזמן שלוקח לשאילתות שממתינות לקלט/פלט לבין הזמן שעובר בפועל. ההגדרה 'המתנה לקלט/פלט' כוללת את ההגדרה 'המתנה לקלט/פלט של קריאה' ואת ההגדרה 'המתנה לקלט/פלט של כתיבה'. אפשר לעיין בטבלת האירועים של PostgreSQL. אם רוצים לראות פירוט של המידע על זמני המתנה של קלט/פלט, אפשר לראות אותו ב-Cloud Monitoring. מידע נוסף זמין במאמר בנושא תרשימי מדדים.
זמן המתנה לנעילה: היחס בין הזמן שלוקח לשאילתות להמתין לנעילות לבין הזמן שחלף בפועל. הוא כולל Lock Waits, LwLock Waits ו-Buffer pin Lock waits. אם רוצים לראות פירוט של מידע על זמן ההמתנה לנעילה, אפשר לראות אותו ב-Cloud Monitoring. מידע נוסף זמין במאמר בנושא תרשימי מדדים.
לאחר מכן, בודקים את הגרף ומשתמשים באפשרויות הסינון כדי לענות על השאלות הבאות:
- האם עומס השאילתות גבוה? האם יש קפיצות או עלייה בגרף לאורך זמן? אם לא מופיע עומס גבוה, הבעיה לא קשורה לשאילתות.
- כמה זמן העומס גבוה? האם המחיר גבוה רק עכשיו? או שהיא גבוהה כבר הרבה זמן? משתמשים בבחירת הטווח כדי לבחור תקופות זמן שונות ולבדוק כמה זמן הבעיה נמשכת. אפשר גם להתקרב כדי לראות חלון זמן שבו נצפו עליות חדות בעומס השאילתות. אפשר להקטין את התצוגה כדי לראות ציר זמן של עד שבוע.
- מה גורם לעומס הגבוה? אפשר לבחור אפשרויות כדי לבדוק את קיבולת המעבד, את המעבד ואת זמן ההמתנה של המעבד, את זמן ההמתנה של הנעילה או את זמן ההמתנה של קלט/פלט. התרשים של כל אחת מהאפשרויות האלה מוצג בצבע אחר, כדי שתוכלו לראות לאיזו מהן יש את העומס הכי גבוה. הקו הכחול הכהה בתרשים מראה את קיבולת המעבד המקסימלית של המערכת. כך אפשר להשוות בין עומס השאילתות לבין קיבולת המערכת המקסימלית של ה-CPU. ההשוואה הזו עוזרת לכם לדעת אם לא נשארו מספיק משאבי CPU במופע.
- באיזה מסד נתונים העומס גבוה? בוחרים מסדי נתונים שונים מהתפריט הנפתח Databases כדי למצוא את מסדי הנתונים עם העומסים הכי גבוהים.
- האם משתמשים ספציפיים או כתובות IP ספציפיות גורמים לעומסים גבוהים יותר? בוחרים משתמשים וכתובות שונים מהתפריטים הנפתחים כדי להשוות בין העומסים הגבוהים יותר.
סינון הטעינה של מסד הנתונים
בקטעים Queries and tags (שאילתות ותגים) אפשר לסנן או למיין את עומס השאילתות לפי שאילתה נבחרת או תג שאילתת SQL.
סינון לפי שאילתות
בטבלה QUERIES מוצגת סקירה כללית של השאילתות שגורמות לעומס הגדול ביותר של שאילתות. בטבלה מוצגות כל השאילתות שעברו נרמול לפי חלון הזמן והאפשרויות שנבחרו במרכז הבקרה של תובנות לגבי שאילתות.
כברירת מחדל, השאילתות בטבלה ממוינות לפי זמן הביצוע הכולל בחלון הזמן שבחרתם.
כדי לסנן את הטבלה, בוחרים מאפיין מתוך Filter queries. כדי למיין את הטבלה, בוחרים כותרת של עמודה. בטבלה מוצגים המאפיינים הבאים:
מחרוזת שאילתה. מחרוזת השאילתה שעברה נורמליזציה. כברירת מחדל, בתובנות לגבי שאילתות מוצגים רק 1,024 תווים במחרוזת השאילתה.
שאילתות עם התווית
UTILITY COMMANDכוללות בדרך כלל פקודותBEGIN,COMMITו-EXPLAINאו פקודות wrapper.מסד נתונים. מסד הנתונים שהשאילתה הופעלה מולו.
עומס לפי זמן כולל / עומס לפי CPU / עומס לפי זמן המתנה של קלט/פלט / עומס לפי זמן המתנה של נעילה. האפשרויות האלה מאפשרות לסנן שאילתות ספציפיות כדי למצוא את העומס הגדול ביותר לכל אפשרות.
זמן הביצוע הממוצע (אלפיות השנייה). הזמן הכולל שלוקח לכל משימות המשנה בכל העובדים המקבילים להשלים את השאילתה. מידע נוסף זמין במאמר בנושא זמן ביצוע ממוצע ומשך זמן.
מספר הפעמים שהתקשרו. מספר הפעמים שהאפליקציה קראה את השאילתה.
מספר השורות הממוצע שאוחזרו. המספר הממוצע של שורות שאוחזרו עבור השאילתה.
בתובנות לגבי שאילתות מוצגות שאילתות מנורמלות, כלומר, הערכים הקבועים המילוליים מוחלפים ב-$1, $2 וכן הלאה. לדוגמה:
UPDATE
"demo_customer"
SET
"customer_id" = $1::uuid,
"name" = $2,
"address" = $3,
"rating" = $4,
"balance" = $5,
"current_city" = $6,
"current_location" = $7
WHERE
"demo_customer"."id" = $8
הערך של הקבוע מוזנח כדי שניתן יהיה לצבור תובנות לגבי שאילתות דומות ולהסיר פרטים אישיים מזהים (PII) שהקבוע עשוי להציג.
סינון לפי תגי שאילתות
כדי לפתור בעיות באפליקציה, קודם צריך להוסיף תגים לשאילתות SQL.
התובנות לגבי שאילתות מספקות מעקב ממוקד באפליקציה כדי לאבחן בעיות בביצועים של אפליקציות שנבנו באמצעות ORM.
אם אתם אחראים לכל מחסנית האפליקציות, התכונה 'תובנות לגבי שאילתות' מספקת מעקב אחרי שאילתות מתצוגת אפליקציה. תיוג שאילתות עוזר לכם למצוא בעיות במבנים ברמה גבוהה יותר, כמו שימוש בלוגיקה עסקית, במיקרו-שירות או במבנה אחר. אפשר לתייג שאילתות לפי הלוגיקה העסקית, למשל, באמצעות התגים payment, inventory, business analytics או shipping. אחר כך תוכלו לראות את עומס השאילתות שנוצר על ידי הסוגים השונים של הלוגיקה העסקית. לדוגמה, יכול להיות שתראו אירועים לא צפויים, כמו עליות חדות בתג של ניתוח נתוני עסק בשעה 13:00. או שתוכלו לראות צמיחה לא צפויה בשירות תשלומים בהשוואה לשבוע הקודם.
תגים של עומס שאילתות מספקים פירוט של עומס השאילתות של התג שנבחר לאורך זמן.
כדי לחשב את עומס מסד הנתונים של התג, התובנות לגבי השאילתות מתבססות על משך הזמן של כל שאילתה שמשתמשת בתג שבחרתם. התובנות לגבי שאילתות מחשבות את זמן ההשלמה בגבול הדקה באמצעות זמן שעון אמיתי.
בלוח הבקרה של תובנות לגבי שאילתות, בוחרים באפשרות תגים כדי להציג את טבלת התגים. בטבלה TAGS התגים ממוינים לפי העומס הכולל שלהם לפי הזמן הכולל.
כדי למיין את הטבלה, בוחרים נכס מתוך Filter queries או לוחצים על כותרת של עמודה. בטבלה מוצגים המאפיינים הבאים:
- Action, Controller, Framework, Route, Application, DB Driver. כל נכס שהוספתם לשאילתות מוצג כעמודה. אם רוצים לסנן לפי תגים, צריך להוסיף לפחות אחד מהמאפיינים האלה.
- עומס לפי זמן כולל / עומס לפי CPU / עומס לפי זמן המתנה של קלט/פלט / עומס לפי זמן המתנה של נעילה. האפשרויות האלה מאפשרות לסנן שאילתות ספציפיות כדי למצוא את העומס הגדול ביותר לכל אפשרות.
- זמן הביצוע הממוצע (אלפיות השנייה). הזמן הכולל שלוקח לכל משימות המשנה בכל העובדים המקבילים להשלים את השאילתה. מידע נוסף זמין במאמר בנושא זמן ביצוע ממוצע ומשך זמן.
- מספר הפעמים שהתקשרו. מספר הפעמים שהאפליקציה קראה את השאילתה.
- מספר השורות הממוצע שאוחזרו. המספר הממוצע של שורות שאוחזרו עבור השאילתה.
- מסד נתונים. מסד הנתונים שהשאילתה הופעלה מולו.
בדיקת שאילתה או תג ספציפיים
כדי לבדוק אם שאילתה או תג הם שורש הבעיה, מבצעים את הפעולות הבאות בכרטיסייה Queries או בכרטיסייה Tags, בהתאם:
- לוחצים על הכותרת טעינה לפי זמן כולל כדי למיין את הרשימה בסדר יורד.
- לוחצים על השאילתה או על התג שנראה שיש לו את העומס הכי גבוה ושזמן הביצוע שלו ארוך יותר משל האחרים.
ייפתח לוח בקרה עם הפרטים של השאילתה או התג שנבחרו.
אם בחרתם שאילתה, מוצג סיכום של השאילתה שנבחרה:
אם בחרתם תג, יוצג לכם סיכום של התג שנבחר.
בדיקת העומס של שאילתה או תג ספציפיים
בתרשים עומס על מסד הנתונים – שאילתה ספציפית מוצג מדד של העבודה (בשניות CPU) שהשאילתה הנורמלית שבחרתם ביצעה בשאילתה שבחרתם לאורך זמן. כדי לחשב את העומס, המערכת משתמשת בכמות הזמן שלוקח לשאילתות המנורמלות שמושלמות בגבול הדקה עד לזמן השעון. בחלק העליון של הטבלה מוצגים 1, 024 התווים הראשונים של השאילתה הנורמלית (שבה מוסרים ערכים מילוליים לצורך צבירה ומסיבות שקשורות לפרטים אישיים מזהים). בדומה לתרשים של סך כל השאילתות, אפשר לסנן את העומס של שאילתה ספציפית לפי מסד נתונים, משתמש וכתובת לקוח. עומס השאילתות מחולק ל-CPU capacity, CPU and CPU Wait, IO Wait ו-Lock Wait.
בתרשים Database load — specific tags (עומס על מסד הנתונים – תגים ספציפיים) מוצגת מדידה של העבודה (בשניות CPU) שבוצעה במסד הנתונים שנבחר על ידי שאילתות שתואמות לתגים שנבחרו, לאורך זמן. בדומה לתרשים של סך השאילתות, אפשר לסנן את העומס של תג ספציפי לפי מסד נתונים, משתמש וכתובת לקוח.
בדיקת זמן האחזור
משתמשים בתרשים השהיה כדי לבדוק את ההשהיה בשאילתה או בתג. זמן האחזור הוא משך הזמן שנדרש להשלמת השאילתה המנורמלת, לפי שעון קיר. בלוח הבקרה של זמן האחזור מוצגים נתוני זמן האחזור באחוזונים ה-50, ה-95 וה-99, כדי לזהות התנהגויות חריגות.
החביון של שאילתות מקבילות נמדד בזמן שעובר בפועל, למרות שעומס השאילתה יכול להיות גבוה יותר כי נעשה שימוש בכמה ליבות כדי להריץ חלק מהשאילתה.
כדי לצמצם את הבעיה, כדאי לבדוק את הדברים הבאים:
- מה גורם לעומס הגבוה? בוחרים אפשרויות כדי לבדוק את קיבולת המעבד, המעבד וההמתנה של המעבד, ההמתנה של הנעילה או ההמתנה של קלט/פלט.
- כמה זמן העומס גבוה? האם המחיר גבוה רק עכשיו? או שהיא גבוהה כבר הרבה זמן? משנים את טווחי הזמן כדי למצוא את התאריך והשעה שבהם הביצועים של העומס התחילו להיות נמוכים.
- האם היו עליות פתאומיות בזמן האחזור? אפשר לשנות את חלון הזמן כדי לבדוק את זמן האחזור ההיסטורי של השאילתה הנורמלית.
אחרי שמאתרים את האזורים והשעות שבהם העומס הכי גבוה, אפשר להמשיך ולהתעמק בנתונים.
בדיקת זמן האחזור באשכול
אפשר להשתמש בתרשים P99 latency on the same query across the cluster כדי לבדוק את חביון P99 בשאילתה או בתג בכל המופעים באשכול.
בדיקת פעולות בתוכנית שאילתה שנדגמה
תוכנית שאילתה לוקחת דגימה של השאילתה ומפרקת אותה לפעולות נפרדות. הוא מסביר ומנתח כל פעולה בשאילתה. בתרשים Query plan samples מוצגות כל תוכניות השאילתות שפועלות בזמנים מסוימים, ומשך הזמן שלקח לכל תוכנית לפעול.
כדי לראות את הפרטים של תוכנית השאילתה לדוגמה, לוחצים על הנקודות בגרף Sample query plans. ברוב השאילתות, אבל לא בכולן, יש תצוגה של תוכניות שאילתות לדוגמה שהופעלו. חשוב לדעת ש-AlloyDB ל-PostgreSQL דוגם שאילתות באופן אוטומטי. ככל ששאילתה מופעלת יותר פעמים, כך גדל הסיכוי שהיא תידגם. אם אתם צריכים לראות עוד תוכניות לדוגמה של שאילתות, אתם יכולים לפעול לפי ההוראות שבקטע עריכת ההגדרה של התובנות לגבי שאילתות כדי להגדיל את שיעור הדגימה המקסימלי.
כשמציגים את הפרטים המורחבים של תוכנית שאילתה, רואים מודל של כל הפעולות בתוכנית הזו. בכל פעולה מוצגים זמן האחזור, השורות שהוחזרו והעלות של הפעולה. כשבוחרים פעולה, אפשר לראות פרטים נוספים, כמו בלוקים של היטים משותפים, סוג הסכימה, הלולאות בפועל, שורות התוכנית ועוד.
כדי לצמצם את הבעיה, כדאי לעיין בשאלות הבאות:
- מהי צריכת המשאבים?
- איך היא קשורה לשאילתות אחרות?
- האם הרגלי הצפייה משתנים לאורך זמן?
בדיקת מעקב שנוצר על ידי שאילתה לדוגמה
בנוסף לצפייה בתוכנית השאילתה לדוגמה, אפשר להשתמש בתובנות לגבי שאילתות כדי להציג מעקב של אפליקציה מקצה לקצה בהקשר של שאילתה לדוגמה. המעקב הזה יכול לעזור לכם לזהות את המקור של שאילתה בעייתית, כי הוא מציג את הפעילות במסד הנתונים עבור בקשה ספציפית. בנוסף, רשומות ביומן שהאפליקציה שולחת אל Cloud Logging במהלך הבקשה מקושרות למעקב, מה שעוזר לכם בחקירה.
כדי לראות את המעקב בהקשר:
בחלונית Sample Query (שאילתה לדוגמה), לוחצים על הכרטיסייה End-to-end Trace (מעקב מקצה לקצה). בכרטיסייה הזו מוצג תרשים גאנט שמפרט את טווחי הזמן, שהם רשומות של פעולות ספציפיות, של העקבות שנוצרו על ידי השאילתה.
כדי לראות פרטים נוספים על כל span, כמו מאפיינים ומטא-נתונים, לוחצים על ה-span.
אפשר לראות את העקבות גם בדף Trace Explorer. כדי לעשות את זה, לוחצים על הצגה ב-Cloud Trace. לפרטים על השימוש בדף Trace Explorer כדי לנתח את נתוני העקבות, אפשר לעיין במאמר חיפוש עקבות וניתוח שלהם.
הוספת תגים לשאילתות SQL
תיוג של שאילתות SQL מפשט את תהליך פתרון הבעיות באפליקציה. אפשר להשתמש ב-sqlcommenter כדי להוסיף תגים לשאילתות SQL באופן אוטומטי באמצעות מיפוי יחסי בין אובייקטים (ORM), או באופן ידני.
שימוש ב-sqlcommenter עם ORM
כשמשתמשים ב-ORM במקום לכתוב ישירות שאילתות SQL, יכול להיות שלא תמצאו קוד אפליקציה שגורם לבעיות בביצועים. יכול להיות שגם תתקשו לנתח את ההשפעה של קוד האפליקציה על ביצועי השאילתות. כדי לפתור את הבעיה הזו, התובנות לגבי שאילתות מספקות ספריית קוד פתוח בשם sqlcommenter, שהיא ספריית אינסטרומנטציה של ORM. הספרייה הזו שימושית למפתחים שמשתמשים ב-ORM ולאדמינים כדי לזהות איזה קוד אפליקציה גורם לבעיות בביצועים.
אם אתם משתמשים ב-ORM וב-sqlcommenter ביחד, התגים נוצרים אוטומטית בלי שתצטרכו לשנות או להוסיף קוד מותאם אישית לאפליקציה.
אפשר להתקין את sqlcommenter בשרת האפליקציות. ספריית האינסטרומנטציה מאפשרת להעביר מידע על האפליקציה שקשור למסגרת ה-MVC שלכם למסד הנתונים יחד עם השאילתות כהערת SQL. מסד הנתונים מזהה את התגים האלה ומתחיל לתעד ולצבור נתונים סטטיסטיים לפי תגים, שהם אורתוגונליים לנתונים סטטיסטיים שמצטברים לפי שאילתות מנורמלות. התובנות לגבי השאילתות מציגות את התגים כדי שתדעו איזו אפליקציה גורמת לעומס השאילתות. המידע הזה עוזר לכם לזהות איזה קוד אפליקציה גורם לבעיות בביצועים.
כשבודקים את התוצאות ביומני מסד הנתונים של SQL, הן מופיעות כך:
SELECT * from USERS /*action='run+this',
controller='foo%3',
traceparent='00-01',
tracestate='rojo%2'*/
התגים הנתמכים כוללים את שם הבקר, המסלול, המסגרת והפעולה.
קבוצת ה-ORM ב-sqlcommenter נתמכת בשפות תכנות שונות:
| Python |
|
| Java |
|
| Ruby |
|
| Node.js |
|
מידע נוסף על sqlcommenter ועל אופן השימוש בו במסגרת ORM זמין במאמרי העזרה של sqlcommenter ב-GitHub.
שימוש ב-sqlcommenter כדי להוסיף תגים באופן ידני
אם אתם לא משתמשים ב-ORM, אתם צריכים להוסיף תגי sqlcommenter באופן ידני לשאילתות ה-SQL. בשביל כל הצהרת SQL בשאילתה, צריך להוסיף הערה שמכילה צמד מפתח/ערך שעבר סריאליזציה. משתמשים לפחות באחד מהמקשים הבאים:
action=''controller=''framework=''route=''application=''db driver=''
תובנות לגבי שאילתות משמיטות את כל המפתחות האחרים. במאמרי העזרה בנושא sqlcommenter מוסבר מהו הפורמט הנכון של הערות SQL.
זמן ומשך הביצוע
התובנות לגבי שאילתות כוללות את המדד זמן ביצוע ממוצע (אלפיות השנייה), שמציג את הזמן הכולל שנדרש לכל משימות המשנה בכל העובדים המקבילים כדי להשלים את השאילתה. המדד הזה יכול לעזור לכם לבצע אופטימיזציה של השימוש המצטבר במשאבים של מסדי נתונים. לשם כך, צריך לאתר ולבצע אופטימיזציה של שאילתות שיוצרות את התקורה הכי גבוהה של המעבד.
כדי לראות את הזמן שחלף, אפשר למדוד את משך הזמן של שאילתה על ידי הפעלת הפקודה \timing בלקוח psql. המדד הזה מודד את הזמן שחולף בין קבלת השאילתה לבין שליחת התגובה משרת PostgreSQL. המדד הזה יכול לעזור לכם להבין למה שאילתה מסוימת נמשכת יותר מדי זמן, ולהחליט אם כדאי לבצע אופטימיזציה כדי שהיא תפעל מהר יותר.
אם שאילתה מסוימת מושלמת על ידי משימה אחת עם שרשור יחיד, משך הזמן וזמן הביצוע הממוצע לא משתנים.
הפעלת תכונות מתקדמות של תובנות לגבי שאילתות ב-AlloyDB
התכונות המתקדמות של מרכז הבקרה של AlloyDB לניתוח שאילתות משולבות במרכז הבקרה הרגיל לניתוח שאילתות. מידע נוסף על הפעלת התכונות המתקדמות של תובנות לגבי שאילתות זמין במאמר שיפור הביצועים של שאילתות באמצעות התכונות המתקדמות של תובנות לגבי שאילתות.
המאמרים הבאים
- סקירה כללית של תובנות לגבי שאילתות
- שיפור ביצועי השאילתות באמצעות תכונות מתקדמות של תובנות לגבי שאילתות ב-AlloyDB
- מדדי AlloyDB
- בלוג SQL Commenter: הכירו את Sqlcommenter: ספריית קוד פתוח לתיעוד אוטומטי של ORM
- בלוג הדרכה: הפעלת תיוג שאילתות באמצעות Sqlcommenter