‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

שימוש גבוה בקובצי 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.

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

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

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

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

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

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

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

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.