שיפור ביצועי השאילתות באמצעות תובנות לגבי שאילתות

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

אתם יכולים להשתמש ב-Gemini Cloud Assist כדי לעקוב אחרי משאבי AlloyDB ולפתור בעיות שקשורות אליהם. מידע נוסף זמין במאמר בנושא מעקב ופתרון בעיות בעזרת Gemini.

לפני שמתחילים

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

לתפקיד בהתאמה אישית צריכה להיות הרשאת ה-IAM הבאה: cloudtrace.traces.get.

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

כדי לפתוח את מרכז הבקרה של תובנות לגבי שאילתות:

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

בדף הבא, אפשר להשתמש באפשרויות הבאות כדי לסנן את התוצאות:

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

עריכת ההגדרות של תובנות לגבי שאילתות

התובנות לגבי שאילתות מופעלות כברירת מחדל במופעי AlloyDB. אפשר לערוך את הגדרות ברירת המחדל של תובנות לגבי שאילתות.

כדי לערוך את ההגדרה של תובנות לגבי שאילתות במופע AlloyDB, פועלים לפי השלבים הבאים:

המסוף

  1. נכנסים לדף Clusters במסוף Google Cloud .

    מעבר אל Clusters

  2. לוחצים על אשכול בעמודה Resource Name (שם המשאב).

  3. בחלונית הניווט הימנית, לוחצים על תובנות לגבי שאילתות.

  4. בוחרים באפשרות Primary או Read pool מהרשימה Query insights ולוחצים על Edit.

  5. עורכים את השדות תובנות לגבי שאילתות:

    1. כדי לשנות את מגבלת ברירת המחדל של 1,024 בייט על אורכי שאילתות לניתוח ב-AlloyDB, בשדה Query lengths (אורכי שאילתות), מזינים מספר בין 256 ל-4,500.

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

      הערה: הגדלת המגבלות על אורך השאילתה דורשת יותר זיכרון.

    2. כדי להתאים אישית את קבוצות התכונות של התובנות לגבי שאילתות, משנים את האפשרויות הבאות:

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

        בשדה שיעור הדגימה המקסימלי, מזינים מספר מ-1 עד 20. כברירת מחדל, קצב הדגימה מוגדר ל-5. כדי להשבית את הדגימה, מבטלים את הסימון בתיבת הסימון Query plan sampling.

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

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

  6. לוחצים על עדכון המופע.

gcloud

כדי להפעיל את התכונה 'תובנות לגבי שאילתות' במכונת AlloyDB באמצעות פקודות Google Cloud CLI, מבצעים את הפעולות הבאות:

  1. התקינו את ה-CLI של Google Cloud.
  2. כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה: 
    gcloud init

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

    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 and CPU Wait: היחס בין הזמן שלוקח לשאילתות במצב פעיל לבין הזמן שחלף בפועל. המתנות של קלט/פלט ונעילה לא חוסמות שאילתות שנמצאות במצב פעיל. יכול להיות שהמדד הזה מצביע על כך שהשאילתה משתמשת במעבד (CPU) או ממתינה לתזמן של Linux כדי לתזמן את תהליך השרת שמריץ את השאילתה, בזמן שתהליכים אחרים משתמשים במעבד.

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

  • IO Wait: היחס בין הזמן שלוקח לשאילתות שממתינות ל-IO לבין הזמן שחלף בפועל. ההגדרה 'המתנה לקלט/פלט' כוללת את ההגדרה 'המתנה לקלט/פלט של קריאה' ואת ההגדרה 'המתנה לקלט/פלט של כתיבה'. אפשר לעיין בטבלת האירועים של PostgreSQL. אם רוצים לראות פירוט של המידע על זמני ההמתנה של קלט/פלט, אפשר לראות אותו ב-Cloud Monitoring. מידע נוסף מופיע במאמר בנושא תרשימי מדדים.

  • המתנה לנעילה: היחס בין הזמן שלוקח לשאילתות להמתין לנעילות לבין הזמן שחלף בפועל. הוא כולל את ההמתנות הבאות: Lock Waits,‏ LwLock Waits ו-Buffer pin Lock waits. אם רוצים לראות פירוט של מידע לגבי המתנות לנעילה, אפשר לראות אותו ב-Cloud Monitoring. מידע נוסף מופיע במאמר בנושא תרשימי מדדים.

