מעקב אחרי ביצועים של מסד נתונים ב-AlloyDB Omni

בוחרים גרסת תיעוד:

בדף הזה מוסבר איך לעקוב אחרי הביצועים של מסד הנתונים של AlloyDB Omni באמצעות סקריפטים של ניטור ב-PostgreSQL.

הצגת המצב של תהליכים מחוברים ואירועי המתנה

כדי לזהות תהליכים שמחוברים למכונה של AlloyDB Omni וגם קצוות עורפיים שממתינים לפעילות, אפשר לשלוח שאילתה לתצוגה pg_stat_activity.

SELECT
    pid,
    datname,
    age(backend_xid) AS age_in_xids,
    now() - xact_start AS xact_age,
    now() - query_start AS query_age,
    state,
    wait_event_type,
    wait_event,
    query_id,
    query
FROM
    pg_stat_activity
WHERE
    state != 'idle'
    AND pid <> pg_backend_pid()
ORDER BY
    4 DESC
LIMIT 10;

הצגת הטבלאות הגדולות ביותר

כדי לקבוע את הגודל של הטבלאות הכי גדולות, אפשר לשלוח שאילתה לתצוגה pg_stat_user_tables.

SELECT
    oid,
    oid::regclass table_name,
    pg_size_pretty(pg_relation_size(oid)),
    relpages,
    s.seq_scan,
    s.idx_scan
FROM
    pg_class,
    pg_stat_user_tables s
WHERE
    s.relid = oid
    AND oid > 16383
    AND relpages > 100
    AND relkind = 'r'
ORDER BY
    relpages DESC
LIMIT 20;

הצגת הסריקות הרציפות המובילות

כדי לראות את הסריקות הרציפות המובילות, אפשר לשלוח שאילתה לתצוגה pg_stat_user_tables.

SELECT
    relid,
    relname,
    seq_scan,
    pg_size_pretty(pg_relation_size(relid))
FROM
    pg_stat_user_tables
ORDER BY
    seq_scan DESC
LIMIT 15;

הצגת סריקות האינדקס המובילות

כדי לראות את סריקות האינדקס המובילות, אפשר לשלוח שאילתה לתצוגה pg_stat_user_tables.

SELECT
    relid,
    relid::regclass table_name,
    idx_scan,
    pg_size_pretty(pg_relation_size(relid))
FROM
    pg_stat_user_tables
WHERE
    idx_scan > 10
ORDER BY
    idx_scan DESC
LIMIT 15;

הצגת העסקאות שפועלות הכי הרבה זמן

כדי לראות את העסקאות שפועלות הכי הרבה זמן, אפשר לשלוח שאילתה לתצוגה pg_stat_activity ולבדוק את משך הזמן של העסקה.

SELECT
    pid,
    age(backend_xid) AS age_in_xids,
    now() - xact_start AS xact_age,
    now() - query_start AS query_age,
    state,
    query
FROM
    pg_stat_activity
WHERE
    state != 'idle'
ORDER BY
    2 DESC
LIMIT 10;

בדיקת ההתקדמות של פעולת ה-VACUUM

כדי לבדוק את ההתקדמות של פעולות ה-VACUUM, אפשר להריץ שאילתה בתצוגה pg_stat_progress_vacuum ולצרף אותה לתצוגה pg_stat_activity באמצעות מזהי תהליכים.

SELECT
  p.pid,
  now() - a.xact_start AS duration,
  coalesce(wait_event_type ||'.'|| wait_event, 'f') AS waiting,
  CASE
    WHEN a.query ~*'^autovacuum.*to prevent wraparound' THEN 'wraparound'
    WHEN a.query ~*'^vacuum' THEN 'user'
  ELSE
    'regular'
  END AS mode,
  p.datname AS database,
  p.relid::regclass AS table,
  p.phase,
  pg_size_pretty(p.heap_blks_total * current_setting('block_size')::int) AS table_size,
  pg_size_pretty(pg_total_relation_size(relid)) AS total_size,
  pg_size_pretty(p.heap_blks_scanned * current_setting('block_size')::int) AS scanned,
  pg_size_pretty(p.heap_blks_vacuumed * current_setting('block_size')::int) AS vacuumed,
  round(100.0 * p.heap_blks_scanned / p.heap_blks_total, 1) AS scanned_pct,
  round(100.0 * p.heap_blks_vacuumed / p.heap_blks_total, 1) AS vacuumed_pct,
  p.index_vacuum_count,
  round(100.0 * p.dead_tuple_bytes / p.max_dead_tuple_bytes,1) AS dead_pct
FROM pg_stat_progress_vacuum p
JOIN pg_stat_activity a using (pid)
ORDER BY now() - a.xact_start DESC;

צפייה בשאילתות אסינכרוניות

