תארו לעצמכם: מסד הנתונים של החנות המקוונת שלכם עמוס; כל 5 דקות הדפים נטענים תוך 10 שניות, ובמהלך שיא המכירות האתר נופל. אתם בודקים את השרת—המעבד פנוי, הזיכרון זמין, אבל השאילתות עדיין איטיות. ללא ניטור ביצועי מסד נתונים, שאילתות איטיות לא מתגלות. אנו מגדירים את pg_stat_statements ויומן השאילתות האיטיות, מחברים את Prometheus עם Grafana, ואתם רואים מדדים מדויקים: שיעור פגיעות בקאש, פיגור שכפול, השאילתות הכבדות ביותר. תוך יומיים אתם מקבלים לוחות מחוונים שמראים בזמן אמת אילו שאילתות מאטות את המערכת. זו לא בדיקה חד-פעמית—זו שליטה מתמשכת.
נתקלנו במקרה שבו JOIN איטי אחד בגלל אינדקס חסר צרך 40% מזמן מסד הנתונים. לאחר הגדרת הניטור, הלקוח מצא ותיקן את הבעיה תוך שעה. החיסכון בעלויות התפעול מגיע ל-30%—שווה ערך ל-$15,000 בשנה עבור חנות איקומרס בינונית. אנו נעריך את הפרויקט שלכם—פנו אלינו.
כיצד pg_stat_statements עוזר לזהות צווארי בקבוק בשאילתות
ההרחבה pg_stat_statements צוברת סטטיסטיקות עבור כל שאילתה ייחודית: זמן ביצוע, מספר קריאות, סטיית תקן. התצורה מינימלית:
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.max = 10000
pg_stat_statements.track = all
pg_stat_statements.track_utility = offלאחר הפעלה מחדש, צרו את ההרחבה והריצו שאילתות כדי למצוא בעיות:
-- Топ по суммарному времени
SELECT left(query, 120) AS query,
calls,
round(total_exec_time::numeric / 1000, 1) AS total_sec,
round(mean_exec_time::numeric, 1) AS avg_ms,
round(stddev_exec_time::numeric, 1) AS stddev_ms,
round(rows::numeric / nullif(calls, 0), 0) AS rows_per_call
FROM pg_stat_statements
WHERE dbid = (SELECT oid FROM pg_database WHERE datname = current_database())
AND calls > 10
ORDER BY total_exec_time DESC
LIMIT 20;
-- Запросы с большим разбросом времени
SELECT left(query, 120) AS query,
calls,
round(mean_exec_time::numeric, 1) AS avg_ms,
round(stddev_exec_time::numeric, 1) AS stddev_ms,
round(stddev_exec_time / nullif(mean_exec_time, 0) * 100, 1) AS cv_pct
FROM pg_stat_statements
WHERE calls > 100
ORDER BY cv_pct DESC
LIMIT 10;בפרויקט אחד, מצאנו שאילתה שממוצע הזמן שלה היה 2.3 שניות והיוותה 15% מזמן מסד הנתונים הכולל. לאחר הוספת אינדקס, הזמן ירד ל-15 אלפיות השנייה—שיפור של פי 153. תיעוד pg_stat_statements מאשר שזו הדרך המהירה ביותר לקבל תמונה מצטברת. בהשוואה ליומן השאילתות האיטיות:
| כלי | מה הוא מספק | מהירות ניתוח | עומק פירוט |
|---|---|---|---|
| pg_stat_statements | סיכום של כל השאילתות | שניות | גבוה (מצטבר) |
| יומן שאילתות איטיות | כל שאילתה איטית עם תוכנית | דקות | מלא |
יחד, הם עוזרים לאתר צווארי בקבוק פי 3 מהר יותר מאשר בדיקה ידנית של יומנים.
דוגמה: כיצד מצאנו JOIN איטי
במערכת ייצור, חיבור של שתי טבלאות עם 2 מיליון שורות לקח 4.5 שניות בגלל אינדקס חסר על המפתח הזר. pg_stat_statements הראה TTFB של 4.2 שניות, ויומן השאילתות האיטיות נתן את התוכנית המלאה. הוספנו אינדקס—הזמן ירד ל-12 אלפיות השנייה. ללא ניטור, מציאת הבעיה הייתה לוקחת ימים.
למה יומן השאילתות האיטיות חשוב עבור MySQL
ב-MySQL, הפעילו את יומן השאילתות האיטיות עם סף של שנייה אחת ורישום שאילתות ללא אינדקסים:
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = ON
min_examined_row_limit = 1000
log_slow_rate_limit = 100מקרה טיפוסי: שאילתה ללא אינדקס סרקה 500,000 שורות, ולקחה 4.2 שניות. לאחר ניתוח, הוספנו אינדקס מורכב, וקיצרנו את הזמן ל-0.03 שניות—הפחתה של 99.3%. אנו מנתחים באמצעות Percona Toolkit:
pt-query-digest --since="1h ago" --limit 20 --output report /var/log/mysql/slow.log זה נותן ספירה, זמן ממוצע/מקסימלי, ושורות שנבדקו עבור כל שאילתה ייחודית.
ניטור מדדים: Prometheus + Grafana
עבור PostgreSQL, אנו משתמשים ב-slow query log; עבור MySQL, shared_preload_libraries = 'pg_stat_statements' pg_stat_statements.max = 10000 pg_stat_statements.track = all pg_stat_statements.track_utility = off . תצורת ה-Exporter היא סטנדרטית וניתן להגדירה תוך שעה. מדדים והתראות מרכזיים:
| מדד | סף התראה |
|---|---|
| שיעור פגיעות בקאש (PG) | < 99% |
| חיבורים פעילים | > 80% מ-max_connections |
| פיגור שכפול | > 30 שניות |
| מספר שאילתות איטיות לדקה | מגמה עולה |
דוגמה לכללי התראה:
---
groups:
- name: postgresql
rules:
- alert: PostgreSQLSlowQueries
expr: rate(pg_stat_statements_total_exec_time_seconds_total[5m]) > 10
for: 2m
- alert: PostgreSQLHighConnections
expr: pg_stat_activity_count > pg_settings_max_connections * 0.8
ניתן לייבא לוחות מחוונים מוכנים של Grafana (ID 9628 עבור PostgreSQL, 7362 עבור MySQL).
מה כלול בהגדרת ניטור מסד הנתונים שלנו
אנו מספקים תיעוד מלא: תצורת גישה, הוראות פריסה, ו-runbook להתראות. לאחר היישום, אתם מקבלים:
- Exporters מוגדרים עבור PostgreSQL ו-MySQL.
- לוחות מחוונים של Grafana עם מדדים מרכזיים (שיעור פגיעות בקאש, פיגור שכפול, שאילתות מובילות).
- התראות מותאמות אישית הנשלחות ל-Telegram או Slack.
- הדרכת צוות על פירוש מדדים ותגובה להתראות.
- דוחות יומיים של pgBadger על שאילתות איטיות.
זה מאפשר לצוות שלכם לשמור על ביצועי מסד הנתונים באופן עצמאי. עלות היישום היא $2,500, והיא מחזירה את עצמה תוך חודשיים על ידי הפחתת עלויות השבתה בממוצע של $10,000 בשנה. קבלו ייעוץ—נעריך את הפרויקט שלכם תוך שעה.
שלבי הגדרת ניטור מסד הנתונים
- ניתוח: איסוף מדדים נוכחיים, זיהוי צווארי בקבוק דרך יומנים וסטטיסטיקות.
- תצורה: הגדרת
-- Топ по суммарному времени SELECT left(query, 120) AS query, calls, round(total_exec_time::numeric / 1000, 1) AS total_sec, round(mean_exec_time::numeric, 1) AS avg_ms, round(stddev_exec_time::numeric, 1) AS stddev_ms, round(rows::numeric / nullif(calls, 0), 0) AS rows_per_call FROM pg_stat_statements WHERE dbid = (SELECT oid FROM pg_database WHERE datname = current_database()) AND calls > 10 ORDER BY total_exec_time DESC LIMIT 20; -- Запросы с большим разбросом времени SELECT left(query, 120) AS query, calls, round(mean_exec_time::numeric, 1) AS avg_ms, round(stddev_exec_time::numeric, 1) AS stddev_ms, round(stddev_exec_time / nullif(mean_exec_time, 0) * 100, 1) AS cv_pct FROM pg_stat_statements WHERE calls > 100 ORDER BY cv_pct DESC LIMIT 10;ו-slow_query_log = ON slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = ON min_examined_row_limit = 1000 log_slow_rate_limit = 100עם פרמטרים אופטימליים. - פריסה: פריסת Exporters של Prometheus (postgres_exporter, mysqld_exporter).
- לוחות מחוונים: יצירת לוחות מחוונים מותאמים של Grafana עבור שיעור פגיעות בקאש, פיגור שכפול, שאילתות מובילות.
- התראות: הגדרת כללי Alertmanager עם הודעות ל-Telegram/Slack.
- אינטגרציה: הגדרת pgBadger לדוחות יומיים והדרכת הצוות.
- תיעוד: מתן מסמכי תצורה ו-runbook לתגובה להתראות.
טעויות נפוצות בהגדרת ניטור מסד נתונים
- אי הגדרת
pt-query-digest --since="1h ago" --limit 20 --output report /var/log/mysql/slow.log—מלכלך את הסטטיסטיקות בשאילתות פנימיות. - שכחת
postgres_exporterב-MySQL—אובדן הקשר ביומני שאילתות איטיות. - שימוש באותו לוח מחוונים לכל מסדי הנתונים—התעלמות ממאפייני שכפול ו-sharding.
- אי הוספת טיפול בקפיצות ב-Alertmanager—קבלת ספאם מקפיצות קצרות.
אנו מתקנים בעיות אלה במהלך היישום. למהנדסים שלנו יש ניסיון של 5+ שנים בניהול PostgreSQL ו-MySQL והם מוסמכים ב-Prometheus. עם למעלה מ-10 פרויקטים של אופטימיזציית ביצועים, אנו מבטיחים תוצאות. לאחר יישום הניטור, לקוחות חוסכים עד 40% מזמן האבחון (כ-$8,000 בחיסכון בעבודה בשנה) ומקצרים את זמן ההשבתה בחצי. הזמינו הגדרת ניטור מסד נתונים—נזהה צווארי בקבוק תוך יומיים.







