נתונים סטטיסטיים של עסקאות

במאמר הזה מתוארים הנתונים הסטטיסטיים של העסקאות ש-Spanner מציע כטבלאות מובנות. אפשר לאחזר נתונים סטטיסטיים מהטבלאות האלה של SPANNER_SYS.TXN_STATS* באמצעות הצהרות SQL.

מתי כדאי להשתמש בנתונים סטטיסטיים של עסקאות

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

איך ניגשים לנתונים הסטטיסטיים של העסקאות

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

ה-methods הבאות לקריאה יחידה ש-Spanner מספק לא תומכות ב-SPANNER_SYS:

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

נתונים סטטיסטיים של זמן אחזור מקובצים לפי טרנזקציה

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

  • ‫SPANNER_SYS.TXN_STATS_TOP_MINUTE: נתונים סטטיסטיים של טרנזקציות שנצברו במרווחים של דקה אחת.

  • ‫SPANNER_SYS.TXN_STATS_TOP_10MINUTE: נתונים סטטיסטיים מצטברים של טרנזקציות במרווחים של 10 דקות.

  • ‫SPANNER_SYS.TXN_STATS_TOP_HOUR: נתונים סטטיסטיים של טרנזקציות שנצברו במרווחים של שעה.

אלה המאפיינים של הטבלאות האלה:

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

  • המרווחים מבוססים על זמני השעון

    • מרווחים של דקה מסתיימים בדקה.
    • מרווחים של 10 דקות מסתיימים כל 10 דקות, החל מהשעה העגולה.
    • מרווחים של שעה מסתיימים בשעה עגולה.

    לדוגמה, בשעה 11:59:30, המרווחים האחרונים שזמינים לשאילתות SQL הם:

    • דקה אחת: 11:58:00 עד 11:58:59
    • 10 דקות: 11:40:00 עד 11:49:59
    • שעה אחת: 10:00:00 עד 10:59:59

  • ‫Spanner מקבץ את הנתונים הסטטיסטיים לפי FPRINT (טביעת אצבע) של העסקאות. אם יש תג עסקה, הערך של FPRINT הוא ה-hash של התג. אחרת, זהו הגיבוב שמחושב על סמך הפעולות שבוצעו בעסקה.

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

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

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

  • כל העמודות בטבלאות יכולות להכיל ערכי null.

סכמת טבלאות

שם העמודה סוג תיאור
INTERVAL_END TIMESTAMP סוף מרווח הזמן שבו התרחשו ביצועי העסקאות הכלולים.
TRANSACTION_TAG STRING תג העסקה האופציונלי לפעולת העסקה הזו. מידע נוסף על השימוש בתגים זמין במאמר פתרון בעיות באמצעות תגי טרנזקציות. הנתונים הסטטיסטיים של כמה עסקאות עם אותה מחרוזת תג מקובצים בשורה אחת, שבה הערך של TRANSACTION_TAG תואם למחרוזת התג הזו.
FPRINT INT64 הגיבוב של TRANSACTION_TAG אם הוא קיים. אחרת, הגיבוב מחושב על סמך הפעולות שמעורבות בעסקה. השדות INTERVAL_END ו-FPRINT משמשים יחד כמפתח ייחודי לטבלאות האלה.
READ_COLUMNS ARRAY<STRING> קבוצת העמודות שנקראו על ידי הטרנזקציה.
WRITE_CONSTRUCTIVE_COLUMNS ARRAY<STRING> קבוצת העמודות שנכתבו באופן קונסטרוקטיבי, כלומר שהוקצו להן ערכים חדשים, על ידי הטרנזקציה.

