Bien que je ne puisse pas parler de "recherche" publiée par des "revues à comité de lecture" - et je ne voudrais pas avoir à m'y fier pour mon travail quotidien - je peux cependant parler des réalités de centaines de serveurs de production sous une variété de systèmes d'exploitation pendant de nombreuses années :

Il y a trois raisons pour lesquelles un disque plein réduit les performances :

• Le manque d'espace libre : Pensez aux fichiers temporaires, aux mises à jour, etc.
• Dégradation du système de fichiers : La plupart des systèmes de fichiers ne sont pas en mesure d'organiser les fichiers de manière optimale s'il n'y a pas assez de place.
• Dégradation au niveau du matériel : Les disques SSD et SMR ne disposant pas de suffisamment d'espace libre verront leur débit diminuer et, pire encore, leur latence augmenter (parfois de plusieurs ordres de grandeur).

Le premier point est trivial, d'autant plus qu'aucun système de production sain n'utiliserait jamais l'espace d'échange pour l'expansion et la réduction dynamiques des fichiers.

Le deuxième point diffère fortement entre les systèmes de fichiers et la charge de travail. Pour un système Windows avec une charge de travail mixte, un seuil de 70% s'avère tout à fait utilisable. Pour un système de fichiers Linux ext4 avec peu de fichiers mais de grande taille (par exemple, des systèmes de diffusion vidéo), cela peut aller jusqu'à 90+%.

Le troisième point dépend du matériel et du microprogramme, mais les SSD équipés d'un contrôleur Sandforce, en particulier, peuvent se replier en effacement de blocs libres sur des charges de travail d'écriture élevées, ce qui entraîne une augmentation des latences d'écriture de plusieurs milliers de pour cent. Nous laissons généralement 25% de blocs libres au niveau de la partition, puis nous observons un taux de remplissage inférieur à 80%.

Recommandations

Je réalise que j'ai mentionné comment s'assurer qu'un taux de remplissage maximal est appliqué. Quelques réflexions au hasard, aucune d'entre elles n'a fait l'objet d'une évaluation par des pairs (payée, truquée ou réelle), mais toutes proviennent de systèmes de production.

• Utiliser les limites du système de fichiers : /var n'a pas sa place dans le système de fichiers racine.
• Surveillance, surveillance, surveillance. Utilisez une solution toute prête si elle vous convient, sinon analysez la sortie de df -h et laisser sonner l'alarme au cas où. Cela peut vous éviter d'avoir 30 noyaux sur un fs racine avec des mises à jour automatiques installées et fonctionnant sans l'option autoremove.
• Mettez en balance la perturbation potentielle d'un débordement de fs et le coût de son agrandissement : Si vous n'êtes pas sur un dispositif embarqué, vous pourriez simplement doubler ces 4G pour l'enracinement.

Y a-t-il eu des recherches... sur le pourcentage ou la quantité absolue d'espace libre requis par des combinaisons spécifiques de systèmes d'exploitation, de systèmes de fichiers et de technologies de stockage... ?

En 20 ans d'administration système, je n'ai jamais rencontré de recherches détaillant les besoins en espace libre de diverses configurations. Je soupçonne que c'est parce que les ordinateurs sont configurés de façon si diverse qu'il serait difficile de le faire en raison du nombre de configurations possibles.

Pour déterminer l'espace libre nécessaire à un système, il faut tenir compte de deux variables :

1. L'espace minimum requis pour empêcher un comportement indésirable, qui peut elle-même avoir une définition fluctuante.

   Notez qu'il n'est pas utile de définir l'espace libre requis par cette seule définition, car cela équivaut à dire que l'on peut rouler à 80 km/h en direction d'un mur de briques jusqu'au moment où l'on entre en collision avec lui.

2. Le rythme auquel le stockage est consommé, ce qui impose de réserver une quantité variable d'espace supplémentaire, de peur que le système ne se dégrade avant que l'administrateur n'ait le temps de réagir.

La combinaison spécifique du système d'exploitation, des systèmes de fichiers, de l'architecture de stockage sous-jacente, du comportement des applications, de la configuration de la mémoire virtuelle, etc.

