איך פועלים דוחות של תמונת מצב של הביצועים
דוחות של תמונת מצב של ביצועים הם כלי מובנה ב-AlloyDB Omni שמתעד ומנתח נתוני ביצועים כדי לעזור לכם לזהות את הגורם לבעיות בביצועים.
בדוחות של תמונת מצב של ביצועים מוצגים מדדים של מסד נתונים בין שתי חותמות זמן בדוח אחד. אפשר להשתמש במידע שבדוח תמונת מצב של הביצועים כדי לזהות בעיות בביצועים של המופע של דוח תמונת המצב של הביצועים, כמו ירידה בביצועים של מסד הנתונים בשעות מסוימות ביום או ירידה בביצועים במהלך תקופה מסוימת.
בעזרת הדוח 'תמונת מצב של הביצועים' אפשר להשוות את המדדים לנקודת בסיס של הביצועים כדי לקבל תובנות לגבי מדדי הביצועים של עומס העבודה. התובנות האלה יכולות לעזור לכם לייעל את הביצועים של מסד הנתונים או לפתור בעיות שקשורות אליהם. קו בסיס הוא קבוצה מותאמת אישית של תמונות מצב של מסד נתונים, שמשמשות למדידת הביצועים וההתנהגות הרגילים של מסד נתונים בהגדרות ובעומס עבודה ספציפיים.
כברירת מחדל, תמונות מצב של הביצועים ב-AlloyDB Omni מאוחסנות בזיכרון ונמחקות אם המופע מופעל מחדש.
התפקידים הנדרשים
חשוב לוודא שיש לכם את התפקיד pg_monitor.
התפקיד הזה מוענק למשתמשי-על, שיכולים להעניק pg_monitor למשתמשים אחרים.
לדוגמה, postgres הוא משתמש-העל כברירת מחדל. אתם יכולים להריץ את GRANT pg_monitor TO my_user בתור postgres כדי לאפשר ל-my_user להשתמש בכלי ליצירת קובץ snapshot של הביצועים, כמו שמתואר במסמך הזה.
התקנת דוח תמונת מצב של ביצועים
perfsnap הוא שם הסכימה שמכילה פונקציות SQL שמאפשרות למשתמשים ליצור תמונות מצב או דוחות. הסכימה הזו היא חלק מהתוסף g_stats של AlloyDB Omni. משתמשים בתפקיד של משתמש על כדי להתקין את הדוח 'תמונת מצב של ביצועים'.
כדי להשתמש בממשקי ה-API של perfsnap, מתחברים לכל מסד נתונים שבו המשתמשים רוצים להתקין את התוסף, ויוצרים את התוסף g_stats באמצעות הפקודה הבאה:
CREATE EXTENSION IF NOT EXISTS g_stats;
יצירת תמונת מצב של מדדי המערכת
יוצרים קובץ snapshot בתחילת עומס העבודה שרוצים לבדוק ובסופו. מרווח הזמן בין שתי התמונות מאפשר לעומס העבודה להתקדם מספיק כדי שהמערכת תוכל לצבור מדדים שמשקפים את עומס העבודה. אחרי שמקבלים מדדים מדוח תמונת המצב של הביצועים, אפשר ליצור עוד קבוצה של תמונות מצב ולחזור על התהליך.
- איך מחברים לקוח
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).
התמונה השנייה בגיבוי דיפרנציאלי לא חייבת להיות מיד אחרי התמונה הראשונה. עם זאת, חשוב לוודא שאתם יוצרים את קובץ ה-snapshot השני בהפרש אחרי קובץ ה-snapshot הראשון.
דוח סיכום הביצועים שנוצר אמור להיראות כמו הדוגמה הבאה (גרסה מקוצרת):
דוגמה לדוח תמונת מצב של הביצועים
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)
מידע על שדות הדוחות והמלצות לאופטימיזציה של הביצועים זמין במאמר המלצות לאופטימיזציה של ביצועי מסד הנתונים. מידע נוסף על אירועי המתנה בדוחות תמונת מצב של ביצועים זמין במאמר הפניה לדוח תמונת מצב של ביצועי מסד הנתונים.
מחיקת תמונת מצב
כדי למחוק קובצי snapshot שהם חלק מקו בסיס קיים, צריך קודם לנקות את קו הבסיס .
כדי למחוק תמונת מצב, מריצים את הפקודה SELECT perfsnap.delete(n). אחרי שמוחקים תמונת מצב, אי אפשר לשחזר אותה.
סימון תמונת מצב כקו בסיס לביצועים
כדי לסמן את כל תמונות המצב עם מזהים בין 1 ל-3, למשל, כערך בסיס לביצועי המערכת, מריצים את הפקודה SELECT perfsnap.make_baseline(1, 3).
ניקוי ערכי הבסיס של הביצועים
כדי לנקות את כל נקודות הבסיס עם מזהים בין 1 ל-3, למשל, מריצים את הפקודה
SELECT perfsnap.clear_baseline(1, 3).
אופטימיזציה של ביצועי מסד הנתונים באמצעות תוצאות של דוח תמונת מצב
כדי לשפר את הביצועים של מסד הנתונים ב-AlloyDB:
- כדאי ליצור תמונות מצב של בסיס נתונים כשהוא לא פעיל או כשהוא חווה עומס ממוצע.
- מפעילים את עומס העבודה או את השאילתה שרוצים לשפר את הביצועים שלהם.
- כשהעומס או השאילתה מגיעים לשיא השימוש במשאבים, יוצרים קבוצה נוספת של קובצי snapshot. מומלץ להשתמש באותו מרווח זמן בשני הדוחות.
- משווים בין הדוחות שיצרתם עם שתי קבוצות של תמונות המצב ומזהים שינויים שיכולים לשפר את הביצועים. מידע נוסף על המלצות לשיפור הביצועים זמין במאמר המלצות לאופטימיזציה של ביצועי מסד הנתונים.
המלצות לאופטימיזציה של ביצועי מסד הנתונים
בטבלה הבאה מפורטים הקטעים בדוח 'תמונת מצב של ביצועים' והשיפורים המומלצים לכל קטע בדוח. מידע נוסף על הקטעים בדוח תמונת המצב של הביצועים ועל אירועי ההמתנה זמין במאמר הפניה לדוח תמונת המצב של ביצועי מסד הנתונים.
| קטע | השדה בדוח | תיאור השדות בדוח | המלצות לאופטימיזציה |
|---|---|---|---|
| פרטים על תמונת המצב | פרטי תמונת המצב | הפלט כולל את המארח, את גרסת ההפצה שתואמת ל-PostgreSQL ואת השעה שבה המכונה הופעלה. | לא רלוונטי |
| מזהה תמונת המצב | מציג את המזהה ואת נקודת הזמן של תמונות המצב ששימשו ליצירת הדוח הזה. | לא רלוונטי | |
| תובנות לגבי המערכת | מעבד (CPU) מארח | פרטים על ניצול המעבד (CPU) של המארח. | אם ניצול המעבד (CPU) גדול מ-80%, מומלץ לעבור למערכת עם יותר מעבדי vCPU. |
| זיכרון המארח | פרטים על ניצול הזיכרון של המארח. | אם הזיכרון הפנוי קטן מ-15%, מומלץ להרחיב אנכית לגודל הזמין הבא. | |
| טעינת פרופיל | המדדים האלה עוזרים לכם להבין את עומס העבודה מבחינת יצירת WAL (רישום מראש), דרישות קלט/פלט וניהול חיבורים. | אם מספר הקריאות הפיזיות גבוה ממספר הקריאות הלוגיות, כדאי להרחיב אנכית לגודל הבא שזמין כדי לתמוך בשמירה גדולה יותר של נתונים במטמון. | |
| פירוט של זמן התגובה וסוג ההמתנה | פירוט של הזמן שבו תהליכי Postgres השקיעו במהלך ההרצה של עומס העבודה. | לדוגמה, אם התהליכים נמצאים בעיקר במצב המתנה, כדאי להתמקד בקיצור זמן ההמתנה לקלט/פלט. | |
| מידע על עומס העבודה במסד הנתונים | מידע על עומס העבודה בכל מסד נתונים | מדדים מרכזיים לכל מסד נתונים, כולל פעולות אישור, ביטול, יחס פגיעות ומידע על טבלאות זמניות ופעולות מיון. | אם יש הרבה חזרות לגרסה קודמת, כדאי לבדוק את האפליקציה. |
| מידע על DML ו-DQL לכל מסד נתונים | מונים לפעולות של שאילתות. | הגדירו את עומס העבודה כעומס קריאה או כעומס כתיבה. | |
| מידע על התנגשויות במסד הנתונים | מדדים לבעיות נפוצות באפליקציות ובמסדי נתונים. | אם יש מצב של קיפאון, מאתרים את הבעיות באפליקציה. | |
| מידע על גודל מסד הנתונים |
כאן מוצגת הצמיחה של מסד הנתונים במהלך המרווח בין שתי תמונות מצב. בשדה הזה אפשר גם לראות אם הוגדרו מגבלות חיבור למסד הנתונים. | אם מסד הנתונים גדל יותר מדי, צריך לאתר את הבעיות באפליקציה. | |
| מידע על שאיבת אבק | מידע על שאיבת אבק | פרטים של קלט/פלט ומונים לפעולות ואקום. | כברירת מחדל, AlloyDB מבצעת פעולות VACUUM מותאמות. אתם יכולים לשנות חלק מהגדרות ה-VACUUM כך שיתאימו לעומס העבודה שלכם. לדוגמה, אם יותר מדי פעולות קלט/פלט מושקעות בבקשות האלה, כדאי לצמצם את פעולות הריקון. |
| מידע על שאיבה לכל מסד נתונים | המידע הבא מוצג:
|
אם הגיל של השדה Frozen XID ישן מדי, או אם אחוז הטרנזקציות שנוצלו קרוב ל-90%, כדאי לשקול לבצע vacuuming. אם הפער הכולל של פעולת ה-vacuum קטן, זה מצביע על כך ש-Postgres יבצע פעולת vacuum כדי למנוע גלישה. | |
| פרטי ההמתנה של תהליכי מסד הנתונים | מידע מפורט על תהליכי Backend ועל תהליכים ברקע |
פרטים על כל ההמתנות של תהליכי הקצה העורפי והתהליכים שפועלים ברקע במרווח הזמן של הדוח. המידע כולל את זמן ההמתנה המצטבר, זמן השימוש במעבד והזמן הממוצע לכל סוג המתנה. | לדוגמה, כדי להפחית את זמן ההמתנה ב-WALWrite, מגדילים את מספר ה-wal_buffers שזמינים למסד הנתונים. |
| היסטוגרמה מפורטת של אירועי המתנה ברקע וב-backend | הוא נכלל בדוח תמונת המצב של הביצועים כברירת מחדל. הרשימה מכילה את ההיסטוגרמה של אירועי ההמתנה לתהליכים בקצה העורפי וברקע, שמחולקים ל-32 קטגוריות, ממיקרו-שנייה אחת ועד ליותר מ-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 קובצי snapshot במכונה אחת. ניפוח נפח האחסון מבטיח שתמונות המצב לא יתפסו יותר מדי נפח אחסון במסד הנתונים.
אם מספר התמונות המיידיות חורג מהמגבלה, AlloyDB Omni מוחק את כל התמונות המיידיות הידניות שנוצרו לפני יותר מ-90 ימים. כדי לא לחרוג ממגבלת תמונות המצב, צריך למחוק תמונות מצב מיותרות לפני שיוצרים תמונת מצב חדשה.
AlloyDB Omni מנקה מעת לעת תמונות מצב ידניות שנוצרו לפני יותר מ-90 ימים.