Auteur Sujet: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France  (Lu 5378 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

Vous savez que je gère le serveur http://fr.archive.ubuntu.com/ qui gère les mises à jour Ubuntu pour 99% des PC Ubuntu (et dérivés) installés comme étant en France. J'exclue de ce pourcentage, les entreprises avec un par Ubuntu important, qui ont déployée en interne leur propre miroir, comme par exemple la gendarmerie nationale.

Voici le trafic typique après une mise à jour, ici une nouvelle version d'un noyau Linux a été proposée à minuit :


Le pic de 6h25 à 6h55 du matin puis de puis 7h25 à 7h55 est lié a des machines connectées 24h/24 : Par défaut elles vérifient les mises à jour (et pour certaines les télécharges et les installes, d'autres ne font que notifier de la présence de mises à jour sans les télécharger)

Le fichier /etc/crontab contient ce type de lignes sur Ubntu :
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

Les actions à exécutées chaque jour, des scripts qui sont dans /etc/cron.daily sont donc exécutés chaque jour.

C'est notamment le cas du script /etc/cron.daily/apt-compat qui gère les mises à jour :

#!/bin/sh

set -e

# Systemd systems use a systemd timer unit which is preferable to
# run. We want to randomize the apt update and unattended-upgrade
# runs as much as possible to avoid hitting the mirrors all at the
# same time. The systemd time is better at this than the fixed
# cron.daily time
if [ -d /run/systemd/system ]; then
    exit 0
fi

check_power()
{
    # laptop check, on_ac_power returns:
    #       0 (true)    System is on main power
    #       1 (false)   System is not on main power
    #       255 (false) Power status could not be determined
    # Desktop systems always return 255 it seems
    if which on_ac_power >/dev/null 2>&1; then
        on_ac_power
        POWER=$?
        if [ $POWER -eq 1 ]; then
            return 1
        fi
    fi
    return 0
}

# sleep for a random interval of time (default 30min)
# (some code taken from cron-apt, thanks)
random_sleep()
{
    RandomSleep=1800
    eval $(apt-config shell RandomSleep APT::Periodic::RandomSleep)
    if [ $RandomSleep -eq 0 ]; then
return
    fi
    if [ -z "$RANDOM" ] ; then
        # A fix for shells that do not have this bash feature.
RANDOM=$(( $(dd if=/dev/urandom bs=2 count=1 2> /dev/null | cksum | cut -d' ' -f1) % 32767 ))
    fi
    TIME=$(($RANDOM % $RandomSleep))
    sleep $TIME
}

# delay the job execution by a random amount of time
random_sleep

# ensure we don't do this on battery
check_power || exit 0

# run daily job
exec /usr/lib/apt/apt.systemd.daily

Le code inclus un "sleep" d'une durée aléatoire comprises entre 0 et 30 minutes, ce qui évite que tous les PC se connectent simultanèment au serveur.

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #1 le: 27 avril 2017 à 09:28:43 »
Sur ces graphes, hebdomadaire, mensuel et annuels, le trafic est représenté en affichant le débit moyen sur 5 minutes le plus élevé de la période.

Graphe hebdomadaire : chaque point représente une période de 20 minutes


Graphe mensuel : chaque point représente une période de 2 heures


Graphe annuel : chaque point représente une période de 24 heures


On a donc sur ce dernier graphe la période de 5 minutes sur l'année avec le maximum de trafic, c'est a dire le matin entre 6h25 et 6h55 ou entre 7h25 à 7h55, certains type de mise à jour (Firefox par exemple) réalisant un pic de trafic plus important sur le créneau de 7h25 à 7h55. Les mises à jour du Kernel par contre ont toujours leur pic de trafic entre 6h25 et 6h55.

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #2 le: 27 avril 2017 à 09:38:07 »
Trafic moyen

Sur les graphes ci-dessous, le trafic reporté est le trafic moyen sur la période et non le trafic sur 5 minutes le plus élevé :



Sur le dernier graphe, on a donc un trafic moyenné sur toute la journée.

Ce type de graphe cache des pic de trafic instantanés à plus de 5 Gb/s.

Exemple de consommation internet instantanée, récupéré avec nload lors d'une mise à jour du kernel :

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #3 le: 27 avril 2017 à 09:38:29 »
Trafic vu du serveur Apache en volume (Mo par seconde et non Mb/s)

Ce trafic est assez proche de celui vu coté réseau, les encapsulations en moins.





Nombre de requêtes sur le serveur Apache en millier de requêtes par secondes

Le nombre de requêtes est lié aux différents serveurs et PC qui se connectent pour vérifier si il y a des mises à jour.
Leur volume est donc assez stable, contrairement au volume.

On voit ici les deux pic qui sont présents chaque jour (sauf une foie dans l'année quand on retarde l'heure d'une heure, il n'y a pas deux téléchargements en moins de 24h)




Avec cette courbe annuelle, vous pensez que le nombre d'utilisateurs Ubuntu diminue ?

On pourrait à juste titre le penser. La réponse est non, c'est simplement que Ubuntu 16.04 a bien optimisé le système de mise à jour et divisé par 2 le nombre de requêtes nécessaires. Le nombre de requêtes diminue donc au fur et à mesure qu'Ubuntu 16.04 est déployé.


Fichier /etc/apt/sources.list par défaut pour Ubuntu server 16.04 LTS :
deb http://fr.archive.ubuntu.com/ubuntu/ xenial main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ xenial-updates main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ xenial universe
deb http://fr.archive.ubuntu.com/ubuntu/ xenial-updates universe
deb http://fr.archive.ubuntu.com/ubuntu/ xenial multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ xenial-updates multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ xenial-backports main restricted universe multiverse
deb http://fr.archive.ubuntu.com/ubuntu xenial-security main restricted
deb http://fr.archive.ubuntu.com/ubuntu xenial-security universe
deb http://fr.archive.ubuntu.com/ubuntu xenial-security multiverse


Fichier /etc/apt/sources.list par défaut pour Ubuntu server 14.04 LTS :
deb http://fr.archive.ubuntu.com/ubuntu/ trusty main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ trusty universe
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty universe
deb http://fr.archive.ubuntu.com/ubuntu/ trusty-updates universe
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty-updates universe
deb http://fr.archive.ubuntu.com/ubuntu/ trusty multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ trusty-updates multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty-updates multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse
deb http://fr.archive.ubuntu.com/ubuntu trusty-security main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu trusty-security main restricted
deb http://fr.archive.ubuntu.com/ubuntu trusty-security universe
deb-src http://fr.archive.ubuntu.com/ubuntu trusty-security universe
deb http://fr.archive.ubuntu.com/ubuntu trusty-security multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu trusty-security multiverse

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #4 le: 27 avril 2017 à 09:39:23 »
Nombre de requêtes simultanées

Un serveur web est limité en nombre de "slot", c'est à dire le nombre de requêtes qu'il est en mesure de traiter simultanèment.

La plupart des requêtes légitimes sont réalisées très rapidement et donc occupent peu de temps le serveur, sachant qu'Ubuntu n'effectue pas de requêtes simultanées, un client ne peut pas occuper plus d'un slot.

Il y a toutes fois du trafic exotique, des scripts, du slow DDOS, ect... qui peuvent occuper des slot. Je vois ainsi des fichiers qui sont téléchargés en plus de 12h depuis des IP situées hors de France. Il y a par moment des petits pic de très forte occupation du slot du serveur...

Avec 2500 slots pour 300 slots maximums utilisés de façon légitime, j'ai de la marge, mais il arrive occasionnellement qu'ils soient tous occupés (dans ces cas là il y a une file d'attente)




Statistiques instantanées, récupérées avec Apache Server Status :

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #5 le: 27 avril 2017 à 09:39:32 »
Le load average du serveur :

Un des facteur d'augmentation du load average est les accès disques lié a des demandes importantes sur du contenu qui n'est pas en RAM, l'augmentation du nombre de slot a cause de slow DDOS et la synchronisation du serveur avec du nouveau contenu.

Les pic de trafic le matin à plus de 4 Gb/s ne font pas monter le load average, car c'est toujours le même contenu qui est demandé et il est en RAM.
De plus tous les serveurs ont un grand débit, ce qui fait que les slot ne sont utilisés qu'un cours laps de temps : télécharger 70 Mo à 1 Gb/s, cela va très vite.







L'utilisation CPU (c'est un Xeon 4 cœurs avec Hyper-Threading)




Indicateur   Définition
systemCPU time spent by the kernel in system activities
userCPU time spent by normal programs and daemons
niceCPU time spent by nice(1)d programs
idleIdle CPU time
iowaitCPU time spent waiting for I/O operations to finish when there is nothing else to do.
irqCPU time spent handling interrupts
softirqCPU time spent handling "batched" interrupts
stealThe time that a virtual CPU had runnable tasks, but the virtual CPU itself was not running
guestThe time spent running a virtual CPU for guest operating systems under the control of the Linux kernel.

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #6 le: 27 avril 2017 à 09:39:43 »
L'utilisation des 16 Go de mémoire, principalement pour du cache disque des élèments les plus demandés :




Il y a un changement important début mars entre page mémoires actives et pages mémoires inactives : c'est lié au changement de kernel Linux : Je suis passé d'un noyau 4.4 à un noyau 4.8. Le reste est strictement inchangé.

IndicateurDéfinition
appsMemory used by user-space applications.
page_tablesMemory used to map between virtual and physical memory addresses.
swap_cacheA piece of memory that keeps track of pages that have been fetched from swap but not yet been modified.
slab_cacheMemory used by the kernel (major users are caches like inode, dentry, etc).
cacheParked file data (file content) cache.
buffersBlock device (e.g. harddisk) cache. Also where "dirty" blocks are stored until written.
unusedWasted memory. Memory that is not used for anything at all.
swapSwap space used.
vmalloc_used   'VMalloc' (kernel) memory used
committedThe amount of memory allocated to programs. Overcommitting is normal, but may indicate memory leaks.
mappedAll mmap()ed pages.
activeMemory recently used. Not reclaimed unless absolutely necessary.
inactiveMemory not currently used.

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #7 le: 27 avril 2017 à 09:47:25 »
Les reboot du serveur pour appliquer les mises à jour de sécurité :



La longue période sans reboot a permis de voir le trafic passe le 1 Po :

Je viens de Passer 1 Po (soit 8 Pb) en 149 jours pour le serveur http://fr.archive.ubuntu.com qui distribue les mises à pour pour la France.

$ uptime
 17:01:09 up 149 days, 11:40,  1 user,  load average: 0,30, 0,48, 0,39


$ ifconfig
lo        Link encap:Boucle locale 
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          Packets reçus:1755415 erreurs:0 :0 overruns:0 frame:0
          TX packets:1755415 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1
          Octets reçus:1737669659 (1.7 GB) Octets transmis:1737669659 (1.7 GB)

p1p1      Link encap:Ethernet  HWaddr 90:e2:ba:19:f7:50 
          inet adr:194.158.119.190  Bcast:194.158.119.191  Masque:255.255.255.252
          adr inet6: fe80::92e2:baff:fe19:f750/64 Scope:Lien
          adr inet6: 2001:860:f70a:100::2/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:319436905449 erreurs:0 :0 overruns:0 frame:0
          TX packets:672964588886 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          Octets reçus:24466146214985 (24.4 TB) Octets transmis:1001402094413622 (1.0 PB)


vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #8 le: 27 avril 2017 à 09:47:34 »
Statistiques sur le téléchargement d'un nouveau noyau Linux, suite à une faille de sécurité :

Tu es sur que RedHat n'a pas distribué le correctif ?

Cela m'étonne fortement.

Pour Ubuntu, il est disponible depuis le 20 octobre à 5h45 du matin, sur le serveur de mise à jour utilisé par défaut en France (http://fr.archive.ubuntu.com)

Comme je gère ce serveur, j'ai réalisé quelques stats. J'ai bien nettoyé les log de tout ce qui est script et j'ai également par mégarde supprimé les mises à jour réalisées depuis un mobile (le serveur reçois le code 304 - Document non modifié depuis la dernière requête, car il est en cache coté FAI).

Nombre de mises à jour du noyau correctif par heure :


Le nombre de machines non patchées dois être encore très important.

Nombre de mises à jour du noyau correctif par heure et par distribution :


Je rappelle que les autres version d'Ubuntu ne sont plus maintenues.

Nombre de mises à jour du noyau correctif par heure par architecture : (i386 = 32bits / AMD64 = 64bits)


Voici un fichier Calc avec les données sources, si vous pensez qu'il y a d'autres graphes à faire : 201610_stats_ubuntu.ods

(lisible avec Libre office Calc et Microsoft Excel)

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #9 le: 27 avril 2017 à 14:21:06 »
Ce matin, j'ai encore dans mes logs AH00485: scoreboard is full, not at MaxRequestWorkers

L'attaque est bien visible :


Voici ma configuration actuelle, j'ai mis de trés nombrex commentaires pour détailler mes choix : /etc/apache2/mods-enabled/mpm_event.conf

# event MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestWorkers: maximum number of worker threads
# MaxConnectionsPerChild: maximum number of requests a server process serves

# Nb de slots total (busy + idle + free) est la valeur la plus basse entre :
# - MaxRequestWorkers (150 par défaut)
# - ThreadsPerChild (25 par défaut) * ServerLimit (16 par défault)

# Nb de slots idle au démarrage à vide est la valeur la plus haute entre :
# - MinSpareThreads (25 par défaut) arrondi supérieur, pour être un multiplde entier de ThreadsPerChild
# - ThreadsPerChild (25 par défaut) * StartServers (2 par défaut)

# Nb minimal de slots idle quand de nombreux slots sont "busy" :
# = MinSpareThreads (25 par défaut) avec un arrondi supérieur pour que
# busy + idle soient un multiplde entier de ThreadsPerChild (25 par défaut)

# Nb maximal de slots idle quand de nombreux slots sont "busy" :
# = MaxSpareThreads (75 par défaut) avec un arrondi supérieur pour que
# busy + idle soient un multiplde entier de ThreadsPerChild (25 par défaut)

<IfModule mpm_event_module>
# Nombre de processus enfants du serveur créés au démarrage
# Influence uniquement le nb de slots idle au démarrage
# Régle pour déterminer StartServers: arrondi supérieur de
# (MinSpareThreads / ThreadsPerChild) + (MaxRequestWorkers / (40 x ThreadsPerChild))
#StartServers 2
StartServers 9

        # Limite supérieure de la définition du nombre de processus
        # Régle pour déterminer ServerLimit: MaxRequestWorkers / ThreadsPerChild
# Pour modifier ServerLimit un restart est nécessaire (donc coupure des connexions en cours)
        # Je conseille donc de prendre une marge ServerLimit = 1.5 x (MaxRequestWorkers / ThreadsPerChild)
# Permet, par la suite, d'augmenter de 50% ThreadsPerChild avec un simple reload
        # ServerLimit            16
        ServerLimit              150

# Nombre minimum de threads inactifs qui seront disponibles
# pour pouvoir traiter les pics de requêtes
        # Régle pour déterminer MinSpareThreads: 20 + (MaxRequestWorkers / 20)
#MinSpareThreads 25
MinSpareThreads 145

# Nombre maximum de threads inactifs
# But: libérer de la RAM inutilisée après un pic de trafic
# Régle pour déterminer MaxSpareThreads: 3 x MinSpareThreads
#MaxSpareThreads 75
MaxSpareThreads 435

# Le nombre de threads maximum que l'on peut définir par processus enfant
# Il est possible de modifier ThreadsPerChild par un simple reload jusqu'à ThreadLimit
# Pour modifier ThreadLimit un restart est nécessaire (donc coupure des connexions en cours)
# Si ThreadLimit > ThreadsPerChild, de la mémoire partagée supplèmentaire sera inutilement allouée.
# Régle pour ThreadLimit: ne pas toucher a la valeur par défault: 64 quel que soit MaxRequestWorkers
# Régle pour déterminer ThreadsPerChild: 25 (valeur par défault), quel que soit MaxRequestWorkers
#ThreadLimit 64
ThreadLimit 25

# Nombre de threads créés par chaque processus enfant
# Influence le nb total de slots max ET le nb minimal de slots
# Si > 40, Apache ne répond plus a certaines requetes, quand il y a de nombreuses connexions asychrones
# Régle pour déterminer ThreadsPerChild: 25 (valeur par défault), quel que soit MaxRequestWorkers
ThreadsPerChild 25

# Nombre maximum de connexions pouvant être traitées simultanèment
# Détermine le nombre de requetes actives pouvant être traitées simltanèment.
# A déterminer en fonciton de la charge et de la mémoire disponible
# Il est possible de modifier MaxRequestWorkers par un simple reload
#MaxRequestWorkers 150
MaxRequestWorkers 2500

# Limite le nombre de connexions qu'un processus enfant va traiter au cours de son fonctionnement
# Définir MaxConnectionsPerChild à une valeur non nulle limite la quantité de mémoire
# qu'un processus peut consommer à cause de fuites (accidentelles) de mémoire.
# Régle pour déterminer MaxConnectionsPerChild: fixé à 0, sauf fuite mémoire importante
MaxConnectionsPerChild   0

# Cette directive permet de personnaliser finement la limite du
# nombre de connexions par thread. Un processus n'acceptera de
# nouvelles connexions que si le nombre actuel de connexions
# (sans compter les connexions à l'état "closing") est inférieur à:
# ThreadsPerChild + (AsyncRequestWorkerFactor * nombre de threads inactifs)
# A faire varier entre 1.5 et 3 en fonction du type de clients du site
# Régle pour déterminer AsyncRequestWorkerFactor: fixé à 2 (valeur par défault)
# Note: Si vous modifiez la valeur par défaut, vous devrez effectuer des tests approfondis
AsyncRequestWorkerFactor 2

</IfModule>

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


GracefulShutdownTimeout d'une heure peut vous sembler énorme, mais je prévois le cas où un client avec une petite connexion fait de gros téléchargements.
Si il commence la nuit au moment où les serveurs redémarrent ou après une attaque, quand il faut diminuer le nombre de serveurs, là je donne une garantie d'un minimum de 1h sans être coupé.
En temps normal, des connexions de plusieurs heures passeront sans problème, cette ligne ne devrait pas trop changer les choses, juste libérer quelques serveurs qui restent bloquées plusieurs heures a cause d'un slow DDOS.

vivien

  • Administrateur
  • *
  • Messages: 27 823
    • Twitter LaFibre.info
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
« Réponse #10 le: 27 avril 2017 à 14:23:44 »
Je m’aperçois que même hors des attaques, j'ai un nombre important de requêtes qui prennent des sots pour rien, qui est important.

Exemple : Apache Server Status ce midi en filtrant les requêtes W (il y a une GET complet qui a été reçu et le serveur envoi la réponse), une durée en secondes SS depuis la dernière requête > 60 secondes et le nombre d'octets transféré Req de 0 octets.


C'est un type de connexion qui me semblent complètement frauduleuses : si j'ai bien compris après le GEt le client n'est plus manifesté. Comme à un time out par défaut de 60 secondes et que ces connexions dépasseent largement ce délais, c'est que les opérations pour faire un GET ont déjà pris pas mal de temps.... bref je pense que c'est du slow DNS...

Légende :

MMode of operation : "_" Waiting for Connection, "S" Starting up, "R" Reading Request, "W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup, "C" Closing connection, "L" Logging, "G" Gracefully finishing, "I" Idle cleanup of worker, "." Open slot with no current process
SSSeconds since beginning of most recent request
ReqMilliseconds required to process most recent request
ConnKilobytes transferred this connection

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 #11 le: 27 avril 2017 à 14:30:08 »
Les reboot du serveur pour appliquer les mises à jour de sécurité :

sudo snap install canonical-livepatch  ::)

 

Mobile View