Auteur Sujet: [Linux] Optimisation d'un serveur pour un SSD : réduire les écritures sur le SSD  (Lu 6763 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
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)

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

2/ Persistent RAM disk pour les fichiers de Munin

3/ Persistent RAM disk pour les RRD de SmokePing

4/ Désactivation de la compression des fichiers de LOG

5/ Écriture des fichiers de log peu importants dans un ramdisque

6/ Réduction du swap avec vm.swappiness

7/ [je doute que cela soit efficace] Augmenter l’intervalle d’écritures périodiques

8/ Augmenter l'overprovisionning, pour augmenter la durée de vie du SSD

vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
Optimisation d'un serveur pour un SSD : réduire les écritures sur le SSD
« Réponse #1 le: 14 décembre 2016 à 22:03:11 »
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


/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.

vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
Optimisation d'un serveur pour un SSD : réduire les écritures sur le SSD
« Réponse #2 le: 14 décembre 2016 à 22:11:05 »
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 :

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/www
par
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

vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
Optimisation d'un serveur pour un SSD : réduire les écritures sur le SSD
« Réponse #3 le: 15 décembre 2016 à 09:02:06 »
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

vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
Optimisation d'un serveur pour un SSD : réduire les écritures sur le SSD
« Réponse #4 le: 15 décembre 2016 à 09:08:21 »
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)

vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
Optimisation d'un serveur pour un SSD : réduire les écritures sur le SSD
« Réponse #5 le: 15 décembre 2016 à 09:34:00 »
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/*

vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
Optimisation d'un serveur pour un SSD : réduire les écritures sur le SSD
« Réponse #6 le: 16 décembre 2016 à 09:02:47 »
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

vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
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 clef USB, tu vois que c'est presque immédiat et que la clef 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

vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
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.

vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
Optimisation d'un serveur pour un SSD : réduire les écritures sur le SSD
« Réponse #9 le: 19 janvier 2017 à 13:12:50 »
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.

vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
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é.


vivien

  • Administrateur
  • *
  • Messages: 29 368
    • Twitter LaFibre.info
[Linux] Optimisation d'un serveur pour un SSD : réduire les écritures sur le SSD
« Réponse #11 le: 09 septembre 2017 à 22:11:26 »
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 :



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.

 

Mobile View