בסנכרון שינויים בזרמי נתונים, אם העסקה כללה כתיבה לעמודות ולטבלאות שסנכרון השינויים בזרמי הנתונים עוקב אחריהן, WRITE_CONSTRUCTIVE_COLUMNS מכיל שתי עמודות – .data ו-._exists, עם קידומת של שם סנכרון השינויים בזרמי הנתונים. ‫_exists הוא שדה שמשמש לבדיקה אם שורה מסוימת קיימת או לא.
WRITE_DELETE_TABLES ARRAY<STRING> קבוצת הטבלאות שהטרנזקציה מחקה או החליפה את השורות שלהן.
ATTEMPT_COUNT INT64 מספר הניסיונות הכולל לביצוע טרנזקציות, כולל ניסיונות שבוטלו לפני הקריאה ל-method‏ commit. המספר הזה מייצג את סך כל הניסיונות במהלך המרווח שצוין. מידע נוסף על מרווחים זמין במאמר מרווחים.
COMMIT_ATTEMPT_COUNT INT64 מספר הניסיונות הכולל לביצוע טרנזקציות. המספר הזה צריך להיות זהה למספר הקריאות ל-method‏ commit של העסקה. המספר הזה מייצג את המספר הכולל של ניסיונות השמירה במהלך המרווח שצוין. למידע נוסף על מרווחים, ראו מרווחים.
COMMIT_ABORT_COUNT INT64 מספר הניסיונות הכולל לביצוע טרנזקציות שבוטלו, כולל ניסיונות שבוטלו לפני הקריאה ל-method‏ commit של הטרנזקציה. המספר הזה מייצג את סך כל הביטולים במהלך המרווח שצוין. מידע נוסף על מרווחים זמין במאמר מרווחים.
COMMIT_RETRY_COUNT INT64 המספר הכולל של ניסיונות חוזרים אחרי ניסיונות קודמים שבוטלו. יכול להיות שטרנזקציה ב-Spanner תנסה להתבצע כמה פעמים לפני שהיא תתבצע, בגלל מחלוקות על נעילה או אירועים זמניים. מספר גבוה של ניסיונות חוזרים ביחס לניסיונות השמירה מצביע על כך שיכול להיות שיש בעיות שכדאי לבדוק. מידע נוסף זמין בקטע הסבר על עסקאות וספירות של ביצוע שינויים שבהמשך הדף.
COMMIT_FAILED_PRECONDITION_COUNT INT64 המספר הכולל של ניסיונות לביצוע טרנזקציות שהחזירו שגיאות של תנאים מוקדמים שנכשלו, כמו הפרות של אינדקס UNIQUE, שורה שכבר קיימת או שורה שלא נמצאה.
SERIALIZABLE_PESSIMISTIC_TXN_COUNT INT64 מספר הניסיונות הכולל של עסקאות שהתחילו עם רמת הבידוד SERIALIZABLE ונעילה מסוג PESSIMISTIC. היא תת-קבוצה של ATTEMPT_COUNT.
SERIALIZABLE_OPTIMISTIC_TXN_COUNT INT64 מספר הניסיונות הכולל לביצוע עסקאות שהתחילו עם רמת הבידוד SERIALIZABLE ונעילת OPTIMISTIC. היא תת-קבוצה של ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT INT64 מספר הניסיונות הכולל של עסקאות שהתחילו עם רמת הבידוד REPEATABLE READ ונעילה מסוג OPTIMISTIC. היא תת-קבוצה של ATTEMPT_COUNT.
AVG_PARTICIPANTS FLOAT64 המספר הממוצע של משתתפים בכל ניסיון לשלוח קוד. מידע נוסף על משתתפים זמין במאמר מחזור החיים של קריאות וכתיבות ב-Spanner.
AVG_TOTAL_LATENCY_SECONDS FLOAT64 מספר השניות הממוצע מהפעולה הראשונה של הטרנזקציה ועד לביצוע/ביטול.
AVG_COMMIT_LATENCY_SECONDS FLOAT64 מספר השניות הממוצע לביצוע פעולת השמירה.
AVG_BYTES FLOAT64 מספר הבייטים הממוצע שנכתבו על ידי הטרנזקציה.
TOTAL_LATENCY_DISTRIBUTION ARRAY<STRUCT>

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

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

המערך מכיל רכיב אחד מהסוג הבא:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
מידע נוסף על הערכים זמין במאמרים Distribution ו-Exponential.

כדי לחשב את זמן האחזור של האחוזון מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64) שמחזירה את האחוזון ה-n המשוער. דוגמה קשורה: חיפוש זמן האחזור באחוזון ה-99 של טרנזקציות.

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

OPERATIONS_BY_TABLE ARRAY<STRUCT>

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

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

מציינים את המערך באופן הבא:
ARRAY<STRUCT<
  TABLE STRING(MAX),
  INSERT_OR_UPDATE_COUNT INT64,
  INSERT_OR_UPDATE_BYTES INT64>>

TOTAL_LATENCY_DISTRIBUTION_JSON_STRING STRING

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

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

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

העמודה הזו נתמכת במסדי נתונים בניב GoogleSQL ובניב PostgreSQL. בעמודה הזו מופיעה ההפצה.

כדי לחשב את זמן האחזור של האחוזון מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64) שמחזירה את האחוזון ה-n המשוער. לדוגמה קשורה, ראו מציאת זמן האחזור באחוזון ה-99 לעסקאות באמצעות העמודה TOTAL_LATENCY_DISTRIBUTION_JSON_STRING.

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

OPERATIONS_BY_TABLE_JSON_STRING STRING

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

ייצוג מחרוזת תואם ל-JSON של העמודה OPERATIONS_BY_TABLE. מחרוזת ה-JSON היא אובייקט JSON עם אותו מבנה כמו ה-STRUCT שמוגדר בעמודה OPERATIONS_BY_TABLE.

העמודה הזו נתמכת במסדי נתונים בניב GoogleSQL ובניב PostgreSQL.

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

COMMIT_LATENCY_DISTRIBUTION ARRAY<STRUCT>

היסטוגרמה של מספר השניות שנדרשו לביצוע פעולת השמירה.

המבנה של המערך הוא:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

למידע נוסף על סוגי הערכים, קראו את המאמרים התפלגות ואקספוננציאלי.

כדי לחשב את אחוזי זמן האחזור של השמירה מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

COMMIT_LATENCY_DISTRIBUTION_JSON_STRING STRING

ייצוג מחרוזת תואם ל-JSON של הנתון הסטטיסטי COMMIT_LATENCY_DISTRIBUTION. מחרוזת ה-JSON היא אובייקט JSON עם מבנה זהה ל-STRUCT שמוגדר בעמודה COMMIT_LATENCY_DISTRIBUTION.

העמודה הזו נתמכת במסדי נתונים בניב GoogleSQL ובניב PostgreSQL.

