Comments 30
Например, mysql, займет всего один поток, поэтому при полной нагрузке будет использовать (1/кол-во виртуальных CPU, присвоенных VM). postgresql является многопоточным, и может использовать больше процессоров, если они будут выделены, – помните об этом, создавая виртуальные машины в гипервизореШайтанама какая.
Мда… Писать по MySQL, что он однопоточный — это вы (обращение к автору статьи, а не к автору коммента) в каком году с ним последний раз имели дело?
А что тут удивительного? Всё зависит от приложения, которое с базой работает.
Для примера, есть у нас сервачок с базой Oracle (Нормальный такой, на 4 socket-а (всего 64 треда), с подключением к SAN по FC).
А приложение самописное — контора одна пишет. Оптимизации под многопоточность никакой.
Как запускается отчёт — часа так на 2-3, один тред (логический cpu) загружен на 100%, остальные почти простаивают.
А потом жалуются, что сервер у нас слабенький, не тянет их софт.
Гнать бы таких программеров из этой конторы куда подальше, дык ведь других нет, монополисты они в нашем городе. Да и заточены под нашу специфику — металлургическое производство…
Для примера, есть у нас сервачок с базой Oracle (Нормальный такой, на 4 socket-а (всего 64 треда), с подключением к SAN по FC).
А приложение самописное — контора одна пишет. Оптимизации под многопоточность никакой.
Как запускается отчёт — часа так на 2-3, один тред (логический cpu) загружен на 100%, остальные почти простаивают.
А потом жалуются, что сервер у нас слабенький, не тянет их софт.
Гнать бы таких программеров из этой конторы куда подальше, дык ведь других нет, монополисты они в нашем городе. Да и заточены под нашу специфику — металлургическое производство…
«время бесперебойной работы»
Я бы лучше выразился, что это время с момента запуска ОС (операционной системы). Работа с момента запуска до текущей даты вполне может быть и «сбойной». Просто эти сбои не приводили с рестарту ОС.
Странно, что не упомянут atop.
Практические рекомендации: устраняйте неполадки, используя команду 'Top'Под катом увидел только куцый man top. С таким же успехом можно написать/перевести целый цикл статей «Практические рекомендации: устраняйте неполадки, используя команду 'man||ps||rm||killall||emerge||apt-get||ping...'» Новичкам, может и будет полезено, но заголовок ИМХО не отражает сути.
работаем над новой фичей нашего сервиса мониторинга, для того чтобы можно было мониторить не только внешние параметры сервера, но и внутренние
Чем утилиты вроде nrpe не устроили?
Тут же был уже сто и один обзор всевозможных top'ов
чем этот лучше? перевод мана на русский?..
чем этот лучше? перевод мана на русский?..
По моему этот в разы хуже, чем тот
А вот мне интересно, какие значения system cpu load (который sy) стоит считать высокими? У меня вот на ноутбуке он держится в районе 10-15%, это много?
Смотря что нагружает. Лучше всего посмотреть по тому же топу или ps aux какие из ядерных процессов дают нагрузку.
Я бы смотрел не на cpu load, а на load average. Оно дает более вменяемую картину чем абстрактные проценты. Все хорошо если load average < 1.0 X количество CPU. Но в принципе можно жить с load average где то до 3-4 на ядро. Но это уже легкий хардкор.
Посмотрите еще вот этот доклад Михаила Епихина из Яндекс.
Сколько лжи и неполной информации!
Больше всего меня поразило лженаучное объяснение про wa. Столько ереси про диск, память (смешались в кучу кони, люди) и ни слова про реальную природу wa.
Больше всего меня поразило лженаучное объяснение про wa. Столько ереси про диск, память (смешались в кучу кони, люди) и ни слова про реальную природу wa.
Пример, где нет никаких операций с диском и при это wa:99.8, и load average over 9000
Пишем скрипт, который просто ждёт 100 секунд данных, которые никогда не придут:
Запускаем его 1000 раз:
Рекомендую сразу 1000 не запускать: всё ляжет. Начните с 20-30.
#!/usr/bin/python
import socket, random
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.settimeout(100)
sock.bind(('127.0.0.1', random.randrange(5000,50000)))
data, addr = sock.recvfrom(1024)
Запускаем его 1000 раз:
~$ for i in {1..1000}; do ./script.py & doneРекомендую сразу 1000 не запускать: всё ляжет. Начните с 20-30.
Странно как-то это. Вернее, что будет высткий iowait и la, не странно, а вот то, что ляжет — странно. По идее, для системы recv, безрезультатно ждущий 100 секунд, не должен отличаться от sleep(100). Разве что в пайтоновском recv баг с busywait. Может быть, 1000 пайтон-скриптов в sleep(100) точно так же все положат?
В вашем коде процесс будет висеть в S-state, и на iowait никак не будет влиять. На iowait влияют только процессы, которые висят в D-state.
Согласен, мой пример не самый удачный (призываю обратить внимание на этот комментарий — он толковый :-)).
Но суть моего примера, думаю, всем понятна. На моей практике бывало множество случаев, когда wa зашкаливал из-за небрежной работы с сетью, а вот wa из-за дисковой подсистемы, мне кажется, — штука экзотическая.
Но суть моего примера, думаю, всем понятна. На моей практике бывало множество случаев, когда wa зашкаливал из-за небрежной работы с сетью, а вот wa из-за дисковой подсистемы, мне кажется, — штука экзотическая.
Это Ваш пример лженаучен. Если запускать одновременно 1000 python-процессов, то, очевидно, подскочит LA и wait, т.к. необходимо обратиться к диску для инициализации библиотек, и процессы будут в R-state кратковременно. И не факт, что все обращения к диску отдадутся из page-кеша.
Но в основной своей части Ваш скрипт, как уже ответили выше, находится в S-state и не оказывает влияния ни на iowait ни на LA.
Но в основной своей части Ваш скрипт, как уже ответили выше, находится в S-state и не оказывает влияния ни на iowait ни на LA.
Хоть и понимаю, что over 9000 — это устоявшаяся фраза, но все равно скажу, что на практике load average больше 1000 не поднимается (или может даже меньше, не помню точно). Потом происходит сброс. Кажется, даже проблемные процессы убиваются.
Если кто-то помнит как там все на самом деле — напишите, пожалуйста.
Если кто-то помнит как там все на самом деле — напишите, пожалуйста.
Процитирую свой же комментарий в статье "CPU Load: когда начинать волноваться?"
В старом посте про load average давали ссылку на замечательную статью, где я и прочитал про это самое «кспоненциально взвешенное скользящее среднее»,
Очень рекомендую к прочтению, можно даже добавить в пост.
Часть 1 www.teamquest.com/pdfs/whitepaper/ldavg1.pdf
Часть 2 www.teamquest.com/pdfs/whitepaper/ldavg2.pdf
Вот из личной практики пример, опровергающий ваше утверждение:
>>iowait% является показателем производительности диска.
Не только диска, а всей подсистемы ввода/вывода. Т.е. включаем сюда же сетевые интерфейсы, usb и прочее.
К слову, работа дисковой подсистемы зависит еще от планировщика. Внутри гостевых систем (linux) прекомендуется выбирать шедулер noop, т.к. прочие оптимизации внутри гостя просто лишние.
Не только диска, а всей подсистемы ввода/вывода. Т.е. включаем сюда же сетевые интерфейсы, usb и прочее.
К слову, работа дисковой подсистемы зависит еще от планировщика. Внутри гостевых систем (linux) прекомендуется выбирать шедулер noop, т.к. прочие оптимизации внутри гостя просто лишние.
Sign up to leave a comment.
Практические рекомендации: устраняйте неполадки, используя команду 'Top' в Linux