LINUX.ORG.RU
ФорумTalks

А чем считают LA?

 ,


0

2

Вот этим, верно?

unsigned long avenrun[3];

static inline void calc_load(unsigned long ticks)
{
   unsigned long active_tasks; /* fixed-point */
   static int count = LOAD_FREQ;

   count -= ticks;
   if (count < 0) {
      count += LOAD_FREQ;
      active_tasks = count_active_tasks();
      CALC_LOAD(avenrun[0], EXP_1, active_tasks);
      CALC_LOAD(avenrun[1], EXP_5, active_tasks);
      CALC_LOAD(avenrun[2], EXP_15, active_tasks);
   }
}

Или может быть кто-либо ткнет в source, где есть расчет LA.

★★★★★

А его точно нужно считать? Разве нельзя посмотреть /proc/loadavg?

Вот этот пример вообще непонятен. Откуда код? На первый взгляд он бессмысленный.

Я думаю что считать надо как соотношение времени простоя относительно общего времени. Например, число тактов в простое за 10 сек, за минуту, за пять минут. По каждому процессорному ядру в отдельности.

Т.е. перед уходом в halt читать счётчик тактов, а в момент любого прерывания читать этот счётчик заново и вычитать из него предыдущее значение. Таким образом станет известно сколько тактов процессор «отдыхал». А затем по таймеру считать соотношение простоя к общему времени. Разумеется, все вычисления в тактах.

Число задач не коррелирует с загрузкой процессора. Все задачи могут ждать ввода/вывода и не грузить процессор. Что, кстати, является вполне нормальной ситуацией в подавляющем большинстве применений. Иначе ноутбуки бы разряжались в 10 раз быстрее.

alman ★★★
()
Последнее исправление: alman (всего исправлений: 1)
Ответ на: комментарий от alman

Я думаю что считать надо как соотношение времени простоя относительно общего времени.

LA показывает сколько задач готовых выполняться стоят в очереди. Если он > 1 (на 1 процессор) значит системе не хватает производительности и по LA можно понять на сколько, а замеряя время простоя процессора нельзя понять степень перегрузки.

vel ★★★★★
()
Ответ на: комментарий от alman

Число задач не коррелирует с загрузкой процессора.

Вот тут да. Как хорошо, что в этом треде мы считаем не ее, правда ведь?

t184256 ★★★★★
()
Ответ на: комментарий от vel

LA показывает сколько задач готовых выполняться стоят в очереди.

Хмм. Действительно считает в «попугаях». Для десктопа совершенно бессмысленная величина. Ибо ответ в моём предыдущем сообщении.

Насколько эта величина полезна для серверов - вопрос обсуждабельный. С учётом того, что скоростная сетевая карта или несколько сетевых карт способны обеспечить поток, который будет трудно «переварить» процессору.

Ах да. Утверждая такое предвижу гневные и обличительные комментарии. Так вот, посмотрим на синхронное микроядро L4 - в какие-то моменты времени очередь готовых задач может быть сильно больше 1. При этом при нормальном функционировании этот факт не значит ровным счётом ничего, потому что очередь успеет обслужиться до следующего вызова планировщика по таймеру. Т.е. если нет тяжелых задач, то процессор уйдёт в sleep до следующего прерывания.

В случае «тяжелой задачи» - загрузка будет 100%, всё свободное время, отданное другими задачами, займёт тяжелая задача.

В случае двух «тяжелых задач» - свободное время будет распределено между ними и загрузка составит те же 100%.

Что такое тяжёлая задача? Например, сложный рекурсивный математический расчёт или синтез топологии микросхемы или кодирование видео. Какой бы быстродействующий процессор не использовали - он всё равно на длительное время загрузит процессор на 100%. Кто запустит два таких процесса - его проблемы. В остальном - «степень перегрузки» означает лишь дисбаланс между скоростными внешними интерфейсами и «медленным» процессором. Проблема частично решается всяким DMA и интеллектуальной периферией, например, сетевой картой, способной без участия процессора считать/верифицировать контрольные суммы пакетов.