כדי לחשב את אחוזי זמן האחזור של השמירה מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

PARTICIPANTS_DISTRIBUTION ARRAY<STRUCT>

היסטוגרמה של מספר המשתתפים בכל ניסיון לשמירת נתונים.

המבנה של המערך הוא:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

למידע נוסף על סוגי הערכים, קראו את המאמרים התפלגות ואקספוננציאלי.

כדי לחשב את אחוזי המשתתפים מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

PARTICIPANTS_DISTRIBUTION_JSON_STRING STRING

ייצוג מחרוזת תואם ל-JSON של הנתון הסטטיסטי PARTICIPANTS_DISTRIBUTION. מחרוזת ה-JSON היא אובייקט JSON עם מבנה זהה ל-STRUCT שמוגדר בעמודה PARTICIPANTS_DISTRIBUTION.

העמודה הזו נתמכת במסדי נתונים בניב GoogleSQL ובניב PostgreSQL.

כדי לחשב את אחוזי המשתתפים מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

שאילתות לדוגמה

בקטע הזה יש כמה דוגמאות להצהרות SQL שמאחזרות נתונים סטטיסטיים של עסקאות. אפשר להריץ את הצהרות ה-SQL האלה באמצעות ספריות הלקוח, gcloud spanner או מסוףGoogle Cloud .

הצגת הנתונים הסטטיסטיים הבסיסיים של כל עסקה בתקופה נתונה

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

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds,
       avg_commit_latency_seconds,
       operations_by_table,
       avg_bytes
FROM spanner_sys.txn_stats_top_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_top_minute);
פלט השאילתה
fprint read_columns write_constructive_columns write_delete_tables avg_total_latency_seconds avg_commit_latency_seconds operations_by_table avg_bytes
40015598317 [] ["Routes.name", "Cars.model"] ["Users"] 0.006578737 0.006547737 [["Cars",1107,30996],["Routes",560,26880]] 25286
20524969030 ["id", "no"] [] [] 0.001732442 0.000247442 [] 0
77848338483 [] [] ["Cars", "Routes"] 0.033467418 0.000251418 [] 0

הצגת רשימה של העסקאות עם זמן האחזור הממוצע הארוך ביותר של השמירה

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

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds,
       avg_commit_latency_seconds,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_top_hour)
ORDER BY avg_commit_latency_seconds DESC;
פלט השאילתה
fprint read_columns write_constructive_columns write_delete_tables avg_total_latency_seconds avg_commit_latency_seconds avg_bytes
40015598317 [] ["Routes.name", "Cars.model"] ["Users"] 0.006578737 0.006547737 25286
77848338483 [] [] ["Cars", "Routes"] 0.033467418 0.000251418 0
20524969030 ["id", "no"] [] [] 0.001732442 0.000247442 0

מציאת זמן האחזור הממוצע של עסקאות שקוראות עמודות מסוימות

השאילתה הבאה מחזירה את מידע זמן האחזור הממוצע של טרנזקציות שקוראות את העמודה ADDRESS מנתונים סטטיסטיים של שעה אחת:

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds
FROM spanner_sys.txn_stats_top_hour
WHERE 'ADDRESS' IN UNNEST(read_columns)
ORDER BY avg_total_latency_seconds DESC;
פלט השאילתה
fprint read_columns write_constructive_columns write_delete_tables avg_total_latency_seconds
77848338483 ["ID", "ADDRESS"] [] ["Cars", "Routes"] 0.033467418
40015598317 ["ID", "NAME", "ADDRESS"] [] ["Users"] 0.006578737

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

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

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
ORDER BY avg_bytes DESC;
פלט השאילתה
fprint read_columns write_constructive_columns write_delete_tables avg_bytes
40015598317 [] [] ["Users"] 25286
77848338483 [] [] ["Cars", "Routes"] 12005
20524969030 ["ID", "ADDRESS"] [] ["Users"] 10923

נתונים סטטיסטיים מצטברים

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

  • ‫SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: נתונים סטטיסטיים מצטברים של כל העסקאות במרווחים של דקה אחת
  • ‫SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: נתונים סטטיסטיים מצטברים של כל העסקאות במרווחים של 10 דקות
  • ‫SPANNER_SYS.TXN_STATS_TOTAL_HOUR: נתונים סטטיסטיים מצטברים לכל העסקאות במרווחים של שעה אחת

לטבלאות של נתונים סטטיסטיים מצטברים יש את המאפיינים הבאים:

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

  • מרווחי הזמן מבוססים על זמני השעון. מרווחים של דקה מסתיימים בדקה, מרווחים של 10 דקות מסתיימים כל 10 דקות החל מהשעה, ומרווחים של שעה מסתיימים בשעה.

    לדוגמה, בשעה 11:59:30, המרווחים האחרונים שזמינים לשאילתות SQL בנתונים סטטיסטיים מצטברים של עסקאות הם:

    • דקה אחת: 11:58:00 עד 11:58:59
    • 10 דקות: 11:40:00 עד 11:49:59
    • שעה אחת: 10:00:00 עד 10:59:59

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

  • הנתונים הסטטיסטיים שנאספים בטבלאות SPANNER_SYS.TXN_STATS_TOTAL_* עשויים לכלול טרנזקציות ש-Spanner לא אסף בטבלאות SPANNER_SYS.TXN_STATS_TOP_*.

  • חלק מהעמודות בטבלאות האלה מוצגות כמדדים ב-Cloud Monitoring. המדדים שמוצגים הם:

    • מספר ניסיונות השמירה
    • מספר הניסיונות החוזרים של השמירה
    • המשתתפים בעסקה
    • זמני האחזור של העסקאות
    • בייטים שנכתבו

    מידע נוסף זמין במאמר מדדי Spanner.

