Problèmes liés à une utilisation élevée du disque

Cette page décrit les problèmes connus liés à une utilisation élevée du disque et propose des conseils de dépannage.

Voici quelques problèmes connus liés à une utilisation élevée du disque :

• Utilisation élevée des fichiers Temporary_files dans MySQL 8.0 et versions ultérieures.
• Utilisation élevée des fichiers Others dans MySQL 8.0 et versions antérieures.

La consommation de fichiers temporaires est classée dans la catégorie des fichiers tmp_data dans les versions antérieures à MySQL 8.0.

Métrique de répartition du stockage MySQL

La métrique principale utilisée pour surveiller l'utilisation détaillée du disque est cloudsql.googleapis.com/database/disk/bytes_used_by_data_type. Cette métrique fournit une répartition de l'utilisation du disque d'instance par type de données, comme suit :

Type de données	Définition
Binlog	Espace de stockage utilisé par les journaux binaires MySQL, essentiels pour la récupération à un moment précis et la réplication.
Cloudsql_mysql_audit_log	Espace de stockage utilisé par le journal d'audit Cloud SQL pour MySQL.
Data	Inclut les espaces de table InnoDB principaux (fichiers .ibd) et l'espace de table système (ibdata1).
General_log	Espace de stockage utilisé par le journal des requêtes générales.
General_tablespace	Espace de stockage utilisé par l'espace de table système InnoDB, composé des fichiers ibdata*.
Last_sys_tablespace	Espace de stockage utilisé par le dernier espace de table.
Others	Inclut les fichiers système internes.
Redo_log	Espace de stockage consommé par les journaux de rétablissement InnoDB utilisés pour la récupération après plantage.
Relaylog	Espace de stockage utilisé par les journaux de relais sur une instance répliquée lors de la réplication.
Slow_log	Espace de stockage utilisé par le journal des requêtes lentes s'il est activé et stocké sur le disque.
Temporary files	Stockage explicitement suivi pour les fichiers temporaires créés par MySQL.
Temporary_space	Espace de stockage utilisé par les fichiers temporaires du système d'exploitation dans le répertoire /tmp.
Tmp_data	Données temporaires créées par MySQL lors d'opérations telles que le tri et la jointure.
Undo_log	Espace de stockage utilisé par les journaux d'annulation.

Localiser des fichiers dans les catégories Temporary_files et Others

Les requêtes de longue durée (telles que les opérations JOIN, ORDER BY ou GROUP BY complexes) créent de grands fichiers temporaires dans le répertoire MySQL.

Pour les instances MySQL utilisant des versions de maintenance publiées à partir d'avril 2026, ces fichiers temporaires sont explicitement signalés dans la catégorie Temporary_files.

Dans les versions antérieures, les fichiers temporaires sont signalés dans la catégorie Others.

Remarque : Les rapports Temporary_files précis pour MySQL 8.0 ont été introduits pour la première fois dans la version r20260320.00_00. Vous pouvez vérifier la version de maintenance dans la console Google Cloud , sur la page Présentation de l'instance Cloud SQL, dans la section Maintenance.

Résoudre les problèmes d'utilisation élevée du disque

Pour résoudre les problèmes de forte utilisation du disque causés par des fichiers temporaires volumineux, procédez comme suit :

1. Identifiez les requêtes actives de longue durée.
2. Mesures d'atténuation immédiates :
3. Utilisez les insights sur les requêtes.
4. Effectuez une analyse rétrospective.
5. Optimisez les requêtes.
6. Configurez la surveillance et les alertes.

Identifier les requêtes actives de longue durée

Les problèmes d'utilisation élevée du disque sont le plus souvent dus à des requêtes de longue durée (par exemple, des opérations JOIN, ORDER BY ou GROUP BY complexes) qui créent des fichiers temporaires volumineux dans le répertoire MySQL. Ces fichiers temporaires sont classés dans les catégories Temporary_files ou Others.

Les instances MySQL avec les nouvelles versions de maintenance (version r20260320.00_00 et ultérieures) comportent le tableau INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES, qui affiche les fichiers temporaires créés par les requêtes de longue durée et qui sont dissociés (c'est-à-dire que les fichiers existent, mais ne sont pas associés au processus MySQL) par MySQL.

Remarque : Les tables temporaires explicites, c'est-à-dire les tables créées manuellement à l'aide de la commande CREATE TEMPORARY TABLE, sont gérées dans l'espace de table temporaire InnoDB et ne sont pas enregistrées dans la table INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES.

Exécutez la requête suivante pour obtenir la requête de longue durée active :

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;

Exemple de résultat :

+----+------------+------+----------------------------------+------+
| 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)

Pour les instances dont les versions de maintenance sont r20260320.00_00 ou antérieures, utilisez la requête suivante pour obtenir la requête active de longue durée :

SHOW FULL PROCESSLIST;

Dans le résultat, recherchez les opérations qui utilisent généralement des fichiers temporaires sur le disque :

• Opérations JOIN volumineuses, en particulier sans index appropriés.
• Opérations ORDER BY ou GROUP BY complexes sur des ensembles de résultats volumineux.
• Opérations ALTER TABLE volumineuses.