כדי לראות שאילתות שפועלות באופן אסינכרוני, אתם יכולים להריץ שאילתה בתצוגה pg_stat_activity ולסנן שאילתות שהן לא התהליך הראשי.

SELECT
    query,
    leader_pid,
    array_agg(pid) FILTER (WHERE leader_pid != pid) AS members
FROM
    pg_stat_activity
WHERE
    leader_pid IS NOT NULL
GROUP BY
    query,
    leader_pid;

הצגת SQL של נעילה חוסמת

כדי לראות את הפעילות שנחסמה, אפשר לשלוח שאילתה לתצוגה pg_locks ולצרף אותה לתצוגה pg_stat_activity.

SELECT blocked_locks.pid     AS blocked_pid,
       blocked_activity.usename  AS blocked_user,
       blocking_locks.pid     AS blocking_pid,
       blocking_activity.usename AS blocking_user,
       blocked_activity.query    AS blocked_statement,
       blocked_activity.wait_event AS blocked_wait_event,
       blocking_activity.wait_event AS blocking_wait_event,
       blocking_activity.query   AS current_statement_in_blocking_process
 FROM  pg_catalog.pg_locks         blocked_locks
  JOIN pg_catalog.pg_stat_activity blocked_activity  ON blocked_activity.pid = blocked_locks.pid
  JOIN pg_catalog.pg_locks         blocking_locks
      ON blocking_locks.locktype = blocked_locks.locktype
      AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
      AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
      AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
      AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
      AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
      AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
      AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
      AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
      AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
      AND blocking_locks.pid != blocked_locks.pid
  JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
 WHERE NOT blocked_locks.granted;

הערכת היעילות של הגדלים work_mem ו-temp_buffers

כדי לבדוק אם הגודל של work_mem ו-temp_buffers מתאים לצרכים שלכם, אתם יכולים לשלוח שאילתה לתצוגה pg_stat_database ולבדוק את הקובץ postgres.log. מריצים את השאילתה הבאה באמצעות pg_stat_database. אם יש גידול ב-temp_files או ב-temp_bytes בין ההרצות, כנראה שצריך לכוונן את work_mem או את temp_buffers.

SELECT
    datname,
    temp_files,
    temp_bytes
FROM
    pg_stat_database;

אחרי שמריצים את הפקודה, בודקים בקובץ postgres.log אם נעשה שימוש בקבצים זמניים:

LOG: [fd.c:1772] temporary file: path "base/pgsql_tmp/pgsql_tmp4640.1", size 139264

המטרה היא לצמצם את היצירה של קבצים זמניים, ולא למנוע אותה לחלוטין. הסיבה לכך היא שהגדרת work_mem ו-temp_buffers היא איזון בין הזיכרון הזמין במארח לבין מספר החיבורים שדורשים את הזיכרון. כדי להגדיר את הפרמטרים האלה בצורה נכונה, צריך להבין כל עומס עבודה בנפרד.

הצגת הביצועים של שאילתות באמצעות Query Insights

אתם יכולים לזהות שאילתות איטיות והצהרות עם קלט/פלט גבוה בדיסק באמצעות Query Insights בממשק המשתמש של AlloyDB Omni באינטרנט. כדי להשתמש ב-Query Insights, צריך להפעיל את התוסף pg_stat_statements במסד הנתונים. הוראות להגדרה זמינות במאמר התקנת ממשק המשתמש באינטרנט.

כדי לראות את מדדי הביצועים של השאילתות בממשק האינטרנט:

  1. מתחברים לממשק המשתמש באינטרנט ובוחרים את האשכול.
  2. בתפריט הניווט, לוחצים על Query Insights.
  3. אופציונלי: משתמשים ברשימה Database כדי לסנן את השאילתות לפי מסד נתונים ספציפי, או בוחרים באפשרות All databases.
  4. בודקים את הטבלה Queries כדי לנתח את הנתונים הסטטיסטיים של הרצת ה-SQL. בכל שורה מוצגים המדדים הבאים, ומתחת לשורה מוצגת הצהרת ה-SQL המלאה:
    • ‫Database name: מסד הנתונים הלוגי שבו ההצהרה הופעלה.
    • קריאות: מספר הפעמים הכולל שההצהרה בוצעה.
    • שורות: המספר הכולל של השורות שאוחזרו או הושפעו מההצהרה.
    • ‫Execution time: mean: זמן הביצוע הממוצע לכל קריאה.
    • זמן ביצוע: סה"כ: זמן הביצוע המצטבר בכל הקריאות.
    • מציאה במטמון של בלוק משותף: המספר הכולל של מציאות במטמון של מאגר נתונים זמני משותף.
    • קריאת בלוקים משותפים: המספר הכולל של בלוקים משותפים שנקראו מהדיסק.
    • סוג השאילתה: מסווג את ההשפעה של השאילתה על הביצועים, למשל Slow query או High disk IO.