סכמת טבלאות

שם העמודה סוג תיאור
INTERVAL_END TIMESTAMP סוף מרווח הזמן שבו הנתון הסטטיסטי הזה נאסף.
ATTEMPT_COUNT INT64 מספר הניסיונות הכולל לביצוע טרנזקציות, כולל ניסיונות שבוטלו לפני הקריאה ל-commit. הספירה הזו מייצגת את מספר הניסיונות הכולל במהלך המרווח שצוין. מידע נוסף על מרווחים זמין במאמר מרווחים.
COMMIT_ATTEMPT_COUNT INT64 מספר הניסיונות הכולל לביצוע טרנזקציות. המספר הזה צריך להיות זהה למספר הקריאות ל-method‏ commit של העסקה. המספר הזה מייצג את המספר הכולל של ניסיונות השמירה במהלך המרווח שצוין. למידע נוסף על מרווחים, ראו מרווחים.
COMMIT_ABORT_COUNT INT64 מספר הניסיונות הכולל לביצוע טרנזקציות שבוטלו, כולל ניסיונות שבוטלו לפני הקריאה ל-method‏ commit של הטרנזקציה. המספר הזה מייצג את סך כל הביטולים במהלך המרווח שצוין. מידע נוסף על מרווחים זמין במאמר מרווחים.
COMMIT_RETRY_COUNT INT64 מספר ניסיונות השמירה שהם ניסיונות חוזרים של ניסיונות קודמים שבוטלו. יכול להיות שטרנזקציה ב-Spanner תנוסה כמה פעמים לפני שהיא תתבצע, בגלל מחלוקות על נעילה או אירועים זמניים. מספר גבוה של ניסיונות חוזרים ביחס לניסיונות השמירה מצביע על כך שיכול להיות שיש בעיות שכדאי לבדוק. מידע נוסף זמין בקטע הסבר על עסקאות וספירות של ביצוע שינויים שבהמשך הדף.
COMMIT_FAILED_PRECONDITION_COUNT INT64 המספר הכולל של ניסיונות לביצוע טרנזקציות שהחזירו שגיאות של תנאים מוקדמים שנכשלו, כמו הפרות של אינדקס UNIQUE, שורה שכבר קיימת או שורה שלא נמצאה.
SERIALIZABLE_PESSIMISTIC_TXN_COUNT INT64 מספר הניסיונות הכולל של עסקאות שהתחילו עם רמת הבידוד SERIALIZABLE ונעילה מסוג PESSIMISTIC. היא תת-קבוצה של ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT INT64 מספר הניסיונות הכולל לביצוע עסקאות שהתחילו עם רמת הבידוד REPEATABLE READ ונעילת OPTIMISTIC. היא תת-קבוצה של ATTEMPT_COUNT.
AVG_PARTICIPANTS FLOAT64 המספר הממוצע של משתתפים בכל ניסיון לשלוח קוד. מידע נוסף על משתתפים זמין במאמר מחזור החיים של קריאות וכתיבות ב-Spanner.
AVG_TOTAL_LATENCY_SECONDS FLOAT64 מספר השניות הממוצע מהפעולה הראשונה של הטרנזקציה ועד לביצוע/ביטול.
AVG_COMMIT_LATENCY_SECONDS FLOAT64 מספר השניות הממוצע לביצוע פעולת השמירה.
AVG_BYTES FLOAT64 מספר הבייטים הממוצע שנכתבו על ידי הטרנזקציה.
TOTAL_LATENCY_DISTRIBUTION ARRAY<STRUCT>

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

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

המערך מכיל רכיב אחד מהסוג הבא:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
מידע נוסף על הערכים זמין במאמרים Distribution ו-Exponential.

כדי לחשב את זמן האחזור של האחוזון מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64) שמחזירה את האחוזון ה-n המשוער. לדוגמה, ראו חיפוש זמן האחזור באחוזון ה-99 של טרנזקציות.

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

OPERATIONS_BY_TABLE ARRAY<STRUCT>

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

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

מציינים את המערך באופן הבא:
ARRAY<STRUCT<
  TABLE STRING(MAX),
  INSERT_OR_UPDATE_COUNT INT64,
  INSERT_OR_UPDATE_BYTES INT64>>

TOTAL_LATENCY_DISTRIBUTION_JSON_STRING STRING

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

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

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

העמודה הזו נתמכת במסדי נתונים בניב GoogleSQL ובניב PostgreSQL. בעמודה הזו מופיעה ההפצה.

כדי לחשב את זמן האחזור של האחוזון מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64) שמחזירה את האחוזון ה-n המשוער. לדוגמה קשורה, ראו מציאת האחוזון ה-99 של זמן האחזור של טרנזקציות באמצעות העמודה TOTAL_LATENCY_DISTRIBUTION_JSON_STRING.

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