Atténuation immédiate

Si une requête en cours d'exécution est identifiée comme la source de la consommation de disque lors de l'enquête, vous pouvez l'arrêter pour libérer l'espace de fichier temporaire associé.

Pour arrêter la requête, exécutez la commande suivante :

KILL PROCESS_ID;

Remplacez PROCESS_ID par l'ID de processus de la requête :

• Pour les versions de maintenance r20260320 ou ultérieures, vous pouvez récupérer la valeur PROCESS_ID via la colonne SESSION_ID de la table INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES.

• Pour les versions antérieures (version r20260117 ou antérieure) , vous pouvez récupérer la valeur PROCESS_ID à partir du résultat de l'opération SHOW FULL PROCESSLIST.

Après l'arrêt d'une requête responsable d'une consommation élevée de disque via des fichiers temporaires, il peut s'écouler jusqu'à cinq minutes environ avant que ces modifications ne soient enregistrées dans les métriques d'utilisation du disque.

Utiliser les insights sur les requêtes

Nous vous recommandons d'utiliser les insights sur les requêtes pour identifier et affiner les requêtes lentes.

Pour en savoir plus, consultez Utiliser Insights sur les requêtes pour améliorer les performances des requêtes.

Effectuer une analyse rétrospective

Une fois le pic d'utilisation passé, vous pouvez analyser les données historiques pour identifier la cause à l'aide des éléments suivants :

• Insights sur les requêtes. Recherchez les requêtes qui ont pu créer des fichiers temporaires volumineux. Examinez les requêtes listées par récapitulatif des requêtes (y compris les métriques telles que la durée moyenne d'exécution, le nombre de requêtes et le nombre moyen de lignes analysées et renvoyées).

• Slow_log : activez Slow_log et définissez long_query_time sur un seuil approprié. Ce journal capture les requêtes de longue durée à des fins d'analyse et d'optimisation.

• General_log : cochez General_log (si activé) pour les requêtes enregistrées pendant la période de l'incident qui comportent des opérations JOIN ou SORT susceptibles d'avoir généré des fichiers temporaires volumineux. Sinon, vous pouvez activer General_log et capturer la requête lors du prochain événement de ce type.

  Remarque : L'activation de ce journal peut avoir un impact rapide sur les performances et le stockage en raison de sa verbosité.

• Métriques Cloud Monitoring Examinez les métriques suivantes :

  • cloudsql.googleapis.com/database/mysql/tmp_disk_tables_created_count : suit le nombre de tables temporaires créées sur le disque, qui sont souvent à l'origine de fichiers volumineux non associés.
  • cloudsql.googleapis.com/database/mysql/handler_operations_count : suit l'augmentation du nombre d'opérations à cette période.
  • cloudsql.googleapis.com/database/mysql/innodb/active_trx_total_time : suit les transactions actives pendant une période plus longue.

  Une augmentation de ces métriques coïncidant avec le pic d'utilisation du disque suggère fortement que les requêtes générant de grandes tables temporaires étaient à l'origine du problème.

• Historique des transactions. Examinez les métriques suivantes :

  • cloudsql.googleapis.com/database/mysql/innodb/history_list_length metric : une longue liste d'historique peut être due à des transactions de longue durée qui bloquent la purge des journaux d'annulation, ce qui peut également contribuer à des problèmes d'utilisation du disque.
  • cloudsql.googleapis.com/database/mysql/innodb/active_trx_longest_time : transactions de longue durée pendant la période de forte utilisation du disque.

Optimiser les requêtes

Une fois que l'analyse des journaux a identifié les requêtes spécifiques à l'origine des pics de métriques, vous pouvez les optimiser ou les réécrire pour minimiser la génération de fichiers temporaires volumineux.

Pour optimiser une requête, vous pouvez procéder comme suit :

• Ajoutez les index appropriés.
• Refactorisez les jointures ou les opérations de tri complexes.

Pour en savoir plus, consultez Optimisation des requêtes.

Configurer la surveillance et les alertes

Pour éviter de futurs incidents causés par une utilisation incontrôlée de l'espace disque, en particulier en raison des fichiers temporaires générés par les requêtes de longue durée, mettez en place une surveillance et des alertes proactives à l'aide de Monitoring.

Vous pouvez créer des alertes pour les métriques qui indiquent une forte consommation de ressources ou des modèles de requêtes connus pour générer de grands fichiers temporaires.

Nom de la métrique	Description	Seuil d'alerte recommandé
cloudsql.googleapis.com/database/disk/utilization	Pourcentage d'espace disque alloué utilisé. Cette métrique surveille l'utilisation globale de la capacité du disque.	> 80% (pendant plus de cinq minutes)
cloudsql.googleapis.com/database/disk/bytes_used	Nombre total d'octets d'espace disque utilisés par l'instance de base de données. Cette métrique suit la croissance absolue de la consommation de disque.	Surveillez la métrique database/disk/quota.

Pour savoir comment configurer des alertes et la surveillance des métriques Cloud SQL, consultez Présentation des alertes et Surveiller les instances Cloud SQL.