La gestion des entrées/sorties fait un important appel à la mémoire pour fluidifier la circulation des données entre les programmes et les disques.

En lecture différents mécanismes permettent de stocker en mémoire le résultat d'un accès disque (en général bien plus "gros" que les données strictement demandées, les disques sont organisés en blocs de 4K et les blocs lus par paquets) ce qui permet lors d'un accès ultérieur séquentiel de pouvoir immédiatement répondre à la demande du programme depuis la mémoire bien plus rapide que le disque. Cela ne pose que peu de problèmes, s'il n'y a pas assez de mémoire pour un programme, la machine libère du cache et y installe le programme. Les données "ecrasées" pourront être relues depuis le disque.

En écriture le même genre de mécanisme est utilisé mais la gestion est beaucoup plus délicate car il faut écrire les données "assez souvent" pour ne pas en perdre sur une coupure ou pour permettre aux autres d'en disposer. Lorsq'un programme effectue un ordre d'écriture le contenu de la demande est stocké en mémoire et le programme est "libéré" pour la suite de son activité. "Un peu plus tard" les données sont écrites physiquement par le système sur le disque. La mémoire ne doit pas être réallouée avant que l'écriture soit entièrement réalisée sur disque, les pages mémoires modifiées sont donc marquées "sales" et ne peuvent être utilisées immédiatement.

Les expressions "assez souvent" et "plus tard" laissent beaucoup d'imprécision, mais en fait il existe un certain nombre de paramètres qui permettent de jouer sur la fréquence de "assez souvent" et sur les éléments qui permettent au système de décider que "plus tard" est arrivé et qu'il doit écrire les données sur le support physique. Voici l'explication de quelques unes de ces variables, qui, comme d'habitude peuvent être modifiées de manière permanente en mettant des valeurs dans "/etc/sysctl.conf" et lues dans /proc/vm/.....

/proc/sys/vm/dirty_writeback_centisecs (default 500) Nombre de "centisecondes" au bout desquelles "pdflush" écrit sur le disque. En général à ne pas toucher.

/proc/sys/vm/dirty_expire_centiseconds (default 3000) Nombre de centisecondes au bout desquelles "pdflush" doit écrire les pages "sales". Le défaut est de 30 secondes --> il y a 30 secondes de décalage entre ecriture logique et physique.

/proc/sys/vm/dirty_background_ratio (default 10 parfois 5) Pourcentage maxi de mémoire utlisé avant que pdflush ecrive. La quantité de mémoire prise en compte est : ( MemFree + Cached - Mapped ) En bref les écritures ne sont réalisées physiquement que quand : - elles on été faites depuis plus de quot;dirty_expire_centiseconds" ou - plus de 10% de ( MemFree + Cached - Mapped ) de la mémoire est utilisé par des pages "sales".

/proc/sys/vm/dirty_ratio (default 40, parfois 20): Pourcentage maxi de la mémoire totale qui peut être utilisé par les pages "sales" avant que le système force les processes à écrire eux-même physiquement au lieu de continuer à générer des écritures en mémoire. Il est à noter que tous les processes sont bloqués en écriture lorsque cela arrive et non pas seulement le process fautif.

Quelques pistes de tuning.

1) D'abord quelques cas "problématiques". En cas d'écriture intensive ou si un ordre "fsync" (utilisé pour synchronisation du file système) arrive il faut synchroniser les fichiers et les métadata cela déclenche un énorme volume d'écriture qui peut bloquer le système pendant un certain temps (le temps que tout soit écrit). Un autre phénomène est le "pompage", un process écrit très vite pendant un certain temps puis ralentit (dès que les écritures physiques commencent) et se maintient à une vitesse de croisière (fonction de la vitesse d'écriture).

2) Quelques pistes de solutions. Adapter les paramètres de gestion des caches. - dirty_background_ratio : le premier à réduire s'il est à 10 le passer à 3 ou 5

- dirty_ratio : on peut parfois constater des améliorations en l'abaissant, mais, là aussi attention aux effets de bord. L'abaissement tend à diminuer la compétition entre différents programmes gros "écriveurs".

- dirty_expire_centisecs : essayer de le réduire un peu, mais il peut y avoir des effets de bord gênants. Trop le réduire (moins de quelques secondes) peut amener à augmenter la quantité d'IO car les pages modifiées sont assez souvent re-modifiées dans la foulée déclenchant une deuxième écriture.

- /proc/sys/vm/dirty_writeback_centisecs : à toucher en dernier recours, il peut être légèrement réduit.

