Combien de données Linux lit-il au démarrage moyen?

Je me demande combien de données au total un système Linux vanilla fraîchement installé (comme CentOS 5.10 32 bits) lit pour accéder à une invite de shell de console virtuelle? Vous savez, lire tous les fichiers de configuration, charger les binaires, l'image du noyau, etc.

Je recherche des estimations d'ordre de grandeur. Je suis conscient que le démarrage Linux varie considérablement en ce qui concerne les détails du processus. Parlons-nous de 10 Mo? 100 Mo? 1 Go?

linux boot benchmark

— amn
source

Pourquoi demandes-tu?

— Zoredache

La variabilité est (peut être) des ordres de grandeur entre les systèmes - le chargement du noyau et des pilotes est la plus petite fraction du processus de démarrage, et les scripts d'initialisation sur un système peuvent littéralement tout faire avant d'obtenir une invite de connexion. Veuillez expliquer la situation à laquelle vous faites face en termes de problème réel et pratique que nous pouvons vous aider à résoudre.

— voretaq7

@amn Pouvez-vous expliquer la raison de votre question initiale? Cela vous aidera avec le contexte. Une autre raison pour laquelle les gens poseraient une question similaire est s'ils utilisent un stockage à cycle limité. Plus de détails, c'est toujours mieux.

— ewwhite

@ewwhite Je démarre des centaines de machines Linux, et 95% du contenu de leur système sont identiques et resteront identiques - les machines sont des clones. Je voudrais décharger la partie partagée identique / en lecture seule du système de fichiers, vers un stockage NFS, le monter à partir de là et démarrer comme ça. Seule une partie inscriptible du système de fichiers, comme / var, / tmp et / home, restera locale sur chaque machine. Étant donné que potentiellement une centaine de machines peuvent démarrer simultanément dans le cadre d'un "cluster", j'ai besoin d'estimer si la liaison de stockage NFS accédée sera un goulot d'étranglement lors du démarrage à partir de.

— amn

I need to estimate...puis en faire un et le mesurer.

— symcbean

Réponses:

Installez un système, démarrez-le et consultez les statistiques de la couche de bloc, par /sys/block/${DEV}/statexemple /sys/block/sda/stat.

Citant de la documentation :

Le fichier de statistiques se compose d'une seule ligne de texte contenant 11 valeurs décimales séparées par des espaces. Les champs sont résumés dans le tableau suivant et décrits plus en détail ci-dessous:
Name            units         description
----            -----         -----------
read I/Os       requests      number of read I/Os processed
read merges     requests      number of read I/Os merged with in-queue I/O
read sectors    sectors       number of sectors read
read ticks      milliseconds  total wait time for read requests
write I/Os      requests      number of write I/Os processed
write merges    requests      number of write I/Os merged with in-queue I/O
write sectors   sectors       number of sectors written
write ticks     milliseconds  total wait time for write requests
in_flight       requests      number of I/Os currently in flight
io_ticks        milliseconds  total time this block device has been active
time_in_queue   milliseconds  total wait time for all requests
lire des secteurs, écrire des secteurs

Ces valeurs comptent le nombre de secteurs lus ou écrits sur ce périphérique de bloc. Les «secteurs» en question sont les secteurs UNIX standard de 512 octets, pas une taille de bloc spécifique au périphérique ou au système de fichiers. Les compteurs sont incrémentés à la fin des E / S.

Vous pouvez utiliser ce one-liner pour obtenir plus facilement le nombre d'octets:

awk '{printf("read %d bytes, wrote %d bytes\n", $3*512, $7*512)}' /sys/block/vda/stat

Résultats pour Scientific Linux 6.1 i386

J'ai testé cela sur une machine virtuelle KVM / qemu exécutant Scientific Linux 6.1 i386 (qui est similaire à RHEL). Les services suivants ont été activés: acpid, auditd, crond, network, postfix, rsyslog, sshd et udev-post. L'échange se fait sur un disque séparé, il n'est donc pas pris en compte.

