Скільки даних читає Linux у середньому завантаженні?

Цікаво, скільки даних загалом читає щойно встановлена ​​ванільна система Linux (наприклад, 32-розрядна CentOS 5.10) для того, щоб потрапити в віртуальну консоль оболонки? Ви знаєте, читання всіх файлів конфігурації, завантаження бінарних файлів, зображення ядра тощо.

Я шукаю оцінки порядку порядку. Я знаю, що завантаження Linux сильно відрізняється щодо деталей процесу. Ми говоримо 10Mb? 100Mb? 1 Гбіт?

Встановіть одну систему, завантажте її та ознайомтеся зі статистикою блокового рівня, /sys/block/${DEV}/statнаприклад /sys/block/sda/stat.

Цитування з документації :

Файл stat складається з одного рядка тексту, що містить 11 десяткових значень, розділених пробілом. Поля підсумовані в наступній таблиці та описані більш докладно нижче:

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

читати сектори, писати сектори

Ці значення підраховують кількість секторів, прочитаних або записаних на цей блок пристрою. Розглянуті "сектори" - це стандартний UNIX 512-байтний сектор, а не будь-який розмір блоку, характерний для пристрою чи файлової системи. Лічильники збільшуються після завершення вводу / виводу.

Ви можете скористатися цим одноклапником, щоб легше отримати кількість байтів:

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

Результати для наукового Linux 6.1 i386

Я перевірив це на віртуальній машині KVM / qemu, що працює під управлінням Scientific Linux 6.1 i386 (що схоже на RHEL). Увімкнено такі сервіси: acpid, auditd, crond, network, postfix, rsyslog, sshd та udev-post. Свід знаходиться на окремому диску, тому він не враховується.

Статистика 85 черевиків, знятих віддалено за допомогою SSH через пару секунд після появи запиту на вхід:

    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

Час завантаження становило близько 20 секунд.

У своїх коментарях ви кажете, що оцінюєте кореневе середовище netboot / network.

Перше, що ви повинні усвідомити, що немає такого поняття, як "ваніль" - ви не збираєтеся запускати CentOS 5.10 прямо з коробки з нульовими змінами (якщо ви думаєте, що обманюєте себе: NFS Root вже є принаймні Полуничне, що межує з Фісташком).

Якщо ви хочете відповісти для вашого конкретного середовища (що насправді рахується), вам знадобиться налаштувати сервер NFS та клієнтську машину, завантажте його та виміряйте:

1. Переказ (кількість)
2. Пропускна здатність (швидкість)

Обидва значення будуть критично важливими для продуктивності. Ви, ймовірно, також захочете налаштувати декілька клієнтів у якийсь момент та змоделювати нормальне використання системи, щоб побачити, який стаціонарний попит вони ставлять на ваш сервер / мережу NFS, коли люди користуються системами, як це було б у їх повсякденному житті робота.

Дивіться також: Наша серія з планування потенціалу - ми не говоримо конкретно про NFS, але застосовуються загальні принципи "Побудуй її, протестуй, наголоси".