GPU ЧаВо
Ферма постоянно перезагружается. Если через Hive Shell включить logs-on, на что обращать внимание?
Когда риг уйдет в оффлайн, Hive Shell разъединится, а на экране как раз останутся именно эти строки.
Как снизить энергопотребление GPU?
Для снижения потребления ваших GPU (при использовании Hive OS), вы можете указать параметры напряжения ядра и памяти индивидуально для каждой карты.
Для этого зайдите на вашем воркере в раздел Разгон и укажите нужные значения в профиле разгона. Обратите внимание, что в графе Состояние памяти вы можете указать как индекс состояния 0, 1, или 2, так и напряжение в мВт.
Так же для снижения энергопотребления вы можете воспользоваться режимом агресивного андервольтинга:
Как проверить, есть ли интернет на GPU риге?
Ошибка 511. Почему она возникает?
Данная ошибка возникает в большинстве случаев из за неисправности райзера видеокарты. Проверьте разъем питания на райзере на предмет подгоревшего провода, и замените райзер.
Что такое DPM на видеокартах AMD?
Производитель с большим запасом выставляет вольтаж для каждой ступени частоты ядра. Наша задача для выбранной частоты ядра, прописанной в DPM, подобрать наименьшее значение вольтажа, но при этом чтобы карта продолжала копать стабильно. Так мы получаем пониженное потребление без потери производительности. Это и есть даунвольт. Пример даунвольтов:
Как риги объединить/перенести на другую ферму?
Перейдите в настройки рига:
Затем перейдите на нижнюю часть страницы и нажмите Расширенные настройки:
Выберите из выпадающего списка нужную ферму, и нажмите на кнопку Перенос:
Запуск mc на риге
Как через Hive-Shell проверить, действительно ли завис риг?
Зайдите по Hive Shell на рабочий риг, находящийся в той же локальной сети что и зависший.
Введите вот эту команду: ssh [email protected]”Ip_адрес_неработающего_рига” :
Далее введите свой пароль от этого рига. Последний ip-адрес рига можно посмотреть на панели управления Hive OS.
Теперь можно проверить, действительно ли риг завис или отключился, или же это какой-то «глюк» сервера веб-интерфейса. Команда exit возвращает каждый раз по цепочке обратно.
Что такое LA (Load Average)?
Load Average (средняя нагрузка) — это среднее количество исполняемых процессов в течение определённого времени. Например, если часовая средняя нагрузка равна 10, то это означает (для однопроцессорной системы), что в любой момент времени в течение этого часа 1 процесс выполняется, а 9 готовы к выполнению (то есть не блокированы для ввода/вывода) и ждут, когда процессор освободится.
Если у вас Celeron G3930 с двумя ядрами, то LA 2 свидетельствует о 100% загрузке системы. Для Ethash это очень ненормально, а вот для современных алгоритмов — вполне подходит.
Максимальное значение LA может быть каким угодно. Это длина очереди к процессору, выраженная в количестве ядер этого процессора. LA всегда считалось в количестве вычислительных устройств, требуемых для выполнения всей текущей очереди задач.
При майнинге Beam и Cuckoo на слабых процессорах, LA может доходить до 3-4. Если не нравится красный цвет индикатора, вы всегда можете настроить пороговое значение вот здесь:
Три значения: LA сейчас / среднее LA за 5 минут / среднее LA за 15 минут.
Высокий load average. Диагностика.
Накидайте каких-нибудь ссылок по диагностике проблем с нагрузкой.
Есть железка 2xE5-2620v2 с SAS-дисками. Памяти достаточно. Трудится в роли веб-сервера. Периодически load average вырастает до 30-40, когда вырастает до 60-70, то сервер начинает уходить в оффлайн. Съедает ЦП в основном userspace. Я примерно догадываюсь какие процессы жрут ресурсы, но хочется диагностировать поточнее.
На какие параметры обратить внимание? Куда смотреть в первую очередь? Хочу что-нибудь почитать на эту тему. Спасибо.
Съедает ЦП в основном userspace
Я примерно догадываюсь какие процессы жрут ресурсы, но хочется диагностировать поточнее.
Посмотрел htop. IO wait околонулевой, в основном userspace. В iotop в основном mysql (логично). Скорость чтения/записи невысокая, иногда бывают пики скорости записи (Total DISK WRITE) до 100МБ/с, но я считаю это мелочи. Т.е. на диск не похоже совсем.
Памяти много, все кэшируется, MySQL тоже.
P.S. Изучаю atop, раньше не пользовался.
atop самый информативный в таких случаях, срузу нужно смотреть общий IDLE + IOWAIT по CPU и utilisation по дискам и сетевым интерфейсам. С загрузкой дисков и сетевых интерфейсов есть небольшой баг в расчетах поэтому значения от 90% до 110% можно считать за стабильные 100%.
PS. Есще у atop есть полезный режим демона, он складирует всю статистику в файл и если например ночью были проблемы с нагрузкой на сервере можно запустить atop в режиме чтения логов и посмотреть что происходило ночью.
atop самый информативный в таких случаях, срузу нужно смотреть общий IDLE + IOWAIT по CPU и utilisation по дискам и сетевым интерфейсам. С загрузкой дисков и сетевых интерфейсов есть небольшой баг в расчетах поэтому значения от 90% до 110% можно считать за стабильные 100%.
Более-менее разобрался, действительно полезная штука. Парсить немного неудобно, но потом привыкаешь.
PS. Есще у atop есть полезный режим демона, он складирует всю статистику в файл и если например ночью были проблемы с нагрузкой на сервере можно запустить atop в режиме чтения логов и посмотреть что происходило ночью.
У меня даже Munin стоит. Только там не видно какие именно процессы съедают ресурсы. Видны только пики load average и userspace cpu.
В общем atop только подтвердил мое предположение — на сервере запущено несколько фоновых воркеров Gearman, вот они и нагружают систему. Временно остановил их.
А На диск нагрузки почти нет, только в моменты когда Redis пишет дамп. На сеть совсем копейки.
Пока писал пост воркеры все это время лежали и load average упал до 13-18. Пусть еще полежат, посмотрю в динамике, но уже неплохо. Сейчас нагружают систему только воркеры PHP-FPM и MySQL.
В общем похоже тред можно закрывать 🙂 Посмотрел код воркеров — там ужас, надо переписывать. Еще надо будет slow log в PHP-FPM включить.
Спасибо большое за помощь.
Где-то тут на ЛОРе кто-то даже писал, что если load average равен количеству ядер, то сервер себя хорошо окупает 🙂 Но у меня LA сильно больше — сервак падает.
Не всегда, LA показывает сколько процессов в системе ждут/потребляют ресурсов в данный момент. Наример если LA 8 это значит что 8 процессов /threads нужнаются в некоторых ресурсах сервера. А дальше все зависит от того какой ресурс им нужен если это CPU и у вас 24 ядра то все ОК, так как 12 ядер есще остается в запасе. Если же все 8 процессов/потоков ожидают ввод/вывод от HDD а HDD у вас 1, то это уже не хорошо и может привести к DOS и/или падению сервера.
Проблема была еще и в распухших логах PHP-FPM (12ГБ) 🙂
Что такое LA (load average) и как правильно его рассчитывать?
Узнать нагрузку на сервере можно прописав команду w через SSH консоль.
Что нужно знать о LA?
Значение LA рассчитывается исходя из процессов, которые выполняются и находятся в очереди на выполнение (CPU, RAM, I/O). В большей степени на LA влияет загруженность процессора, которая в свою очередь является одним из основных факторов повышенной нагрузки на сервере.
1(единица) LA = 100% нагрузка на 1 ядро CPU. Соответственно, когда на VPS два ядра, то допустимая средняя нагрузка может достигать 2 LA:
Если нагрузка растёт и превышает количество ядер и держится продолжительное время, то несмотря на это, Ваш сервер продолжает работать. В данном случае, LA увеличивает очередь запросов на выполнение и в случае с виртуализацией KVM / OpenVZ данная нагрузка начинает негативно влиять на физический сервер, на котором находится Ваш VPS.
Как правило, мы не реагируем на всплески нагрузки (например, когда выполняется бэкап или выгрузка товаров в 1с), но если мы видим, что LA на физическом сервере гораздо выше нормы, то будем вынуждены предпринять меры, т.к. это будет иметь негативный эффект для всех клиентов на данном физическом сервере.
- load average, la, cpu, нагрузка, vds, vps, cputime 2 Пользователи нашли это полезным
Похожие статьи
Если у вашего сайта не отображаются латинские буквы, как в данном примере:То вам необходимо.
Для VPS/VDS Сервера мы предлагаем панель управления ISPmanager Lite совершенно бесплатно*.
Данная услуга предназначена для клиентов, которые заказали «выделенный сервер» или «VPS/VDS.
Мануал написан для тех, у кого установлена панель управления ISPmanager Lite и операцинная.
У Вас выскакивает ошибка «Конвертация в UTF-8 не поддерживается на стороне сервера» при.
Linux: CPU Load — когда пора волноваться или что значит Load Average
load average: 0.09, 0.05, 0.01
Большинство людей знают, что обозначают эти цифры: они отображают среднюю нагрузку за определённое время (1, 5 и 15 минут), и знают, что чем меньшее значение — тем лучше. Большие же значения означают какие-то проблемы с нагрузкой на процессор. Но — какой порог? как выглядит «хорошее» и «плохое» значение Load Average? Когда начинать беспокоиться — а когда пора уже паниковать и срочно фиксить проблему?
Для начала — давайте рассмотрим, что именно обозначает Load Average. Начнём с простого примера — машина с одноядерным процессором.
Пример с движением по дороге
Одноядерный процессор можно представить себе как дорогу с однополосным движением. Представьте себе, что вы — оператор моста, по которому проходит эта дорога. Иногда движение по ней такое интенсивное, что машины выстраиваются в очередь для переезда. Вы хотите, что бы водители знали — какова скорость прохождения машин по вашему мосту. Самое простое решение — определить, сколько машин уже ожидают очереди на переезд моста: если машин в очереди нет — то водители будут знать, что могут проехать без проблем, а если машины скапливаются в очереди на подъезде к мосту — водители будут видеть, что им придётся простоять в этой очереди.
И так, оператор — какую систему измерения вы выберете? Как на счёт такой:
= load of 0.50
= load of 1.00
= load of 1.70
Это пример того, чем является загрузка процессора. «Машины» тут — процессы, занимающие процессорное время («переезжают мост«), или стоящие в очереди на подъезде к нему. UNIX считает загрузку, как «длина в очереди на выполнение«: сумма процессов, которые в настоящие момент выполняются + количество процессов в очереди на обработку:
Как оператор моста, вы бы хотели, что бы машины (процессы) никогда не стояли в очереди. Так же и ваш процессор, в идеале, должен оставаться ниже 1.00. Так же, вы можете быть спокойны, если иногда возникают пики немного выше 1.00 — но вы должны начинать волноваться, если это происходит постоянно.
Так что — Load Average 1.00 является идеальным показателем?
Не совсем. Проблема нагрузки 1.00 в том, что у вас не остаётся «просвета» (запаса). На практике, многие системные администраторы придерживаются оптимального значения в 0.70:
А как на счёт многоядерных процессоров? У меня Load Average 3.00 — но всё работает отлично!
У вас четырёхъядерный процессор? Тогда — Load Average в 3.00 совершенно нормальное значение.
На многоядерных процессорах значение LA взаимосвязано с количеством процессоров. Использование на 100% отображается как 1.00 на одноядерной системе, 2.00 на двухъядерной, 4.00 на четырёх и так далее.
Если мы вернёмся к аналогии с мостом, то 1.00 значит, что одна полоса движения на мосту полностью занята. На мосту с одной полосой — это и будет 100% его «пропускной способности». На двухполосном мосту — это уже 50%, т.к. только одна полоса занята полностью — но есть ещё одна, полностью свободная.
То же самое и с процессором — нагрузка в 1.00 будет 100% на одноядерной системе, а на двухъядерной — значение 2.00 будет 100% нагрузки.
Многоядерность vs многопроцессорность
Раз уж мы затронули эту тему — давайте поговорим о разнице между многоядерными и многопроцессорными системами. С точки зрения производительности — равна ли машина с одним двухъядерным процессоров — машине с двумя процессорами по одному ядру? Грубо говоря — да. Есть много тонкостей, связанных с кешированием, передачей процессов между процессорами и так далее. Несмотря на это, в целях вычисления итоговой нагрузки на процессор(ы) — важно общее количество ядер, независимо от того, на сколько физических процессоров они распределены.
Это приводит нас к ещё двум правилам:
Подведём итог
Давайте посмотрим на Load Average в выводе утилиты uptime :
Это двухъядерный процессор, значит у нас имеется большой запас производительности, и можно даже не задумываться о нагрузке, пока значение не достигнет хотя бы 1.7.
Далее, как на счёт остальных значений? 0.65 значит нагрузку за последнюю минуту, 0.42 — за последние 5 минут и 0.36 — за прошедшие 15 минут. Это приводит нас к вопросу:
За каким именно значением наблюдать? 1, 5 или 15 минут?
Помня правила, которые мы обсудили (1.00 == «Пора исправлять это«) — вам необходимо обращать внимание на значения 5 и 15 минут. Т.е., если на вашей машине бывают пики нагрузки за 1 минуту — это нормально. Если же значение 15-ти минут поднимается выше 1.00 и остаётся таким — пора заняться этим вопросом (конечно, учитывая момент, касающийся количества ядер в системе).
Значит, количество ядер в системе важный вопрос для выяснения реальной нагрузки. Как мне узнать — сколько ядер в моей системе?
так вы получите полную информацию о процессоре(ах).
А что бы получить просто число, без другой информации — выполните:
Оригинал статьи взят отсюда>>>. Замечания/предложения к переводу категорически приветствуются.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
С необходимостью правильно оценить нагрузку на систему сталкивается каждый системный администратор. Если говорить о Linux-системах, то одним из основных терминов, с которым придется столкнуться начинающему администратору окажется Load Average (средняя загрузка). Однако, если говорить о русскоязычном сегменте сети интернет, описание данного параметра сводится к общим малозначащим фразам, в то время как за этими простыми цифрами кроется глубокий пласт информации о работе системы.
Если обратиться к популярным источникам (Википедия), то можно найти примерно следующее:
Посмотреть текущую загрузку системы можно командной
Также ее значения выводят утилиты top и htop, а также множество других инструментов. В ответ мы получим что-то вроде:
Много это или мало? Хорошо или плохо? Давайте разбираться.
Чтобы понять, что такое загрузка системы следует обратиться к логике работы центрального процессора. Вне зависимости от того, мощный у вас процессор или слабый, многоядерный или нет, он выполняет некий программный код для некоторых процессов. Если процесс один, то вопросов нет, а вот когда их несколько? Надо как-то распределять ресурсы между ними и, желательно, равномерно, чтобы один процесс, «дорвавшись» до CPU, не оставил без вычислений другие.
Здесь можно провести аналогию, когда несколько игроков хотят поиграть на одной приставке. Что обычно делают в таких случаях? Договариваются о времени, скажем каждый играет по 15 минут, затем дает поиграть другому.
Процессор поступает аналогичным образом. Каждому нуждающемуся в вычислениях процессу выделяется некий промежуток времени, который зависит от типа процессора и системы, если говорить о современных процессорах Intel, то это значение обычно составляет 10 мс и называется тиком. Каждый тик процессорное время отдается какому-то одному процессу в порядке очереди, но если процесс имеет повышенный или пониженный приоритет, то он, соответственно получит большее или меньшее количество тиков.
Количество использованных тиков, в первом приближении, и представляет загрузку системы. В Linux для оценки загрузки используется интервал в 500 тиков (5 секунд), при этом учитываются как работающие процессы (использованные тики), так и ожидающие (которым не хватило тика, либо они не смогли его использовать, ожидая завершения иной операции).
Если мы используем все тики за указанный промежуток времени и у нас не будет ожидающих сводного тика процессов, то мы получим загрузку процессора на 100% или load average (LA) равное 1.
Давайте рассмотрим следующую схему:
Справа показана ситуация, когда каждый тик был занят своим процессом, но некоторые процессы так и не получили своего тика или не смогли получить, например, ждали окончания операции ввода-вывода. В таком случае загрузка процессора составит все те же 100%, но load average вырастет до 1,33, указывая на наличие очереди.
А теперь зайдем в магазин вечером, все кассы заняты, и чтобы оплатить покупки придется ждать. Теперь если за 10 минут касса обслужила 10 человек и еще 10 стоят в очереди, то средняя загрузка будет равна 2, хотя касса загружена всего на 100%.
Вернемся к процессору и еще одному моменту, процессам, ожидающим окончания операций ввода-вывода (диск, сеть и т.п.). Во многих источниках указывается, что такие процессы искажают результат load average и мы можем получить высокие значения LA при отсутствии загрузки процессора. Да, это так. Посмотрим на еще одну схему ниже:
Как видим, из 9 тиков было использовано только 6, т.е. процессор загружен всего на 67%, но так как три процесса ждут данные от диска, то load average по-прежнему равен 1.
Если продолжать аналогию с супермаркетом, то похожая ситуация возникает, когда вы уже подошли к кассе и уже собрались выгружать продукты на ленту, но ваша супруга говорит вам, что она забыла купить хлеб, и вы тут стойте, а она сбегает. Собственно, все что вам остается до того, как она принесет хлеб, это стоять рядом с кассой и ждать, пропуская тех, кто находится в очереди позади вас.
Т.е. если у нас имеется 1 процессор и 500 тиков, но за это время процессорные ресурсы требуются тысяче процессов, то нагрузка у нас явно вдвое превышает имеющиеся ресурсы. И то, что часть процессов ждут жесткий диск и процессор работает вхолостую, не говорит о том, что система находится в простое, наоборот, она не может обработать нагрузку, правда по другой, не зависящей от процессора причине.
Пользователю ведь все равно по какой причине тормозит сайт или приложение, тем более что недостаток дисковых ресурсов обычно выражается подвисании приложения, в то время как при недостатке процессорных оно просто начинает тормозить.
Подведем промежуточный итог. Load average показывает отношение имеющихся запросов на вычислительные ресурсы к количеству этих самых ресурсов (тиков). Для одного процессора (одного процессорного ядра) использование всех имеющихся ресурсов обозначает load average = 1. Причем это будет справедливо и для Core i7 и для Pentium I, хотя производительность у этих двух процессоров разная.
Теперь перейдем к многопроцессорности и многоядерности. При появлении второго процессора или второго ядра у нас появляются дополнительные вычислительные ресурсы, т.е. же самые 500 тиков. Но за эти 500 тиков система уже может обработать уже 1000 запросов, что покажет нам load average = 2.
Значит ли это, что производительность выросла в два раза? Нет! Производительность зависит от того, сколько вычислений способен произвести процессор в течении одного тика. Понятно, что более мощный процессор выполнит за этот промежуток времени больше вычислений, но оба из них сделают одинаковое число тиков (для каждого процессорного ядра). В многопроцессорных (многоядерных) системах часть процессорного времени вместо вычислений занимают задачи межпроцессорного взаимодействия, переключения контекста и т.д. Поэтому появление второго ядра никогда не даст 100% прироста производительности, но всегда позволяет обработать вдвое большее количество запросов.
Это хорошо видно на примере технологии Hyper-threading, которая позволяет сделать из одного физического ядра процессора два виртуальных. Физическая производительность ядра процессора, т.е. количество производимых им вычислений в единицу времени не меняется, но появляется, хоть и виртуальное, но второе ядро, а это еще 500 тиков. Как показывают тесты, прирост производительности от Hyper-threading составляет 15-30%, что еще раз подтверждает старую поговорку, что лучше плохо ехать, чем хорошо стоять. Второе ядро, хоть и виртуальное, позволяет обрабатывать вычислительные запросы тех процессов, которые в одноядерном варианте стояли бы в очереди.
Непонимание этого момента приводит к тому, что load average ошибочно связывают не с доступностью и достаточностью вычислительных ресурсов, а с производительностью процессора, что приводит к неверным выводам.
Например, переводчик довольно неплохой статьи на Хабре делает ошибочный вывод в отношении Hyper-threading:
Хабраюзер esvaf в комментариях интересуется, как интерпретировать значения load average в случае использования процессора с технологией HyperThreading. Однозначного ответа на данный момент я не нашел. В данной статье утверждается, что процессор, который имеет два виртуальных ядра при одном физическом, будет на 10-30% более производительным, чем простой одноядерный. Если принимать такое допущение за истину, считаю, при интерпретации load average стоит брать в расчет только количество физических ядер.
А Википедия вообще написала полную ерунду (что для технических статей там совсем не редкость):
Убедиться, что это не так довольно легко. Если запустить бесконечный цикл командой
то мы обеспечим полную загрузку одного процессорного ядра и load average = 1 (в данный момент смотрим только на первые, минутные показания данного параметра).
Мы не знаем, сколько именно операций в единицу времени выполняет наш процессор, но нам и не нужно знать это, гораздо важнее понимать, что на текущий момент все вычислительные ресурсы системы задействованы, но недостатка в них нет.
Запустим пятый процесс:
Что изменилось? Загрузка процессора осталась на уровне 100%, это и понятно, выше головы не прыгнешь, но load average вырос до 5, что означает нехватку вычислительных ресурсов примерно на 20%. Таким образом понимание сути значения средней загрузки позволяет администратору однозначно сделать выводы о текущей ситуации, чего не скажешь, глядя просто на индикатор загрузки CPU.
Теперь касательно HyperThreading, виртуализации и т.п. случаев, когда процессор, с которым работает система далеко не соответствует физическому процессору, искусственно создадим данную ситуацию. Для этого запустим на хосте параллельно с виртуальной машиной какой-нибудь ресурсоемкий процесс, например, кодирование видео. Виртуальная машина будет рассчитывать на 4 полных процессорных ядра, а по факту получит в лучшем случае половину их производительности. Проверим?
Теперь уберем стороннюю нагрузку. Гипервизор тут же передаст максимум ресурсов виртуальной машине.
Как видим, вычислительных ресурсов снова стало достаточно и load average опустился до значения 4.
Какие выводы мы можем сделать из этого примера? Что значение load average корректно отражает загрузку системы даже в тех условиях, когда иные показатели не дают корректного представления о происходящих процессах. Так нагрузка на CPU в 157% явно противоречит здравому смыслу, а вот LA = 4,55 вполне реально отражает ситуацию. Поэтому никаких корректив на виртуальные ядра, виртуализацию и т.п. вносить не надо. Load average является относительной величиной и от реальной производительности CPU не зависит в тоже время показывая наличие или дефицит вычислительных ресурсов.
Например, скользящие средние широко применяются в финансовом анализе, для выделения общих тенденций движения курсов валют и акций, позволяя отбросить так называемый «биржевой шум» и понять общие тренды рынка.
То, что подходит финансисту, наверняка подойдет и системному администратору. В чем основное преимущество скользящих средних? В том, что они позволяют выделить основные тенденции, отбросив кратковременные колебания. Это достоинство, а не недостаток, как пытается убедить нас Википедия:
Именно усредненные по особому алгоритму значения позволяют нам окинуть ситуацию взглядом вширь и вглубь и разглядеть за деревьями лес. В этом отношении временные значения load average представляют собой не время, за которое посчитали среднее значение, а период времени относительно которого проводится усреднение.
Благодаря автору Хабра ZloyHobbit, который не поленился изучить исходный код Linux, можно точно смоделировать различные значения load average при заданной модели нагрузки. Мы смоделировали ситуацию, когда первые 30 минут единственное ядро CPU было нагружено на 100%, без ждущих в очереди процессов, в последующие полчаса нагрузка была полностью снята.
Как видим, разные периоды усреднения дают совершенно различные результаты, так LA 1 (1 min), начинает показывать реальные значения где-то через 4 минуты, LA 5 для отражения текущей нагрузки потребовалось уже 20 минут, а LA 15 за полчаса полной загрузки вышла только на 0,8.
О чем это говорит и как интерпретировать данные значения? Можно сказать, что LA 1 представляет собой недавнее прошлое (несколько минут назад), LA 5 прошлое (полчаса-час) и LA 15 отдаленное прошлое (несколько часов).
Теперь, располагая этим багажом знаний, мы можем правильно интерпретировать простые, на первый взгляд, три числа load average.
Для примера возьмем такое значение:
Это говорит о том, что имеет место достаточно кратковременный (около десятка минут) всплеск нагрузки, при этом вычислительных ресурсов пока достаточно.
Говорит о том, что не так давно система испытывала значительные нагрузки в течении довольно продолжительного времени (полчаса-час).
А вот такая картина:
Для четырехядерного процессора означает, что он работает на пределе своих возможностей в течении длительного времени (несколько часов).
Как видим, load average, несмотря всего на три цифры, способна представить системному администратору огромный пласт информации о фактической загрузке системы на протяжении последних нескольких часов.
Теперь самое время дать ответы на вопросы, поставленные нами в начале статьи: «Много это или мало? Хорошо или плохо? » Для одного ядра мы считаем приемлемыми следующие значения:
На многоядерной (многопроцессорной) системе значения load average следует откорректировать пропорционально числу ядер. Узнать их количество можно командой
Так, например, с учетом вышесказанного, для четырехядерной системы LA 15 не должен превышать 3.00, для двухядерной 1.5, а для одноядерной 0.75.
Теперь, понимая, что такое load average и каким образом формируются его значения вы всегда сможете быстро оценить производительность собственной системы и вовремя принять меры если в работе вашего сервера возникнут узкие места.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 