Сколько данных Linux читает в среднем при загрузке?

Интересно, сколько всего данных читает недавно установленная система Linux vanilla (например, 32-разрядная CentOS 5.10), чтобы получить приглашение оболочки виртуальной консоли? Вы читаете все файлы конфигурации, загружаете двоичные файлы, образ ядра и т. Д.

Я ищу оценки по порядку величины. Я знаю, что загрузка Linux сильно варьируется в зависимости от деталей процесса. Мы говорим 10Mb? 100Mb? 1Gb?

linux boot benchmark

— атп
источник

Почему ты спрашиваешь?

— Зоредаче

Изменчивость составляет (может быть) порядки величин между системами - загрузка ядра и драйверов - это самая незначительная часть процесса загрузки, и сценарии инициализации в системе могут выполнять буквально все, что угодно, прежде чем вы получите приглашение для входа в систему. Пожалуйста, объясните ситуацию, с которой вы имеете дело, с точки зрения реальной, практической проблемы, которую мы можем помочь вам решить.

— voretaq7

@amn Можете ли вы указать причину в своем первоначальном вопросе? Это поможет с контекстом. Другая причина, по которой люди задают подобный вопрос, заключается в том, что они используют хранилище с ограниченным циклом. Больше деталей всегда лучше.

— ewwhite

@ewwhite Я загружаю сотни компьютеров Linux, и 95% их системного содержимого идентичны и останутся идентичными - машины являются клонами. Я хотел бы выгрузить идентичную / доступную только для чтения общую часть файловой системы в хранилище NFS, смонтировать ее оттуда и загрузить таким образом. Только доступная для записи часть файловой системы, такая как / var, / tmp и / home, останется локальной для каждой машины. Поскольку потенциально «сотни» компьютеров могут загружаться одновременно как часть «кластера», мне нужно оценить, будет ли узкое место при загрузке с доступной ссылки на хранилище NFS.

— атп

I need to estimate...затем сделайте один и измерьте это.

— symcbean

Ответы:

Установите одну систему, загрузите ее и посмотрите статистику уровня блоков, /sys/block/${DEV}/statнапример, из /sys/block/sda/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
читать секторы, писать секторы

Эти значения подсчитывают количество секторов, считанных или записанных на этом блочном устройстве. Рассматриваемые «сектора» - это стандартные 512-байтовые сектора UNIX, а не размер блока, специфичный для устройства или файловой системы. Счетчики увеличиваются, когда ввод / вывод завершается.

Вы можете использовать эту однострочную строку для более легкого получения количества байтов:

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

Результаты для Scientific Linux 6.1 i386

Я проверил это на виртуальной машине KVM / qemu под управлением Scientific Linux 6.1 i386 (которая аналогична RHEL). Были включены следующие службы: acpid, auddd, 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 секунд.

— Кристиан Чиупиту
источник

Обратите внимание, что это только дает вам потребность в передаче (количество), а не пропускную способность (скорость). Вы можете разделить на время работы, чтобы получить среднее число, хотя.

— voretaq7

В ваших комментариях вы говорите, что оцениваете среду сетевой загрузки / сети.

Первое, что вы должны понять, это то, что нет такой вещи, как «ваниль» - вы не собираетесь запускать CentOS 5.10 сразу из коробки с нулевыми изменениями (если вы думаете, что вы обманываете себя: NFS Root уже по крайней мере, клубника, грани на фисташке).

Если вы хотите получить ответ для своей конкретной среды (что действительно имеет значение), вам потребуется настроить сервер NFS и клиентский компьютер, загрузить его и измерить:

Передача (количество)
Пропускная способность (скорость)

Оба значения будут критически важны для производительности. Вы, вероятно, также захотите настроить несколько клиентов в какой-то момент и смоделировать нормальное использование системы, чтобы увидеть, какой постоянный спрос они предъявляют к вашему NFS-серверу / сети, когда люди используют системы, как в повседневной работе. Работа.

Смотрите также: Наша серия по планированию мощностей - мы не говорим конкретно о NFS, но применяются общие принципы «Построй, проверь, подчеркни».

— voretaq7
источник

Если есть ванильное мороженое, то есть ванильный Linux! ;-) Если серьезно, это довольно неизменный CentOS 5.10, и все, что было изменено, является частью доступной для записи файловой системы, которая не будет монтироваться из NFS, так что это не фактор - да, есть гигантская база данных Postgres в / var / lib но / var не монтируется из NFS, а находится на локальном физическом загрузочном диске. И если бы я хотел профилировать это, я не задавал бы вопрос здесь :-)

— amn

@amn Мне жаль, что ты не хочешь заниматься профилированием, но ты должен делать то, что должен - мы не можем вытащить подходящие цифры из наших задниц для тебя. Ваше решение (NFS root) является надежным, проверенным временем, и, честно говоря, вы, вероятно, можете просто развернуть его без проблем без проблем (десятки тысяч сред Sun Microsystems были развернуты вслепую, как это было во времена расцвета NFS-root и сетевой загрузки). Солярис и работал отлично). Если вы беспокоитесь о производительности, хотя вам нужно выполнить профилирование, чтобы определить спрос и узкие места для вашей конкретной среды - это всего лишь путь вселенной.

— voretaq7

+1 за клубнику

— alexyorke

@ voretaq7 Не могу поспорить с аргументом профилирования, и никогда не спорил. Я просто хотел следующую лучшую вещь, прежде чем закатать рукава и настроить NFS. Спасибо за ваш ценный вклад.

— атп