Comments 34
А вы прошли собеседование?
Как-то без собеседования захотелось узнать что это такое, почитал официальный ман и всё понял. С другой стороны подобные вопросы, это не способ найти кандидата, а способ повыпендриваться перед ним, в самом лучшем случае это психологический вопрос не влияющий на результат собеседования, в худшем как и сказал — повыпендриваться. Но разбор данного вопроса хорош. Ябвзял на работу :-)
Это зависит от настроения, с которым кандидат пришёл. Я первый раз почувствовал на собеседовании интерес, когда меня не спрашивали общеобтекающими фразами про моё видение меня в их компании, а задали крайне каверзный вопрос, ответа на который я не знал и который мне пришлось срочно придумывать в режиме мозгового штурма.
Каверзные вопросы (не вида «чему равен FIXED_1 на 64-битных системах?»), а подразумевающий некие тонкие процессы в системе — это отличный повод поговорить по теме. Гипотезы (в т.ч. неверные), которые высказывает кандидат позволяют лучше оценить его ход мысли и способности, чем готовый ответ (42).
Другое дело, если кандидат воспринимает вопрос на который он не знает ответа как «всё пропало, собеседование провалено». Ещё хуже, если его таковым воспринимает кто-то из собеседующих. Но это вопрос корпоративной культуры, и лучше не пройти на собеседовании, чем обнаружить эту «культуру» в полной красе спустя пару месяцев потраченного времени на освоение никому не полезных особенностей жизни компании.
Каверзные вопросы (не вида «чему равен FIXED_1 на 64-битных системах?»), а подразумевающий некие тонкие процессы в системе — это отличный повод поговорить по теме. Гипотезы (в т.ч. неверные), которые высказывает кандидат позволяют лучше оценить его ход мысли и способности, чем готовый ответ (42).
Другое дело, если кандидат воспринимает вопрос на который он не знает ответа как «всё пропало, собеседование провалено». Ещё хуже, если его таковым воспринимает кто-то из собеседующих. Но это вопрос корпоративной культуры, и лучше не пройти на собеседовании, чем обнаружить эту «культуру» в полной красе спустя пару месяцев потраченного времени на освоение никому не полезных особенностей жизни компании.
Спасибо. Образец того, как надо искать финальные ответы в Документации.
Во второй части статьи в PDF больше объяснений, а мне уже не удобно самого себя цитировать дважды:
Процитирую свой же комментарий в статье "CPU Load: когда начинать волноваться?"
В старом посте про load average давали ссылку на замечательную статью, где я и прочитал про это самое «экспоненциально взвешенное скользящее среднее»,
Очень рекомендую к прочтению, можно даже добавить в пост.
Часть 1 www.teamquest.com/pdfs/whitepaper/ldavg1.pdf
Часть 2 www.teamquest.com/pdfs/whitepaper/ldavg2.pdf
Почему-то вспомнилось.
дано 8xXeon сервер 16G RAM
небольшой шаредхостинг под DDoS.
на LA= 1024 он у меня отвалился по ssh.
Я, к сожалению, не очень дружу с высшей математикой. но какое количество процессов там могло быть…
дано 8xXeon сервер 16G RAM
небольшой шаредхостинг под DDoS.
на LA= 1024 он у меня отвалился по ssh.
Я, к сожалению, не очень дружу с высшей математикой. но какое количество процессов там могло быть…
Дело было скорее не в количестве собственно процессов, а в очереди на обработку. SSH — сервис, чаще всего, имеет средний приоритет, в то время, как на сервере под DDoS будет большое количество процессов, требующих «немедленной» обработки большого количества ресурсов (а это как раз куча PHP и иже с ними). В таком случае, отклик системы будет очень большим, а иногда и просто начнут теряться пакеты (уже по таймауту обработки).
И как раз Load Average в Вашем случае указывал на то, что многим процессам необходимо обработать множество данных, но в настоящее время они ждутвторого пришествия самой медленной части — диска.
Допустим, 100 процессов обратились к базе данных (например, MySQL), та ответила «Жди, я сейчас» и ушла на диск… 100 раз. В разные места. Диск в тихом шоке, и не может определить что считать ранее… потому читает частички из случайных мест… в итоге, все стоят и ждут. А фактически, в этот момент процессор не занят, ожидая появления флага «Дисковая операция завершилась».
У нас была аналогичная ситуация при проблеме с базой данных. Процессор 8 ядер (не Xeon, но серверный) был загружен на 30-50% (из 800 возможных), а вот диск…
«sar -d» неизменно выводил 99.99% активности диска.
SSH работал, процессы жили… но плохо. Load Average рос до 10-20.
И как раз Load Average в Вашем случае указывал на то, что многим процессам необходимо обработать множество данных, но в настоящее время они ждут
Допустим, 100 процессов обратились к базе данных (например, MySQL), та ответила «Жди, я сейчас» и ушла на диск… 100 раз. В разные места. Диск в тихом шоке, и не может определить что считать ранее… потому читает частички из случайных мест… в итоге, все стоят и ждут. А фактически, в этот момент процессор не занят, ожидая появления флага «Дисковая операция завершилась».
У нас была аналогичная ситуация при проблеме с базой данных. Процессор 8 ядер (не Xeon, но серверный) был загружен на 30-50% (из 800 возможных), а вот диск…
«sar -d» неизменно выводил 99.99% активности диска.
SSH работал, процессы жили… но плохо. Load Average рос до 10-20.
Познавательно, спасибо. Еще хорошая статья по теме: habrahabr.ru/post/216827
Наводящий вопрос:
А Вы не встречали такую ситуацию, когда LA на сервере около сотни, а нагрузка на каждое ядро меньше 10%?
А Вы не встречали такую ситуацию, когда LA на сервере около сотни, а нагрузка на каждое ядро меньше 10%?
в стандартной архитектуре intel этот промежуток равен 10мс
Вообще это определяется ОС, какой она выберет период для системного таймера, по которому контексты переключаются. От железа это особо не зависит.
Про экспонету — так работает rolling average.
en.wikipedia.org/?title=Moving_average
Там даже есть этот конкретный пример про длину очереди планировщика.
Про 10мс, на самом деле не все так понятно. В первой из указанных мной статей сказано:
Что больше всего похоже на описание хардварного watchdog timer, вставленного на 10мс.
Так же есть описание от автора второй статьи, где сказано:
На сколько я понимаю, есть два параметра, которые в результате принимают одно значение, один из них хардварный, а другой — системный:
Но если вы знаете как, это устроено на самом деле, то мне было бы интересно узнать подробное объяснение. Пока что мне кажется странным прерывание каждые 10мс, независимо от состояния системы, поскольку они с большой вероятностью попадут на нормально работающий процесс. А если они зависят от состояния системы, тогда 500 таких прерываний вовсе не гарантируют 5 секундного интервала.
Про экспоненту почитаю, спасибо.
If the process uses its fully allotted CPU time of 10ms, an interrupt is raised by the hardware, and the kernel regains control from the process.
Что больше всего похоже на описание хардварного watchdog timer, вставленного на 10мс.
Так же есть описание от автора второй статьи, где сказано:
It is the name of a number. The actual value of that number is machine-
dependent. The following platforms use HZ == 100:
•Intel Pentium
•Power PC
•Ultra-SPARC
whereas the HP Alpha uses HZ == 1024 or HZ == 1200, depending on the CPU model. We’ll
assume HZ represents 100 in the subsequent explanation.
На сколько я понимаю, есть два параметра, которые в результате принимают одно значение, один из них хардварный, а другой — системный:
Every computer platform has a clock implemented in hardware that has a constant ticking
rate by which everything else in the system is synchronized. To make this ticking rate known
to the system, the hardware sends an interrupt to the Linux kernel on every clock tick. A HZ
value of 100 means that one second of wall-clock time corresponds to 100 CPU ticks.
Но если вы знаете как, это устроено на самом деле, то мне было бы интересно узнать подробное объяснение. Пока что мне кажется странным прерывание каждые 10мс, независимо от состояния системы, поскольку они с большой вероятностью попадут на нормально работающий процесс. А если они зависят от состояния системы, тогда 500 таких прерываний вовсе не гарантируют 5 секундного интервала.
Про экспоненту почитаю, спасибо.
Ядро Linux разрабатывается как легко переносимое, потому у него нет жестких завязок на хардварные таймеры (если вы их сами не прикрутите).
То, что здесь названо CONFIG_HZ — это исторический системный таймер, к которому привязан счетчик jiffies, планировщик и классические struct timer. Он платформонезависим, а изменение значения jiffies с изменением реального времени связно при помощи соотношения dT (sec) = djiffies / CONFIG_HZ.
Да, исторически ядро всегда дергалось аппаратным прерыванием с константным рейтом раз в 1/CONFIG_HZ миллисекунд чтобы вызвать планировщик, произвести необходимые отложенные операции (например с RCU), а также обработать сработавшие struct timer, потому что это просто и переносимо. Плюс раньше процессоры были слабые, и обработка прерывания даже раз в 1 мс уже была слишком дорогой, а перепрограммировать системный таймер раз в прерывание тоже было дорого.
Но мощь ЦПУ роста, и со временем некоторым (как и вам) все больше и больше не нравилась постоянная обработка бесполезных прерываний аппаратного таймера (а заметная часть их бесполезна, особенно при малом количестве процессов в системе и отсутствии необходимости в обработке множества bottom-halves, tasklets и workqueues при низкой нагрузке на систему), потому придумали так называемый tickless-режим, задаваемый опцией CONFIG_NO_HZ (а старый обозвали FULL_HZ соответственно), в котором прерывания от аппаратного таймера включаются тогда, когда они нужны и хардварный таймер регулярно меняет рейт (подробное описание всех вариаций режима займет много времени, проще погуглить по «linux kernel tickless», идеальное начало тут: git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/NO_HZ.txt ); другим же товарищам стало мало точности в 1/CONFIG_HZ (реально, по меркам большинства подсистем ядра, особенно при современной мощности ЦПУ и сетевых картах в 40 GBps это целая вечность), потому ввели поддержку High-Precision Event Timers и новых struct hrtimer (High-Resolution Timers) с точностью вплоть до 1 нс.
Так что все течет, все меняется, и утверждения из комментария можно считать справедливыми разве что для ядер < 2.6 (и соответственно для 2003 года и раньше). Ну и на 2.4 вообще имхо сейчас стоит смотреть разве что с археологическими целями — тот же планировщик процессов в цикле разработки 2.6 был переписан неоднократно, его разработка постоянно приковывала к себе внимание и вызывала жаркие дискуссии.
То, что здесь названо CONFIG_HZ — это исторический системный таймер, к которому привязан счетчик jiffies, планировщик и классические struct timer. Он платформонезависим, а изменение значения jiffies с изменением реального времени связно при помощи соотношения dT (sec) = djiffies / CONFIG_HZ.
Да, исторически ядро всегда дергалось аппаратным прерыванием с константным рейтом раз в 1/CONFIG_HZ миллисекунд чтобы вызвать планировщик, произвести необходимые отложенные операции (например с RCU), а также обработать сработавшие struct timer, потому что это просто и переносимо. Плюс раньше процессоры были слабые, и обработка прерывания даже раз в 1 мс уже была слишком дорогой, а перепрограммировать системный таймер раз в прерывание тоже было дорого.
Но мощь ЦПУ роста, и со временем некоторым (как и вам) все больше и больше не нравилась постоянная обработка бесполезных прерываний аппаратного таймера (а заметная часть их бесполезна, особенно при малом количестве процессов в системе и отсутствии необходимости в обработке множества bottom-halves, tasklets и workqueues при низкой нагрузке на систему), потому придумали так называемый tickless-режим, задаваемый опцией CONFIG_NO_HZ (а старый обозвали FULL_HZ соответственно), в котором прерывания от аппаратного таймера включаются тогда, когда они нужны и хардварный таймер регулярно меняет рейт (подробное описание всех вариаций режима займет много времени, проще погуглить по «linux kernel tickless», идеальное начало тут: git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/NO_HZ.txt ); другим же товарищам стало мало точности в 1/CONFIG_HZ (реально, по меркам большинства подсистем ядра, особенно при современной мощности ЦПУ и сетевых картах в 40 GBps это целая вечность), потому ввели поддержку High-Precision Event Timers и новых struct hrtimer (High-Resolution Timers) с точностью вплоть до 1 нс.
Так что все течет, все меняется, и утверждения из комментария можно считать справедливыми разве что для ядер < 2.6 (и соответственно для 2003 года и раньше). Ну и на 2.4 вообще имхо сейчас стоит смотреть разве что с археологическими целями — тот же планировщик процессов в цикле разработки 2.6 был переписан неоднократно, его разработка постоянно приковывала к себе внимание и вызывала жаркие дискуссии.
Что больше всего похоже на описание хардварного watchdog timer, вставленного на 10мс.
Нет, это не watchdog, это именно таймер. Если быть точным в архитектуре IBM PC используется 8253 (точнее некое его обратно совместимое подобие в глубинах чипсета). Его частота настраивается, и может быть выбрана ОС. Кроме того ОС вообще вольна выбирать, что будет источником тиков для переключения контекстов, необязательно даже, что этот таймер (даже будучи запущенным на архитектуре IBM PC), и, конечно, необязательно на этой частоте.
Пока что мне кажется странным прерывание каждые 10мс, независимо от состояния системы, поскольку они с большой вероятностью попадут на нормально работающий процесс.
Никакой проблемы в этом нет. Если очень упрощённо, то когда срабатывает прерывание, ядро смотрит на текущий активный процесс (точнее поток, если ОС поддерживает потоки на уровне ядра). Если он работал непрерывно с предыдущего прерывания (а чтобы за этим следить, достаточно флаг выставлять в прерывании и сбрасывать при переключении контекста), то при наличии других процессов в очереди, контекст переключается, чтобы дать возможность поработать другим (в таком случае говорят, что процесс исчерпал свой time slot). Иначе он будет продолжать работать до следующего прерывания, или пока сам не отдаст контекст другим (зайдёт в ожидание). В реальности, конечно, всё намного сложнее, у процессов и потоков есть приоритеты, влияющие на этот процесс, которые к тому же могут динамически меняться, в зависимости от поведения процесса. Как написал товарищ выше, частота прерывания в современных ОС тоже может меняться динамически. А логика планировщика постоянно эволюционирует.
1,5 или 15 минут
Я прочитал половину текста, пока не понял, что после запятой пропущен пробел. Никак не мог понять, откуда взялись «полторы и пятнадцать минут» :) Добавьте пробел, пожалуйста: «1, 5 или 15 минут».
В хабе *nix*, а только к Linux относиться, который к никсам как кузен…
На мой взгляд, в статье не до конца раскрыто значение TASK_UNINTERRUPTIBLE.
Если вспомнить про машинки из этой статьи, то грубо говоря, LA показывает, сколько машинок едут, или стоят в ожидании ресурсов.
Ресурсы — это не столько CPU, сколько I/O.
Чаще всего это жесткий или сеть.
Приведу короткую цитату отсюда:
По своему опыту — на обычных задачах современный процессор редко становится причиной роста LA
Если вспомнить про машинки из этой статьи, то грубо говоря, LA показывает, сколько машинок едут, или стоят в ожидании ресурсов.
Ресурсы — это не столько CPU, сколько I/O.
Чаще всего это жесткий или сеть.
Приведу короткую цитату отсюда:
Thus the 3 factors that drive the Load Average on a Linux system are processes that are on the run-queue because they:Таким образом, при хорошей нагрузке легко получить высокий LA при затупах дисковой или сетевой подсистемы (как из за аппаратных проблем, так и из за программных).
* Run on, or are waiting for, the CPU
* Perform disk I/O
* Perform network I/O
По своему опыту — на обычных задачах современный процессор редко становится причиной роста LA
сколько всего процессов находится в состоянии RUNNING и UNINTERRUPTIBLE
Вроде там написано не «и», а «или». То есть RUNNING или UNINTERRUPTIBLE.
632 if ((p->state == TASK_RUNNING ||
633 (p->state & TASK_UNINTERRUPTIBLE)))
634 nr += FIXED_1;
Интересно, похоже на Exponentially Weighted Moving Average во всю применяющийся в эконометрике
Судя по всему, это именно оно и есть. Во второй части статьи в PDF это сглаживание называется «exponentially-damped moving average», или, как мне подсказали выше «rolling average».
Ситуация, когда la > cpu, как правило, связана с IO. То есть в силу разных причин процессы висят в D стейте. Я недавно заприметил обратную ситуацию — когда la < cpu и вот это меня очень заинтриговало. Вот пример 
Я, конечно, догадываюсь, что виной всему S Interruptible sleep (waiting for an event to complete). Может кто подскажет, прав ли я?
Я, конечно, догадываюсь, что виной всему S Interruptible sleep (waiting for an event to complete). Может кто подскажет, прав ли я?
Построил график, поясняющий статью. Если запустить один процесс, который будет 100% времени что-то делать, то la будет выглядеть так(через пол часа процесс завершили):
Даже через пол-часа 15-минутный la достиг отметки только 0.8.
Скрипт для построения: alexbers.com/load_average/la.py
В соответствии теории практике можно убедиться, запустив perl -e 'while(1){}' на любом свободном сервере.
Даже через пол-часа 15-минутный la достиг отметки только 0.8.
Скрипт для построения: alexbers.com/load_average/la.py
В соответствии теории практике можно убедиться, запустив perl -e 'while(1){}' на любом свободном сервере.
Sign up to leave a comment.
Как считается Load Average