OPERATIONS_BY_TABLE_JSON_STRING STRING

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

ייצוג מחרוזת תואם ל-JSON של העמודה OPERATIONS_BY_TABLE. מחרוזת ה-JSON היא אובייקט JSON עם אותו מבנה כמו ה-STRUCT שמוגדר בעמודה OPERATIONS_BY_TABLE.

העמודה הזו נתמכת במסדי נתונים בניב GoogleSQL ובניב PostgreSQL.

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

COMMIT_LATENCY_DISTRIBUTION ARRAY<STRUCT>

היסטוגרמה של מספר השניות שנדרשו לביצוע פעולת השמירה.

המבנה של המערך הוא:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

למידע נוסף על סוגי הערכים, קראו את המאמרים התפלגות ואקספוננציאלי.

כדי לחשב את אחוזי זמן האחזור של השמירה מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

COMMIT_LATENCY_DISTRIBUTION_JSON_STRING STRING

ייצוג מחרוזת תואם ל-JSON של הנתון הסטטיסטי COMMIT_LATENCY_DISTRIBUTION. מחרוזת ה-JSON היא אובייקט JSON עם מבנה זהה ל-STRUCT שמוגדר בעמודה COMMIT_LATENCY_DISTRIBUTION.

העמודה הזו נתמכת במסדי נתונים בניב GoogleSQL ובניב PostgreSQL.

כדי לחשב את אחוזי זמן האחזור של השמירה מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

PARTICIPANTS_DISTRIBUTION ARRAY<STRUCT>

היסטוגרמה של מספר המשתתפים בכל ניסיון לשמירת נתונים.

המבנה של המערך הוא:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

למידע נוסף על סוגי הערכים, קראו את המאמרים התפלגות ואקספוננציאלי.

כדי לחשב את אחוזי המשתתפים מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

PARTICIPANTS_DISTRIBUTION_JSON_STRING STRING

ייצוג מחרוזת תואם ל-JSON של הנתון הסטטיסטי PARTICIPANTS_DISTRIBUTION. מחרוזת ה-JSON היא אובייקט JSON עם מבנה זהה ל-STRUCT שמוגדר בעמודה PARTICIPANTS_DISTRIBUTION.

העמודה הזו נתמכת במסדי נתונים בניב GoogleSQL ובניב PostgreSQL.

כדי לחשב את אחוזי המשתתפים מההתפלגות, משתמשים בפונקציה SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

שאילתות לדוגמה

בקטע הזה יש כמה דוגמאות להצהרות SQL שמאחזרות נתונים סטטיסטיים של עסקאות. אפשר להריץ את הצהרות ה-SQL האלה באמצעות ספריות הלקוח, gcloud spanner או מסוףGoogle Cloud .

מציאת המספר הכולל של ניסיונות השמירה של כל העסקאות

השאילתה הבאה מחזירה את המספר הכולל של ניסיונות ה-commit לכל הטרנזקציות במרווח הזמן האחרון של דקה אחת:

SELECT interval_end,
       commit_attempt_count
FROM spanner_sys.txn_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_minute)
ORDER BY interval_end;
פלט השאילתה
interval_end commit_attempt_count
2020-01-17 11:46:00-08:00 21

שימו לב שיש רק שורה אחת בתוצאה, כי לנתונים סטטיסטיים נצברים יש רק רשומה אחת לכל interval_end בכל משך זמן.

חיפוש זמן האחזור הכולל של השמירה בכל העסקאות

השאילתה הבאה מחזירה את זמן האחזור הכולל של האישור בכל העסקאות ב-10 הדקות האחרונות:

SELECT (avg_commit_latency_seconds * commit_attempt_count / 60 / 60)
  AS total_commit_latency_hours
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute);
פלט השאילתה
total_commit_latency_hours
0.8967

שימו לב שיש רק שורה אחת בתוצאה, כי לנתונים סטטיסטיים נצברים יש רק רשומה אחת לכל interval_end בכל משך זמן.

חיפוש זמן האחזור באחוזון ה-99 של העסקאות

השאילתות הבאות מחזירות את האחוזון ה-99 של זמן הביצוע של שאילתות שהופעלו ב-10 הדקות האחרונות.

במסדי נתונים עם ניב GoogleSQL, אפשר להשתמש בעמודה TOTAL_LATENCY_DISTRIBUTION:

SELECT interval_end, avg_total_latency_seconds,
       SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution[OFFSET(0)], 99.0)
  AS percentile_latency
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute)
ORDER BY interval_end;

במסדי נתונים עם ניב PostgreSQL, משתמשים בעמודה TOTAL_LATENCY_JSON_DISTRIBUTION_JSON_STRING:

SELECT interval_end, avg_total_latency_seconds,
       SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution_json_string, 99.0)
  AS percentile_latency
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute)
ORDER BY interval_end;
פלט השאילתה
interval_end avg_total_latency_seconds percentile_latency
2022-08-17 11:46:00-08:00 0.34576998305986395 9.00296190476190476

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

יש רק שורה אחת בתוצאה כי לנתונים הסטטיסטיים המצטברים יש רק רשומה אחת לכל interval_end בכל משך זמן.

