This blog is hosted by IONOS.fr, a subsidiary of the German IONOS (formerly 1&1), merely because French is a language I can really understand and use, not just get headaches from. The physical hosting is still in Germany, although the various online tools don’t agree on the location: Essen, Frankfurt, or Karlsruhe? Anyway, the incompetent way their shared hosting is designed stroke again.

Last time, it was like this:

  • phpMyAdmin showed 137.1 MiB.
  • IONOS Control Panel said MariaDB took 1.44 GB.
  • I reduced the total size of the DB, as reported by phpMyAdmin, to 93.3 MiB.
  • After a very long time, the occupied space reported by their control panel dropped to 1.26 GB.

This time, when I checked, it was (obviously) worse:

  • phpMyAdmin showed almost 190 MiB (I don’t remember the exact value).
  • IONOS Control Panel said MariaDB took 1.87 GB.
  • I reduced the total size of the DB, as reported by phpMyAdmin, to 179.1 MiB.
  • After some time, the occupied space reported by their control panel dropped to 1.83 GB.
  • Several hours later: 1.78 GB.

The largest table: xbdg_posts = 125.73 MB.

How do they manage to use 1.78 GB to store 179.1 MiB worth of tables?

I had a nice chat with my “conseiller personnel” (yeah, sure), Michel G. He tried what he could but couldn’t do much. He escalated the issue to an admin, who was out to lunch.

Upon his return, that admin was completely useless. He pointed to the same “help” page already indicated by Michel, Dépassement de capacité de la base de données MySQL ou MariaDB.

We left the issue unsolved, in the hope that later, some sync will make IONOS show less than 1.83 GB. Well, not 1.78 GB, but much less!

Meanwhile, I received two follow-up e-mails from IONOS’ support.

One, from Mireille C., sending me to the same non-helpful “help” page.

A second one, from Barka Z. (“Précisions concernant l’affichage de l’espace utilisé”):

Je fais suite au retour du service administrateur concernant votre demande.

Le quota affiché dans votre espace client n’est pas mis à jour en temps réel, mais environ une fois par heure.

Par ailleurs, l’affichage dans PHPMyAdmin ne reflète pas la taille réelle de la base de données. En effet, il ne prend pas en compte l’espace occupé par les données supprimées dans les tables InnoDB, ni la taille de la structure des fichiers.

De son côté, le quota IONOS est calculé sur la taille réelle des fichiers présents sur le serveur, ce qui peut expliquer l’écart constaté.

To which I replied:

« l’affichage dans PHPMyAdmin … ne prend pas en compte l’espace occupé par les données supprimées dans les tables InnoDB »

C’est exactement ça le problème ! Le dump UpdraftPlus de ma base de données donne 112 MiB / 117 MB (24 Mo en comprimé), donc c’est la faute du manque d’optimisation sur le serveur.

« le quota IONOS est calculé sur la taille réelle des fichiers présents sur le serveur, ce qui peut expliquer l’écart constaté. »

L’écart est IMMENSE !

Le problème principal réside dans le fait qu’InnoDB ne libère pas d’espace disque pour le système d’exploitation lorsque des lignes sont supprimées : il se contente de marquer cet espace comme réutilisable en interne. Pour récupérer réellement de l’espace disque, il faut reconstruire les tables.

Sur un hébergement mutualisé comme IONOS, le client ne dispose pas des privilèges nécessaires pour exécuter OPTIMIZE TABLE ou ALTER TABLE. C’est alors à vous d’effectuer cette opération côté serveur.

Solutions possibles que vous pourriez mettre en œuvre :

1. Exécuter OPTIMIZE TABLE sur toutes les tables (nécessite le privilège ALTER dont vous disposez en tant qu’hébergeur) :

-- Reconstruit toutes les tables et libère l'espace
OPTIMIZE TABLE xbdg_posts, xbdg_postmeta, xbdg_options, ...;

Inconvénient : Verrouille les tables brièvement avec impact sur le site, d’autant plus qu’il s’agit d’un serveur mutualisé.

2. Reconstruction :

-- Alternative : Force la reconstruction sans verrouillage total
ALTER TABLE xbdg_posts ENGINE=InnoDB;

D’autres tables pourrait avoir des données supprimées qui occuppent toujours du place.

3. La vraie solution : activer innodb_file_per_table, si ce n’est pas déjà activé sur MariaDB (je ne pourrais pas le savoir) :
– Chaque table aurait son propre fichier .ibd
– Vous pourriez alors optimiser individuellement
– Les suppressions libéreraient réellement l’espace disque

4. Maintenance serveur globale :

# En ligne de commande (ce que seulement un admin IONOS peut faire)
mariadb-check --optimize --all-databases

Ne prenez pas ça pour une réfutation, mais, côté technique, IONOS ne me semble pas bien géré.

Nothing will happen. Like, ever. They don’t have a ticketing system. There isn’t a ticket number to reference, to track, to follow, to use as history.

Deutsche Qualität is a bad joke. IONOS is a bad joke. I sincerely hope that China buys the entire Europe, because there is no way it can get any worse!