בעיות שקשורות לשימוש גבוה בדיסק

בדף הזה מפורטות בעיות ידועות שקשורות לשימוש גבוה בדיסק, ומוצעים פתרונות לבעיות האלה.

בעיות מוכרות שקשורות לשימוש גבוה בדיסק:

• שימוש גבוה בקובצי Temporary_files ב-MySQL מגרסה 8.0 ואילך.
• שימוש גבוה בקבצים מסוג Others ב-MySQL 8.0 ובגרסאות קודמות.

השימוש בקבצים זמניים מסווג כשימוש בtmp_data בקבצים בגרסאות שקדמו ל-MySQL 8.0.

מדד של פירוט נפח האחסון ב-MySQL

המדד העיקרי שמשמש למעקב אחרי השימוש המפורט בדיסק הוא cloudsql.googleapis.com/database/disk/bytes_used_by_data_type. המדד הזה מספק פירוט של השימוש בדיסק במופע לפי סוג הנתונים, באופן הבא:

סוג נתונים	הגדרה
Binlog	נפח האחסון שנדרש ליומנים בינאריים של MySQL, שחיוניים לשחזור לנקודת זמן מסוימת ולשכפול.
Cloudsql_mysql_audit_log	שטח האחסון שבו נעשה שימוש ביומן הביקורת של Cloud SQL MySQL.
Data	כולל את מרחבי הטבלאות הראשיים InnoDB (.ibd קבצים) ואת מרחב הטבלאות של המערכת (ibdata1).
General_log	נפח האחסון שמשמש את יומן השאילתות הכללי.
General_tablespace	נפח האחסון שנמצא בשימוש של מרחב הטבלאות של המערכת InnoDB, שמורכב מהקבצים ibdata*.
Last_sys_tablespace	נפח האחסון שנמצא בשימוש של מרחב הטבלאות האחרון.
Others	כולל קבצים פנימיים של המערכת.
Redo_log	נפח האחסון שנוצל על ידי יומני ה-redo של InnoDB שמשמשים לשחזור אחרי קריסה.
Relaylog	נפח האחסון שמשמש ליומני ממסר במופע משוכפל במהלך השכפול.
Slow_log	נפח האחסון שמשמש את יומן השאילתות האיטיות אם הוא מופעל ומאוחסן בדיסק.
Temporary files	אחסון במעקב מפורש של קבצים זמניים שנוצרו על ידי MySQL.
Temporary_space	האחסון שמשמש את הקבצים הזמניים של מערכת ההפעלה בספרייה /tmp.
Tmp_data	נתונים זמניים שנוצרו על ידי MySQL במהלך פעולות כמו מיון וצירוף.
Undo_log	נפח האחסון שמשמש את יומני הביטול.

איתור קבצים בקטגוריות Temporary_files ו-Others

שאילתות שפועלות לאורך זמן (למשל, פעולות מורכבות של JOIN, ORDER BY או GROUP BY) יוצרות קבצים זמניים גדולים בספריית MySQL.

במכונות MySQL שמשתמשות בגרסאות תחזוקה שפורסמו החל מאפריל 2026, הקבצים הזמניים האלה מדווחים באופן מפורש בקטגוריה Temporary_files.

בגרסאות קודמות, הקבצים הזמניים מדווחים בקטגוריה Others.

הערה: דיווח גרנולרי של Temporary_files ל-MySQL 8.0 הוצג לראשונה בגרסה r20260320.00_00. אפשר לבדוק את גרסת התחזוקה במסוף Google Cloud , בדף Overview של מכונת Cloud SQL, בקטע Maintenance.

פתרון בעיות שקשורות לשימוש גבוה בדיסק

כדי לפתור בעיות של שימוש גבוה בדיסק שנגרמות בגלל קבצים זמניים גדולים, פועלים לפי השלבים הבאים:

1. זיהוי שאילתות פעילות שפועלות במשך זמן רב.
2. צמצום מיידי של הסיכון.
3. שימוש בתובנות לגבי שאילתות.
4. ביצוע ניתוח רטרוספקטיבי.
5. אופטימיזציה של שאילתות.
6. הגדרת מעקב והתראות.

זיהוי שאילתות פעילות ממושכות

בעיות של שימוש גבוה בדיסק נגרמות בדרך כלל על ידי שאילתות שפועלות במשך זמן רב (לדוגמה, פעולות מורכבות של JOIN, ORDER BY או GROUP BY) שיוצרות קבצים זמניים גדולים בספריית MySQL. הקטגוריות של הקבצים הזמניים האלה הן Temporary_files או Others.

במופעי MySQL עם גרסאות תחזוקה חדשות (גרסה r20260320.00_00 ואילך) יש טבלה INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES שמציגה את הקבצים הזמניים שנוצרו על ידי שאילתות שפועלות לאורך זמן ושלא מקושרים (כלומר, הקבצים קיימים, אבל לא מקושרים לתהליך MySQL) על ידי MySQL.

הערה: טבלאות זמניות מפורשות, כלומר טבלאות שנוצרו באופן ידני באמצעות הפקודה CREATE TEMPORARY TABLE, מנוהלות בטבלה הזמנית InnoDB ולא נרשמות בטבלה INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES.

כדי לקבל את השאילתה הפעילה הממושכת, משתמשים בשאילתה הבאה:

SELECT
otf.fd, otf.size, p.id, p.info, p.user
FROM
 INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES otf
LEFT JOIN
performance_schema.processlist p
ON
otf.SESSION_ID = p.ID;

פלט לדוגמה:

