איך פועלים דוחות תמונת מצב של הביצועים
דוחות תמונת מצב של הביצועים הם כלי מובנה ב-AlloyDB Omni שמנתח נתוני ביצועים כדי לעזור לכם לזהות את הסיבה לבעיות בביצועים.
בדוחות של תמונת מצב של הביצועים מוצגים מדדים של מסד הנתונים בין שני חותמות זמן בדוח אחד. אפשר להשתמש במידע שבדוח הזה כדי לזהות בעיות בביצועים של המופע של תמונת המצב של הביצועים, כמו ירידה בביצועים של מסד הנתונים בשעות מסוימות ביום או ירידה בביצועים לאורך תקופה מסוימת.
בעזרת דוח תמונת המצב של הביצועים, אפשר להשוות את המדדים לרמת ביצועים בסיסית כדי לקבל תובנות לגבי מדדי הביצועים של עומס העבודה. התובנות האלה יכולות לעזור לכם לבצע אופטימיזציה של ביצועי מסד הנתונים או לפתור בעיות שקשורות אליהם. רמת ביצועים בסיסית היא קבוצה מותאמת אישית של תמונות מצב של מסד נתונים, שמשמשת למדידת הביצועים וההתנהגות הסטנדרטיים של מסד נתונים עבור הגדרה ועומס עבודה ספציפיים.
כברירת מחדל, תמונות מצב של הביצועים ב-AlloyDB Omni מאוחסנות בזיכרון ונמחקות אם המופע מופעל מחדש.
התפקידים הנדרשים
מוודאים שיש לכם את התפקיד pg_monitor.
התפקיד הזה מוענק למשתמשי-על, שיכולים להעניק את ההרשאה pg_monitor למשתמשים אחרים.
לדוגמה, postgres הוא משתמש העל כברירת מחדל. כדי לאפשר ל-my_user להשתמש בכלי ליצירת תמונת מצב של הביצועים כמו שמתואר במסמך הזה, אפשר להריץ את הפקודה GRANT pg_monitor TO my_user בתור postgres.
דוח תמונת מצב של הביצועים
perfsnap הוא שם הסכימה שמכילה פונקציות SQL שמאפשרות למשתמשים לצלם תמונות מצב או ליצור דוחות. הסכימה הזו היא חלק מהתוסף AlloyDB Omni g_stats. משתמשים בתפקיד סופר-אדמין כדי להתקין את דוח תמונת המצב של הביצועים.
כדי להשתמש בממשקי ה-API של perfsnap, מתחברים לכל מסד נתונים שבו המשתמשים רוצים להתקין את התוסף, ויוצרים את התוסף g_stats באמצעות הפקודה הבאה:
CREATE EXTENSION IF NOT EXISTS g_stats;
יצירת תמונת מצב של מדדי המערכת
יוצרים תמונת מצב בתחילת עומס העבודה שרוצים לבדוק ובסופו. המרווח בין שתי התמונות מאפשר לעומס העבודה להתקדם מספיק כדי שהמערכת תוכל לצבור מדדים שמשקפים את עומס העבודה. אחרי שמקבלים מדדים מדוח תמונת המצב של הביצועים, אפשר לצלם עוד כמה תמונות מצב ולחזור על התהליך.
- חיבור לקוח
psqlלמכונת AlloyDB. מריצים את
SELECT perfsnap.snap(). הפלט אמור להיראות כך:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
יצירת snapshot שמכיל נתונים סטטיסטיים של ביצוע SQL
כברירת מחדל, AlloyDB Omni משתמש בתוסף pg_stat_statements כדי לעקוב אחרי הצהרות SQL. כדי לכלול בדוח הביצועים נתונים סטטיסטיים מפורטים על ביצוע SQL, צריך קודם ליצור את התוסף pg_stat_statements במסד הנתונים postgres. חשוב לדעת: איסוף הנתונים הסטטיסטיים האלה מופעל על ידי הדגל pg_stat_statements.track, ולא על ידי יצירת התוסף עצמו.
כדי ליצור תמונת מצב שמכילה גם נתונים סטטיסטיים של ביצוע SQL, פועלים לפי השלבים הבאים:
יוצרים את התוסף
pg_stat_statementsבמסד הנתוניםpostgres.postgres=# CREATE EXTENSION pg_stat_statements;מעכשיו, כשמצלמים תמונת מצב, היא כוללת באופן אוטומטי את הנתונים הסטטיסטיים של SQL מ-
pg_stat_statements.postgres=# select perfsnap.snap(); snap ------ 2 (1 row)
צפייה ברשימת תמונות המצב
- חיבור לקוח
psqlלמכונת AlloyDB. מריצים את
SELECT * FROM perfsnap.g$snapshots. הפלט אמור להיראות כך:postgres=# select * from perfsnap.g$snapshots; snap_id | snap_time | instance_id | node_id | snap_description | snap_type | is_baseline ---------+-------------------------------+-------------+---------+--------------------+-----------+------------- 1 | 2023-11-13 22:13:43.159237+00 | sr-primary | | Manual snapshot | Manual | f 2 | 2023-11-13 22:53:40.49565+00 | sr-primary | | Automatic snapshot | Automatic | f (2 rows)
יצירת דוח תמונת מצב
כדי ליצור דוח שכולל את ההבדל בין תמונות המצב 1 ו-2, למשל, מריצים את הפקודה SELECT perfsnap.report(1,2).
התמונה השנייה בגיבוי דיפרנציאלי לא צריכה להיות מיד אחרי התמונה הראשונה. עם זאת, חשוב לוודא שהתמונה השנייה בגיבוי הדיפרנציאלי צולמה אחרי התמונה הראשונה.
דוח סיכום הביצועים שנוצר אמור להיראות כמו הדוגמה הבאה (גרסה מקוצרת):
דוגמה לדוח תמונת מצב של ביצועים
psql -d postgres -U alloydbsuperuser
select perfsnap.report(22, 23);
report
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PGSNAP DB Report for:
Snapshot details
--------------------------------------
Host i841-sr-primary-2a34f46e-06bc
Release 14.12
Startup Time 2024-10-08 03:23:15+00
Snap Id Snap Time
------------ ---------- ------------------------
Begin Snap: 22 24.10.2024 04:33:56 (UTC) Automatic snapshot
End Snap: 23 25.10.2024 04:38:56 (UTC) Automatic snapshot
Elapsed: 1 day 00:04:59.979321
Database Cache sizes
~~~~~~~~~~~~~
Shared Buffers: 31 GB Block Size: 8192
Effective Cache Size: 25 GB WAL Buffers: 16384
Host CPU
~~~~~~~~~~
%User %Nice %System %Idle %WIO %IRQ %SIRQ %Steal %Guest
------- ------- ------- ------- ------- ------- ------- ------- -------
1.07 0.22 0.91 97.40 0.09 0.00 0.31 0.00 0.00
Host Memory
~~~~~~~~~~~~
Total Memory: 63 GB
Available Memory: 11 GB
Free Memory: 726 MB
Buffers Memory: 3706 MB
Load profile (in bytes)
~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
------------ ---------------
Redo size: 63083.64 4489.93
Logical reads: 1961.21 139.59
...
Response Time Profile (in s)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CPU time: 5399 ( 0.39%)
Wait time: 1386906 ( 99.61%)
Total time: 1392306
Backend Processes Wait Class Breakdown (in s)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IO 119.300 ( 98.91%)
LWLock 1.305 ( 1.08%)
IPC .010 ( 0.01%)
Lock .000 ( 0.00%)
Backend Processes Wait Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits Time (us) Avg (us)
-------------------------------------- ------------- ------------- -------------- -------------
CPU 1995948632
WALInsert LWLock 1 6656 6656
Vacuum Information
~~~~~~~~~~~~~~~~~~~
Num Analyze operations: 1976
Num Vacuum operations: 3435
Per Database Information
~~~~~~~~~~~~~~~~~~~~~~~~~
Name Commits Rollbacks BlkRds Blkhits TempFiles TempBytes
------------------------- ------------- ------------- ------------- ------------- ------------- -------------
bench 27939 0 0 7823038 0 0 bytes
postgres 39792 0 7 11089243 0 0 bytes
Per Database DML & DQL Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Tuples returned Tuples fetched Tuples inserted Tuples updated Tuples deleted Index splits Index Only heap fetches HOT updates
------------------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ------------------------- ----------------
bench 16119481 4843262 0 0 0 0 16 0
postgres 25415473 6327188 0 10 0 0 0 8
Per Database Conflict Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Lock Timeout Old Snapshot Buffer Pins Deadlock
------------------------- ------------- ------------- ------------- -------------
bench 0 0 0 0
postgres 0 0 0 0
Per Database Vacuum Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Frozen XID % Consumed Aggregate Vacuum Gap
------------------------- ------------- ------------- --------------------
bench 179460916 9.00% 20539084
postgres 179339239 9.00% 20660761
Per Database Sizing Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Conn.
Name Collation Limit Tablespace DB Size Growth
-------------------- ------------- ------- -------------------- ---------- ----------
bench C.UTF-8 -1 pg_default 80 GB 0 bytes
postgres C.UTF-8 -1 pg_default 135 MB 0 bytes
Backend Wait Event Histogram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits <= 1us <= 2us <= 4us <= 8us <= 16us <= 32us <= 64us <= 128us <= 256us <= 512us
-------------------------------------- ------------- ----------- --------- --------- --------- --------- --------- --------- --------- --------- --------- --------
WALInsert LWLock 1 0 0 0 0 0 0 0 0 0 0
Background Wait Event Histogram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits <= 1us <= 2us <= 4us <= 8us <= 16us <= 32us <= 64us <= 128us <= 256us <= 512us
-------------------------------------- ------------- ----------- --------- --------- --------- --------- --------- --------- --------- --------- --------- --------
WALInsert LWLock 542 107 174 39 113 93 8 1 1 0 1
Write Ahead Log (WAL) Statistics
--------------------------------
Records Full Page Images Bytes Buffers Full Write Sync Write Time Sync Time
----------- ---------------- ----------- ------------ ----------- ----------- ----------- -----------
2936305 100 805989345 0 0 0 0 0
Summary Stats (across all databases)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Value
-------------------------------- ----------------------------------
Buffers evicted 0
Commits 1216693
...
Parameter Settings
~~~~~~~~~~~~~~~~~~~
Parameter Value
--------------------------------- --------------------------------------------------------------
DateStyle ISO, MDY
TimeZone UTC
autovacuum on
work_mem 4096
Columnar Engine available size Columnar Engine configured size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
14959MB 19293MB
Columnar Engine Statistics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
name count
---------------------------------------------------------- ------------
CU Populations/Refreshes 13197
CU Auto Refreshes 10975
...
Columnar Engine Ultra-fast Cache Statistics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ultra-fast Cache Size (MB): 19200
Ultra-fast Cache Used Size (MB): 0
Ultra-fast Cache Block Size (MB): 80
----------------------------------------------------
Created by G_STATS v1.0.100
----------------------------------------------------
(rows)
מידע על שדות הדוחות והמלצות לאופטימיזציה של הביצועים זמין במאמר המלצות לאופטימיזציה של ביצועי מסד הנתונים. מידע נוסף על אירועי המתנה בדוחות תמונת מצב של ביצועים זמין במאמר הפניה לדוח תמונת מצב של ביצועי מסד הנתונים.
מחיקת תמונת מצב
כדי למחוק תמונות מצב שמהוות חלק מנקודת בסיס קיימת, צריך לנקות את נקודת הבסיס .
כדי למחוק תמונת מצב, מריצים את הפקודה SELECT perfsnap.delete(n). אחרי שמוחקים תמונת מצב, אי אפשר לשחזר אותה.
סימון תמונת מצב כנקודת השוואה לביצועים
כדי לסמן את כל תמונות המצב עם מזהים בין 1 ל-3, למשל, כנקודת בסיס לביצועי המערכת, מריצים את הפקודה SELECT perfsnap.make_baseline(1, 3).
מחיקת נתוני הבסיס של הביצועים
כדי לנקות את כל נקודות הבסיס עם מזהים בין 1 ל-3, למשל, מריצים את הפקודה
SELECT perfsnap.clear_baseline(1, 3).
אופטימיזציה של ביצועי מסד הנתונים באמצעות תוצאות דוח תמונת מצב
כדי לשפר את הביצועים של מסד נתונים ב-AlloyDB, פועלים לפי השלבים הבאים:
- כדאי ליצור תמונות מצב של קו הבסיס כשהמסד נתונים לא פעיל או כשהעומס הממוצע עליו נמוך.
- מפעילים את עומס העבודה או את השאילתה שרוצים לשפר את הביצועים שלהם.
- כשעומס העבודה או השאילתה מגיעים לשיא השימוש במשאבים, יוצרים עוד קבוצה של תמונות מצב. מומלץ להשתמש באותו מרווח זמן בשני הדוחות.
- משווים בין הדוחות שיצרתם עם שני סטים של תמונות מצב ומזהים שינויים שיכולים לשפר את הביצועים. מידע נוסף על המלצות לשיפור הביצועים זמין במאמר המלצות לאופטימיזציה של ביצועי מסד הנתונים.
המלצות לאופטימיזציה של ביצועי מסד הנתונים
בטבלה הבאה מפורטים הקטעים בדוח תמונת מצב של הביצועים והשיפורים המומלצים לכל קטע בדוח. למידע נוסף על הקטעים בדוח תמונת מצב של הביצועים ועל אירועי המתנה, אפשר לעיין במאמר הפניה לדוח תמונת מצב של ביצועי מסד הנתונים.
| קטע | השדה בדוח | תיאור השדה בדוח | המלצות לאופטימיזציה |
|---|---|---|---|
| פרטים על תמונת המצב | פרטי תמונת המצב | הפלט כולל את המארח, את גרסת ההפצה שתואמת ל-PostgreSQL ואת השעה שבה המכונה הופעלה. | לא רלוונטי |
| מזהה תמונת המצב | רשימה של המזהה והנקודה בזמן של התמונות שמשמשות ליצירת הדוח הזה. | לא רלוונטי | |
| תובנות לגבי המערכת | מעבד המארח | פרטים על ניצול המעבד של המארח. | אם השימוש במעבד גבוה מ-80%, מומלץ לעבור למערכת עם יותר מעבדים וירטואליים. |
| זיכרון המארח | פרטים על ניצול הזיכרון של המארח. | אם הזיכרון הפנוי קטן מ-15%, מומלץ להגדיל את גודל הזיכרון לערך הבא שזמין. | |
| טעינת פרופיל | רשימת מוניטורים שעוזרים לאפיין את עומס העבודה מבחינת יצירת רישום מקדים (WAL), דרישות קלט/פלט וניהול חיבורים. | אם הקריאות הפיזיות גבוהות מהקריאות הלוגיות, כדאי לשקול הגדלה של הקיבולת לגודל הבא שזמין כדי לתמוך בשמירת נתונים במטמון. | |
| פירוט של זמן התגובה וסוג ההמתנה | פירוט של הזמן שבו תהליכי Postgres השקיעו במהלך ההרצה של עומס העבודה. | לדוגמה, אם התהליכים נמצאים בעיקר במצב המתנה, כדאי להתמקד בקיצור זמן ההמתנה של קלט/פלט. | |
| מידע על עומס העבודה של מסד הנתונים | מידע על עומס העבודה של כל מסד נתונים | מדדים מרכזיים לכל מסד נתונים, כולל פעולות אישור (commit), ביטול (rollback), יחס ההתאמה (hit ratio) ומידע על טבלאות זמניות ופעולות מיון. | אם יש הרבה חזרה לגרסה קודמת, כדאי לאבחן את האפליקציה. |
| מידע על DML ו-DQL לכל מסד נתונים | מונים של פעולות שאילתה. | הגדרת עומס העבודה כקריאה אינטנסיבית או ככתיבה אינטנסיבית. | |
| מידע על התנגשות במסד הנתונים | מדדים לבעיות נפוצות באפליקציות ובמסדי נתונים. | אם יש מצב של חסימה הדדית, מאתרים את הבעיות באפליקציה. | |
| מסד נתונים מידע על גודל |
השדה הזה מראה בכמה גדל מסד הנתונים במהלך המרווח בין שתי תמונות מצב. השדה הזה מראה גם אם הוגדרו מגבלות על החיבור למסד הנתונים. | אם גודל מסד הנתונים גדול מדי, צריך לאתר את הבעיות באפליקציה. | |
| מידע על שואבי אבק | מידע על שואבי אבק | פרטים על קלט/פלט ועל מוני פעולות של שואב אבק. | כברירת מחדל, מתבצעת ב-AlloyDB פעולת vacuuming אדפטיבית. אתם יכולים לשנות חלק מהגדרות ה-vacuuming כך שיתאימו לעומס העבודה שלכם. לדוגמה, אפשר להפחית את פעולות ה-vacuuming אם יותר מדי קלט/פלט מושקע בבקשות האלה. |
| מידע על שאיבת אבק לכל מסד נתונים | מוצג המידע הבא:
|
אם הגיל של השדה Frozen XID ישן מדי, או אם אחוז העסקאות שבוצעו קרוב ל-90%, כדאי לבצע דחיסה. אם הפער המצטבר של ה-vacuum קטן, זה מצביע על כך ש-Postgres יבצע vacuum כדי למנוע גלישה. | |
| פרטי המתנה של תהליכים במסד הנתונים | מידע מפורט על תהליכי רקע ועל ה-Backend |
פרטים על כל ההמתנות לפי תהליכי קצה עורפי ותהליכי רקע במרווח הדוחות. המידע כולל את זמן ההמתנה המצטבר, זמן השימוש במעבד והזמן הממוצע לכל סוג המתנה. | כדי לקצר את זמן ההמתנה ב-WALWrite, למשל, מגדילים את מספר ה-wal_buffers שזמינים למסד הנתונים. |
| היסטוגרמה מפורטת של אירועי המתנה ברקע ובקצה העורפי | המדד הזה נכלל בדוח 'תמונת מצב של הביצועים' כברירת מחדל. הרשימה מכילה את ההיסטוגרמה של אירועי ההמתנה לתהליכי קצה עורפי ורקע, שמחולקים ל-32 קטגוריות, מ-1 מיקרו-שנייה ועד יותר מ-16 שניות. | מחפשים את אירועי ההמתנה ובודקים אם יש יותר מדי אירועי המתנה בדלי הגדול יותר של זמן ההמתנה. יכול להיות שיש בעיה עם יותר מדי אירועי המתנה או עם כל זמן המתנה שנצרך. | |
| נתונים סטטיסטיים שונים | נתונים סטטיסטיים של Write Ahead Log (WAL) | סיכום של נתונים סטטיסטיים של WAL. | אם זמן הסנכרון ארוך מדי, אפשר לשנות את ההגדרות של מסד הנתונים הרלוונטי (GUC) כדי לשפר את עומס העבודה. GUC הוא תת-מערכת של PostgreSQL שמטפלת בהגדרת השרת. |
| סיכום נתונים סטטיסטיים (בכל מסדי הנתונים) | סיכום של כל הפעולות במסד הנתונים שמתרחשות במהלך מרווח הזמן של התמונה. | לא רלוונטי | |
| הגדרות פרמטרים | הגדרות פרמטרים | פרמטרים מרכזיים להגדרת Postgres בזמן הצילום של התמונה. | בודקים את הגדרות הפרמטר GUC (הדגלים של מסד הנתונים Postgres) כדי לראות אם הערכים לא צפויים או לא מומלצים. |
| נתונים סטטיסטיים של הרצת SQL | מידע על כל שאילתה (50 המובילות) לפי סך הזמן שחלף | רשימה של 50 השאילתות המובילות שחלף הכי הרבה זמן עד להשלמתן במהלך שני הצילומים, וגם מספר ההפעלה הכולל שלהן, עם פירוט לפי המשתמש ומסד הנתונים שבהם השאילתה הונפקה.Elapsed time = Difference of total_exec_time in pg_stat_statements at the two snapshot time |
בקטע הזה אפשר לזהות את השאילתה הכבדה ביותר שצורכת את רוב זמן המערכת. |
| מידע על כל שאילתה (50 המובילות) לפי קריאת קלט/פלט | רשימה של 50 השאילתות המובילות שבהן בוזבז הכי הרבה זמן קריאה של קלט/פלט במהלך שני הצילומים, וגם מספר ההרצות, הפגיעות במאגר, קריאות הבלוקים, גם בסך הכול וגם בממוצע.ReadIO = blk_read_time + temp_blk_read_time מצטבר במהלך שני הצילומיםBuffer Hits = shared_blks_hit + local_blks_hit מצטבר במהלך שני הצילומיםBuffer Reads = shared_blks_read + local_blks_read מצטבר במהלך שני הצילומיםהמעקב אחרי השדות האלה מופעל כברירת מחדל ב-AlloyDB Cloud כי הערך של track_io_timing מוגדר. |
בקטע הזה מוסבר איך לזהות שאילתות שדורשות הרבה פעולות קלט/פלט, במיוחד אם הן צריכות לקרוא נתונים מהדיסקים לעיתים קרובות. | |
| מידע על כל שאילתה (50 המובילות) לפי סטיית תקן של הזמן שחלף | תציג רשימה של 50 השאילתות עם סטיית התקן הגבוהה ביותר של הזמן שחלף, ותפרט את סטיות התקן שחושבו גם בתחילת תקופת הצילום וגם בסופה. הערך כאן מתייחס ל- stddev_exec_time מ-pg_stat_statements |
אם השאילתה כוללת סטיית תקן גבוהה, זה אומר שזמן הביצוע של השאילתה משתנה מאוד, וכדאי לבדוק את קלט/פלט. |
מגבלות
כדי למנוע ניפוח של נפח האחסון, אפשר ליצור באופן ידני עד 2,500 תמונות מצב במופע אחד. ניפוח נפח האחסון מוודא שתמונות המצב לא תופסות יותר מדי מקום אחסון במסד הנתונים.
אם מספר תמונות המצב חורג מהמגבלה, מערכת AlloyDB Omni מוחקת את כל תמונות המצב הידניות שנוצרו לפני יותר מ-90 ימים. כדי לא לחרוג ממגבלת תמונות המצב, צריך למחוק תמונות מצב מיותרות לפני שיוצרים תמונת מצב חדשה.
AlloyDB Omni מנקה מעת לעת תמונות מצב ידניות שנוצרו לפני יותר מ-90 ימים.