Auteur Sujet: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France  (Lu 5379 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #12 le: 27 avril 2017 à 15:35:01 »
Canonical Livepatch Service est limité à 3 machines par identifiant.

Il ne gère pas le kernel des Hardware Enablement Stack... (je suis en Kernel 4.8 sur un LTS 16.04)

Bref c'est utile mais je ne l'utilise pas.

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 5 463
  • Lyon & Paris
    • MilkyWan
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #13 le: 27 avril 2017 à 15:48:36 »
Pourquoi utiliser l'Hardware Enablement Stack ? Autant passer en non LTS dans ce cas...

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #14 le: 27 avril 2017 à 19:23:49 »
Pour que ceux qui nous lisent comprennent, il y a 3 type de cycles qu'il est possible de suivre chez Ubuntu :

- Ubuntu server LTS => On reste deux ans avec le même kernel (4.4 pour Ubuntu 16.04). Il y a un support de 5ans, on n'est pas obligé d'upgrader tout de suite à la sortie de la version suivante.

- Ubuntu server LTS avec Enablement Stacks => On profite des améliorations de performances des nouveaux Kernel, en changant automatiquement de Kernel tous les 6 mois. Ubuntu 16.04 et 16.04.1 utilise le kernel 4.4, Ubuntu 16.04.2 le kernel 4.8, Ubuntu 16.04.3 le kernel 4.10, Ubuntu 16.04.4 un kernel à définir. Le support reste de 5 ans et il est possible de supprimer facilement Enablement Stacks.
A noter que les kernel sont utilisés pendant 3 mois dans les version Ubuntu classiques avant d'être mis dans Enablement Stacks. Il ne devrait donc pas y avoir de gros bugs.

- Ubuntu server => Il est nécessaire d'upgrader le système d’exploitation tous les 6 mois. Le support d'une version se termine 3 mois après la sortie de la version suivante. Cela laisse très peu de marge de manœuvre pour décaler un upgrade. Il faut donc éviter ce type d'OS en prod.

Bref, j'utilise presque systématiquement Enablement Stacks sur mes serveurs, car cela permet de profiter des améliorations des nouveaux noyaux sans prendre le moindre risque. Par exemple pour ce forum, toujours pas compatible PHP7, j'aurais été embêté si j'étais obligé d'upgrader tous les 6 mois.




vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #15 le: 27 avril 2017 à 19:32:45 »
Comment activer Enablement Stacks ?

Ubuntu et dérivé (avec interface graphique)

sudo apt install --install-recommends linux-generic-hwe-16.04 xserver-xorg-hwe-16.04

On passe alors dans le dernier noyau (le 4.8 actuellement, le 4.10 en juillet après avoir été utilisé 3 mois par Ubuntu 17.04) mais aussi dans la dernière pile graphique, celle de Ubuntu 16.10 actuellement (En juillet, ce sera celle d'Ubuntu 17.04) permettant des amélioration de performances.


Ubuntu Server (sans interface graphique)

sudo apt install --install-recommends linux-generic-hwe-16.04



Comment désactiver Enablement Stacks ?

Ubuntu et dérivé (avec interface graphique)

sudo apt purge linux-generic-hwe-16.04 xserver-xorg-hwe-16.04


Ubuntu Server (sans interface graphique)

sudo apt purge linux-generic-hwe-16.04

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 5 463
  • Lyon & Paris
    • MilkyWan
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #16 le: 27 avril 2017 à 19:33:10 »
Ok, je comprends ton choix :)

Perso j'essaie d'être le plus à jour sur les serveurs non critiques, donc j'ai déjà une bonne partie en Zesty, même si la majorité reste en Xenial (avec du livepatch sur tous !)  ;)

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #17 le: 27 avril 2017 à 19:42:41 »
Je n'ai aucun serveur en Zesty (Ubuntu 17.04) par contre tous mes PC (interface graphique) pour mon utilisation sont en Zesty.
Les PC de mes connaissances par contre reste en LTS, une upgrade tous les 2 ans, c'est largement suffisant.

Pour le livepatch tu payes le service ?

(cliquez sur la miniature ci-dessous - le document est au format PDF)


Quand-est ce que Debian va sortir ça ? Cela permettrait de se différencier (aujourd'hui toutes les distrib que le proposent le font payer)

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 5 463
  • Lyon & Paris
    • MilkyWan
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #18 le: 27 avril 2017 à 20:54:15 »
Pour le livepatch tu payes le service ?

*tousse* j'ai un très bon système d'alias mail *tousse*


 ;)

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #19 le: 30 avril 2017 à 07:03:35 »
Je viens de rajouter deux mesures de protections supplèmentaires : (je suis preneur de vos autres idées)

   # Temps pendant lequel le serveur va attendre certains évènements avant de considérer
   # qu'une requête a échoué. Lors de la lecture de données en provenance du client,
   # c'est le temps maximum jusqu'à l'arrivée d'un paquet TCP si le tampon est vide.
   # Défaut: TimeOut 60
   # Réduire le TimeOut a 30 secondes, permet de limiter le temps maximum pendant
   # lequel Apache httpd va attendre des entrées/sorties, lors des attaques de slow DDOS.
   Timeout 30

   # Spécifie le délai maximum après lequel le serveur va s'arrêter dans le cas d'un arrêt "en douceur"
   # Défaut: GracefulShutdownTimeout 0 => le serveur va attendre jusqu'à ce que toutes les requêtes en cours aient été traitées.
   # Réduire le GracefulShutdownTimeout a une heure (3600 secondes) permet de réduire certains attaques slow DDOS.
   # Réduire cette valeur en dessous d'une heure peut poser problème pour des clients avec du bas débit
   # Une connexion a 400 Kb/s (50 Ko/s) est en mesure de télécharger 180 Mo en une heure.
   GracefulShutdownTimeout 3600


Le gain du timeout à 30 secondes est impressionnant => plus de slow DDOS depuis sa mise en place le 27 en milieu de journée.

La valeur était de 300 secondes avant la modification.

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #20 le: 02 mai 2017 à 22:42:52 »
Nouvelles tentatives de mettre un Timeout 300 (en conservant GracefulShutdownTimeout 3600) :



No comment.

Je vais donc remettre :
- Timeout 30
- GracefulShutdownTimeout 3600

+ rajouter une nouvelle : KeepAliveTimeout 2
La valeur par défaut est de 5 secondes.

KeepAliveTimeout est la durée pendant laquelle le serveur va attendre une requête avant de fermer une connexion persistante

L'implèmentation des connexions persistantes dans HTTP/1.1 permet de faire plusieurs requêtes dans une même connexion TCP.

Avec KeepAliveTimeout 2, Apache va fermer 3 secondes plus tôt cette cette attente d'une nouvelle requête sur la même connexion TCP. Cela permet de libérer des ressources importantes, quand il y a de nombreux petit téléchargements effectués, comme les mises à jour qui sont checké char jour par tous les PC Ubuntu.

Si le serveur est très long pour enchaîner les requêtes, le seul impact sera l’obligation d'ouvrir une nouvelle connexion TCP. Ce cas devrait être très rare. Le Timeout restant lui à 30 secondes.

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #21 le: 23 juin 2017 à 09:27:56 »
J'entends souvent dire qu'un disque SATA 7200tr/min sait réaliser des transfert a plusieurs centaines de Mo/s. Vous allez voir que dans la vraie vie sur un serveur, c'est 20 Mo max.

Oui, un disque traditionnel sait monter a des très haut débit dans un bench, avec une lecture séquentielle, mais pour la lecture de nombreux fichiers sur un serveur, on est loin du compte.

Cette nuit, une personne a cloné le miroir Ubuntu.

J'ai deux disques dur sur le miroir Ubuntu:
- sda : Un disque dur SATA 3,5 pouces 7200tr/min de 500Go type serveur, qui héberge 293 Go d'archive (les moins consultées) + le système
- sdb : Un SSD grand public de 1 To qui héberge 829 Go d'archive (les plus consultées)

L'objectif était de mettre tous le miroir sur le SSD, mais il dépasse maintenant 1To.

Le disque SATA a été utilisé plus d'une heure à 100% de sa capacité lors du clonage du miroir, ce qui permet de voir les débit qu'il est capable de délivrer :



On ne dépasse pas 20 Mo sur un disque dur SATA sur ce type d'utilisation ! (le SSD monte à 70 Mo/s mais il n'a pas été utilisé au maximum, cf courbe précédente)


