במאמר הזה נסביר איך ליצור באופן ידני דוחות של תמונת מצב של הביצועים, שמאפשרים להשוות בין תמונות מצב של מדדי המערכת בשתי נקודות זמן שונות. אתם יכולים להשתמש בדוחות של תמונת מצב של הביצועים כדי לזהות בעיות בביצועים של מסד נתונים ב-AlloyDB ל-PostgreSQL ולצמצם אותן. המדדים של המערכת שמתועדים בכל תמונת מצב כוללים את השימוש במעבד וירטואלי (vCPU), השימוש בזיכרון, קלט/פלט (I/O) בדיסק, ספירת העסקאות ואירועי המתנה.
תמונות מצב אוטומטיות וידניות
AlloyDB תומך בצילומים הבאים:
תמונות מצב אוטומטיות: כברירת מחדל, AlloyDB מצלם תמונות מצב באופן אוטומטי פעם ביום ושומר אותן למשך 7 ימים. תמונות מצב אוטומטיות עוזרות ליצור דוחות עם רמת פירוט של עומס העבודה ברמה היומית. אי אפשר לשנות את תקופת השמירה של תמונת מצב אוטומטית, אבל אפשר להגדיר את התדירות.
תמונות מצב ידניות: אתם יכולים לצלם תמונות מצב וליצור דוחות באופן ידני.
אתם יכולים לשלב בין תמונות מצב אוטומטיות וידניות כדי ליצור דוחות ביצועים. לדוגמה, אתם יכולים ליצור דוח תמונת מצב של הביצועים שמשווה בין תמונת מצב שנוצרה באופן ידני לבין תמונת מצב שנוצרה באופן אוטומטי.
במאמר הזה מוסבר איך ליצור באופן ידני דוחות של תמונת מצב של הביצועים.
איך פועלים דוחות תמונת מצב של הביצועים
דוחות תמונת מצב של הביצועים הם כלי מובנה ב-AlloyDB שמתעד ומנתח נתוני ביצועים כדי לעזור לכם לזהות את הגורם לבעיות בביצועים. הכלי הזה משלים תכונות אחרות של AlloyDB לצפייה, כמו תובנות לגבי מערכות, תובנות לגבי שאילתות וMetrics Explorer, שמספק מדדים בזמן אמת לגבי המופע.
בדוחות של תמונת מצב של ביצועים מוצגים מדדים של מסד נתונים בין שני חותמות זמן בדוח אחד. אתם יכולים להשתמש במידע שבדוח תמונת מצב של הביצועים כדי לזהות בעיות בביצועים של המופע של דוח תמונת המצב של הביצועים, כמו ירידה בביצועים של מסד הנתונים בשעות מסוימות ביום או ירידה בביצועים לאורך תקופת זמן מסוימת. כשמשתמשים בדוח הזה בצומת של מאגר לקריאה, הוא עוזר לזהות אם השהיית הרפליקציה נגרמת בגלל מגבלות של משאבי המערכת, כמו מעבד (CPU) או זיכרון, או בגלל התנגשויות ספציפיות בשאילתות, כמו נעילות של מאגרי נתונים זמניים.
בעזרת דוח תמונת המצב של הביצועים, אפשר להשוות את המדדים לנקודת בסיס של ביצועים כדי לקבל תובנות לגבי מדדי הביצועים של עומס העבודה. התובנות האלה יכולות לעזור לכם לבצע אופטימיזציה של ביצועי מסד הנתונים או לפתור בעיות שקשורות אליהם. נתוני בסיס הם קבוצה מותאמת אישית של תמונות מצב של מסד נתונים שמודדות את הביצועים וההתנהגות הרגילים של מסד נתונים עבור הגדרה ועומס עבודה ספציפיים.
מידע על אירועי המתנה בדוח תמונת המצב של הביצועים זמין במאמר הפניה לדוח תמונת המצב של ביצועי מסד הנתונים.
התפקידים הנדרשים
מוודאים שיש לכם את התפקיד alloydbsuperuser.
כברירת מחדל, AlloyDB מעניק את התפקיד pg_monitor ל-alloydbsuperuser. מידע נוסף מופיע במאמר בנושא תפקידים מוגדרים מראש ב-PostgreSQL.
אם אתם מעדיפים להשתמש בתפקידים אחרים שהגדרתם בעצמכם, אתם צריכים להריץ את הפקודה GRANT pg_monitor TO my_user בתור alloydbsuperuser קודם. למידע נוסף, אפשר לקרוא את המאמר עדכון חשבון בניהול הזהויות והרשאות הגישה (IAM) עם התפקיד המתאים.
יצירת תמונות מצב
תמונות מצב של הביצועים הן כלי יעיל להבנה ולאופטימיזציה של ביצועי מסד הנתונים. הם מתעדים מדדי מערכת מרכזיים בנקודת זמן ספציפית, ומאפשרים לכם להשוות את הביצועים של מסד הנתונים בין שתי נקודות זמן. AlloyDB תומך בשני סוגים של תמונות מצב:
- תמונות מצב של מדדי המערכת: תמונות המצב האלה מתעדות מדדי מערכת מרכזיים כמו שימוש ב-vCPU, שימוש בזיכרון וקלט/פלט (I/O) בדיסק.
- תמונות מצב של מדדי מערכת וסטטיסטיקות של ביצוע SQL: תמונות המצב האלה מכילות את כל מדדי המערכת מתמונת מצב רגילה, בנוסף לסטטיסטיקות מפורטות של ביצוע SQL מהתוסף
pg_stat_statements.
כך תוכלו לבחור את רמת הפירוט שאתם צריכים לניתוח.
יצירת תמונת מצב של מדדי המערכת
יוצרים קובץ snapshot בתחילת עומס העבודה שמעניין אתכם ובסופו. מרווח הזמן בין שני הצילומים צריך להיות ארוך מספיק כדי לכלול מדגם מייצג של עומס העבודה.
כדי לשפר את הביצועים של מסד נתונים ב-AlloyDB, פועלים לפי השלבים הבאים:
- יוצרים תמונות מצב של קו בסיס כשהמסד נתונים לא פעיל או כשהעומס הממוצע עליו נמוך.
- חיבור לקוח
psqlלמופע AlloyDB במקרה של צומת של מאגר לקריאה, צריך להתחבר ישירות לכתובת ה-IP שלו. מידע נוסף זמין במאמר בנושא אחזור רשימת כתובות ה-IP של צומתי Read Pool. מריצים את
SELECT perfsnap.snap(). הפלט אמור להיראות כך:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)הפלט של הפקודה הזו מחזיר את מזהה תמונת המצב (
snap_id), שהוא1בדוגמה הזו. תצטרכו את המזהה הזה כדי ליצור בהמשך דוח סיכום ביצועים. הערך שלsnap_idבסביבה שלכם כנראה שונה.משווים בין הדוחות שיצרתם עם שני סטים של תמונות מצב ומזהים שינויים שיכולים לשפר את הביצועים. מידע נוסף על המלצות לשיפור הביצועים זמין במאמר המלצות לאופטימיזציה של ביצועי מסד הנתונים.
אחרי שמקבלים את המדדים מדוח תמונת המצב של הביצועים, אפשר לצלם עוד תמונות מצב ולחזור על התהליך.
יצירת snapshot שמכיל נתונים סטטיסטיים של ביצוע SQL
כברירת מחדל, AlloyDB משתמש בתוסף 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 כדי להתחבר לצומת של מאגר לקריאה, צריך להתחבר ישירות לכתובת ה-IP שלו באמצעותpsql. מידע נוסף זמין במאמר בנושא אחזור רשימת כתובות ה-IP של צומתי Read Pool. - מריצים את
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 | perf-primary | sab3-perf-primary-cab835ef-4cm8 | Manual snapshot | Manual | f 2 | 2023-11-13 22:53:40.49565+00 | perf-primary | sab3-perf-primary-cab835ef-4cm8 | Automatic snapshot| Automatic | f 3 | 2023-11-13 22:56:42.57094+00 | perf-replica | sab3-perf-replica-b9250422-tz4n | Automatic snapshot| Automatic | f 4 | 2023-11-13 22:56:42.59476+00 | perf-replica | sab3-perf-replica-b9250422-63q3 | Automatic snapshot| Automatic | f 5 | 2023-11-13 23:11:55.23157+00 | perf-replica | sab3-perf-replica-b9250422-tz4n | Manual snapshot | Manual | f (5 rows)
יצירת דוח תמונת מצב של הביצועים
כדי ליצור דוח שמציג את ההבדל בין שתי תמונות מצב, למשל תמונות מצב 1 ו-2, מריצים את הפקודה:SELECT perfsnap.report(1,2)
התמונה השנייה בגיבוי דיפרנציאלי לא חייבת להיות מיד אחרי התמונה הראשונה. עם זאת, חשוב לוודא שהתמונה השנייה של מצב המערכת נשמרת בהפרש אחרי התמונה הראשונה.
דוח סיכום הביצועים שנוצר דומה לדוגמה הבאה:
דוח לדוגמה
זוהי דוגמה מקוצרת לדוח תמונת מצב של ביצועים שנוצר:
דוגמה לדוח תמונת מצב של הביצועים
$ psql -d postgres -U alloydbsuperuser
postgres=> 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
SQL Report
~~~~~~~~~~
NOTE: Query might be empty if query ID does not have a match in pg_stat_statements at report time. This is expected if the query is not run recently.
Per Query Information (Top 50) By Total Elapsed Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Total Elapsed Time(ms) Execution Count Avg Elapsed Time(ms)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 276400877.8014 36928106 7.4848
prepare payment (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, NUMERIC, VARCHAR) AS select p 36272 36274 tpcc 3864683359055073968 127719636.4656 36928456 3.4586
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 48540963.0880 3694128 13.1400
prepare slev (INTEGER, INTEGER, INTEGER) AS select slev($1,$2,$3) 36272 36274 tpcc -8637448842172635004 35361366.9271 3692785 9.5758
...
Per Query Information (Top 50) By Read IO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Total ReadIO Time(ms) Execution Count Avg ReadIO Time(ms) Total buffer hits Avg buffer hits Total blk reads Avg blk reads
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
prepare ostat (INTEGER, INTEGER, INTEGER, INTEGER, VARCHAR) AS select * from ostat($1,$2,$3,$4,$5) a 36272 36274 tpcc -1640504351418263816 498072.4004 3693895 0.1348 80360201 21.75486877672484 105858 0.028657555236410347
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 12.5438 3694128 0.0000 4477308168 1212.0067761593534 1219908 0.33022894712906536
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 0.8039 36928106 0.0000 10337394097 279.9329620912592 6245570 0.16912781825312134
SELECT name, default_version, installed_version FROM pg_catalog.pg_available_extensions 10 5 postgres 6619165036968781114 0.0000 361 0.0000 361 1 0 0
...
Per Query Information (Top 50) By Standard Deviation of Elapsed Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Begin STDDEV Elapsed Time(ms) End STDDEV Elapsed Time(ms)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SELECT COUNT($1) FROM perfsnap.g$snapshots 10 5 postgres -8741741796612173369 17.8084 18.1239
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 15.0626 19.8495
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 13.9820 17.0074
prepare slev (INTEGER, INTEGER, INTEGER) AS select slev($1,$2,$3) 36272 36274 tpcc -8637448842172635004 8.4333 9.6205
----------------------------------------------------
Created by G_STATS v1.0.100
----------------------------------------------------
(xxx rows)
מידע על שדות הדוחות והמלצות לאופטימיזציה של הביצועים זמין במאמר המלצות לאופטימיזציה של ביצועי מסד הנתונים. מידע נוסף על אירועי המתנה בדוחות תמונת מצב של ביצועים זמין במאמר הפניה לדוח תמונת מצב של ביצועי מסד נתונים.
מחיקת תמונת מצב
כדי למחוק תמונות מצב שכלולות בבסיס נתונים קיים, צריך לנקות את בסיס הנתונים.
כדי למחוק תמונת מצב, מריצים את הפקודה הבאה:
SELECT perfsnap.delete(SNAP_ID);
מחליפים את SNAP_ID במזהה של התמונה של מצב המערכת שרוצים למחוק.
אחרי שמוחקים תמונת מצב, אי אפשר לשחזר אותה.
סימון תמונת מצב כנקודת השוואה לביצועים
כדי לסמן את כל תמונות המצב עם מזהים בין 1 ל-3, למשל, כנקודת בסיס לביצועי המערכת, מריצים את הפקודה SELECT perfsnap.make_baseline(1, 3).
מחיקת נתוני הבסיס של הביצועים
כדי למחוק את כל נקודות הבסיס עם מזהים בין 1 ל-3, למשל, מריצים את הפקודה
SELECT perfsnap.clear_baseline(1, 3).
שינוי התדירות של תמונות המצב האוטומטיות
צילומי מצב אוטומטיים מתבצעים למופע הראשי ולצמתי הקריאה פעם ביום כברירת מחדל.
כדי להתאים אישית את התדירות של צילומי המסך האוטומטיים, מגדירים את הדגל perfsnap.interval, שמגדיר את מרווח הזמן בין צילומי המסך האוטומטיים בשניות. מידע נוסף זמין במאמר בנושא הגדרת דגלים של מסד נתונים.
מומלץ להגדיר את ערך הדגל לכמה דקות לפחות כדי לתעד מידע משמעותי.
כדי לבצע אופטימיזציה של השימוש במשאבים, כשאין יותר צורך בתדירות המותאמת אישית, צריך לאפס את הדגל לערך ברירת המחדל, שהוא 86,400 שניות ביום.
אופטימיזציה של ביצועי מסד הנתונים באמצעות תוצאות של דוח תמונת מצב
כדי לשפר את הביצועים של מסד נתונים ב-AlloyDB, פועלים לפי השלבים הבאים:
- יוצרים תמונות מצב של קו הבסיס כשהמסד נתונים בלי פעילות או כשהעומס הממוצע עליו נמוך.
- מפעילים את עומס העבודה או את השאילתה שרוצים לשפר את הביצועים שלהם.
- כשעומס העבודה או השאילתה מגיעים לשיא השימוש במשאבים, יוצרים עוד קבוצה של תמונות מצב. מומלץ להשתמש באותו מרווח זמן בשני הדוחות.
- משווים בין הדוחות שיצרתם עם שני סטים של תמונות מצב ומזהים שינויים שיכולים לשפר את הביצועים. מידע נוסף על המלצות לשיפור הביצועים זמין במאמר המלצות לאופטימיזציה של ביצועי מסד הנתונים.
המלצות לאופטימיזציה של ביצועי מסד הנתונים
בטבלה הבאה מפורטים הקטעים בדוח 'תמונת מצב של ביצועים' והשיפורים המומלצים לכל קטע בדוח. מידע נוסף על הקטעים בדוח תמונת המצב של הביצועים ועל אירועי ההמתנה זמין במאמר הפניה לדוח תמונת המצב של ביצועי מסד הנתונים.
| קטע | השדה בדוח | תיאור השדה בדוח | המלצות לאופטימיזציה |
|---|---|---|---|
| פרטי תמונת המצב | פרטי תמונת המצב | הפלט כולל את המארח, את גרסת ההפצה התואמת של PostgreSQL ואת השעה שבה המכונה הופעלה. | לא רלוונטי |
| מזהה תמונת המצב | מציג את המזהה ואת נקודת הזמן של תמונות המצב ששימשו ליצירת הדוח הזה. | לא רלוונטי | |
| תובנות לגבי המערכת | מעבד המארח | פרטים על ניצול המעבד של המארח. | אם ניצול המעבד גבוה מ-80%, מומלץ להגדיל את הקיבולת לגודל הבא שזמין. במקרים של מופעי מאגר לקריאה, צריך לוודא שגודל הצומת זהה למופע הראשי או גדול ממנו. יכול להיות שצמתים קטנים לקריאה לא יוכלו לעמוד בקצב יצירת ה-WAL של הצומת הראשי במהלך עומסי עבודה כבדים של כתיבה. |
| זיכרון המארח | פרטים על ניצול הזיכרון של המארח. | אם הזיכרון הפנוי קטן מ-15%, מומלץ להגדיל את הזיכרון לגודל הבא שזמין. במקרים של מופעי מאגר לקריאה, צריך לוודא שגודל הצומת זהה למופע הראשי או גדול ממנו. יכול להיות שצמתים קטנים לקריאה לא יוכלו לעמוד בקצב יצירת ה-WAL של הצומת הראשי במהלך עומסי עבודה כבדים של כתיבה. | |
| טעינת פרופיל | מונה רשימות שעוזרות להעריך את עומס העבודה של רישום מראש (WAL) שנוצר, דרישות קלט/פלט וניהול חיבורים. | אם הקריאות הפיזיות גבוהות מהקריאות הלוגיות, כדאי לשקול הגדלה לגודל הבא שזמין כדי לתמוך בשמירת נתונים במטמון. | |
| פירוט של זמן התגובה וסוג ההמתנה | פירוט של הזמן שבו תהליכי Postgres השקיעו במהלך הרצת עומס העבודה. | לדוגמה, אם התהליכים נמצאים בעיקר במצב המתנה, כדאי להתמקד בקיצור זמן ההמתנה של קלט/פלט. | |
| מידע על עומס העבודה במסד הנתונים | מידע על עומס העבודה בכל מסד נתונים | מדדי מפתח לכל מסד נתונים, כולל פעולות אישור (commit), ביטול (rollback), יחס פגיעה (hit ratio) ומידע על טבלאות זמניות ופעולות מיון. | אם יש הרבה חזרה לגרסה קודמת, כדאי לאבחן את האפליקציה. |
| מידע על DML ו-DQL לכל מסד נתונים | מונים של פעולות שאילתה. | הגדרת עומס העבודה כקריאה אינטנסיבית או כתיבה אינטנסיבית. | |
| מידע על התנגשות במסד הנתונים | מדדים לבעיות נפוצות באפליקציות ובמסדי נתונים. | אם יש מצב של קיפאון, מאתרים את הבעיות באפליקציה. אם יש הרבה התנגשויות של Buffer Pins במופע של מאגר קריאה, כדאי להקטין את הערך של max_standby_streaming_delay כדי לאפשר את ההפעלה מחדש, או להעביר שאילתות שפועלות לאורך זמן למאגר קריאה אחר כדי למנוע החזקה של פינים למשך פרקי זמן ארוכים. |
|
| מידע על גודל מסד הנתונים | הנתון הזה מראה את הגידול במסד הנתונים במהלך המרווח בין שתי תמונות מצב. בשדה הזה מופיע גם אם הוגדרו מגבלות חיבור למסד הנתונים. | אם הגידול במסד הנתונים גדול מדי, צריך לאתר בעיות באפליקציה. | |
| מידע על שואבי אבק | מידע על שואבי אבק | פרטים על קלט/פלט ועל מוני פעולות של ניקוי. | כברירת מחדל, ב-AlloyDB מתבצעת פעולת vacuuming אדפטיבית. אתם יכולים לשנות חלק מהגדרות הניקוי כדי שיתאימו לעומס העבודה שלכם. לדוגמה, אפשר לצמצם את פעולות הניקוי אם יותר מדי קלט/פלט מושקע בבקשות האלה. |
| מידע על ניקוי מסד נתונים | מוצג המידע הבא:
|
אם הערך בשדה Frozen XID ישן מדי, או אם אחוז העסקאות שבוצעו קרוב ל-90%, כדאי לבצע פעולת vacuum. אם הפער הכולל של ה-vacuum יורד, זה מצביע על כך ש-Postgres יבצע vacuum כדי למנוע wraparound. | |
| פרטי המתנה של תהליכים במסד הנתונים | מידע מפורט על תהליכים ברקע ובקצה העורפי | פרטים על כל ההמתנות של תהליכי backend ורקע במרווח הדוחות. המידע כולל את זמן ההמתנה המצטבר, זמן השימוש ביחידת העיבוד המרכזית (CPU) והזמן הממוצע לכל סוג המתנה. | כדי לקצר את זמן ההמתנה ב-WALWrite, למשל, מגדילים את מספר wal_buffers שזמין למסד הנתונים. |
| היסטוגרמה מפורטת של אירועי המתנה ב-Backend וברקע | הוא נכלל בדוח תמונת המצב של הביצועים כברירת מחדל. הרשימה מכילה את ההיסטוגרמה של אירועי ההמתנה לתהליכי קצה עורפיים ולתהליכי רקע, שמחולקים ל-32 קטגוריות, מ-1 מיקרו-שנייה ועד ליותר מ-16 שניות. | מחפשים את אירועי ההמתנה וקובעים אם יש יותר מדי אירועי המתנה בדלי הגדול יותר של זמן ההמתנה. יכול להיות שיש בעיה עם יותר מדי אירועי המתנה או עם כל זמן המתנה שנצרך. | |
| נתונים סטטיסטיים שונים | נתונים סטטיסטיים של Write Ahead Log (WAL) | סיכום של נתונים סטטיסטיים של WAL. | אם הסנכרון נמשך זמן רב מדי, כדאי לשנות את ההגדרות של מסד הנתונים הרלוונטי (GUC) כדי לשפר את עומס העבודה. GUC הוא תת-מערכת של PostgreSQL שמטפלת בהגדרת השרת. |
| סיכום נתונים סטטיסטיים (בכל מסדי הנתונים) | סיכום של כל פעולות מסד הנתונים שמתרחשות במהלך מרווח הזמן של ה-Snapshot. | לא רלוונטי | |
| הגדרות פרמטרים | הגדרות פרמטרים | פרמטרים מרכזיים להגדרת 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 מוחק את כל תמונות המצב הידניות שנוצרו לפני יותר מ-90 ימים. כדי לא לחרוג מהמגבלה על מספר תמונות המצב, צריך למחוק תמונות מצב מיותרות לפני שיוצרים תמונה חדשה.
AlloyDB מנקה באופן תקופתי תמונות מצב ידניות שנוצרו לפני יותר מ-90 ימים.