Dans le cadre d’un audit de performance sur un serveur Linux utilisé pour l’hébergement d’un Moodle en production, nous avons constaté une charge anormalement élevée. Après une analyse approfondie des ressources système, nous avons identifié F-Secure Linux Security (EDR) comme étant le principal responsable de cette surcharge. Cet article détaille le processus de diagnostic, les solutions mises en place et l’impact positif de la désactivation de F-Secure sur les performances du serveur.
Table of Contents
📌 Symptômes Observés
L’audit a été lancé suite à des plaintes concernant la lenteur du serveur, avec des requêtes Moodle s’exécutant très lentement et un load average anormalement élevé, dépassant 50 en période d’activité normale. En exécutant la commande top, nous avons rapidement repéré les processus responsables :
top -b -n 1 | head -n 20📊 Résultat :
fsicapd(F-Secure ICAP Daemon) consommait plus de 100 % du CPU.fsaccd, un autre processus F-Secure, affichait également une charge importante.- De nombreux processus PostgreSQL étaient en état
D(uninterruptible sleep), indiquant un blocage au niveau des entrées/sorties disque.
📌 Analyse Approfondie
Pour comprendre l’origine de cette charge anormale, nous avons utilisé plusieurs outils d’audit :
🔍 Surveillance CPU :
ps aux --sort=-%cpu | head -n 10Les résultats montraient clairement fsicapd en tête des processus consommateurs de ressources.
🔍 Analyse des entrées/sorties disque (I/O) :
iostat -x 1 5Un fort taux d’attente (%iowait) a été constaté, indiquant que les ressources disques étaient surexploitées.
🔍 Vérification du swap :
vmstat 1 5Aucun swap excessif n’a été détecté, ce qui confirmait que le problème n’était pas lié à un manque de mémoire vive.
🔎 Découverte du Problème : F-Secure Linux Security (EDR)
Suite aux analyses, nous avons identifié F-Secure Linux Security 64 comme étant le principal responsable de la surcharge du serveur. Ce comportement a déjà été référencé dans un article de RedHat (5201171), où il est décrit que fsicapd peut entrer dans une boucle de forte utilisation CPU, causant un ralentissement extrême du serveur.
⚠️ Causes possibles :
- L’EDR analysait constamment des fichiers temporaires, des caches Moodle et des logs PostgreSQL, générant une charge inutile.
- Aucune exclusion n’avait été configurée pour éviter d’analyser des répertoires critiques à forte activité.
🚀 Résolution du Problème : Désactivation et Suppression de F-Secure
1️⃣ Désactivation Temporaire
Nous avons tenté d’arrêter F-Secure temporairement pour voir son impact :
sudo /opt/f-secure/fsbg/bin/master-switch off❌ Résultat : « Operation not permitted by policy »
La politique de sécurité empêchait cette désactivation. Nous avons donc essayé de tuer les processus manuellement :
sudo pkill -9 fsicapd
sudo pkill -9 fsaccd📉 Impact immédiat : Le load average est passé de 50 à 3 en quelques minutes !
2️⃣ Exclusion des Répertoires Critiques
Pour éviter que F-Secure ne scanne des fichiers inutiles, nous avons modifié la configuration :
📄 Ajout d’exclusions dans /etc/opt/f-secure/fsicapd/fsicapd.conf
[exclusions]
paths=/var/data/moodledata/cache,/var/data/moodledata/sessions,/var/log,/tmp
processes=apache2,php-fpm,postgresPuis redémarrage du service :
sudo systemctl restart fsicapd📉 Impact : Diminution immédiate de la charge CPU.
3️⃣ Suppression Définitive
Après discussion avec l’équipe, la décision a été prise de désinstaller complètement F-Secure pour éviter que ce problème ne réapparaisse.
sudo /opt/f-secure/fsav/bin/uninstall-fsav
sudo rm -rf /etc/opt/f-secure/fsma📉 Impact final : Performance du serveur multipliée par 10 et disparition des ralentissements Moodle.
📊 Résultats Après Suppression de F-Secure
| Avant 🔴 | Après 🟢 |
|---|---|
| Load Average : 50+ | Load Average : 2 – 3 |
fsicapd consommait plus de 100% du CPU | fsicapd n’existe plus |
| Serveur extrêmement lent | Serveur rapide et fluide |
| Requêtes Moodle très lentes | Temps de réponse normal |
| Processus PostgreSQL bloqués | Plus aucun blocage |
🎯 Moralité : Un EDR mal configuré peut causer des ralentissements catastrophiques sur un serveur en production.
🔎 Leçons à Retenir et Recommandations
✅ 1. Toujours Vérifier les Processus Gourmands
L’utilisation de top, ps et iostat permet de rapidement repérer les processus consommateurs de CPU et de disque.
✅ 2. Configurer Correctement un EDR
Si un EDR comme F-Secure est utilisé :
- Configurer des exclusions pour éviter d’analyser en boucle des fichiers temporaires.
- Mettre à jour l’agent pour éviter les bugs liés aux versions obsolètes.
- Surveiller les logs (
/var/log/fsicapd.log) pour détecter toute anomalie.
✅ 3. Se Référer aux Articles Officiels
L’article RedHat 5201171 (lien) explique bien ce problème et comment il peut être résolu.
✅ 4. Ne Pas Hésiter à Supprimer un EDR Mal Optimisé
Si l’EDR consomme plus de ressources qu’il n’en protège, sa suppression peut être la meilleure option.
🔚 Conclusion
Grâce à un audit minutieux des performances système, nous avons identifié F-Secure Linux Security comme étant la cause principale du ralentissement du serveur. La suppression de cet agent a permis de récupérer une machine fluide et réactive, tout en évitant une refonte inutile du serveur.
Si vous constatez des problèmes de performance inexpliqués, pensez à vérifier votre EDR et suivez ces étapes pour retrouver un système performant. 🚀