Les statistiques pour 85 démarrages, prises à distance avec SSH quelques secondes après l'apparition de l'invite de connexion, étaient les suivantes:

    Name            Median   Average   Stdev
    -------------   ------   -------   -----
    read I/Os       1920     1920.2    2.6
    read merges     1158     1158.4    1.8
    read sectors    85322    85330.9   31.9
 >> read MiBytes    41.661   41.665    0.016
    read ticks      1165     1177.2    94.1
    write I/Os      33       32.6      1.7
    write merges    64       59.6      7.4
    write sectors   762      715.2     70.9
 >> write MiBytes   0.372    0.349     0.035
    write ticks     51       59.0      17.4
    in_flight       0        0.0       0.0
    io_ticks        895      909.9     57.8
    time_in_queue   1217     1235.2    98.5

Le temps de démarrage était d'environ 20 secondes.

— Cristian Ciupitu
source

Notez que cela ne semble vous donner que la demande de transfert (quantité), pas la demande de débit (taux). Vous pouvez cependant diviser par le temps de disponibilité pour obtenir un nombre moyen.

— voretaq7

Vous dites dans vos commentaires que vous évaluez un environnement racine netboot / réseau.

La première chose que vous devez comprendre est qu'il n'y a pas de "vanille" - vous n'allez pas lancer CentOS 5.10 dès le départ avec zéro changement (si vous pensez que vous vous trompez: NFS Root est déjà fraise au moins, proche de la pistache).

Si vous voulez une réponse pour votre environnement spécifique (ce qui compte vraiment), vous devrez configurer un serveur NFS et une machine cliente, démarrez-la et mesurez:

Le transfert (quantité)
Le débit (taux)

Les deux valeurs seront d'une importance critique pour les performances. Vous souhaiterez probablement également configurer plusieurs clients à un moment donné et simuler une utilisation normale du système pour voir quel type de demande d'état permanent ils imposent à votre serveur / réseau NFS lorsque les gens utilisent les systèmes comme ils le feraient dans leur vie quotidienne. travail.

Voir aussi: Notre série sur la planification de la capacité - nous ne parlons pas spécifiquement de NFS, mais les principes généraux de "Build it, Test it, Stress it" s'appliquent.

— voretaq7
source

S'il y a de la glace vanille, il y a de la vanille Linux! ;-) Sérieusement cependant, il s'agit d'un CentOS 5.10 assez inchangé, et tout ce qui a été modifié fait partie du système de fichiers inscriptible, celui qui ne sera pas monté à partir de NFS, donc ce n'est pas un facteur - oui, il y a une gigantesque base de données Postgres dans / var / lib mais / var n'est pas monté à partir de NFS mais se trouve sur le disque de démarrage physique local. Et si je voulais le profiler, je ne poserais pas la question ici :-)

— amn

@amn Je suis désolé que vous ne vouliez pas faire de profilage, mais vous devez faire ce que vous devez faire - nous ne pouvons pas retirer les chiffres applicables de nos mégots pour vous. Votre solution (racine NFS) est une solution solide et éprouvée, et honnêtement, vous pouvez probablement la déployer en aveugle sans aucun problème (des dizaines de milliers d'environnements Sun Microsystems ont été déployés en aveugle comme ça à l'époque de la racine NFS et de Netboot Solaris et a très bien fonctionné). Si vous êtes préoccupé par les performances, vous devrez effectuer un profilage pour déterminer la demande et les goulots d'étranglement pour votre environnement spécifique - c'est juste la voie de l'univers.

— voretaq7

+1 pour la fraise

— alexyorke

@ voretaq7 Je ne peux pas contester l'argument de profilage, et je ne l'ai jamais fait. Je voulais juste la meilleure chose avant de retrousser mes manches et de configurer le NFS. Merci de votre contribution précieuse.

— amn