La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: vivien le 14 décembre 2016 à 22:01:25
-
Optimisation d'un serveur Linux pour un SSD : réduire au maximum les écritures sur le SSD
LaFibre.info est passé sur un SSD, suite à la panne du disque dur conventionnel en novmbre (cf Le SSD de LaFibre.info (https://lafibre.info/evolution/ssd-lafibre-info/))
Je vous présentes les optimisations que j'ai réalisées afin de prolonger au maximum la durée de vie du SSD (limité en écriture) :
1/ RAM disk pour /tmp (https://lafibre.info/serveur-linux/optimisation-ssd/msg398266/#msg398266)
2/ Persistent RAM disk pour les fichiers de Munin (https://lafibre.info/serveur-linux/optimisation-ssd/msg398268/#msg398268)
3/ Persistent RAM disk pour les RRD de SmokePing (https://lafibre.info/serveur-linux/optimisation-ssd/msg398305/#msg398305)
4/ Désactivation de la compression des fichiers de LOG (https://lafibre.info/serveur-linux/optimisation-ssd/msg398309/#msg398309)
5/ Écriture des fichiers de log peu importants dans un ramdisque (https://lafibre.info/serveur-linux/optimisation-ssd/msg398324/#msg398324)
6/ Réduction du swap avec vm.swappiness (https://lafibre.info/serveur-linux/optimisation-ssd/msg398661/#msg398661)
7/ [je doute que cela soit efficace] Augmenter l’intervalle d’écritures périodiques (https://lafibre.info/serveur-linux/optimisation-ssd/msg398665/#msg398665)
8/ Augmenter l'overprovisionning, pour augmenter la durée de vie du SSD (https://lafibre.info/serveur-linux/optimisation-ssd/msg398667/#msg398667)
-
1/ RAM disk pour /tmp
De nombreuses données temporaires, généralement rapidement effacées, sont crées dans /tmp
Il est donc important de ne pas écrire ces information sur le SSD.
La création d'un RAM disque pour /tmp se fait dans /etc/fstab :
nano /etc/fstab rajouter ces 2 lignes dans le fichier /etc/fstab :
# Placer /tmp sur un RamDisque
tmpfs /tmp tmpfs defaults,size=40% 0 0
=> Créer un ramdisque d'une capacité maximum de 40% de la mémoire vive.
Comme tous les tmpfs, la RAM n'est utilisée qu'a hauteur des données mises sur le disque.
Autre solution : indiquer en Mo la taille du ramdisque :
# Placer /tmp sur un RamDisque
tmpfs /tmp tmpfs defaults,size=4g 0 0
(https://lafibre.info/images/smileys/exclamation2.gif)
/tmp ne dois jamais être saturé, sous peine de blocage de nombreux process sur un serveur.
Il est donc nécessaire de fortement sur-estimer la taille de /tmp et de superviser son utilisation.
-
2/ Persistent RAM disk pour Munin
(tutoriel avec un script system V pour Ubuntu server 14.04 LTS - il faut faire des modifications pour Ubuntu server 16.04 LTS qui utilise systemd)
Pour vous montrer les gains, voici l'évolution IO disque sur une machine qui héberge plusieurs sites web et un Munin. Le 13 la base de donnée est passée sur ramdisque persistant et le 14 j'ai passé les fichiers images de munin :
(https://lafibre.info/images/stats/201612_diskstats_iops_munin.png)
Le gain est impressionnant !
Tutoriel :
1/ Créer le fichier /etc/init.d/munin-ramdisk : sudo nano /etc/init.d/munin-ramdisk
#! /bin/sh
#
# /etc/init.d/munin-ramdisk
#
### BEGIN INIT INFO
# Provides: munin-ramdisk
# Required-Start: $munin + tmpfs for /tmp in file /etc/fstab
# Required-Stop: Attention: arreter Munin avant d'executer ce script Stop
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Nécessaire pour que Munin écrive ses données sur un RamDisque
# Description: Start: Créeation des dossiers nécessaire pour que Munin
# utilise le RamDisque /tmp (crée avant par /etc/fstab)
# Stop : Sauvegarde des fichiers du ramdisque sur le SSD
### END INIT INFO
# Dossiers par défault :
#dbdir /var/lib/munin
#htmldir /var/cache/munin/www
case "$1" in
start)
echo "Munin: Création des dossiers dans le ramdisk /tmp"
mkdir /tmp/munin-www
chown munin:munin /tmp/munin-www
echo "Munin: Copie des fichiers du SSD /home/munin-rrd.tar.lzop vers le ramdisk /tmp/munin-rrd"
cd /tmp
tar --lzop -xf /home/munin-rrd.tar.lzop
#chown munin:munin /tmp/munin-rrd
echo [`date +"%d-%m-%Y %H:%M"`] Démarrage du serveur : Fichiers Munin copiés sur le ramdisk >> /tmp/munin-ramdisk.log
;;
sync)
echo "Munin: Sauvegarde des fichiers du ramdisk /tmp/munin-rrd vers le SSD /home/munin-rrd.tar.lzop"
#mv -f /home/munin-rrd.tar.lzop /home/munin-rrd-old.tar.lzop
rm /home/munin-rrd.tar.lzop
cd /tmp
tar --lzop -cf /home/munin-rrd.tar.lzop munin-rrd
echo [`date +"%d-%m-%Y %H:%M"`] SYNC : Sauvegarde des fichiers Munin sur le SSD >> /tmp/munin-ramdisk.log
;;
stop)
echo "Munin: Sauvegarde des fichiers du ramdisk /tmp/munin-rrd vers le SSD /home/munin-rrd.tar.lzop"
rm /home/muni-rrd.tar.lzop
cd /tmp
tar --lzop -cf /home/munin-rrd.tar.lzop munin-rrd
echo [`date +"%d-%m-%Y %H:%M"`] Extinction du serveur : Sauvegarde des fichiers Munin sur le SSD >> /tmp/munin-ramdisk.log
;;
*)
echo "Usage: /etc/init.d/munin-ramdisk {start|stop|sync}"
exit 1
;;
esac
exit 0
2/ Le rendre exécutable : sudo chmod +x /etc/init.d/munin-ramdisk
3/ Installer lzop : sudo apt install lzop
4/ Lancer le script avant le démarrage de smokeping, pour restaurer les données lors du lancement du système d'exploitation et l’exécuter après l’arrêt de munin lors de l’arrêt du système : sudo update-rc.d munin-ramdisk defaults 10 30
# update-rc.d munin-ramdisk defaults 10 30
Adding system startup for /etc/init.d/munin-ramdisk ...
/etc/rc0.d/K30munin-ramdisk -> ../init.d/munin-ramdisk
/etc/rc1.d/K30munin-ramdisk -> ../init.d/munin-ramdisk
/etc/rc6.d/K30munin-ramdisk -> ../init.d/munin-ramdisk
/etc/rc2.d/S10munin-ramdisk -> ../init.d/munin-ramdisk
/etc/rc3.d/S10munin-ramdisk -> ../init.d/munin-ramdisk
/etc/rc4.d/S10munin-ramdisk -> ../init.d/munin-ramdisk
/etc/rc5.d/S10munin-ramdisk -> ../init.d/munin-ramdisk
5/ Créer un ramdisque de 4Go max pour /tmp au démarrage du système d'exploitation : éditer /etc/fstab sudo nano /etc/fstab
6/ Rajouter à la fin du fichier /etc/fstab les lignes suivantes :
# Placer /tmp sur un RamDisque
tmpfs /tmp tmpfs defaults,size=4g 0 0
7/ Créer les dossiers les fichiers de Munin : sudo mkdir /tmp/munin-www ; sudo mkdir /tmp/munin-rrd
8/ Lui donner les droits SmokePing : sudo chown munin:munin /tmp/munin-www ; sudo chown munin:munin /tmp/munin-rrd
9/ Copier les fichiers dans /tmp/smokeping-rrd depuis le dossier avec les .rrd : sudo cp -r -p /var/lib/munin/* /tmp/munin-rrd
10/ Faire une première sauvegarde : sudo service munin-ramdisk sync
11/ Vérifier que la sauvegarde est ok (les fichiers doivent avoir munin:munin comme propriétaire)
12/ Faire un reboot
13/ Vérifier que le ramdisque de 4Go est bien en place et que les fichiers munin sont bien à l'intérieur
14/ Modifier les fichiers de Munin pour pointer dans le dossier /tmp : sudo nano /etc/munin/munin.conf
Modifier les lignes suivantes :
#dbdir /var/lib/munin
#htmldir /var/cache/munin/wwwpar
dbdir /tmp/munin-rrd
htmldir /tmp/munin-www
15/ Modifier les fichiers de configuration Apache pour que l'url des images crée par SmokePing pointe vers /tmp/munin-www
16/ Redémarrer et vérifier que tout est ok. Il faut attendre 3 minutes pour que tous les fichiers soient présent dans /tmp/munin-www (pas de sauvegarde de ce dossier)
17/ Supprimez les 2 dossiers d'origine : /var/lib/munin et /var/cache/munin/www
18/ Mettre en place une sauvegarde automatique à 11h58 : sudo crontab -e
# Sauvegarde du ramdisque persistant
58 11 * * * service munin-ramdisk sync
-
3/ Persistent RAM disk pour SmokePing
(tutoriel avec un script system V pour Ubuntu server 14.04 LTS - il faut faire des modifications pour Ubuntu server 16.04 LTS qui utilise systemd)
J'ai mis sur plusieurs serveurs (même à disque conventionnel) le système de "persistent RAM disk". Sur une machine qui réalisait un peu de SmokePing et du Munin (outil pour monitorer des serveurs Linux), j'ai divisé par 100 le volume des écritures (il y a très peu de lectures vu que les données sont toutes en cache quelques heures après un reboot)
Que ce soit pour Smokeping ou Munin, le principe est le même : on met les données au format RRD (base de donnée circulaire) dans un ramdisque sauvegardé 1 fois par jour et immédiatement avant un reboot ou un extinction du système.
Les fichiers images .png générées ne sont eux pas sauvegardés : ils sont générés à chaque appel de page avec SmokePing et ils sont générés toutes les 5 minutes avec Munin.
Utilitaire à installer : lzop (sudo apt install lzop) : lzop permet une compression proche de gzip, mais 4 fois plus rapide. Le but est donc de créer le fichier de sauvegarde le plus rapidement possible quand ont reboot le serveur et le restaure le plus rapidement possible. Ne mettre aucune compression n'est pas une bonne idée car on perdra du temps avec les E/S disque. Lzop va compresser un peu pour une charge CPU / ram quasiment nulle.
Tutoriel:
1/ Créer le fichier /etc/init.d/smokeping-ramdisk : sudo nano /etc/init.d/smokeping-ramdisk
Code du script /etc/init.d/smokeping-ramdisk :
#! /bin/sh
#
# /etc/init.d/smokeping-ramdisk
#
### BEGIN INIT INFO
# Provides: smokeping-ramdisk
# Required-Start: $smokeping + tmpfs for /tmp in file /etc/fstab
# Required-Stop: Attention: arreter Smokeping avant d'executer ce script Stop
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Nécessaire pour que SmokePing écrive ses données sur un RamDisque
# Description: Start: Créeation des dossiers nécessaire pour que SmokePing
# utilise le RamDisque /tmp (crée avant par /etc/fstab)
# Stop : Sauvegarde des fichiers du ramdisque sur le SSD
### END INIT INFO
case "$1" in
start)
echo "SmokePing: Création des dossiers dans le ramdisk /tmp"
mkdir /tmp/smokeping-cache
chown www-data:www-data /tmp/smokeping-cache
mkdir /tmp/smokeping-dyndir
chown smokeping:www-data /tmp/smokeping-dyndir
chmod 775 /tmp/smokeping-dyndir
echo "SmokePing: Copie des fichiers du SSD /home/smokeping-rrd.tar.lzop vers le ramdisk /tmp/smokeping-rrd"
cd /tmp
tar --lzop -xf /home/smokeping-rrd.tar.lzop
#chown smokeping:smokeping /tmp/smokeping-rrd
echo [`date +"%d-%m-%Y %H:%M"`] Démarrage du serveur : Fichiers SmokePing copiés sur le ramdisk >> /tmp/smokeping-ramdisk.log
;;
sync)
echo "SmokePing: Sauvegarde des fichiers du ramdisk /tmp/smokeping-rrd vers le SSD /home/smokeping-rrd.tar.lzop"
#mv -f /home/smokeping-rrd.tar.lzop /home/smokeping-rrd-old.tar.lzop
rm /home/smokeping-rrd.tar.lzop
cd /tmp
tar --lzop -cf /home/smokeping-rrd.tar.lzop smokeping-rrd
echo [`date +"%d-%m-%Y %H:%M"`] SYNC : Sauvegarde des fichiers SmokePing sur le SSD >> /tmp/smokeping-ramdisk.log
;;
stop)
echo "SmokePing: Sauvegarde des fichiers du ramdisk /tmp/smokeping-rrd vers le SSD /home/smokeping-rrd.tar.lzop"
rm /home/smokeping-rrd.tar.lzop
cd /tmp
tar --lzop -cf /home/smokeping-rrd.tar.lzop smokeping-rrd
echo [`date +"%d-%m-%Y %H:%M"`] Extinction du serveur : Sauvegarde des fichiers SmokePing sur le SSD >> /tmp/smokeping-ramdisk.log
;;
*)
echo "Usage: /etc/init.d/persistent-ramdisk {start|stop|sync}"
exit 1
;;
esac
exit 0
2/ Le rendre exécutable : sudo chmod +x /etc/init.d/smokeping-ramdisk
3/ Installer lzop : sudo apt install lzop
4/ Lancer le script avant le démarrage de smokeping, pour restaurer les données lors du lancement du système d'exploitation et l’exécuter après l’arrêt de smokpeping lors de l’arrêt du système : sudo update-rc.d smokeping-ramdisk defaults 10 30
# update-rc.d smokeping-ramdisk defaults 10 30
Adding system startup for /etc/init.d/smokeping-ramdisk ...
/etc/rc0.d/K30smokeping-ramdisk -> ../init.d/smokeping-ramdisk
/etc/rc1.d/K30smokeping-ramdisk -> ../init.d/smokeping-ramdisk
/etc/rc6.d/K30smokeping-ramdisk -> ../init.d/smokeping-ramdisk
/etc/rc2.d/S10smokeping-ramdisk -> ../init.d/smokeping-ramdisk
/etc/rc3.d/S10smokeping-ramdisk -> ../init.d/smokeping-ramdisk
/etc/rc4.d/S10smokeping-ramdisk -> ../init.d/smokeping-ramdisk
/etc/rc5.d/S10smokeping-ramdisk -> ../init.d/smokeping-ramdisk
5/ Créer un ramdisque de 4Go max pour /tmp au démarrage du système d'exploitation : éditer /etc/fstab sudo nano /etc/fstab
6/ Rajouter à la fin du fichier /etc/fstab les lignes suivantes :
# Placer /tmp sur un RamDisque
tmpfs /tmp tmpfs defaults,size=4g 0 0
7/ Créer le dossier pour les fichiers RRD de SmokePing : mkdir /tmp/smokeping-rrd
8/ Lui donner les droits SmokePing : sudo chown smokeping:smokeping /tmp/smokeping-rrd
9/ Copier les fichiers dans /tmp/smokeping-rrd depuis le dossier avec les .rrd : sudo cp -r -p * /tmp/smokeping-rrd
10/ Faire une première sauvegarde : sudo service smokeping-ramdisk sync
11/ Vérifier que la sauvegarde est ok (les fichiers doivent avoir smokeping:smokeping comme propriétaire)
12/ Faire un reboot
13/ Vérifier que le ramdisque de 4Go est bien en place et que les fichiers smokeping sont bien à l'intérieur
14/ Modifier les fichiers de SmokePing pour pointer dans le dossier /tmp : sudo nano /etc/smokeping/config.d/pathnames
Modifier les lignes suivantes : (seul /tmp/smokeping-rrd est sauvegardé, /tmp/smokeping-cache et /tmp/smokeping-dyndir est vide a chaque démarrage du système, ce qui ne pose aucun problème)
imgcache = /tmp/smokeping-cache
datadir = /tmp/smokeping-rrd
dyndir = /tmp/smokeping-dyndir
15/ Modifier les fichiers de configuration Apache pour que l'url des images crée par SmokePing pointe vers /tmp/smokeping-cache
16/ Redémarrer et vérifier que tout est ok
17/ Supprimez les 3 dossiers d'origine : /var/cache/smokeping/images , /var/lib/smokeping et /var/lib/smokeping/__cgi
18/ Mettre en place une sauvegarde automatique à 11h59 : sudo crontab -e
# Sauvegarde du ramdisque persistant
59 11 * * * service smokeping-ramdisk sync
-
4/ Désactivation de la compression des fichiers de LOG
Compresser les fichiers de log nécessite des opérations d'écritures supplèmentaires, j'ai donc désactivé cette fonction dans tous les fichiers de log :
1/ Aller dans le dossier de la conf logrotate : cd /etc/logrotate.d/
2/ Chercher les fichiers de conf avec compress : grep compress *
3/ Pour chaque fichier dans le dossier /etc/logrotate.d/ :
A/ Supprimer la ligne delaycompress si présente
B/ Modifier la ligne compress par nocompress
4/ Supprimer les .gz existants dans les dossiers des log : sudo rm /var/log/*.gz ; rm /var/log/*/*.gz
(Si vous ne supprimez pas les fichiers, ils vont rester)
-
5/ Écriture des fichiers de log peu importants dans un ramdisque
J'ai catégorisé les fichiers de log en 3 catégories :
- Les fichiers de log importants qui ont écrit sur le SSD puis sauvegardés
- Les fichiers de log normaux qui sont écrit sur le SSD
- Les fichiers de log peu important pour lesquels ils n'est pas important de perdre le contenu à chaque reboot
Le fichier access.log d'un site internet fait pour moi partie ds log importants.
Les fichiers error.log (et access.log des connexions aux serveur sans nom de domaine) ne sont pas importants : je les place sur le ramdisque dans /tmp
...
Modifier l'emplacement des log Apache2
sudo nano /etc/apache2/apache2.conf
Chercher error.log
Remplacez ErrorLog ${APACHE_LOG_DIR}/error.log
Par ErrorLog /tmp/apache2-error.log
sudo nano /etc/apache2/conf-available/other-vhosts-access-log.conf
Remplacez CustomLog ${APACHE_LOG_DIR}/other_vhosts_access.log vhost_combined
Par CustomLog /tmp/apache2-other-vhosts-access.log vhost_combined
Il faut faire la même chose pour les différents fichiers de configuration de vos sites web qui sont dans /etc/apache2/sites-available/
PS : ne pas oublier sudo nano /etc/apache2/sites-available/000-default.conf
sudo service apache2 reload
Vérifier que les nouveaux fichiers sont bien crées dans /tmp
Effacer les anciens log : sudo rm /var/log/apache2/*
Modifier l’emplacement de rotation des log Apache : sudo nano /etc/logrotate.d/apache2
/home/log/*/*.log permet de demander la rotation des fichiers .log de tous les sous-dossiers de /home/log (c'est là que je place les fichiers de log importants)
Note: si vous avez supprimé le dossier /var/log/apache2, n'oublier pas de supprimer la ligne dans /etc/logrotate.d/apache2 pour éviter une erreur si le dossier n'existe pas.
/tmp/apache*.log
/home/log/*/*.log
/var/log/apache2/*.log {
daily
missingok
rotate 40
nocompress
notifempty
create 666 vivien vivien
sharedscripts
postrotate
/etc/init.d/apache2 reload > /dev/null;
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}
Modifier l'emplacement l'emplacement des log MySQL
sudo nano /etc/mysql/my.cnf
Remplacer log_error = /var/log/mysql/error.log par log_error = /tmp/mysql-error.log
Remplacer # log_slow_queries = /var/log/mysql/mysql-slow.log par # log_slow_queries = /tmp/mysql-slow.log
sudo service mysql reload
Vérifier que les nouveaux fichiers sont bien crées dans /tmp
Effacer les anciens log : sudo rm /var/log/mysql/*
-
6/ Réduction du swap avec vm.swappiness
Je passe swappiness de la valeur par défaut 60 à 10 : le swap est utilisé uniquement quand la mémoire est utilisée à plus de 90% (100-10) contre 40% par défaut (100-60). Cela diminue fortement l’utilisation du swap. Je n'ai mis que 1 Go de partition de swap sur le SSD.
Pour modifier cette option : sudo nano /etc/sysctl.conf
rajouter cette ligne dans le fichier /etc/sysctl.conf (peu importe l'emplacement) :
vm.swappiness = 10
Personnellement, cela n'a plus rien a voir avec le SSD, mais il est possible de mettre d'autres commandes pour une serveur fortement demandé :
vm.swappiness = 10
net.ipv4.tcp_max_syn_backlog = 1024
net.core.somaxconn = 512
-
7/ Augmenter l’intervalle d’écritures périodiques
[je doute que cela soit efficace, il me semble qu l'écriture est fait immédiatement, sauf si le disque est déjà occupé]
Le modification de ce paramètre se fait au moment de monter le système de fichier, c'est l'option commit=300 pour 300 secondes = 5 minutes
Par défaut, les données sont écrites sur un disque dur dans un temps maximum de 30 secondes. Si tu envoi un fichier de 500 Mo vers une clé USB, tu vois que c'est presque immédiat et que la clé travaille bien après que le transfert soit théoriquement terminé.
commit=secondes
Définir l’intervalle d’écritures périodiques, 30 secondes par défaut. Les plus grandes valeurs décalent la synchronisation des données vers le stockage permanent, avec des conséquences évidentes si le système plante. Aucune limite haute n’est forcée, mais un avertissement est affiché si elle est supérieure à 300 secondes (5 minutes).
sudo nano /etc/fstab :
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=fbe1d9a3-4bf9-49c1-b826-2437d58ad97e / ext4 commit=300,errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=B6EF-0D72 /boot/efi vfat defaults 0 1
# /home was on /dev/sda4 during installation
UUID=b7e28cf3-5b6b-4f2b-9ea6-cba8ee3c02ec /home ext4 commit=300,defaults 0 2
# swap was on /dev/sda3 during installation
UUID=d480f518-8f40-4867-b0db-1953a11fa4dd none swap sw 0 0
# Placer /tmp sur un RamDisque
tmpfs /tmp tmpfs defaults,size=4g 0 0
Redémarrer pour la prise en compte : sudo reboot
Il est possible de vérifier que le paramètre est bien passé :
$ dmesg | grep EXT4
[ 3.260881] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[ 3.945954] EXT4-fs (sda2): re-mounted. Opts: commit=300,errors=remount-ro
[ 4.032655] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: commit=300
-
8/ Augmenter l'overprovisionning, pour augmenter la durée de vie du SSD
Il est recommandé de laisser un peu plus de 10% du disque non partitionné, afin d'augmenter l'overprovisionning.
Extrait de la doc :
La fonction Over provisioning permet de redimensionner les partitions d’un lecteur. Les SSD fonctionnement mieux et durent plus longtemps lorsqu’ils disposent d’une grande quantité d’espace utilisable comme espace d’échange.
Durant les périodes d’inactivité, l’espace d’échange est utilisé pour effectuer en arrière-plan les tâches de maintenance courante du SSD (fonctions TRIM et Garbage Collection), ce qui permet au contrôleur SSD de préparer des blocs libres en vue d’une utilisation ultérieure. Dans la mesure où le SSD offre de meilleures performances lorsqu’il écrit dans des blocs libres, il en résulte une meilleure expérience utilisateur.
La fonction Over provisioning contribue à dégager de l’espace libre en redimensionnant les partitions d’un lecteur.
-
5/ Écriture des fichiers de log peu importants dans un ramdisque
J'ai oublié de parler de la rotation de log...
J'ai opté pour une rotation rapide des log qui sont sur le ramdisque /tmp : je ne garde que deux jours de log en plus du jour en cours
Les log importants sont pour ma part dans le dossier /home/log avec un classement avec des sous-dossier pour chaque site web. J'ai opté pour une rotation sur 40 jours, car tous les mois j'archive les fichiers de log hors du serveur.
Voici ce que cela donne pour Apache2 :
sudo nano /etc/logrotate.d/apache2
/tmp/apache2-*.log
/var/log/apache2/*.log {
daily
missingok
rotate 2
nocompress
notifempty
create 666 vgu vgu
sharedscripts
postrotate
/etc/init.d/apache2 reload > /dev/null;
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}
/home/log/*/*.log {
daily
missingok
rotate 40
nocompress
notifempty
create 666 vgu vgu
sharedscripts
postrotate
/etc/init.d/apache2 reload > /dev/null;
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}
Je ne sais pas si c'est très propre : /etc/init.d/apache2 reload est exécuté deux fois.
J'hésite à le supprimer dans le paragraphe du haut, car il devrait être exécuté ensuite quand la rotation des log du bas sera fait.
-
Attention à la saturation de /tmp si vous l'avez mis dans un ramdisque.
J'ai fait l’amère expérience la semaine dernière sur le serveur diffusant les mises à jour Ubuntu par défaut en France : /tmp s'est rempli et a ma grande surprise de nombreux outils refuse de marcher avec un /tmp en read-only. C'est le cas de mon script de synchronisation, qui ne s'est plus lancé alors qu'il me semble qu'il ne fait pas appel à /tmp. Il y a aussi de nombreux outits de ligne de commande a commencer par l'auto-complétion qui ont besoin d'écrire dans /tmp.
Bref, pensez a bien superviser ce point...
Le trafic sur le serveur que je suivais est lui resté a un niveau assez haut (700 Mb/s en moyenne en journée) alors qu'il n'y avait plus de nouveauté.
La diffusion de la mise à jour Firefox 52 => 52.0.1 est ce qui explique la hausse de trafic une fois /tmp vidé.
(https://lafibre.info/images/stats/201703_trafic_ubuntu_archive.png)
-
Voici un exemple de serveur avec un /proc/sys/vm/swappiness de 10
Je suis étonné de la proportion que peut prendre le swap alors que peu de ram est utilisée (max de 395 Mo utilisé) - il y a 15 Go de cache, dont 7 Go utilisé pour un ramdisque :
(https://lafibre.info/images/stats/201709_memory_swap.png)
apps : Memory used by user-space applications.
page_tables : Memory used to map between virtual and physical memory addresses.
swap_cache : A piece of memory that keeps track of pages that have been fetched from swap but not yet been modified.
slab_cache : Memory used by the kernel (major users are caches like inode, dentry, etc).
cache : Parked file data (file content) cache.
buffers : Block device (e.g. harddisk) cache. Also where "dirty" blocks are stored until written.
unused : Wasted memory. Memory that is not used for anything at all.
swap : Swap space used.
vmalloc_used : 'VMalloc' (kernel) memory used
committed : The amount of memory allocated to programs. Overcommitting is normal, but may indicate memory leaks.
mapped : All mmap()ed pages.
active : Memory recently used. Not reclaimed unless absolutely necessary.
inactive : Memory not currently used.
-
Superviser son SSD : exemple avec le SSD BX100 de Crucial
Voici le SSD qui héberge les mises à jour d'Ubuntu http://fr.archive.ubuntu.com/ (Note: les logs Apache sont situés sur le disque dur classique, ce dernier servant également pour booter le serveur)
smartctl nous donne les informations suivantes : (les informations varient avec chaque SSd et il faut pour certains avoir la doc pour savoir quelle taille est comptabilisé - ici c'est écrit dans le nom : 32 Mio)
- Temps de fonctionnement : Power_On_Hours = 14748 heures soit 614 jours
- Lecture : Host_Reads_32MiB = 14505213 soit 486,7 To => 793 Go /jour (le reste est en cache en ram)
- Écriture demandé : Host_Writes_32MiB = 388632 soit 13040,3 Go => 21,2 Go /jour
- Écriture réel : Flash_Writes_32MiB = 667008 soit 22381,1 Go => 36,5 Go/jour
Flash_Writes est supérieur à Host_Writes car il n'est pas possible de modifier seulement quelques Ko sur un SSD : l'écriture peut nécessite d'effacer plus que ce qui est demandé (les données non modifiées sont ré-écrites à l'identique)
Attention, les données remontées par Smart sont bien différentes entre les maques / modèles. Ici c'est un SSD de Crucial, le BX100.
# smartctl -a /dev/sdb
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.10.0-42-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: SiliconMotion based SSDs
Device Model: CT1000BX100SSD1
Serial Number: 1504F0023ECA
LU WWN Device Id: 5 00a075 1f0023eca
Firmware Version: MU01
User Capacity: 1 000 204 886 016 bytes [1,00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Dec 16 14:31:33 2017 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x71) SMART execute Offline immediate.
No Auto Offline data collection support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0002) Does not save SMART data before
entering power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 10) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x0000 100 100 000 Old_age Offline - 0
5 Reallocated_Sector_Ct 0x0000 100 100 000 Old_age Offline - 0
9 Power_On_Hours 0x0000 100 100 000 Old_age Offline - 14748
12 Power_Cycle_Count 0x0000 100 100 000 Old_age Offline - 4
160 Uncorrectable_Error_Cnt 0x0000 100 100 000 Old_age Offline - 0
161 Valid_Spare_Block_Cnt 0x0000 100 100 000 Old_age Offline - 147
163 Initial_Bad_Block_Count 0x0000 100 100 000 Old_age Offline - 52
164 Total_Erase_Count 0x0000 100 100 000 Old_age Offline - 41688
165 Max_Erase_Count 0x0000 100 100 000 Old_age Offline - 91
166 Min_Erase_Count 0x0000 100 100 000 Old_age Offline - 1
167 Average_Erase_Count 0x0000 100 100 000 Old_age Offline - 18
168 Max_Erase_Count_of_Spec 0x0000 100 100 000 Old_age Offline - 2000
169 Remaining_Lifetime_Perc 0x0000 100 100 000 Old_age Offline - 100
175 Program_Fail_Count_Chip 0x0000 100 100 000 Old_age Offline - 0
176 Erase_Fail_Count_Chip 0x0000 100 100 000 Old_age Offline - 0
177 Wear_Leveling_Count 0x0000 100 100 050 Old_age Offline - 0
178 Runtime_Invalid_Blk_Cnt 0x0000 100 100 000 Old_age Offline - 0
181 Program_Fail_Cnt_Total 0x0000 100 100 000 Old_age Offline - 0
182 Erase_Fail_Count_Total 0x0000 100 100 000 Old_age Offline - 0
192 Power-Off_Retract_Count 0x0000 100 100 000 Old_age Offline - 0
194 Temperature_Celsius 0x0000 100 100 000 Old_age Offline - 21
195 Hardware_ECC_Recovered 0x0000 100 100 000 Old_age Offline - 4975
196 Reallocated_Event_Count 0x0000 100 100 016 Old_age Offline - 0
197 Current_Pending_Sector 0x0000 100 100 000 Old_age Offline - 0
198 Offline_Uncorrectable 0x0000 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0000 100 100 050 Old_age Offline - 3
232 Available_Reservd_Space 0x0000 100 100 000 Old_age Offline - 100
241 Host_Writes_32MiB 0x0000 100 100 000 Old_age Offline - 388632
242 Host_Reads_32MiB 0x0000 100 100 000 Old_age Offline - 14505213
245 Flash_Writes_32MiB 0x0000 100 100 000 Old_age Offline - 667008
SMART Error Log not supported
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
-
Je passe swappiness de la valeur par défaut 60 à 10 : le swap est utilisé uniquement quand la mémoire est utilisée à plus de 90% (100-10) contre 40% par défaut (100-60). Cela diminue fortement l’utilisation du swap. Je n'ai mis que 1 Go de partition de swap sur le SSD.
Swapiness ne détermine pas le pourcentage de RAM au-delà duquel tu risques de swapper : c'est juste une pondération pour favoriser la mémoire des process (anonymous) par rapport aux autres types de pages (pages mappées et cache filesystem).
Il faut donc plus le voir comme une probabilité de voir ses pages anonymes swappés.
Schématiquement, car ça semble en réalité plus compliqué :
Avec swapiness = 100 : tu auras en probabilité autant de pages anonymes que de pages mappées/du cache évincées de la RAM
Avec swapiness = 1 : tu auras 100 fois mois de pages anonymes que de pages mappées/du cache évincées de la RAM
Avec swapiness = 0 : tu n'auras plus de pages anonymes évincées de la RAM, (sauf si un seuil très bas de RAM disponible est atteint)
Voici un exemple de serveur avec un /proc/sys/vm/swappiness de 10
Je suis étonné de la proportion que peut prendre le swap alors que peu de ram est utilisée (max de 395 Mo utilisé) - il y a 15 Go de cache, dont 7 Go utilisé pour un ramdisque :
C'est normal si ton cache filesystem met une grosse pression sur le VMM et que des process sont plutôt inactifs : même si tu as un swapiness à 10 , la probabilité de swapper est non nulle (juste réduite de 1/10) et donc le kernel aura tendance à pousser en swap les pages des process inactifs, plus que des pages filesystems qui sont plus actives.
-
swapiness = 1 a eu son comportement changé avec les noyaux récents, pour ne pas utiliser de swap, sauf nécessité.
swapiness = 0 est déconseillé car les demandes d’allocations peuvent être refusées.
-
swapiness = 0 est déconseillé car les demandes d’allocations peuvent être refusées.
C'est surtout qu'avec 0 tu risques de déclencher l'OOM Killer plus facilement en cas d'activité IO intense, ce qui est logique puisqu'il ne pourra plus libérer des pages suffisamment vite en poussant les pages anonymes en swap.