Я улыбаюсь периодическому плАчу о плохой отзывчивости UI при записи на медленную флешку. И улыбаюсь десятку различных алгоритмов планирования в ядре Linux. И ещё смеюсь когда сильно поцарапанный CD/DVD диск приводил к блокировке ввода/вывода до такой степени, что «плохеет» всей системе. Причём, это проявлялось и на Linix, и на производных от NT версиях Windows.

Не убедительно? Другими словами - задачи на современных процессора в абсолютно подавляющем числе случаев блокируются операцией ввода/вывода до того как задача исчерпывает свой квант планирования.

alman ★★★
()
Ответ на: комментарий от t184256

Как хорошо, что в этом треде мы считаем не ее, правда ведь?

Да, мы считаем величину, которая, возможно, была актуальна 30 лет назад.

alman ★★★
()
Ответ на: комментарий от alman

И улыбаюсь десятку различных алгоритмов планирования в ядре Linux.

Поясни. И покажи эти 10 различных алгоритмов. АФАИК, планировщик 1.

unt1tled ★★★★
()
Ответ на: комментарий от unt1tled

Очень давно не собирал ядро Linux. Если мой склероз не изменяет, то выбор планировщика производился на этапе конфигурирования ядра с помощью make menuconfig. Ну и вспоминаются периодические патчи в ядро на предмет планировщика. Типа - выбери что хочешь, общее быстродействие системы или отзывчивость интерфейса.

alman ★★★
()
Ответ на: комментарий от alman

очередь готовых задач может быть сильно больше 1. При этом при нормальном функционировании этот факт не значит ровным счётом ничего, потому что очередь успеет обслужиться до следующего вызова планировщика по таймеру.

А кем она обслужится, если планировщиком по таймеру?

Kuzz ★★★
()
Ответ на: комментарий от alman

Это наверно IO планировщик был. Процессовый всегда был один, если ты об этом. Щас там CFS. Есть еще BFS (позиционируется как шедулер для десктопа) но он out of tree и включать его не собираются.

ps: и я бы правда хотел видеть в ядре 10 шедулеров процессов вместо одного монстра на все случаи жизни

unt1tled ★★★★
()
Последнее исправление: unt1tled (всего исправлений: 1)
Ответ на: комментарий от Kuzz

С помощью сообщений. Любое взаимодействие между задачами или между задачей и ядром системы реализуется через сообщения. Сообщение начинается через вход в планировщик, который может отдать процессорное время более приоритетной задаче, при этом инициировавшая сообщение задача блокируется, а само сообщение ставится в очередь. После того как более приоритетная задача заблокируется или исчерпает свой квант, произойдёт обслуживание сообщений из очереди.

alman ★★★
()
Последнее исправление: alman (всего исправлений: 1)
Ответ на: комментарий от alman

И тут Остапа понесло.

Ну и при чем тут десктоп/сервер/попугаи? Есть параметр который позволяет оценить потребность в CPU. Да, на десктопе LA редко превышает 1.

Абсолютная загрузка CPU это другой параметр, есть еще время ввода-вывода. Вместе эти параметры позволяют оценить общую загрузку системы.

Если тебе не нравится LA - не смотри на него :)

Учитывая всеобщую виртуализацию, постоянный LA > 1 в VM это повод добавить ядер, если хочется считать быстрее.

vel ★★★★★
()
Ответ на: комментарий от unt1tled

А у меня не жрет.

top - 22:30:39 up 7 days,  1:18,  2 users,  load average: 0.23, 0.22, 0.18
Tasks: 205 total,   1 running, 204 sleeping,   0 stopped,   0 zombie

Это FF + transmission-daemon отдающий 8Мбит

vel ★★★★★
()
Ответ на: комментарий от Kuzz

Исчерпание кто отслеживает?