+----+------------+------+----------------------------------+------+
| fd | size       | id   | info                             | user |
+----+------------+------+----------------------------------+------+
| 39 | 1670750208 |    8 | select * from t1 order by rand() | root |
| 40 | 1670750208 |    8 | select * from t1 order by rand() | root |
+----+------------+------+----------------------------------+------+
2 rows in set (0.00 sec)

במקרים שבהם הגרסה של התחזוקה היא r20260320.00_00 או גרסה קודמת, אפשר להשתמש בשאילתה הבאה כדי לקבל את השאילתה הפעילה לטווח ארוך:

SHOW FULL PROCESSLIST;

בפלט, מחפשים את הפעולות שבדרך כלל משתמשות בקבצים זמניים בדיסק:

• פעולות גדולות של JOIN, במיוחד ללא אינדקסים מתאימים.
• פעולות מורכבות של ORDER BY או GROUP BY בקבוצות גדולות של תוצאות.
• פעולות ALTER TABLE גדולות.

צמצום מיידי

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

כדי להפסיק את השאילתה, מריצים את הפקודה הבאה:

KILL PROCESS_ID;

מחליפים את PROCESS_ID במזהה התהליך של השאילתה:

• בגרסאות תחזוקה r20260320 ואילך, אפשר לאחזר את הערך PROCESS_ID דרך העמודה SESSION_ID בטבלה INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES.

• בגרסאות קודמות (גרסה r20260117 ומטה) , אפשר לאחזר את הערך PROCESS_ID מהפלט של הפעולה SHOW FULL PROCESSLIST.

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

שימוש בתובנות לגבי שאילתות

מומלץ להשתמש בתובנות לגבי שאילתות כדי לזהות ולשפר שאילתות שפועלות לאט.

מידע נוסף מופיע במאמר שימוש בתובנות לגבי שאילתות כדי לשפר את הביצועים של השאילתות.

ביצוע ניתוח רטרוספקטיבי

אחרי שהשימוש יחזור לרמה הרגילה, תוכלו לנתח את הנתונים ההיסטוריים כדי לזהות את הסיבה באמצעות הכלים הבאים:

• תובנות לגבי שאילתות. בודקים אם יש שאילתות שיצרו קבצים זמניים גדולים. בודקים את השאילתות שמופיעות בסיכום השאילתות (כולל מדדים כמו זמן הביצוע הממוצע, מספר השאילתות והממוצע של השורות שנסרקו והוחזרו).

• ‫Slow_log. מפעילים את Slow_log ומגדירים את long_query_time לסף מתאים. ביומן הזה מתועדות שאילתות שפועלות לאורך זמן לצורך ניתוח ואופטימיזציה.

• ‫General_log. בודקים את General_log (אם האפשרות מופעלת) כדי לראות אם יש שאילתות שנרשמו ביומן במהלך חלון האירוע עם פעולות JOIN או SORT שאולי יצרו קבצים זמניים גדולים. אחרת, אפשר להפעיל את התכונה General_log ולתעד את השאילתה באירוע הבא.

  הערה: הפעלת היומן הזה עלולה להשפיע על הביצועים ועל נפח האחסון במהירות, בגלל רמת הפירוט שלו.

• מדדים של Cloud Monitoring. בודקים את המדדים הבאים:

  • ‫cloudsql.googleapis.com/database/mysql/tmp_disk_tables_created_count: עוקב אחרי מספר הטבלאות הזמניות שנוצרו בדיסק, שלעתים קרובות הן הגורם לקבצים גדולים שלא מקושרים.
  • ‫cloudsql.googleapis.com/database/mysql/handler_operations_count: עוקב אחרי העלייה במספר הפעולות באזור באותו זמן.
  • ‫cloudsql.googleapis.com/database/mysql/innodb/active_trx_total_time: עוקב אחרי העסקאות שפעילות למשך זמן ארוך יותר.

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

• היסטוריית עסקאות. בודקים את המדדים הבאים:

  • ‫cloudsql.googleapis.com/database/mysql/innodb/history_list_length metric: אורך רשימת היסטוריה גבוה יכול להיגרם מעסקאות שפועלות במשך זמן רב וחוסמות את הטיהור של יומני הביטול, מה שיכול גם לתרום לבעיות בשימוש בדיסק.
  • ‫cloudsql.googleapis.com/database/mysql/innodb/active_trx_longest_time: עסקאות שפועלות לאורך זמן במהלך התקופה של שימוש גבוה בדיסק.

אופטימיזציה של שאילתות

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

כדי לבצע אופטימיזציה של שאילתה, אפשר לבצע את הפעולות הבאות:

• מוסיפים אינדקסים מתאימים.
• מבצעים רפקטורינג לצירופים מורכבים או לפעולות מיון.

מידע נוסף זמין במאמר בנושא שיפור שאילתות.

הגדרה של מעקב והתראות

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

אפשר ליצור התראות לגבי מדדים שמצביעים על צריכת משאבים גבוהה או על דפוסי שאילתות שידוע שהם יוצרים קבצים זמניים גדולים.

שם המדד	תיאור	סף ההתראה המומלץ
cloudsql.googleapis.com/database/disk/utilization	אחוז ניצול נפח האחסון שהוקצה. המדד הזה עוקב אחרי השימוש הכולל בקיבולת הדיסק.	יותר מ-80% (למשך 5 דקות)
cloudsql.googleapis.com/database/disk/bytes_used	מספר הבייטים הכולל של נפח האחסון שבו נעשה שימוש במופע של מסד הנתונים. המדד הזה עוקב אחרי הגידול האבסולוטי בצריכת הדיסק.	מעקב אחרי המדד database/disk/quota.

במאמרים סקירה כללית על התראות ומעקב אחרי מכונות Cloud SQL מוסבר איך מגדירים התראות ומעקב אחרי מדדים של Cloud SQL.