vasek |
|
Темы:
48
Сообщения:
11340
Участник с: 17 февраля 2013
|
-_oЭто совсем не то. Возникают ситуации, когда необходимо проанализировать причину большой нагрузки cpu, а практически все утилиты показывают вообщем то нагрузку правильно (например, 100%), но толку от этого мало - не понятно чем в основном занят cpu - истинной работой, ожиданием завершения дисковых операций ввода/вывода или же ожиданием завершения операций ввода/вывода, но связанных с памятью. Для понимания даю ссылку на статью по теме производительности cpu. Нет ни одной утилиты, которая покажет все эти части нагрузки cpu, правда есть профилировщики (Performance Monitoring), но это очень уж специализированный инструмент и не так то просто с ним работать, а главное, он всеравно покажет только косвенные результаты, которые в придачу еще нужно уметь интерпетировать. В наших репах имеется perf. Вот тут и приходит на помощь простая в использовании утилита tiptop, заточенная на мониторинг производительности и единственная из утилит данного уровня, которая считывает информацию из аппаратных счётчиковго производительности. И как следствие этого, tiptop единственная утилита, показывающая значение IPC, что дает возможность оценить (и только оценить) причину большой нагрузки cpu — или это действительно фактическая нагрузка cpu (т.е. истинная работа) или же cpu простаивает в режиме ожидания завершения операций ввода/вывода, связанных с памятью, а не дисковых операций. EDIT 1 - забыл дать ссылку на первоисточник - хотя они практически совпадают, но в 1-ой ссылке правильно стоит термин "stalled", потому и привел ее.
Ошибки не исчезают с опытом - они просто умнеют
|
-_o |
|
Темы:
3
Сообщения:
251
Участник с: 13 января 2018
|
Более 80-ти средств мониторинга системы Linux |
amon |
|
Темы:
42
Сообщения:
780
Участник с: 01 июня 2017
|
пять страниц базара, который близко не пахнет "вкусными полезностями" |
safocl |
|
Темы:
121
Сообщения:
1570
Участник с: 08 октября 2015
|
amonты чо новенький? енто жеж незатейливый арчесвский юмарок такой тут |
indeviral |
|
Темы:
38
Сообщения:
3196
Участник с: 10 августа 2013
|
amonдля тех кто всегда хотел значок наушников в статусбаре)) (это для pulse(потому что очень просто распарсить), есть и для alsa но там мрак...)
Ошибки в тексте-неповторимый стиль автора©
|
Aivar |
|
Темы:
4
Сообщения:
6897
Участник с: 17 февраля 2011
|
indeviralАсь? Глифы, звиняйте, переставлял/переделывал. Скриншот:Выглядит так: Или я в танке? |
indeviral |
|
Темы:
38
Сообщения:
3196
Участник с: 10 августа 2013
|
ну, а я про что мрак)), только я имел ввиду ну amixer тоже хороший пример)p.s. что то я всё никак не разживусь шрифтом с иконками((
Ошибки в тексте-неповторимый стиль автора©
|
Aivar |
|
Темы:
4
Сообщения:
6897
Участник с: 17 февраля 2011
|
indeviralНормально. Бывает и похуже. ) |
-_o |
|
Темы:
3
Сообщения:
251
Участник с: 13 января 2018
|
amonЭх... Сразу набросились на новенького все и никто так и не оценил. :) А вот в linux-hardened так по умолчанию: Restricting access to kernel logshttps://wiki.archlinux.org/index.php/Security#Kernel_hardening Закончу уж раз начал. Все было хорошо у меня, но обнаружилась одна нестыковка. Если не добавлять пользователя в группу wheel, то polkit требует тогда пароль root, а если логин и пароль root в системе заблокирован, что тоже рекомендуется, то polkit тогда не будет работать. /etc/polkit-1/rules.d/50-default.rules пока не знаю, как починить. Если с root всё как обычно, то тогда restricting access to kernel logs, описанное мною выше, вкусно и полезно, и даже hardened. :) UPD: чтобы и polkit в данном случае работал правильно в /etc/polkit-1/rules.d/50-default.rules нужно заменить group:wheel на user:имяпользователя. Ну, ффсёёё... Теперь я просто hardened happy. :)) |
vasek |
|
Темы:
48
Сообщения:
11340
Участник с: 17 февраля 2013
|
-_o, одно не понятно, зачем это все и для чего?
Ошибки не исчезают с опытом - они просто умнеют
|