LINUX.ORG.RU

KSysGuard

 


0

2

Наболело. Монитор ресурсов всегда был неотъемлемой частью десктопа. Поскольку пользуюсь KDE разных версий, то время от времени запускаю KSysGuard наблюдать кто чего отожрал. И всё больше поражаюсь неадекватности его авторов, поскольку с годами ничего не меняется. А именно дефолтный системный монитор KDE как правило отжирает больше ресурсов, чем процессы, которые он должен мониторить. Я один чего-то непонимаю в современных тенденциях, но мне всегда казалось, что программа мониторинга должна выживать в условиях полного саботажа системы, когда ушла вся память, процессор загружен на 100%, а радиатор видеокарты раскалился докрасна. Потреблять минимум ресурсов, не аллоцировать память в бесконечных циклах, не использовать двойной буферизации при отрисовке, отказаться от шашечек вроде красивых графиков со сглаживанием и градиентами. Но видимо авторы KSysGuard имеют другое представление.

К чему это я. Кто какой использует графический системный монитор на десктопе, желательно не привязанный к ДЕ, мгновенно запускающийся и потребляющий минимум ресурсов?

★★★★★

Я один чего-то непонимаю в современных тенденциях, но мне всегда казалось, что программа мониторинга должна выживать в условиях полного саботажа системы, когда ушла вся память, процессор загружен на 100%, а радиатор видеокарты раскалился докрасна.

Наивный. Система мониторинга должна круто выглядеть: графики, стрелочки, диаграммы, лампочки, шкалы, и т.д. И чем круче это всё свистит и пердит, тем лучше! Вот примерчик, совсем минималистичный: http://portallive.ucoz.com/posts/gaua0.jpg

gkrellm же

Ага, очень минималистично по сжиранию ресурсов http://orig02.deviantart.net/2e83/f/2015/206/5/d/gkrellm_64_bit_plugins_and_a... Но может быть. Можно ли до неё добраться в критической ситуации? А если мониторинг вывести на отдельный монитор — то там пофиг на ресурс, оно всё равно на порядки (ну в разы) меньше сожратого кем-то.

htop в консольке

В ядерной, или вообще только удаленно попробовать прицепиться — ведь всё раком стоит.

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

Сходу так и не понял, там есть таблица процессов или просто графики загрузки? Если только второе, то ненужно. Ну и упор на темы с картинками и градиентиками как бы намекают, что куда-то не туда авторы свернули. В ситуации когда система неотзывчива любая даже казалось бы незначительная нагрузка на процессор может оказаться фатальной. Я уже не говорю, что эти картинки нужно подгрузить с файловой системы при холодном старте, что закономерно выльется в зависание самой программы мониторинга.

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

На счёт скорости работы, да, похоже товарищ минималистичен что надо. А остальное? Смотрю на официальном сайте, списка процессов не нахожу. Поставил, тоже сходу ничего подобного. Куда копать?

Dendy ★★★★★ ()

дефолтный системный монитор KDE как правило отжирает больше ресурсов, чем процессы, которые он должен мониторить

15 Мб это много? Пользуйтесь htop.

alexferman ()
Ответ на: комментарий от Avial

Похоже рано я обрадовался, qps так же ничего не делая показывает в фоне стабильно до 1% загрузки CPU. Кроме того видимо ещё и течёт, плавно дорос уже с 7 до 64 Мб.

Dendy ★★★★★ ()

ничего не делая показывает в фоне стабильно до 1% загрузки CPU.

Системный монитор не может ничего не делать. Он мониторит.

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

Запусти htop и ksysguard паралельно, сравни их показания относительно друг друга и удивись.

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

Отправь баг-репорт автору, пожалуйста.

Я его потыкал всего ничего, может это и не баг, а фича, он там кеширует что-то на самом деле. Да и ссылка в самом qps ведёт на 404.

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

Он мониторит.

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

Открыл исходники KSysGuard, вижу что он каждую секунду переоткрывает /proc/$pid/status и парсит текст, причём не самым оптимальным образом. Неужели в Линуксе всё так плохо с мониторингов процессов? Разве не должно быть системных вызовов или хотя-бы бинарного протокола для обновления статистики? Чтобы получить одну цифру нужно распарсить килобайт текста ненужной информации, помножить это на количество процессов и так каждую секунду.

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

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

Раз в секунду потратить 1% процессорного времени - это мизер, вообще ни на что не влияющий. Открой уже ksysguard и htop паралельно, и убедись, что он практически ничего не жрёт.

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

Раз в секунду потратить 1%

Нет такого понятия как раз в секунду потратить 1%. Есть перманентная загрузка процессора, для сравнения: htop: ~0.5%, qps: ~0.8%, ksysguardd: ~1.5%. Последние два можно списать на графику, но htop видимо тратит ресурсы именно на низкоуровневую долбёжку /proc. Пол процента это дофигища, особенно в условиях когда процессор кто-то занял и достучаться до файловой системы, пусть даже виртуальной, не получится.

Получая циферки через syscall'ы ты практически ничего не сэкономишь.

Это за гранью моего понимания. С каких это пор open(), read() и close() перестали быть сисколами? А именно так и читаются файлы из /proc. Каждую секунду тысяча системных вызовов с вычитыванием мегабайта текста. Я уже не говорю про затраты на поиск файла в виртуальной файловой системе и время на превращение текста в цифры, 99% которых тебе в данный момент не показываются, но распарсить ты их обязан. Сравнить это с одним (одним, Карл!) потенциальным сисколом на чтение циферок из пайпа каждую секунду, с информацией на которую ты подписался.

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

