ניצול גבוה של המעבד (CPU) משפיע לרעה על הביצועים של המכונה. כל פעילות שמתבצעת במכונה משתמשת במעבד (CPU). לכן, אם מופיעה הודעה על ניצול גבוה של המעבד (CPU), קודם צריך לזהות את שורש הבעיה, בין אם מדובר בשאילתות שכתובות בצורה לא טובה, בעסקאות שנמשכות זמן רב או בכל פעילות אחרת במסד הנתונים.
במאמר הזה נסביר איך לזהות צווארי בקבוק של המעבד (CPU) במכונה, ואיך לפתור את הבעיות בשימוש במעבד (CPU) במכונה.
זיהוי צווארי הבקבוק של המעבד (CPU)
בקטעים הבאים נדון בתרחישים שונים של שימוש במעבד (CPU).
שימוש בתובנות לגבי שאילתות כדי לזהות שאילתות עם צריכת מעבד (CPU) גבוהה
בעזרת Query Insights תוכלו לזהות, לאבחן ולמנוע בעיות בביצועי השאילתות במסדי נתונים של Cloud SQL.
שימוש בתוסף pg_proctab
משתמשים בתוסף pg_proctab בשילוב עם כלי השירות pg_top כדי לקבל פלט של מערכת ההפעלה שמספק מידע על ניצול המשאבים של המעבד (CPU) לכל תהליך.
שימוש בשאילתות
בקטעים הבאים מפורטות שאילתות שונות שאפשר להשתמש בהן.
זיהוי החיבורים הפעילים לפי מצב
כל חיבור פעיל למסד הנתונים צורך כמות מסוימת של משאבי מעבד (CPU), כך שאם למכונה יש מספר גבוה של חיבורים, הניצול המצטבר עשוי להיות גבוה. כדי לקבל מידע על מספר החיבורים לפי מדינה, משתמשים בשאילתה הבאה:
SELECT
state,
usename,
count(1)
FROM
pg_stat_activity
WHERE
pid <> pg_backend_pid()
group by
state,
usename
order by
1;
הפלט אמור להיראות כך:
state | usename | count
---------------------+---------------+-------
active | ltest | 318
active | sbtest | 95
active | | 2
idle | cloudsqladmin | 2
idle in transaction | ltest | 32
idle in transaction | sbtest | 5
| cloudsqladmin | 3
| | 4
(8 rows)
אם מספר החיבורים הפעילים גבוה, צריך לבדוק אם יש שאילתות שפועלות במשך זמן רב או אירועי המתנה שחוסמים את הפעלת השאילתות.
אם מספר החיבורים הלא פעילים גבוה, מריצים את השאילתה הבאה כדי לסיים את החיבורים, אחרי שמקבלים את האישורים הנדרשים.
SELECT
pg_terminate_backend(pid)
FROM
pg_stat_activity
WHERE
usename = 'sbtest'
and pid <> pg_backend_pid()
and state in ('idle');
אפשר גם לסיים את החיבורים בנפרד באמצעות pg_terminate_backend, בעזרת השאילתה הבאה:
SELECT pg_terminate_backend (<pid>);
כאן אפשר לקבל את מזהה המוצר מ-pg_stat_activity.
זיהוי החיבורים שפועלים לאורך זמן
הנה דוגמה לשאילתה שמחזירה שאילתות שפועלות במשך זמן רב. במקרה כזה, אתם יכולים לזהות את השאילתות שפעילות יותר מ-5 דקות.
SELECT
pid,
query_start,
xact_start,
now() - pg_stat_activity.query_start AS duration,
query,
state
FROM
pg_stat_activity
WHERE
(
now() - pg_stat_activity.query_start
) > interval '5 minutes' order by 4 desc;
בדיקת תוכנית ההסבר כדי לזהות שאילתות שכתובות בצורה לא טובה
אפשר להשתמש ב-EXPLAIN PLAN כדי לבדוק שאילתה שכתובה בצורה לא טובה ולשכתב אותה, אם צריך. אם רוצים, אפשר לבטל את השאילתה שפועלת במשך זמן רב באמצעות הפקודה הבאה, עם האישורים הנדרשים.
SELECT pg_cancel_backend(<pid>);
מעקב אחרי פעילות VACUUM
פעילות ה-AUTOVACUUM שמנקה את ה-dead tuples היא פעולה שצורכת הרבה משאבי מעבד. אם במכונה שלכם מותקנת גרסה 11 או גרסה חדשה יותר של PostgreSQL, אתם יכולים להשתמש בשאילתה הבאה כדי לבדוק אם יש פעילות AUTOVACUUM או VACUUM פעילה.
SELECT
relid :: regclass,
pid,
phase,
heap_blks_total,
heap_blks_scanned,
heap_blks_vacuumed,
index_vacuum_count,
max_dead_tuples,
num_dead_tuples
FROM
pg_stat_progress_vacuum;
כדי לבדוק אם יש פעילות VACUUM מתמשכת במכונה, משתמשים בשאילתה הבאה:
SELECT
pid,
datname,
usename,
query
FROM
pg_stat_activity
WHERE
query like '%vacuum%';
בנוסף, אתם יכולים לבצע אופטימיזציה ופתרון בעיות של פעולות VACUUM ב-PostgreSQL.
הוספת התוסף pg_stat_statements
כדי לקבל מידע מילוני משופר על פעילות המכונה, צריך להגדיר את התוסף pg_stat_statements.
נקודות ביקורת תכופות
נקודות ביקורת תכופות פוגעות בביצועים. אם ביומן ההתראות של PostgreSQL מופיעה האזהרה checkpoint occurring too frequently, כדאי לשנות את הדגל checkpoint_timeout.
איסוף נתונים סטטיסטיים
כדי לבחור את התוכנית הטובה ביותר לשאילתות, ודאו שלמתכנן השאילתות יש את הנתונים הסטטיסטיים העדכניים ביותר לגבי הטבלאות. הפעולה ANALYZE אוספת נתונים סטטיסטיים על התוכן של הטבלאות במסד הנתונים, ושומרת את התוצאות בקטלוג המערכת pg_statistic. לאחר מכן, הכלי לתכנון שאילתות משתמש בנתונים הסטטיסטיים האלה כדי לקבוע את תוכניות הביצוע היעילות ביותר לשאילתות. תהליך ה-AUTOVACUUM מנתח את הטבלאות באופן אוטומטי מדי פעם, לכן צריך להריץ את הפקודה הבאה כדי לבדוק אם כל הטבלאות נותחו והמטא-נתונים העדכניים ביותר זמינים למתכנן.
SELECT
relname,
last_autovacuum,
last_autoanalyze
FROM
pg_stat_user_tables;
הגדרות מערכת לא מתאימות
יש גורמים אחרים, הגדרות של דגלים או גורמי מערכת שמשפיעים על הביצועים של השאילתה. מריצים את השאילתה הבאה כדי לבדוק את אירועי ההמתנה ואת סוג אירוע ההמתנה, ולקבל תובנות לגבי הביצועים של הגדרות מערכת אחרות.
SELECT
datname,
usename,
(
case when usename is not null then state else query end
) AS what,
wait_event_type,
wait_event,
backend_type,
count(*)
FROM
pg_stat_activity
GROUP BY
1,
2,
3,
4,
5,
6
ORDER BY
1,
2,
3,
4 nulls first,
5,
6;
הפלט אמור להיראות כך:
.. | .. | what | wait_event_type | wait_event | .. | count
-..--+-..-+----------------+-----------------+----------------------+-..----+------
..
.. | .. | active | IO | CommitWaitFlush | .. | 750
.. | .. | idle | IO | CommitWaitFlush | .. | 360
.. | .. | active | LWLock | BufferMapping | .. | 191
מעקב אחרי סריקות רציפות
סריקות רציפות תכופות בטבלאות עם יותר מכמה עשרות שורות בדרך כלל מצביעות על אינדקס חסר. כשהסריקות נוגעות באלפי או אפילו במאות אלפי שורות, הן עלולות לגרום לשימוש מוגזם במעבד (CPU).
סריקות רציפות תכופות בטבלאות עם מאות אלפי שורות עלולות לגרום לשימוש מוגזם במעבד (CPU). כדי להימנע מסריקות רציפות בטבלאות כאלה, צריך ליצור את האינדקסים הנדרשים.
מריצים את השאילתה הבאה כדי לבדוק כמה פעמים הופעלו סריקות רציפות בטבלה כלשהי.
SELECT
relname,
idx_scan,
seq_scan,
n_live_tup
FROM
pg_stat_user_tables
WHERE
seq_scan > 0
ORDER BY
n_live_tup desc;
לבסוף, אם השימוש ב-CPU עדיין גבוה ואתם חושבים שהשאילתות האלה הן תנועה לגיטימית, כדאי להגדיל את משאבי ה-CPU במכונה כדי למנוע קריסה של מסד הנתונים או זמן השבתה.