מציאת זמן האחזור של אישור העסקה באחוזון ה-99 בעסקאות בפרקי זמן מותאמים אישית

‫SPANNER_SYS.DISTRIBUTION_AGG היא פונקציית צבירה שממזגת כמה ערכי התפלגות בשורות להתפלגות אחת מאותו סוג. כדי לחשב את האחוזון בטווח זמן מותאם אישית, כמו השעה האחרונה, צריך לציין את זמני ההתחלה והסיום של INTERVAL_END בסעיף WHERE. לאחר מכן משתמשים ב-SPANNER_SYS.DISTRIBUTION_AGG כדי למזג את ההתפלגויות מהמרווחים שבהם COUNT גדול מאפס, ומעבירים את התוצאה אל SPANNER_SYS.DISTRIBUTION_PERCENTILE:

GoogleSQL 

WITH aggregated_stats AS (
  SELECT
    T.FPRINT,
    -- Aggregate distribution structs by checking the COUNT field directly
    SPANNER_SYS.DISTRIBUTION_AGG(
      IF(
        T.COMMIT_LATENCY_DISTRIBUTION[SAFE_OFFSET(0)].COUNT > 0,
        T.COMMIT_LATENCY_DISTRIBUTION[SAFE_OFFSET(0)],
        NULL
      )
    ) AS commit_latency_dist
  FROM
    SPANNER_SYS.TXN_STATS_TOP_MINUTE AS T
  WHERE
    T.INTERVAL_END > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)
    AND T.INTERVAL_END <= CURRENT_TIMESTAMP()
    AND T.FPRINT = transaction-fingerprint
  GROUP BY
    T.FPRINT
)
SELECT
  FPRINT,
  -- Calculate percentiles only if an aggregated distribution exists
  IF(commit_latency_dist IS NOT NULL,
    SPANNER_SYS.DISTRIBUTION_PERCENTILE(commit_latency_dist, 99.0),
    NULL) AS p99_commit_latency
FROM
  aggregated_stats;

מחליפים את transaction-fingerprint בטביעת אצבע של עסקה.

PostgreSQL 

WITH aggregated_stats AS (
  SELECT
    T.FPRINT,
    -- Aggregate distribution JSON strings by checking the COUNT field
    SPANNER_SYS.DISTRIBUTION_AGG(
      CASE
        WHEN T.COMMIT_LATENCY_DISTRIBUTION_JSON_STRING::jsonb ->> 'COUNT' != '0'
          THEN T.COMMIT_LATENCY_DISTRIBUTION_JSON_STRING
        ELSE NULL
      END
    ) AS commit_latency_dist_str
  FROM
    SPANNER_SYS.TXN_STATS_TOP_MINUTE AS T
  WHERE
    T.INTERVAL_END > spanner.timestamptz_subtract(now(), '1 HOUR')
    AND T.INTERVAL_END <= now()
    AND T.FPRINT = transaction-fingerprint
  GROUP BY
    T.FPRINT
)
SELECT
  FPRINT,
  CASE
    WHEN commit_latency_dist_str IS NOT NULL
      THEN SPANNER_SYS.DISTRIBUTION_PERCENTILE(commit_latency_dist_str, 99.0)
    ELSE NULL
  END AS p99_commit_latency
FROM
  aggregated_stats;

מחליפים את transaction-fingerprint בטביעת אצבע של עסקה.

שמירת נתונים

‫Spanner שומר את הנתונים של כל טבלה לפחות למשך פרקי הזמן הבאים:

  • ‫SPANNER_SYS.TXN_STATS_TOP_MINUTE ו-SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: מרווחים שכוללים את 6 השעות הקודמות.

  • ‫SPANNER_SYS.TXN_STATS_TOP_10MINUTE ו-SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: מרווחים שכוללים את 4 הימים הקודמים.

  • ‫SPANNER_SYS.TXN_STATS_TOP_HOUR ו-SPANNER_SYS.TXN_STATS_TOTAL_HOUR: מרווחים שכוללים את 30 הימים הקודמים.

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

הסבר על טרנזקציות וספירת פעולות commit

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

  • בעיות זמניות ברשת.

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

  • למכונה של Spanner אין את הקיבולת לטפל בכל הבקשות שהיא מקבלת.

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

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

בטבלה הבאה מתוארות כמה דוגמאות לאופן שבו COMMIT_ATTEMPT_COUNT,‏ COMMIT_ABORT_COUNT ו-COMMIT_RETRY_COUNT נרשמים ביומן בתרחישים שונים.

תרחיש COMMIT_ATTEMPT_COUNT COMMIT_ABORT_COUNT COMMIT_RETRY_COUNT
העסקה בוצעה בהצלחה בניסיון הראשון. 1 0 0
העסקה בוטלה בגלל שגיאת זמן קצוב לתפוגה. 1 1 0
הטרנזקציה בוטלה בגלל בעיה זמנית ברשת, ובוצעה בהצלחה אחרי ניסיון חוזר אחד. 2 1 1
‫5 עסקאות עם אותו FPRINT מבוצעות בטווח של 10 דקות. 3 מהעסקאות בוצעו בהצלחה בניסיון הראשון, ו-2 עסקאות בוטלו ואז בוצעו בהצלחה בניסיון השני. 7 2 2

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

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

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

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

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

