Spanner מספק טבלאות מובנות שמאחסנות נתונים סטטיסטיים על קריאות. אפשר לאחזר נתונים סטטיסטיים מטבלאות SPANNER_SYS.READ_STATS* האלה באמצעות הצהרות SQL.
מתי כדאי להשתמש בנתוני קריאה
הנתונים הסטטיסטיים של קריאה מספקים תובנות לגבי השימוש במסד הנתונים באפליקציה, והם שימושיים כשבודקים בעיות בביצועים. לדוגמה, אתם יכולים לבדוק אילו צורות קריאה מופעלות מול מסד נתונים, באיזו תדירות הן מופעלות ולהסביר את מאפייני הביצועים של צורות הקריאה האלה. אתם יכולים להשתמש בנתוני הקריאה של מסד הנתונים כדי לזהות צורות קריאה שגורמות לשימוש גבוה במעבד (CPU). ברמה גבוהה, נתונים סטטיסטיים של קריאה יעזרו לכם להבין את התנהגות התנועה שנכנסת למסד נתונים מבחינת השימוש במשאבים.
מגבלות
הכלי הזה מתאים במיוחד לניתוח של זרמי קריאה דומים שמהווים את רוב השימוש במעבד. הוא לא מתאים לחיפוש קריאות שהופעלו רק פעם אחת.
השימוש במעבד (CPU) שמתועד בנתונים הסטטיסטיים האלה מייצג את השימוש במעבד בצד השרת של Spanner, לא כולל שימוש במעבד לצורך אחזור מראש (prefetch) וחלק מהתקורה (overhead) האחרת.
הנתונים הסטטיסטיים נאספים כמיטב יכולתנו. כתוצאה מכך, יכול להיות שנתונים סטטיסטיים לא ידווחו אם יש בעיות במערכות הבסיסיות. לדוגמה, אם יש בעיות ברשת הפנימית, יכול להיות שחלק מהנתונים הסטטיסטיים לא יופיעו.
גישה לנתוני קריאה
Spanner מספק את נתוני הקריאה בסכימה SPANNER_SYS. אפשר לגשת לנתוני SPANNER_SYS בדרכים הבאות:
דף Spanner Studio של מסד נתונים במסוף Google Cloud .
הפקודה
gcloud spanner databases execute-sql.השיטה
executeSqlאו השיטהexecuteStreamingSql.
השיטות הבאות לקריאה יחידה ש-Spanner מספק לא תומכות ב-SPANNER_SYS:
- ביצוע קריאה חזקה משורה אחת או מכמה שורות בטבלה.
- ביצוע קריאה בעבר משורה אחת או מכמה שורות בטבלה.
- קריאה משורה אחת או מכמה שורות באינדקס משני.
שימוש במעבד מקובץ לפי צורת קריאה
הטבלאות הבאות עוקבות אחרי צורות הקריאה עם השימוש הכי גבוה במעבד (CPU) במהלך תקופה מסוימת:
-
SPANNER_SYS.READ_STATS_TOP_MINUTE: נתונים סטטיסטיים של צורת הקריאה שמצטברים במרווחי זמן של דקה אחת. -
SPANNER_SYS.READ_STATS_TOP_10MINUTE: קריאת נתונים סטטיסטיים של צורות שמצטברים במרווחי זמן של 10 דקות. -
SPANNER_SYS.READ_STATS_TOP_HOUR: קריאת נתונים סטטיסטיים של צורות שמצטברים במרווחי זמן של שעה.
הטבלאות האלה כוללות את המאפיינים הבאים:
כל טבלה מכילה נתונים של מרווחי זמן לא חופפים באורך שצוין בשם הטבלה.
המרווחים מבוססים על שעות. מרווחי זמן של דקה מסתיימים בתחילת הדקה, מרווחי זמן של 10 דקות מסתיימים כל 10 דקות החל מתחילת השעה, ומרווחי זמן של שעה מסתיימים בתחילת השעה. אחרי כל מרווח זמן, מערכת Spanner אוספת נתונים מכל השרתים, ואז הנתונים האלה זמינים בטבלאות SPANNER_SYS זמן קצר לאחר מכן.
לדוגמה, בשעה 11:59:30, המרווחים האחרונים שזמינים לשאילתות SQL הם:
- דקה אחת: 11:58:00–11:58:59
- 10 דקות: 11:40:00–11:49:59
- שעה אחת: 10:00:00–10:59:59 AM
מערכת Spanner מקבצת את הנתונים הסטטיסטיים לפי צורת הקריאה. אם התג קיים, FPRINT הוא הגיבוב של התג. אחרת, זה הגיבוב של הערך
READ_COLUMNS.כל שורה מכילה נתונים סטטיסטיים לגבי כל ההרצות של צורת קריאה מסוימת ש-Spanner אוסף לגביה נתונים סטטיסטיים במהלך האינטרוול שצוין.
אם Spanner לא מצליח לאחסן מידע על כל הפעלה של צורת קריאה נפרדת במהלך המרווח, המערכת נותנת עדיפות לצורות קריאה עם השימוש הכי גבוה במעבד במהלך המרווח שצוין.
סכמת טבלאות
| שם העמודה | סוג | תיאור |
|---|---|---|
INTERVAL_END |
TIMESTAMP |
סוף מרווח הזמן שבו התרחשו פעולות הקריאה הכלולות. |
REQUEST_TAG |
STRING |
תג הבקשה האופציונלי לפעולת הקריאה הזו. מידע נוסף על השימוש בתגים זמין במאמר פתרון בעיות באמצעות תגי בקשות. נתונים סטטיסטיים של כמה קריאות עם אותו מחרוזת תג מקובצים בשורה אחת עם התג `REQUEST_TAG` שתואם למחרוזת התג. |
READ_TYPE |
STRING |
מציין אם הקריאה היא PARTITIONED_READ או READ. קריאה עם partitionToken שהתקבל מ-PartitionRead API מיוצגת על ידי סוג הקריאה PARTITIONED_READ, וקריאות עם ממשקי API אחרים לקריאה מיוצגות על ידי READ.
|
READ_COLUMNS |
ARRAY<STRING> |
קבוצת העמודות שנקראו. הם מופיעים בסדר אלפביתי. |
FPRINT |
INT64 |
הגיבוב של הערך REQUEST_TAG אם הוא קיים, אחרת הגיבוב של הערך READ_COLUMNS. |
EXECUTION_COUNT |
INT64 |
מספר הפעמים ש-Spanner ביצע את פעולת הקריאה במהלך המרווח. |
AVG_ROWS |
FLOAT64 |
המספר הממוצע של שורות שהפעולה read החזירה. |
AVG_BYTES |
FLOAT64 |
מספר הבייטים הממוצע של נתונים שהפעולה read החזירה, לא כולל תקורה של קידוד שידור. |
AVG_CPU_SECONDS |
FLOAT64 |
מספר השניות הממוצע של השימוש במעבד בצד השרת של Spanner במהלך ביצוע הקריאה, לא כולל שימוש במעבד לצורך אחזור מראש והוצאות תקורה אחרות. |
AVG_LOCKING_DELAY_SECONDS |
FLOAT64 |
המספר הממוצע של השניות שהמתינו בגלל נעילה. |
AVG_CLIENT_WAIT_SECONDS |
FLOAT64 |
המספר הממוצע של השניות שהוקדשו להמתנה בגלל שהלקוח לא צרך נתונים מהר כמו ש-Spanner יכל ליצור אותם. |
AVG_LEADER_REFRESH_DELAY_SECONDS |
FLOAT64 |
המספר הממוצע של שניות ההמתנה לאישור ממוביל Paxos שכל פעולות הכתיבה נצפו. |
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT |
INT64 |
מספר הפעמים שהקריאה בוצעה כחלק מטרנזקציית קריאה-כתיבה. העמודה הזו עוזרת לכם לקבוע אם אפשר להימנע ממחלוקות על נעילה על ידי העברת הקריאה לעסקה לקריאה בלבד. |
AVG_DISK_IO_COST |
FLOAT64 |
העלות הממוצעת של השאילתה הזו במונחים של Spanner HDD disk load. אפשר להשתמש בערך הזה כדי להשוות בין עלויות קריאה של קלט/פלט של כונן קשיח שמופעלות במסד הנתונים. הפעלת שאילתות על נתונים באחסון HDD כרוכה בתשלום, בהתאם לקיבולת הטעינה של דיסק ה-HDD של המכונה. ערך גבוה יותר מציין שאתם משתמשים בעומס דיסק גבוה יותר של HDD, והשאילתה עשויה לפעול לאט יותר מאשר אם היא הייתה פועלת ב-SSD. בנוסף, אם העומס על דיסק ה-HDD שלכם הוא בקיבולת מלאה, יכול להיות שהביצועים של השאילתות שלכם ייפגעו עוד יותר. אתם יכולים לעקוב אחרי הקיבולת הכוללת של עומס הדיסק של ה-HDD של המכונה כערך באחוזים. כדי להוסיף עוד קיבולת עומס לדיסק HDD, אפשר להוסיף עוד יחידות עיבוד או צמתים למופע. מידע נוסף זמין במאמר שינוי קיבולת המחשוב. כדי לשפר את ביצועי השאילתות, כדאי גם להעביר חלק מהנתונים ל-SSD. לסביבות עבודה שצורכות הרבה קלט/פלט בדיסק, מומלץ לאחסן נתונים שניגשים אליהם לעיתים קרובות באחסון SSD. הגישה לנתונים מכונן SSD לא צורכת את קיבולת הטעינה של דיסק HDD. אפשר לאחסן טבלאות, עמודות או אינדקסים משניים נבחרים באחסון SSD לפי הצורך, ולהשאיר נתונים שניגשים אליהם לעיתים רחוקות באחסון HDD. מידע נוסף זמין במאמר סקירה כללית על אחסון בשכבות. |
שאילתות לדוגמה
בקטע הזה מופיעות כמה דוגמאות להצהרות SQL שמאחזרות נתונים סטטיסטיים של קריאה. אפשר להריץ את הצהרות ה-SQL האלה באמצעות ספריות הלקוח, gcloud spanner או מסוףGoogle Cloud .
ציין את הנתונים הסטטיסטיים הבסיסיים של כל צורה של קריאה בפרק זמן נתון
השאילתה הבאה מחזירה את הנתונים הגולמיים של הצורות הנקראות ביותר במרווחי הזמן האחרונים של דקה אחת.
SELECT fprint,
read_columns,
execution_count,
avg_cpu_seconds,
avg_rows,
avg_bytes,
avg_locking_delay_seconds,
avg_client_wait_seconds
FROM spanner_sys.read_stats_top_minute
ORDER BY interval_end DESC LIMIT 3;
פלט השאילתה
| fprint | read_columns | execution_count | avg_cpu_seconds | avg_rows | avg_bytes | avg_locking_delay_seconds | avg_client_wait_seconds |
|---|---|---|---|---|---|---|---|
125062082139 |
["Singers.id", "Singers.name"] |
8514387 |
0.000661355290396507 |
310.79 |
205 |
8.3232564943763752e-06 |
0 |
151238888745 |
["Singers.singerinfo"] |
3341542 |
6.5992827184280315e-05 |
12784 |
54 |
4.6859741349028595e-07 |
0 |
14105484 |
["Albums.id", "Albums.title"] |
9306619 |
0.00017855774721667873 |
1165.4 |
2964.71875 |
1.4328191393074178e-06 |
0 |
הצג רשימה של צורות הקריאה, מסודרות לפי סה"כ השימוש במעבד, מהגבוה לנמוך
השאילתה הבאה מחזירה את צורות הקריאה עם השימוש הכי גבוה ב-CPU בשעה האחרונה:
SELECT read_columns,
execution_count,
avg_cpu_seconds,
execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.read_stats_top_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.read_stats_top_hour)
ORDER BY total_cpu DESC LIMIT 3;
פלט השאילתה
| read_columns | execution_count | avg_cpu_seconds | total_cpu |
|---|---|---|---|
["Singers.id", "Singers.name"] |
1647 |
0.00023380297430622681 |
0.2579 |
["Albums.id", "Albums.title"] |
720 |
0.00016738889440282034 |
0.221314999999999 |
["Singers.singerinfo""] |
3223 |
0.00037764625882302246 |
0.188053 |
נתונים סטטיסטיים מצטברים
SPANNER_SYS מכיל גם טבלאות לאחסון נתונים סטטיסטיים מצטברים של קריאה שנאספו על ידי Spanner בתקופה מסוימת:
-
SPANNER_SYS.READ_STATS_TOTAL_MINUTE: נתונים סטטיסטיים מצטברים של כל הצורות לקריאה במרווחי זמן של דקה. -
SPANNER_SYS.READ_STATS_TOTAL_10MINUTE: נתונים סטטיסטיים מצטברים של כל צורות הקריאה במרווחי זמן של 10 דקות. -
SPANNER_SYS.READ_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 AM
כל שורה מכילה נתונים סטטיסטיים של כל צורות הקריאה שהופעלו במסד הנתונים במהלך המרווח שצוין, שנאספו יחד. יש רק שורה אחת לכל מרווח זמן.
יכול להיות שהנתונים הסטטיסטיים שנאספו בטבלאות
SPANNER_SYS.READ_STATS_TOTAL_*כוללים צורות קריאה שלא נאספו בטבלאותSPANNER_SYS.READ_STATS_TOP_*ב-Spanner.חלק מהעמודות בטבלאות האלה מוצגות כמדדים ב-Cloud Monitoring. אלה המדדים שמוצגים:
- מספר השורות שהוחזרו
- קריאת מספר הרצות
- זמן קריאה של CPU
- עיכובים בנעילה
- זמן ההמתנה של הלקוח
- השהיה לפני רענון של מנהיג
- מספר הבייטים שהוחזרו
מידע נוסף מופיע במאמר בנושא מדדי Spanner.
סכמת טבלאות
| שם העמודה | סוג | תיאור |
|---|---|---|
INTERVAL_END |
TIMESTAMP |
סוף מרווח הזמן שבו התרחשו ההרצות של צורת הקריאה שכלולה. |
EXECUTION_COUNT |
INT64 |
מספר הפעמים ש-Spanner ביצע את פעולת הקריאה במהלך המרווח. |
AVG_ROWS |
FLOAT64 |
המספר הממוצע של השורות שהוחזרו בקריאות. |
AVG_BYTES |
FLOAT64 |
מספר הבייטים הממוצע של נתונים שהפעולות לקריאה החזירו, לא כולל תקורה של קידוד שידור. |
AVG_CPU_SECONDS |
FLOAT64 |
מספר השניות הממוצע של השימוש במעבד בצד השרת של Spanner במהלך ביצוע הקריאה, לא כולל שימוש במעבד לצורך אחזור מראש והוצאות תקורה אחרות. |
AVG_LOCKING_DELAY_SECONDS |
FLOAT64 |
המספר הממוצע של השניות שהמתינו בגלל נעילה. |
AVG_CLIENT_WAIT_SECONDS |
FLOAT64 |
מספר השניות הממוצע שבהן המשתמשים נאלצו לחכות בגלל הגבלת קצב הבקשות. |
AVG_LEADER_REFRESH_DELAY_SECONDS |
FLOAT64 |
המספר הממוצע של שניות שנדרשות לתיאום הקריאות בין מכונות בתצורות במספר אזורים. |
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT |
INT64 |
מספר הפעמים שפעולות קריאה הופעלו כחלק מטרנזקציות של קריאה וכתיבה. העמודה הזו עוזרת לכם לקבוע אם אפשר להימנע ממחלוקות לגבי נעילה על ידי העברת חלק מהקריאות לעסקאות לקריאה בלבד. |
שאילתות לדוגמה
בקטע הזה מופיעות כמה דוגמאות להצהרות SQL שמחלצות נתונים סטטיסטיים מצטברים של קריאה. אפשר להריץ את הצהרות ה-SQL האלה באמצעות ספריות הלקוח, gcloud spanner או מסוףGoogle Cloud .
איך מוצאים את סה"כ השימוש במעבד בכל צורות הקריאה
השאילתה הבאה מחזירה את מספר שעות השימוש במעבד (CPU) שנצרכו על ידי צורות קריאה בשעה האחרונה:
SELECT (avg_cpu_seconds * execution_count / 60 / 60)
AS total_cpu_hours
FROM spanner_sys.read_stats_total_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.read_stats_total_hour);
פלט השאילתה
| total_cpu_hours |
|---|
0.00026186111111111115 |
חיפוש המספר הכולל של ההפעלות בתקופה נתונה
השאילתה הבאה מחזירה את המספר הכולל של צורות קריאה שהופעלו במרווח הזמן האחרון של דקה אחת:
SELECT interval_end,
execution_count
FROM spanner_sys.read_stats_total_minute
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.read_stats_total_minute);
פלט השאילתה
| interval_end | execution_count |
|---|---|
2020-05-28 11:02:00-07:00 |
12861966 |
שמירת נתונים
לפחות, Spanner שומר נתונים לכל טבלה למשך תקופות הזמן הבאות:
SPANNER_SYS.READ_STATS_TOP_MINUTEandSPANNER_SYS.READ_STATS_TOTAL_MINUTE: מרווחי זמן שכוללים את 6 השעות האחרונות.
SPANNER_SYS.READ_STATS_TOP_10MINUTEו-SPANNER_SYS.READ_STATS_TOTAL_10MINUTE: מרווחי זמן שכוללים את 4 הימים הקודמים.
SPANNER_SYS.READ_STATS_TOP_HOURו-SPANNER_SYS.READ_STATS_TOTAL_HOUR: מרווחי זמן שכוללים את 30 הימים האחרונים.
פתרון בעיות של שימוש גבוה ב-CPU באמצעות נתוני קריאה
סטטיסטיקות הקריאה של Spanner שימושיות במקרים שבהם צריך לבדוק שימוש גבוה במעבד במסד הנתונים של Spanner, או כשמנסים להבין את צורות הקריאה שדורשות הרבה משאבי מעבד במסד הנתונים. בדיקה של צורות קריאה שצורכות כמות משמעותית של משאבי מסד נתונים יכולה לעזור למשתמשי Spanner לצמצם את העלויות התפעוליות ולשפר את זמן האחזור הכללי של המערכת. בשלבים הבאים נראה לכם איך להשתמש בסטטיסטיקות קריאה כדי לבדוק שימוש גבוה במעבד (CPU) במסד הנתונים.
בחירת תקופת זמן לבדיקה
כדי להתחיל את החקירה, מחפשים מועד שבו החלה צריכת CPU גבוהה באפליקציה. לדוגמה, בתרחיש הבא, הבעיה התחילה להתרחש בערך בשעה 17:20 ב-28 במאי 2020.
איסוף נתוני קריאה לתקופת הזמן שנבחרה
אחרי שבחרנו תקופת זמן כדי להתחיל את הבדיקה, נסתכל על הנתונים הסטטיסטיים שנאספו בטבלה READ_STATS_TOTAL_10MINUTE באותו זמן.
התוצאות של השאילתה הזו יכולות לתת לנו רמזים לגבי השינויים בנתונים הסטטיסטיים של השימוש במעבד (CPU) ובקריאה במהלך פרק הזמן הזה. השאילתה הבאה מחזירה את הנתונים הסטטיסטיים המצטברים של פעולות הקריאה מהתאריך 4:30 pm עד התאריך 7:30 pm (כולל).
SELECT
interval_end,
ROUND(avg_cpu_seconds,4) as avg_cpu_seconds,
execution_count,
avg_locking_delay_seconds
FROM SPANNER_SYS.READ_STATS_TOTAL_10MINUTE
WHERE
interval_end >= "2020-05-28T16:30:00"
AND interval_end <= "2020-05-28T19:30:00"
ORDER BY interval_end;
הנתונים הבאים הם דוגמה לתוצאה שמתקבלת מהשאילתה שלנו.
| interval_end | avg_cpu_seconds | execution_count | avg_locking_delay_seconds |
|---|---|---|---|
| 2020-05-28 16:40:00-07:00 | 0.0004 | 11111421 | 8.3232564943763752e-06 |
| 2020-05-28 16:50:00-07:00 | 0.0002 | 8815637 | 8.98734051776406e-05 |
| 2020-05-28 17:00:00-07:00 | 0.0001 | 8260215 | 6.039129247846453e-06 |
| 2020-05-28 17:10:00-07:00 | 0.0001 | 8514387 | 9.0535466616680686e-07 |
| 2020-05-28 17:20:00-07:00 | 0.0006 | 13715466 | 2.6801485272173765e-06 |
| 2020-05-28 17:30:00-07:00 | 0.0007 | 12861966 | 4.6859741349028595e-07 |
| 2020-05-28 17:40:00-07:00 | 0.0007 | 3755954 | 2.7131391918005383e-06 |
| 2020-05-28 17:50:00-07:00 | 0.0006 | 4248137 | 1.4328191393074178e-06 |
| 2020-05-28 18:00:00-07:00 | 0.0006 | 3986198 | 2.6973481999639748e-06 |
| 2020-05-28 18:10:00-07:00 | 0.0006 | 3510249 | 3.7577083563017905e-06 |
| 2020-05-28 18:20:00-07:00 | 0.0004 | 3341542 | 4.0940589703795433e-07 |
| 2020-05-28 18:30:00-07:00 | 0.0002 | 8695147 | 1.9914494947583975e-05 |
| 2020-05-28 18:40:00-07:00 | 0.0003 | 11679702 | 1.8331461539001595e-05 |
| 2020-05-28 18:50:00-07:00 | 0.0003 | 9306619 | 1.2527332321222135e-05 |
| 2020-05-28 19:00:00-07:00 | 0.0002 | 8520508 | 6.2268448078447915e-06 |
| 2020-05-28 19:10:00-07:00 | 0.0006 | 13715466 | 2.6801485272173765e-06 |
| 2020-05-28 19:20:00-07:00 | 0.0005 | 11947323 | 3.3029114639321295e-05 |
| 2020-05-28 19:30:00-07:00 | 0.0002 | 8514387 | 9.0535466616680686e-07 |
כאן אפשר לראות שזמן המעבד הממוצע, avg_cpu_seconds, גבוה יותר במרווחי הזמן שמסומנים. ל-interval_end עם הערך 2020-05-28 19:20:00 יש זמן CPU גבוה יותר, ולכן נבחר את המרווח הזה כדי לבדוק אותו לעומק בשלב הבא.
איך בודקים אילו צורות קריאה גורמות לשימוש גבוה במעבד (CPU)
כדי להתעמק קצת יותר, אנחנו שולחים עכשיו שאילתה לטבלה READ_STATS_TOP_10MINUTE לגבי המרווח שנבחר בשלב הקודם. תוצאות השאילתה הזו יכולות לעזור לזהות אילו צורות קריאה גורמות לשימוש גבוה ב-CPU.
SELECT
read_columns,
ROUND(avg_cpu_seconds,4) as avg_cpu_seconds,
execution_count,
avg_rows
FROM SPANNER_SYS.READ_STATS_TOP_10MINUTE
WHERE
interval_end = "2020-05-28T19:20:00"
ORDER BY avg_cpu_seconds DESC LIMIT 3;
הנתונים הבאים הם דוגמה לתוצאה שמתקבלת מהשאילתה, שכוללת מידע על שלושת הצורות המובילות של קריאה, לפי דירוג של avg_cpu_seconds. שימו לב לשימוש ב-ROUND בשאילתה שלנו כדי להגביל את הפלט של avg_cpu_seconds ל-4 מקומות אחרי הנקודה העשרונית.
| read_columns | avg_cpu_seconds | execution_count | avg_rows |
|---|---|---|---|
[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.shares]1 |
0.4192 | 1182 | 11650.42216582 |
[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.likes,globalTagAffinity.score] |
0.0852 | 4 | 12784 |
[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.ugcCount] |
0.0697 | 1140 | 310.7921052631 |
1 _exists הוא שדה פנימי שמשמש לבדיקה אם שורה מסוימת קיימת או לא.
אחת הסיבות לשימוש גבוה במעבד יכולה להיות שמתחילים להפעיל כמה צורות קריאה בתדירות גבוהה יותר (execution_count). יכול להיות שהמספר הממוצע של השורות שהקריאה החזירה גדל (avg_rows). אם אף אחת מהמאפיינים האלה של צורת הקריאה לא חושפת משהו מעניין, אפשר לבדוק מאפיינים אחרים כמו avg_locking_delay_seconds, avg_client_wait_seconds או avg_bytes.
יישום שיטות מומלצות לצמצום שימוש גבוה ב-CPU
אחרי שמבצעים את השלבים הקודמים, כדאי לבדוק אם יישום של אחת מהשיטות המומלצות הבאות יעזור לפתור את הבעיה.
מספר הפעמים שבהן Spanner ביצע הרצה של קריאות צורות במהלך האינטרוול הוא דוגמה טובה למדד שנדרש לו Baseline כדי להראות אם המדידה סבירה או שהיא מעידה על בעיה. אחרי שתקבעו את רמת הבסיס של המדד, תוכלו לזהות ולבדוק את הסיבה לכל חריגה לא צפויה מההתנהגות הרגילה.
אם השימוש במעבד יחסית קבוע רוב הזמן, אבל פתאום מופיע זינוק שאפשר לקשר אותו לזינוק פתאומי דומה בבקשות של משתמשים או בהתנהגות של האפליקציה, יכול להיות שהמשמעות היא שהכול פועל כצפוי.
אפשר לנסות את השאילתה הבאה כדי למצוא את צורות הקריאה המובילות, מדורגות לפי מספר הפעמים ש-Spanner ביצע הרצה לכל צורת קריאה:
SELECT interval_end, read_columns, execution_count FROM SPANNER_SYS.READ_STATS_TOP_MINUTE ORDER BY execution_count DESC LIMIT 10;אם אתם מחפשים את השהיות הנמוכות ביותר האפשריות בקריאה, במיוחד כשמשתמשים בהגדרות של מופעים מרובי-אזורים, כדאי להשתמש בקריאות לא עדכניות במקום בקריאות חזקות כדי לצמצם או להסיר את הרכיב
AVG_LEADER_REFRESH_DELAY_SECONDSשל השהייה בקריאה.אם אתם מבצעים רק קריאות, ואתם יכולים לבטא את הקריאה באמצעות שיטת קריאה אחת, כדאי להשתמש בשיטת הקריאה הזו. קריאות בודדות לא נועלות, בניגוד לעסקאות קריאה-כתיבה, ולכן כדאי להשתמש בעסקאות לקריאה בלבד במקום בעסקאות קריאה-כתיבה יקרות יותר כשלא כותבים נתונים.
המאמרים הבאים
- מידע נוסף על כלים אחרים לבדיקת תכונות
- מידע נוסף על נתונים אחרים שמאוחסנים ב-Spanner לכל מסד נתונים מופיע בטבלאות של סכימת המידע של מסד הנתונים.
- מידע נוסף על שיטות מומלצות ל-SQL ב-Spanner
- מידע נוסף על בדיקת שימוש גבוה במעבד