לאחר מכן, בודקים את הגרף ומשתמשים באפשרויות הסינון כדי לענות על השאלות הבאות:

  1. האם עומס השאילתות גבוה? האם יש קפיצות או עלייה בגרף לאורך זמן? אם לא מופיע עומס גבוה, הבעיה לא קשורה לשאילתות.
  2. כמה זמן העומס גבוה? האם הוא גבוה רק עכשיו? או שהיא גבוהה כבר הרבה זמן? אפשר להשתמש בבחירת הטווח כדי לבחור תקופות זמן שונות ולבדוק כמה זמן הבעיה נמשכת. אפשר גם להגדיל את התצוגה כדי לראות חלון זמן שבו נצפו עליות חדות בעומס השאילתות. אפשר להקטין את התצוגה כדי לראות ציר זמן של עד שבוע.
  3. מה גורם לעומס הגבוה? אתם יכולים לבחור אפשרויות כדי לראות את קיבולת המעבד, את המעבד ואת זמן ההמתנה של המעבד, את זמן ההמתנה של הנעילה או את זמן ההמתנה של קלט/פלט. התרשים של כל אחת מהאפשרויות האלה מוצג בצבע אחר, כדי שתוכלו לראות לאיזו מהן יש את העומס הכי גבוה. הקו הכחול הכהה בתרשים מראה את קיבולת המעבד המקסימלית של המערכת. כך אפשר להשוות בין עומס השאילתות לבין קיבולת המערכת המקסימלית של ה-CPU. ההשוואה הזו עוזרת לכם לדעת אם נגמרים המשאבים של המעבד במופע.
  4. באיזה מסד נתונים העומס גבוה? כדי למצוא את מסדי הנתונים עם העומסים הכי גבוהים, בוחרים מסדי נתונים שונים מהתפריט הנפתח Databases (מסדי נתונים).
  5. האם משתמשים ספציפיים או כתובות IP ספציפיות גורמים לעומסים גבוהים יותר? בוחרים משתמשים וכתובות שונים מהתפריטים הנפתחים כדי להשוות בין העומסים הגבוהים יותר.

סינון של טעינת מסד הנתונים

בקטעים Queries and tags (שאילתות ותגים) אפשר לסנן או למיין את עומס השאילתות לפי שאילתה נבחרת או תג שאילתת SQL.

סינון לפי שאילתות

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

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

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

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

  • מחרוזת שאילתה. מחרוזת השאילתה שעברה נורמליזציה. כברירת מחדל, בתובנות לגבי שאילתות מוצגים רק 1,024 תווים במחרוזת השאילתה.

    שאילתות עם התווית UTILITY COMMAND כוללות בדרך כלל פקודות BEGIN, COMMIT ו-EXPLAIN או פקודות wrapper.

  • מסד נתונים. מסד הנתונים שהשאילתה הופעלה מולו.

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

  • זמן הביצוע הממוצע (באלפיות השנייה). הזמן הכולל שנדרש לכל משימות המשנה בכל העובדים המקבילים כדי להשלים את השאילתה. מידע נוסף זמין במאמר בנושא זמן ביצוע ממוצע ומשך זמן.

  • מספר הפעמים שהתקשרתם. מספר הפעמים שהשאילתה נקראה על ידי האפליקציה.

  • מספר השורות הממוצע שאוחזרו. המספר הממוצע של שורות שאוחזרו עבור השאילתה.

בתובנות לגבי שאילתות מוצגות שאילתות מנורמלות, כלומר, הערכים הקבועים המילוליים מוחלפים ב-$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 התגים ממוינים לפי העומס הכולל שלהם לפי הזמן הכולל.

איור 5 מציג את לוח הבקרה של תובנות לגבי שאילתות, עם נתונים לגבי טעינה של תגים. מתחת לתרשים מופיעה רשימה של תגים.

כדי למיין את הטבלה, בוחרים מאפיין מתוך Filter queries או לוחצים על כותרת של עמודה. הטבלה מציגה את המאפיינים הבאים:

  • Action, Controller, Framework, Route, Application, DB Driver. כל נכס שהוספתם לשאילתות מוצג כעמודה. כדי לסנן לפי תגים, צריך להוסיף לפחות אחד מהמאפיינים האלה.
  • טעינה לפי זמן כולל / טעינה לפי מעבד / טעינה לפי המתנה של קלט/פלט / טעינה לפי המתנה של נעילה. האפשרויות האלה מאפשרות לסנן שאילתות ספציפיות כדי למצוא את העומס הגדול ביותר לכל אפשרות.
  • זמן הביצוע הממוצע (באלפיות השנייה). הזמן הכולל שנדרש לכל משימות המשנה בכל העובדים המקבילים כדי להשלים את השאילתה. מידע נוסף זמין במאמר בנושא זמן ביצוע ממוצע ומשך זמן.
  • מספר הפעמים שהתקשרתם. מספר הפעמים שהשאילתה נקראה על ידי האפליקציה.
  • מספר השורות הממוצע שאוחזרו. המספר הממוצע של שורות שאוחזרו עבור השאילתה.
  • מסד נתונים. מסד הנתונים שהשאילתה הופעלה מולו.

בדיקת שאילתה או תג ספציפיים

כדי לקבוע אם שאילתה או תג הם שורש הבעיה, מבצעים את הפעולות הבאות בכרטיסייה Queries או בכרטיסייה Tags, בהתאם:

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

ייפתח לוח בקרה עם הפרטים של השאילתה או התג שנבחרו.

אם בחרתם שאילתה, מוצגת סקירה כללית של השאילתה שנבחרה:

מוצגת גרסה קטומה של השאילתה שנבחרה.

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

בדיקת העומס של שאילתה או תג ספציפיים