L’utilisation du disque dur classique, comme du SSD entraîne un échauffement du disque : (ils sont positionnées au niveau de l’entrée d'air du serveur, donc ce ne peut pas etre le CPU qui les chauffe)


Le fait d'attendre les entrée / sortie du disque SATA provoque une explosion des i/o wait et du load average :


Comme cela se fait probablement avec une seulle connexion TCP, coté Apache, on ne vois rien sur les accés et les slots utilisés :


Cela se voir sur le volume utilisé par Apache et la carte réseau : On ne dépasse pas 1 Gb/s de trafic mais comme ces fichiers ne sont pas en cache ram, cela consomme beaucoup plus de ressources que les pic à 4 Gb/s qui concernent des données en cache.


vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #22 le: 07 janvier 2018 à 21:58:55 »
Il y a un mois, j'avais l'archive Ubuntu qui était pour grande partie sur un SSD de 1 to et sur un disque dur classique de 500 Go.

Depuis trois semaines, j'ai maintenant tout sur SSD (un RAID 0 hardware Dell PERC H330 de deux SSD Intel de 960 Go chacun, connecté en SATA et avec des puces MLC)

J'ai donc ouvert le serveurs aux connexions rsync comme le font presque tous les serveurs par défaut pour un pays et je vois que c'était attendu car sans même communiquer sur cette nouvelle fonctionnalité, j'ai eu plusieurs synchronisations.

Problème : je suis déçu par les performances des SSD, vous allez comprendre dans les stats : je sature un RAID 0 de deux SSD avec un débit en lecture de 100 Mo/s (800 Mb/s). Pourquoi ?

Rsync: Quantités de données échanges via Rsync, par période de 5 minutes, en Go :

On est a environ 19 Go/5minutes soit environ 500 Mb/s.

Rsync: Nombre de fichiers échangés par période de 5 minute :

On est a environ 10k fichiers/5minutes, soit 33 fichiers par seconde environ (pic de 65k fichiers/5minutes, soit 220 fichiers par seconde

Regardez l'impact sur l'utilisation disque :

Pourcentage d'utilisation des disques: (c'est un RAID 0 hardware constitué de deux SSD Intel 960Go MLC en SATA)

"sda" correspond au RAID 0 hardware de deux SSD Intel

Les caractéristiques de la carte RAID Dell PERC H330 dans le lscpi -v :

03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS-3 3008 [Fury] (rev 02)
   DeviceName: Integrated RAID
   Subsystem: Dell PERC H330 Adapter
   Flags: bus master, fast devsel, latency 0, IRQ 18
   I/O ports at 3000 [size=256]
   Memory at 95c00000 (64-bit, non-prefetchable) [size=64K]
   Memory at 95b00000 (64-bit, non-prefetchable) [size=1M]
   Expansion ROM at <ignored> [disabled]
   Capabilities: [50] Power Management version 3
   Capabilities: [68] Express Endpoint, MSI 00
   Capabilities: [d0] Vital Product Data
   Capabilities: [a8] MSI: Enable- Count=1/1 Maskable+ 64bit+
   Capabilities: [c0] MSI-X: Enable+ Count=97 Masked-
   Capabilities: [100] Advanced Error Reporting
   Capabilities: [1e0] #19
   Capabilities: [1c0] Power Budgeting <?>
   Capabilities: [148] Alternative Routing-ID Interpretation (ARI)
   Kernel driver in use: megaraid_sas
   Kernel modules: megaraid_sas


Débit en Mo/s lu / écrit sur les disques: (Ne correspond pas au trafic réseau, car la RAM cache les données les plus lues)

On est sur un trafic de 650 à 800 Mb/s, soit 150 à 300 Mb/s de plus que le débit RSYNC => C'est lié au fait que le transfert RSYNC doit vider du cache disque des fichiers fortement demandés.

Nombre de IOPS sur les disques (opérations d'entrée-sortie par seconde) :
 

Latence accès disque (enfin le RAID 0 de SSD) :


Avec un disque saturé à 100% en E/S, le Load average explose et le CPU attend les E/S (iowait) :
 

Bien sur il n'y a pas que RSYNC qui charge le serveur, il y a les requêtes http de mise à jour de milliers d'ordinateurs, mais c'est toujours les mêmes fichiers qui sont chargés et le contenu est probablement en cache RAM (il y a 32 Go de RAM)

Débit des connexions Apache (mises à jour via http/https) en Mo/s :   Nombre de fichiers téléchargés par seconde :
   

Trafic réseau en Mb/s sur la carte réseau : (comprend donc les requêtes http/https et rsync)







Thornhill

  • Client SFR fibre FTTH
  • *
  • Messages: 451
  • Saint-Médard-en-Jalles (33)
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #23 le: 07 janvier 2018 à 22:53:05 »

Avec un disque saturé à 100% en E/S, le Load average explose et le CPU attend les E/S (iowait) :

Ce n'est pas le CPU qui attend en IOWait mais les process/threads.
Un CPU en iowait veut simplement dire qu'il est idle (rien d'autre à traiter), avec au moins process/threads en attente d'IO.

%iowait
    Show the percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.


Aussi, tu indiques que le logical disk est saturé, ce n'est pas certain : il suffit qu'il ait en moyenne toujours une I/O en cours de traitement pour être comptabilisé à 100% Busy par l'OS, mais avec le Command Queuing il peut accepter plusieurs I/O simultanèment donc peut-être a-t-il de la réserve en pratique.

As-tu fais un bench avec un outil comme fio ou IOmeter pour voir ce que peut réellement encaisser ton système IO ?



 

Mobile View