בוחרים את תקופת הזמן שרוצים לבדוק.

אפשר למצוא אותו באפליקציה שמשתמשת ב-Spanner.

לצורך התרגיל הזה, נניח שהבעיה התחילה ב-17 במאי 2020 בסביבות השעה 17:20.

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

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

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

לדוגמה, השאילתה הבאה מחזירה את הנתונים הסטטיסטיים המצטברים של העסקאות מ-4:30 pm עד 7:40 pm (כולל).

SELECT
  interval_end,
  ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
  commit_attempt_count,
  commit_abort_count
FROM SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE
WHERE
  interval_end >= "2020-05-17T16:40:00"
  AND interval_end <= "2020-05-17T19:40:00"
ORDER BY interval_end;

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

interval_end avg_total_latency_seconds commit_attempt_count commit_abort_count
2020-05-17 16:40:00-07:00 0.0284 315691 5170
2020-05-17 16:50:00-07:00 0.0250 302124 3828
2020-05-17 17:00:00-07:00 0.0460 346087 11382
2020-05-17 17:10:00-07:00 0.0864 379964 33826
2020-05-17 17:20:00-07:00 0.1291 390343 52549
2020-05-17 17:30:00-07:00 0.1314 456455 76392
2020-05-17 17:40:00-07:00 0.1598 507774 121458
2020-05-17 17:50:00-07:00 0.1641 516587 115875
2020-05-17 18:00:00-07:00 0.1578 552711 122626
2020-05-17 18:10:00-07:00 0.1750 569460 154205
2020-05-17 18:20:00-07:00 0.1727 613571 160772
2020-05-17 18:30:00-07:00 0.1588 601994 143044
2020-05-17 18:40:00-07:00 0.2025 604211 170019
2020-05-17 18:50:00-07:00 0.1615 601622 135601
2020-05-17 19:00:00-07:00 0.1653 596804 129511
2020-05-17 19:10:00-07:00 0.1414 560023 112247
2020-05-17 19:20:00-07:00 0.1367 570864 100596
2020-05-17 19:30:00-07:00 0.0894 539729 65316
2020-05-17 19:40:00-07:00 0.0820 479151 40398

הזמן הכולל של זמן האחזור ומספר הביטולים גבוהים יותר בתקופות המודגשות. בוחרים מרווח זמן של 10 דקות שבו זמן האחזור המצטבר ומספר הביטולים, או שניהם, גבוהים. בשלב הבא נשתמש במרווח הזמן שמסתיים ב-2020-05-17T18:40:00 כדי לזהות אילו טרנזקציות תורמות לזמן האחזור הארוך ולמספר הביטולים.

זיהוי עסקאות עם זמן אחזור ארוך

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

מריצים את השאילתה הבאה כדי לקבל את הטרנזקציות שמשפיעות הכי הרבה על הביצועים, בסדר יורד של זמן האחזור הכולל, במרווח הזמן לדוגמה שמסתיים ב-2020-05-17T18:40:00.

SELECT
  interval_end,
  fprint,
  ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
  ROUND(avg_commit_latency_seconds,4) as avg_commit_latency_seconds,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC;
interval_end fprint avg_total_latency_seconds avg_commit_latency_seconds commit_attempt_count commit_abort_count commit_retry_count
2020-05-17 18:40:00-07:00 15185072816865185658 0.3508 0.0139 278802 142205 129884
2020-05-17 18:40:00-07:00 15435530087434255496 0.1633 0.0142 129012 27177 24559
2020-05-17 18:40:00-07:00 14175643543447671202 0.1423 0.0133 5357 636 433
2020-05-17 18:40:00-07:00 898069986622520747 0.0198 0.0158 6 0 0
2020-05-17 18:40:00-07:00 10510121182038036893 0.0168 0.0125 7 0 0
2020-05-17 18:40:00-07:00 9287748709638024175 0.0159 0.0118 4269 1 0
2020-05-17 18:40:00-07:00 7129109266372596045 0.0142 0.0102 182227 0 0
2020-05-17 18:40:00-07:00 15630228555662391800 0.0120 0.0107 58 0 0
2020-05-17 18:40:00-07:00 7907238229716746451 0.0108 0.0097 65 0 0
2020-05-17 18:40:00-07:00 10158167220149989178 0.0095 0.0047 3454 0 0
2020-05-17 18:40:00-07:00 9353100217060788102 0.0093 0.0045 725 0 0
2020-05-17 18:40:00-07:00 9521689070912159706 0.0093 0.0045 164 0 0
2020-05-17 18:40:00-07:00 11079878968512225881 0.0064 0.0019 65 0 0

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

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

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

SELECT
  fprint,
  read_columns,
  write_constructive_columns,
  write_delete_tables
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC LIMIT 3;
fprint read_columns write_constructive_columns write_delete_tables
15185072816865185658 [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.shares] [TestHigherLatency._exists,TestHigherLatency.shares,TestHigherLatency_lang_status_score_index.shares] []
15435530087434255496 [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.likes,globalTagAffinity.score] [TestHigherLatency._exists,TestHigherLatency.likes,TestHigherLatency_lang_status_score_index.likes] []
14175643543447671202 [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.ugcCount] [TestHigherLatency._exists,TestHigherLatency.ugcCount,TestHigherLatency_lang_status_score_index.ugcCount] []

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

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

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