Таймер. Но я повторюсь - это нестандартная ситуация при которой задача не использовала сообщение. Например какие-то продолжительные вычисления или зависла в цикле. В стандартной ситуации задача раньше выполняет ввод/вывод до истечения своего кванта.

alman ★★★
()
Ответ на: комментарий от vel

Абсолютная загрузка CPU это другой параметр, есть еще время ввода-вывода.

Ага. Понесло. И останавливаться не хочется. :)

Например, время ввода/вывода. Вот не считаю что при анализе загрузки процессора задачей надо учитывать это время. Т.е. когда мы смотрим top, то видим сколько задача провела в пользовательском контексте, а сколько в контексте ядра. Работа в контексте ядра это уже не время задачи, а время потреблённое ядром. Если уж так нужна эта статистика, то тогда имеет смысл собирать её на уровне ядра, типа, сколько ресурсов ядра потребила каждая задача.

alman ★★★
()
Ответ на: комментарий от alman

задача раньше выполняет ввод/вывод до истечения своего кванта.

И, блокируясь на IO, вызывает планировщик, т.к. только он может переместить ее из очереди готовых/выполняющихся в список блокированных, а другую задачу поставить на выполнение.

Kuzz ★★★
()
Ответ на: комментарий от alman

это нестандартная ситуация

С чего бы? Очень даже стандартная. Если все данные у задачи есть (предварительно в память загрузила, например), то выполняться она будет до окончания кванта.

Впрочем, первоначальная фраза об быстро отработавшей куче задач и на линуксе точно так же не уложит систему, да и LA изменится незначительно. Статистика то берется минимум за минуту.

Kuzz ★★★
()
Ответ на: комментарий от Kuzz

Так я и не спорю с предыдущими двумя сообщениями. Всё в них верно сказано.

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

Такую ситуацию можно представить, например, при выполнении SQL запроса. Чтобы при этом обеспечить полную загрузку, то такие запросы должны приходить довольно часто. Опять возвращаемся к сценарию нагруженного сервера, о котором я оговорился в самом начале.

В случае десктопа или сервера без нагрузки, процессор простаивает большую часть времени.

alman ★★★
()
Ответ на: комментарий от unt1tled

вирусы, подумал штирлиц...

Скорее кривые руки у разработчиков сайтов или их недобросовестность - с высокой вероятностью процессорное время жрёт какой-то тупой скрипт со страницы, крутящий банер или собирающий статистику или действительно что-то считающий для владельца сайта.

Ради эксперимента закрой все вкладки и посиди на ЛОР - подозреваю что статистика загрузки CPU тебя приятно удивит. При условии что на компе действительно нет вирусов (и богопротивных антивирусов).

alman ★★★
()
Последнее исправление: alman (всего исправлений: 1)
Ответ на: комментарий от alman

Величина на десктопе эта довольно полезна, так как позволяет понять, процессор загружен до предела или ввод-вывод, когда всё тормозит.

Quasar ★★★★★
()
Ответ на: комментарий от alman

alman> Так вот, посмотрим на синхронное микроядро L4 - в какие-то моменты времени очередь готовых задач может быть сильно больше 1. При этом при нормальном функционировании этот факт не значит ровным счётом ничего, потому что очередь успеет обслужиться до следующего вызова планировщика по таймеру.

Это уже не loadavg, а load. Величина loadavg определяется за промежуток времени. И в зависимости от этих промежутков значения для одной и той же ситуации могут быть сильно разными.

Quasar ★★★★★
()
Ответ на: комментарий от unt1tled

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

Quasar ★★★★★
()
Ответ на: комментарий от alman

У меня итак открыт только лор. + noscript, ublock & ghostery. Может это плагины кстати и жрут цпу :D

unt1tled ★★★★
()
Ответ на: комментарий от alman

Насколько эта величина полезна для серверов - вопрос обсуждабельный.

Очень. Всегда можно показать ее начальству и сказать: «че-то, босс, нам надо уже 2.35 таких сервера».

t184256 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.