Swapping : Le swapping tend à "virer" dans le swap les processes un peu endormis pour conserver de la mémoire pour les caches. Ce comportement (plus ou moins agressif) peut être contrôlé par le paramètre "swappiness". cf /proc/sys/vm/swappiness 
Augmenter ce paramètre favorise le "swap" et augmente la disponibilité de mémoire pour le cache, le diminuer diminue la disponibilité de mémoire pour le cache mais améliore le réveil des processes un peu endormis.

Autre paramètre. overcommit_memory : visible dans /proc/sys/vm/overcommit_memory (default 0) 
0 = comportement "standard" à préférer dans la plupart des cas 
1 = toujours "over_commiter" à n'utiliser que pour cetaines applications scientifiques 
2 = ne pas over_commiter au delà de la valeur calculée avec overcommit_ratio overcommit_ratio : visible dans /proc/sys/vm/overcommit_ratio (default 50) Ce paramètre donne au système d'allouer plus de mémoire qu'il n'en a. 
Par exemple avec 1GB de RAM et 2GB de swap la mémoire disponible est de 2GB, un "overcommit_ratio" à 50 (50%) permet au système d'allouer (swap + mémoire physique + 50 * (mémoire physique) / 100). 
Dans notre exemple précédent on aurait donc un espace mémoire maxi de 2 + 1 + 0,5 soit 2,5GB. On peut en général le réduire sans inconvénients dans une utilisation normale.

A NOTER :

Certains logiciels n'apprécient pas/peu l'overcommit et peuvent causer problème en manifestant leur mécontentement lorsque les limites approchent.

10 Février 2024 :

Depuis hier la folie du port 23462, un nombre très importants de hits sur le port 23462. Depuis 01:00 le 9 février j'ai constaté plus de 110000 connexions sur le port 23462, alors que un jour normal je constate de 250 à 350 connexions sur l'ensemble des ports fermés.

Je n'ai pas réussi (pas encore) à trouver l'origine de ce scan à gros volume mais il est probable qu'il s'agit d'un zéro day sur un IOT quelconque.  Un petit graphique sur un peu plus de 24 heures montre bien l'ampleur du phénomène on a atteint plus de 8000 hits par heure sur ce port précis.  Par contre la recherche qui a commencé vers 08:00 le 09/02/3024 s'est quasiment terminée le 10/02/2024 à 00:00.

Mais cette attaque est très bizarre car :

1.  Je n'en ai pas trouvé trace ailleurs ... 
2.  Sa durée a été très limitée
3.  Serai-je le seul à avoir été touché, si oui quelle peut en être la raison ?

Malgré de nombreuses recherches je n'ai rien trouvé sur ce foutu port qui d'après l'IANA n'est même pas assigné !

Linux 5.0 est sorti, pour l'instant en rc1. 
Le noyau se compile sans difficulté particulière et s'installe non moins raisonnablement.