SELECT
  interval_end,
  ROUND(avg_total_latency_seconds, 3) AS latency,
  ROUND(avg_commit_latency_seconds, 3) AS commit_latency,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count,
  commit_failed_precondition_count,
  avg_bytes
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end >= "2020-05-17T16:40:00"
  AND interval_end <= "2020-05-17T19:40:00"
  AND fprint = $FPRINT
ORDER BY interval_end;
interval_end זמן אחזור commit_latency commit_attempt_count commit_abort_count commit_retry_count commit_failed_precondition_count avg_bytes
2020-05-17 16:40:00-07:00 0.095 0.010 53230 4752 4330 0 91
2020-05-17 16:50:00-07:00 0.069 0.009 61264 3589 3364 0 91
2020-05-17 17:00:00-07:00 0.150 0.010 75868 10557 9322 0 91
2020-05-17 17:10:00-07:00 0.248 0.013 103151 30220 28483 0 91
2020-05-17 17:20:00-07:00 0.310 0.012 130078 45655 41966 0 91
2020-05-17 17:30:00-07:00 0.294 0.012 160064 64930 59933 0 91
2020-05-17 17:40:00-07:00 0.315 0.013 209614 104949 96770 0 91
2020-05-17 17:50:00-07:00 0.322 0.012 215682 100408 95867 0 90
2020-05-17 18:00:00-07:00 0.310 0.012 230932 106728 99462 0 91
2020-05-17 18:10:00-07:00 0.309 0.012 259645 131049 125889 0 91
2020-05-17 18:20:00-07:00 0.315 0.013 272171 137910 129411 0 90
2020-05-17 18:30:00-07:00 0.292 0.013 258944 121475 115844 0 91
2020-05-17 18:40:00-07:00 0.350 0.013 278802 142205 134229 0 91
2020-05-17 18:50:00-07:00 0.302 0.013 256259 115626 109756 0 91
2020-05-17 19:00:00-07:00 0.315 0.014 250560 110662 100322 0 91
2020-05-17 19:10:00-07:00 0.271 0.014 238384 99025 90187 0 91
2020-05-17 19:20:00-07:00 0.273 0.014 219687 84019 79874 0 91
2020-05-17 19:30:00-07:00 0.198 0.013 195357 59370 55909 0 91
2020-05-17 19:40:00-07:00 0.181 0.013 167514 35705 32885 0 91

בפלט הזה אפשר לראות שזמן האחזור הכולל גבוה בתקופת הזמן המודגשת. בכל מקום שבו זמן האחזור הכולל גבוה, גם commit_attempt_count,‏ commit_abort_count ו-commit_retry_count גבוהים, למרות שזמן האחזור של ה-commit‏ (commit_latency) לא השתנה הרבה. מכיוון שביטול של אישורי טרנזקציות מתרחש בתדירות גבוהה יותר, גם ניסיונות האישור גבוהים בגלל ניסיונות חוזרים לאישור.

סיכום

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

זיהוי עסקאות שלא בוצע בהן ניסיון חוזר בצורה נכונה

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

SELECT
  *
FROM (
  SELECT
    fprint,
    SUM(commit_attempt_count) AS total_commit_attempt_count,
    SUM(commit_abort_count) AS total_commit_abort_count,
    SUM(commit_retry_count) AS total_commit_retry_count
  FROM
    SPANNER_SYS.TXN_STATS_TOP_10MINUTE
  GROUP BY
    fprint )
WHERE
  total_commit_retry_count = 0
  AND total_commit_abort_count > 0
ORDER BY
  total_commit_abort_count DESC;
fprint total_commit_attempt_count total_commit_abort_count total_commit_retry_count
1557557373282541312 3367894 44232 0
5776062322886969344 13566 14 0

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

השאילתה הבאה מחזירה פרטים נוספים על העסקה עם fprint‏ 1557557373282541312, כולל read_columns,‏ write_constructive_columns ו-write_delete_tables. המידע הזה עוזר לזהות את הטרנזקציה בקוד הלקוח, שבו אפשר לבדוק את לוגיקת הניסיון החוזר בתרחיש הזה.

SELECT
  interval_end,
  fprint,
  read_columns,
  write_constructive_columns,
  write_delete_tables,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count
FROM
  SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  fprint = 1557557373282541312
ORDER BY
  interval_end DESC;
interval_end fprint read_columns write_constructive_columns write_delete_tables commit_attempt_count commit_abort_count commit_retry_count
2021-01-27T18:30:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 805228 1839 0
2021-01-27T18:20:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 1034429 38779 0
2021-01-27T18:10:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 833677 2266 0
2021-01-27T18:00:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 694560 1348 0

הטרנזקציה כוללת קריאה של העמודה הנסתרת Singers._exists כדי לבדוק אם קיימת שורה. הטרנזקציה גם כותבת לעמודות Singers.FirstName ו-Singer.LastName. המידע הזה יכול לעזור לכם להבין אם מנגנון הניסיון החוזר של העסקה שהוטמע בספריית הלקוח בהתאמה אישית פועל כמו שצריך.

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