C'est pourquoi il existe tant de "pépites" de conseils. Vous remarquerez que beaucoup d'entre eux font une recommandation autour d'une configuration spécifique. Par exemple, "Si vous avez un SSD qui est sujet à des problèmes de performance lorsqu'il approche de sa capacité, restez au-dessus de 20% d'espace libre".

Parce qu'il n'y a pas de réponse simple à cette question, l'approche correcte pour identifier les besoins de l'entreprise est la suivante votre Pour déterminer l'espace libre minimum requis pour un système, il faut prendre en compte les différentes recommandations génériques à la lumière de la configuration spécifique de votre système, puis fixer un seuil, le surveiller et être prêt à l'ajuster si nécessaire.

Ou vous pouvez simplement garder au moins 20% d'espace libre. À moins, bien sûr, que vous n'ayez un volume RAID 6 de 42 To soutenu par une combinaison de SSD et de disques durs traditionnels et un fichier d'échange pré-alloué... (c'est une blague pour les gens sérieux).

Bien sûr, un disque (qu'il s'agisse d'un disque dur ou d'un disque dur SSD) ne se soucie pas du pourcentage d'espace utilisé, à l'exception des disques durs SSD qui sont capables d'effacer leur espace libre à l'avance. Les performances en lecture seront exactement les mêmes, et les performances en écriture seront peut-être un peu moins bonnes sur un SSD. De toute façon, les performances en écriture ne sont pas si importantes sur un disque presque plein, puisqu'il n'y a pas d'espace pour écrire quoi que ce soit.

D'autre part, votre système d'exploitation, votre système de fichiers et vos applications s'attendent à ce que vous disposiez d'un espace libre à tout moment. Il y a 20 ans, il était courant qu'une application vérifie l'espace dont vous disposiez sur le disque avant d'essayer d'y enregistrer vos fichiers. Aujourd'hui, les applications créent fichiers temporaires sans demander votre permission, et se plantent généralement ou se comportent de manière erratique lorsqu'ils ne le font pas.

Les systèmes de fichiers ont une attente similaire. Par exemple, NTFS réserve une grande partie de votre disque pour MFT, mais vous montre toujours cet espace comme étant libre. Lorsque vous remplissez votre disque NTFS au-delà de 80% de sa capacité, vous obtenez Fragmentation MFT ce qui a un impact très réel sur les performances.

En outre, le fait de disposer d'espace libre permet effectivement de lutter contre la fragmentation des fichiers ordinaires. Les systèmes de fichiers ont tendance à éviter fragmentation des fichiers en trouvant le bon emplacement pour chaque fichier en fonction de sa taille. Sur un disque presque plein, ils auront moins d'options et devront donc faire de moins bons choix.

Sous Windows, vous êtes également censé disposer d'un espace disque suffisant pour l'application fichier d'échange qui peut s'agrandir si nécessaire. Si ce n'est pas le cas, vous devez vous attendre à ce que vos applications soient fermées de force. Avoir très peu d'espace de pagination peut en effet aggraver la performance.

Même si votre swap a une taille fixe, être complètement à court d'espace disque peut faire planter votre système et / ou le rendre impossible à démarrer (Windows et Linux), parce que le système d'exploitation s'attend à pouvoir écrire sur le disque pendant le démarrage. Donc oui, atteindre 90% d'utilisation du disque devrait vous faire considérer que vos peintures sont en feu. Pas une seule fois je n'ai vu des ordinateurs qui ne démarraient pas correctement jusqu'à ce que les téléchargements récents soient supprimés pour donner au système d'exploitation un peu d'espace disque.

Pour les SSD, il doit rester de l'espace car le taux de réécriture augmente alors et affecte négativement les performances d'écriture du disque. Le taux d'occupation de 80 % est probablement une valeur sûre pour tous les disques SSD. Certains modèles récents peuvent fonctionner sans problème même avec une capacité occupée de 90 à 95 %.

https://www.howtogeek.com/165542/why-solid-state-drives-slow-down-as-you-fill-them-up/