Il tourne sur une machine de test (celle depuis laquelle j'écris en ce moment) depuis deux ou trois jours sans manifester le moindre problème et tous les logiciels testés fonctionnent sans aucune difficulté. 
Le prochain épisode est le test sur une machine supportant XEN pour vérifier que tout va bien de ce coté. Au passage la dernière mise à jour de ma Debian 9 a installé une nouvelle version de XEN : 4.8. 5 après 4.8.4. Bientôt des nouvelles. 
La compilation du noyau 5.0 a duré quelques 17 minutes ... je me rappelle de compilation de noyau de presque 24 heures dans les années 90 ... sur un Amiga pourtant muni d'un processeur 68060 !

Une fois le noyau installé et "grub.cfg" régénéré on reboote et ... ça démarre. 
Testons XEN, vite je lance une machine virtuelle et lance sa mise à jour (Debian), puis une deuxième, puis une troisième ... tout a l'air parfaitement OK, les machines répondent normalement. 
La 5.0 semble bien partie.

Tests 5.0-rc2.

Là j'ai quelques problèmes de plantages aléatoires sans aucune trace dans les logs ... investigations en cours. Je vais attendre la rc3 ou rc4 pour re-tester. 
Après quelques vacances j'ai re-testé la avec 5.0.1 qui, depuis hier, fonctionne sur une machine, a priori aucun incident constaté et des machines KVM se lancent normalement. Oui, je sais que les containers c'est dans l'air du temps ... j'y travaille ! 
Je vais tester un noyau supportant XEN en 5.0.2 et voir si les MV fonctionnent bien. 
Après deux jours de 5.0.2 (Xen) tout semble OK, les machines virtuelles se lancent comme à leur (bonne!) habitude et tous les logiciels testés fonctionnent sans problème apparent. Les quelques plantages (freeze ?) que j'ai pu constater avec la 5.0-rc1 ne se sont pas (pas encore ?) reproduits, cette version 5.0 semble bien partie.

Depuis, 5.0.5 et 5.0.7, 5.0.9. 
Aujourd'hui la plupart de mes machines fonctionnent en version 5.0.5 (avec XEN) et 5.0.7 sans qu'aucun problème ne soit apparu.

Pour continuer la série 5 j'ai installé une version 5.1 sur une machine de test qui tourne imperturbablement.

Un nouveau robot sur le web : chatpgpt se forme sur le web.

Ce site vient de recevoir ce jour la visite d'un nouveau robot : GPTBot/1.0.

Ce nouveau robot semble respecter les fichiers robots.txt et scanne le web comme un grand avec un espacement très correct entre deux accès de pages.
Il est identifié par le user-agent suivant :  
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.0; https://openai.com/gptbot) 

La plage d'adresses utilisées est : 40.83.2.64/28  voir ici : https://openai.com/gptbot-ranges.txt

Depuis j'ai remarqué quelques passages de ce type de robot et aussi de quelques autres sur lesquels je cherche encore des informations.

Se connecter à l'interface de sa BBOX devient un peu sportif. 
Chez moi l'adresse est 192.168.1.254, jusque là il me suffisait d'un :
https://192.168.1.254 pour y accéder ou https://gateway (présent dans mon DNS), 
comme j'y accède rarement je n'avait pas noté de changement depuis la dernière mise 
à jour. 
Mais maintenant si je tente cette opération le browser me répond "mabbox.bytel.fr" site introuvable.

La solution, ajouter : 192.168.1.254   mabbox.bytel.fr  
dans votre fichier /etc/hosts. 
Et là, miracle ça marche. 
Plus récemment Bouygues m'a échangé la BBOX et, curieusement, cela ne se produit plus ... question de version de logiciel de la box ?

Je n'avais plus suivi activement l'activité au niveau du kernel et j'ai été surpris de voir un paquet "linux-image-6.0.0.1" s'installer lors de la mise à jour d'un système en Debian Bookworm. 
Après une petite recherche j'ai vu que c'était déjà la version 6.0.2 de ce kernel. 
Apparament pas de nouveauté fracassante à part, peut-être, un meilleur support des processeurs les plus récents. 
Je vais le tester rapidement sur un AMD Ryzen 7 5800X "pour voir". 
Sur un vieux processeur Intel ( i7-6700) je n'ai pas remarqué quelque chose de "spécial" sinon un fonctionnement "normal" sans particularités notables.
Note Novembre 2022 : malheureusement pour les tests j'utilise une carte Nvidia GT710 (un peu ancienne) et le driver Nvidia ne compile plus (pas encore) avec ce noyau ... il m'a fallu aller sur le site de Nvidia chercher dans les drivers pour les cartes video "anciennes" comme la mienne !
Note janvier 2024 : Depuis çà marche sur une 6.3 avec cette vieille carte et même avec une 6.5 sur une autre machine.

Je ne sais pas pourquoi mais depuis quelques semaines j'ai constaté que les robots de Google s'intéressent particulièrement aux pages commençant par "/manual". 
J'en ai compté plus de 100 sur une journée, je me demande quel est le but de cette recherche. En effet à ma connaissance (et on le voit dans les URL demandées) il s'agit des pages du manuel de Apache, peut-être quelqu'un qui a besoin de formation sur Apache ? 
Je n'arrive pas à comprendre pourquoi une société comme Google s'acharne à balayer le web à la recherche des pages de manuel, auraient-ils perdu la tête ? 
Voici un petit graphique sur les 4 dernières semaines.

C'est assez bizarre qu'une société comme Google s'amuse à recenser les accès possibles aux pages de manuel d'Apache ! 

Quelques mois plus tard cela s'est bien réduit et il ne reste plus que quelques rares erreurs "403" faisant référence à ces fameuses pages de manuel dans toutes les langues, mais cela existe toujours. Est-ce un balayage pour rechercher des sites mal configurés ? 
 

Cette analyse date de 2016, réalisée à partir des logs Apache, ne concerne que ce site (à fin mai 2016) et ne prétends pas être exhaustive. 
Pour les principaux browsers une analyse des archives sur 30 jours (en éliminant les robots), donne les résultats suivants :

Browser	%
Chrome	46%
Firefox	37%
Internet Explorer	5%
Iceweasel	5%

Pour les principaux systèmes (toujours sans les robots) :

Système	%
Windows 7	42%
Windows 10	24%
GNU/Linux	11%
Ubuntu	5%
Mac 10.11	5%
Windows 8.1	4%

Vive les vacances ! 
Juste avant de partir en congés, la machine, déja un peu ancienne, qui héberge ce site a jugé bon de se mettre elle aussi en congés et a refusé de même démarrer, congé probablement définitif ! 
Les vacances étant une chose importante je suis parti en laissant cette pauvre bête en l'état. 
De retour je me suis mis à la recherche d'une nouvelle machine permettant de reprendre le travail ... et de récupérer les données de l'ancienne machine, au moins pour ce qui n'est pas sauvegardé régulièrement. 
C'est fait, et j'ai pu ré-installer la sauvegarde des machines virtuelles depuis une autre machine. Les sauvegardes dans plusieurs lieux c'est bien mieux ... et surtout beaucoup plus sûr. 
Pour ce qui concerne le système et tout le paramétrage des logiciels la plupart des répertoires sont suivis dans Subversion, Eh oui je sais ça date mais ça fonctionne bien. Je passerai à "git" quand j'aurais le temps ... 
J'ai donc pu recréer dans une nouvelle machine les fonctionnalités de l'ancienne qui datait d'environ 8 ans. 
Ce site est donc reparti sur de nouvelles bases et j'espère que cela tiendra au moins aussi longtemps que l'ancienne bécane.

PS : Description rapide de cette (belle) machine :

• Carte mère : PRIME B550M
• Processeur : AMD Ryzen 5 3600
• RAM : 32 Go
• Disque système + VM : 2 x NVME Samsung 980 Pro en Raid 1
• Disques données : 2 x SSD  Western Digital Rouge 2To  en Raid 1
• Vidéo par une "vieille" carte Nvidia qui traînait dans un tiroir
• Debian Bullseye

J'ai mis tous les disques en Raid 1 pour sécuriser au mieux. Cette machine supporte aussi d'autres applications ....

Tout ceci doit être bon au niveau performance car j'ai un peu augmenté la mémoire des machines virtuelles et je leur ai attribué deux processeurs au lieu d'un dans l'ancienne machine (core I5 à 4 coeurs). 
En connexion directe le site réponds instantanément et depuis mon téléphone le temps de réponse est aussi très bon.

Je ne peux m'empêcher de mettre ici quelques éléments de performance mesurés lors du chargement des disques des machines virtuelles. 
Les fichier d'entrée étaient "hébergés" sur un disque amovible (USB) Sandisk très performant. Ces fichiers sont des images de disques obtenues avec "dd" et compressées par "lbzip". 
La restauration se fait donc de la manière suivante :

• Fichier "bz2" sur le disque externe
• Décompression à la volée avec "lbzip2"
• "dd" recopie sur la nouvelle partition LVM dédiée à une VM.
• La partition cible est sur le Raid 1 sur les puces NVME

Les résultats sont les suivants (chiffres donnés par "dd" lui même)

Premier disque avec 2 processeurs pour lbzip2 
615162+47965 records in 
615162+47965 records out 
42949672960 bytes (43 GB, 40 GiB) copied, 173,02 s, 248 MB/s

Deuxième disque avec 3 processeurs pour lbzip2 
1225179+95524 records in 
1225179+95524 records out 
85899345920 bytes (86 GB, 80 GiB) copied, 229,237 s, 375 MB/s

Troisième disque avec 4 processeurs pour lbzip2 
735159+57285 records in 
735159+57285 records out 
51539607552 bytes (52 GB, 48 GiB) copied, 100,055 s, 515 MB/s

J'ai, bien sûr, eu mon lot d'ennuis lors de cette migration mais pas forcément là où j'en attendais, 

Les images sur un site c'est bien beau mais :

• Cela tient de la place
• Cela augmente le volume de données à transférer et donc augmente le temps de réponse.

Pour mes besoins j'ai utilisé trois outils différents :

• Deux outils en ligne de commande car cela permet de travailler "à distance" sans utiliser un interface graphique (idéal pour passer par des connexions SSH peu rapides, vive les vacances).
• Un outil avec interface graphique. 
   

D'abord les outils en ligne de commande :

• Pour les fichiers "PNG" le programme "optipng" fonctionne parfaitement et est disponible en paquet Debian.
• Pour les fichiers "JPEG" le programme "jpegoptim" donne de bons résultats et est, lui aussi, disponible dans les dépôts Debian.

Puis celui à interface graphique :

• "trimage" fonctionne sur tous les types de fichiers (testé avec png et jpeg) et donne de bons résultats avec une grande simplicité d'utilisation. C'est celui que j'utilise de préférence car il fonctionne avec tout format d'image (png, jpeg, ...)