Ок. Я кругом не прав. Неправильно интерпретировал показания жора cpu.

Но нагрузка всё-таки не перманентная. У меня инфа для kde4, т.к. пятых нет под рукой. Запускаешь htop -d 1. В таком режиме он опрашивает систему каждую 0.1 секунды.

Для ksysguard, вызванного по ctrl+esc в основном 0.0, иногда показывает 8-20%. Реже, чем ksysguard обновляет статистику. Видимо htop не всегда успевает засечь.

Для ksysguard, вызванного командой (он со статистикой и доп вкладками) - ситуация та же, но показывает чаще и 8-60%.

Для обычного htop - тоже в основном 0.0, иногда 8-17%.

С каких это пор open(), read() и close() перестали быть сисколами?

Тут тоже не прав. Я про них забыл.

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

ЗЫЖ Моя не системщик, моя лор аналитик.

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

Но помимо циферок top'ам нужна ещё команда запуска, пользователь, память и остальная куча информации

Большинство этой информации инициализируется один раз, того что меняется в рантайме капля по сравнению с остальным. К примеру, в Windows этот функционал есть в WinAPI, в Дарвине тоже что-то похожее. А в Линуксе... ковырять текстовые файлы и тормозить?

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

Проверил в федорке с пятыми кедами:

Для ksysguardd, запущенного по ctlr+esc, увидеть цифры, отличные от 0.0 не удалось ни в htop, ни в htop -d 1.

Для ksysguard с графиками в htop -d 1 раз в пару секунд проц взлетал до 40-70. В остальное время по нулям. Просто htop показывал 1.3-7 %. Иногда до 15%.

Процессор fx8350.

Так что, судя по всему, опрос /proc не жрёт практически ничего. Проц жрут графики.

Если хочешь, чтобы проц не жрался - ctrl+esc к твоим услугам. Как его запускать командой я не знаю.

А в Линуксе... ковырять текстовые файлы и тормозить?

Я не знаю, есть ли в линуксе подобные сисколы.

Судя по всему, разработчики ядра не видят проблем в скорости ковыряния текстовых файлов, и считают /proc более удобным и расширяемым.

Я, в свою очередь, тоже не вижу каких-то проблем в потреблении htop или ksysguard.

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

Я, в свою очередь, тоже не вижу каких-то проблем в потреблении htop или ksysguard.

Выборка маловата, отдельно взятому человеку всегда будет достаточно (-: Разработчики же делают для максимальной аудитории и должны рассчитывать на худший результат. Вот у меня, к примеру, Core 2 Duo 1.8 GHz, но разработчики всегда могут налепить тормозных поделий и рассказывать байки про обновление железа, когда для этого нет причин. Вон Гугл вообще со своим Андроидом с ума сходит, для сборки N уже рекомендуется 32 Гб ОЗУ, иначе билд система может отказать.

Запустил вот $ htop --delay=2, обновлять в 5 раз чаще, чтобы посмотреть более честные цифры загрузки процессора самими htop'ом. Итого имеем 4-6% (то-есть в среднем 8-12% на одно ядро) просто чтобы печатать минимум информации в консоль. Я даже размер консольки уменьшил, чтоб там только шапка таблицы осталась — всё равно долбит проц как и раньше.

Интересно, в новых ядрах Линукса что-то появилось по этому поводу?

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

имеем 4-6%
то-есть в среднем 8-12% на одно ядро

Загрузка 100% - одно ядро выжрано на 100%. xz -T 8 testfile у меня жрёт 745%.

ksysguard, запущенный по ctrl+esc по показаниям htop'а у тебя сколько жрёт?

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

Разве не должно быть системных вызовов или хотя-бы бинарного протокола для обновления статистики?

Как Леннарта хаять, так все горазды. Как что-то серьёзное, а не парсинг текста нужен, так Лёнь приди, напиши.

А в Линуксе... ковырять текстовые файлы и тормозить?

Ты ничего не понимаешь в духе UNIX-Way.

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

Ты ничего не понимаешь в духе UNIX-Way.

Полагаю, дух был бы сейчас сильнее, если бы Ричи в 70-х использовал паскалеподобные строки (с указанием размера в первых байтах), а не null-term. Фундаментально, было бы меньше пробежек на сравнение с \0

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

Полагаю, дух был бы сейчас сильнее, если бы Ричи в 70-х использовал паскалеподобные строки (с указанием размера в первых байтах), а не null-term. Фундаментально, было бы меньше пробежек на сравнение с \0

Нашли козла отпущения, что кто-то в 70-х не предугадал развитие технологий на 50 лет вперёд (-: Уже сколько языков с тех времени придумали на любой вкус и цвет. В том же C++11 добавили строковые литералы, а в 14-м узаконили стандартные суффиксы, "foobar"s вернёт вам std::string, ностальгирующие могут писать "foobar"ps, которая посчитает вам паскалевскую строку на этапе компиляции, ещё и ругнётся на кодировку или если за пределы вылезли. Даже string_view завезли (в C++17) для совместимости между разными строковыми типами.

Так что проблема исключительно в ретроградах, которые тянут протухшие подходы из года в год. Вот открываю я /proc/$pid/stat, а там 50 чисел/строк через пробел. Понять глазами что есть что невозможно, если ты не Торвальдз. Почему это не превратить в структуру с числами, раз уж последовательность и типы не меняются, мне не понять. Просто бесполезный расход по памяти, процессорному времени, не говоря уже об ошибках текстового разбора.

Dendy ★★★★★ ()