בתרשים Database load — specific query (עומס על מסד הנתונים – שאילתה ספציפית) מוצג מדד של העבודה (בשניות CPU) שהשאילתה הנורמלית שבחרתם ביצעה בשאילתה שבחרתם לאורך זמן. כדי לחשב את העומס, המערכת משתמשת בכמות הזמן שלוקח לשאילתות המנורמלות שהושלמו בגבול הדקה עד לשעה המקומית. בחלק העליון של הטבלה מוצגים 1, 024 התווים הראשונים של השאילתה הנורמלית (שבה הוסרו מילוליים לצורך צבירה ומסיבות שקשורות לפרטים אישיים מזהים). בדומה לתרשים של סך כל השאילתות, אפשר לסנן את העומס של שאילתה ספציפית לפי מסד נתונים, משתמש וכתובת לקוח. עומס השאילתות מחולק ל-CPU capacity,‏ CPU and CPU Wait,‏ IO Wait ו-Lock Wait.

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

בתרשים Database load — specific tags מוצגת מדידה של העבודה (בשניות CPU) שבוצעה במסד הנתונים שנבחר על ידי שאילתות שתואמות לתגים שנבחרו, לאורך זמן. בדומה לתרשים של סך השאילתות, אפשר לסנן את העומס של תג ספציפי לפי מסד נתונים, משתמש וכתובת לקוח.

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

בדיקת זמן האחזור

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

תרשים חביון השאילתה עבור שאילתה ספציפית עם מסננים שנבחרו לקיבולת CPU, ל-CPU ולזמן המתנה של CPU, לזמן המתנה של קלט/פלט ולזמן המתנה של נעילה.

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

כדי לצמצם את הבעיה, כדאי לבדוק את הדברים הבאים:

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

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

בדיקת זמן האחזור באשכול

אתם יכולים להשתמש בתרשים P99 latency on the same query across the cluster כדי לבדוק את חביון P99 בשאילתה או בתג בכל המופעים באשכול.

תרשים חביון השאילתה עבור שאילתה ספציפית עם מסננים שנבחרו לקיבולת CPU, ל-CPU ולזמן המתנה של CPU, לזמן המתנה של קלט/פלט ולזמן המתנה של נעילה.

בדיקת פעולות בתוכנית לביצוע שאילתה שנדגמה

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

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

כדי לראות את הפרטים של תוכנית לביצוע שאילתה לדוגמה, לוחצים על הנקודות בגרף Sample query plans. ברוב השאילתות, אבל לא בכולן, יש תצוגה של תוכניות שאילתות לדוגמה שהופעלו. שימו לב: מערכת AlloyDB ל-PostgreSQL דוגמת שאילתות באופן אוטומטי. ככל שמריצים שאילתה יותר פעמים, כך גדל הסיכוי שהמערכת תבצע דגימה. אם אתם צריכים לראות עוד תוכניות לדוגמה של שאילתות, אתם יכולים לפעול לפי ההוראות שבקטע עריכת ההגדרה של תובנות לגבי שאילתות כדי להגדיל את קצב הדגימה המקסימלי.

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

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

כדי לצמצם את הבעיה, כדאי לעיין בשאלות הבאות:

  1. מהי צריכת המשאבים?
  2. איך זה קשור לשאילתות אחרות?
  3. האם הרגלי הצפייה משתנים לאורך זמן?

בדיקת מעקב שנוצר על ידי שאילתה לדוגמה

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

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

  1. בחלונית Sample Query (שאילתת לדוגמה), לוחצים על הכרטיסייה End-to-end Trace (מעקב מקצה לקצה). בכרטיסייה הזו מוצג תרשים גאנט עם פרטים על טווחי הזמן, שהם רשומות של פעולות בודדות, של העקבות שנוצרו על ידי השאילתה.

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

אפשר לראות את העקבות גם בדף 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
  • Django
  • psycopg2
  • Sqlalchemy
  • בקבוקון לשתייה חריפה
Java
  • מצב תנומה
  • Spring
Ruby
  • Rails
Node.js
  • Knex.js
  • Sequelize.js
  • Express.js

מידע נוסף על sqlcommenter ועל אופן השימוש בו במסגרת ORM זמין במאמרי העזרה של sqlcommenter ב-GitHub.

שימוש ב-sqlcommenter כדי להוסיף תגים באופן ידני

אם אתם לא משתמשים ב-ORM, אתם צריכים להוסיף תגי sqlcommenter באופן ידני לשאילתות ה-SQL. בשילוב עם השאילתה, צריך להוסיף לכל הצהרת SQL הערה שמכילה צמד מפתח/ערך שעבר סריאליזציה. צריך להשתמש לפחות באחד מהמקשים הבאים:

  • action=''
  • controller=''
  • framework=''
  • route=''
  • application=''
  • db driver=''

התובנות לגבי שאילתות משמיטות את כל שאר המפתחות. במאמרי העזרה בנושא sqlcommenter מוסבר מהו פורמט התגובה הנכון ב-SQL.

זמן ומשך הביצוע

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

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

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

הפעלת תכונות מתקדמות של תובנות לגבי שאילתות ב-AlloyDB

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

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