Conky и странная нагрузка на одно ядро

Koluchka	# 3 года, 8 месяцев назад
Темы: 2 Сообщения: 151 Участник с: 15 октября 2011	Периодически у меня случается вот такая штука- А странность в том, что эта стопроцентная нагрузка видна только в коньках, а top, htop, qps, ps и прочие мониторы никаких нагрузок на процессор не видят. полная перезагрузка эту фигню лечит, а перезагрузка иксов нет. Напрягает меня это уже не меньше года, то есть обновлялись и ядра, и коньки. Иногда несколько недель не вижу, а иногда каждый день всплывает... Чем и что можно ещё посмотреть, когда оно опять появится?

# 3 года, 8 месяцев назад

Сообщения: 151

Участник с: 15 октября 2011

Периодически у меня случается вот такая штука-

А странность в том, что эта стопроцентная нагрузка видна только в коньках, а top, htop, qps, ps и прочие мониторы никаких нагрузок на процессор не видят. полная перезагрузка эту фигню лечит, а перезагрузка иксов нет. Напрягает меня это уже не меньше года, то есть обновлялись и ядра, и коньки. Иногда несколько недель не вижу, а иногда каждый день всплывает... Чем и что можно ещё посмотреть, когда оно опять появится?

vasek	# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Koluchka А странность в том, что эта стопроцентная нагрузка видна только в коньках, а top, htop, qps, ps и прочие мониторы никаких нагрузок на процессор не видят. Прежде чем мониторить посмотри этот старый топик, не поможет, мониторь - к упомянутой там утилите dstat можно использовать и другие, например, vmstat , sysstat, которые показывают более широкую статистику cpu (чем он конкретно занят) EDIT 1 - а вообще conky в части мониторинга cpu показывает не совсем верно. И лучше его не использовать. Лично для меня важны 2 параметра - температура и память, хотя если не используется больших приложений, то и память не нужна. А на cpu вообще нет смысла смотреть, всеравно это выйдет на температуру. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Koluchka
А странность в том, что эта стопроцентная нагрузка видна только в коньках, а top, htop, qps, ps и прочие мониторы никаких нагрузок на процессор не видят.

Прежде чем мониторить посмотри этот старый топик, не поможет, мониторь - к упомянутой там утилите dstat можно использовать и другие, например, vmstat , sysstat, которые показывают более широкую статистику cpu (чем он конкретно занят)

EDIT 1 - а вообще conky в части мониторинга cpu показывает не совсем верно. И лучше его не использовать. Лично для меня важны 2 параметра - температура и память, хотя если не используется больших приложений, то и память не нужна. А на cpu вообще нет смысла смотреть, всеравно это выйдет на температуру.

Ошибки не исчезают с опытом - они просто умнеют

Koluchka	# 3 года, 8 месяцев назад
Темы: 2 Сообщения: 151 Участник с: 15 октября 2011	Тот топик имеет малое отношение к моей проблеме, поскльку там потребление ресурсов вызывалось самими conky и было видно в htop, а у меня - не видно, именно это и интересно. За dstat спасибо, попробую. Мониторить загрузку cpu по температуре у меня не получится, у меня процессор нагревается в диапазоне от 45 до 50 градусов, ну, может, до 55 летом при повышенных нагрузках.

Koluchka

# 3 года, 8 месяцев назад

Темы: 2

Сообщения: 151

Участник с: 15 октября 2011

Тот топик имеет малое отношение к моей проблеме, поскльку там потребление ресурсов вызывалось самими conky и было видно в htop, а у меня - не видно, именно это и интересно. За dstat спасибо, попробую. Мониторить загрузку cpu по температуре у меня не получится, у меня процессор нагревается в диапазоне от 45 до 50 градусов, ну, может, до 55 летом при повышенных нагрузках.

vasek	# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Понятно. Не помню как считает нагрузку cpu conky, но помнится, что он обсчитывает ее упрощенно. А вообще все серьезные утилиты парсят вывод /proc/stat (для процесса /proc/PID/stat) и показывают значения (время) чем занят cpu. Наиболее используемые - dstat, mpstat, vmstat. В принципе, top тоже дает этот вывод, если использовать top -b \| grep Cpu (расшифровка есть в man), правда ни разу этот вывод не использовал и не сравнивал с другими утилитами. И еще имеется много скриптов для подсчета нагрузки cpu, которые парсят вывод /proc/stat, например, наиболее простой cpu-usage-monitor.sh Но у всех этих утилит и скриптов есть один, скажем так, нюанс - большие кратковременные скачки нагрузки при запуске приложений и др., не нужно этого пугаться, а потому лучше использовать усредненный вывод за определенный промежуток времени (по существу показывается все верно, так устроено - просто некоторые глядя на это говорят о неправильном выводе значений). А вот если conky показывает постоянно нагрузу под 100%, то да согласен, нужно промониторить данный cpu. UPD - А вообще я бы дал нагрузку cpu (например, запустил бы утилиту stress) и одновременно запустил бы какую-либо утилиту и сравнил с выводом conky. EDIT 1 - кстати, vmstat уже стоит, эта утилита, как и top, входит в пакет procps-ng Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Понятно. Не помню как считает нагрузку cpu conky, но помнится, что он обсчитывает ее упрощенно.
А вообще все серьезные утилиты парсят вывод /proc/stat (для процесса /proc/PID/stat) и показывают значения (время) чем занят cpu.
Наиболее используемые - dstat, mpstat, vmstat.
В принципе, top тоже дает этот вывод, если использовать top -b | grep Cpu (расшифровка есть в man), правда ни разу этот вывод не использовал и не сравнивал с другими утилитами.
И еще имеется много скриптов для подсчета нагрузки cpu, которые парсят вывод /proc/stat, например, наиболее простой cpu-usage-monitor.sh
Но у всех этих утилит и скриптов есть один, скажем так, нюанс - большие кратковременные скачки нагрузки при запуске приложений и др., не нужно этого пугаться, а потому лучше использовать усредненный вывод за определенный промежуток времени (по существу показывается все верно, так устроено - просто некоторые глядя на это говорят о неправильном выводе значений). А вот если conky показывает постоянно нагрузу под 100%, то да согласен, нужно промониторить данный cpu.

UPD - А вообще я бы дал нагрузку cpu (например, запустил бы утилиту stress) и одновременно запустил бы какую-либо утилиту и сравнил с выводом conky.

EDIT 1 - кстати, vmstat уже стоит, эта утилита, как и top, входит в пакет procps-ng

Ошибки не исчезают с опытом - они просто умнеют

Koluchka	# 3 года, 8 месяцев назад
Темы: 2 Сообщения: 151 Участник с: 15 октября 2011	Вообще, я подозреваю, что это какой-то баг в коньках, который начинается при каких-то условиях. Ведь если никто, кроме conky не видит этой нагрузки, такая мысль сама собой напрашивается. Можно было бы подозревать какого-то зловреда навроде майнера, который скрывается ото всех, но почему тогда его видят коньки? Ведь не самая хитрая мониторинговая утилита. Stress я запускала, в общем, вывод коньков похож на вывод htop. Да и вообще я иногда сравниваю их выводы и все более-менее похоже.

Koluchka

# 3 года, 8 месяцев назад

Темы: 2

Сообщения: 151

Участник с: 15 октября 2011

Вообще, я подозреваю, что это какой-то баг в коньках, который начинается при каких-то условиях. Ведь если никто, кроме conky не видит этой нагрузки, такая мысль сама собой напрашивается. Можно было бы подозревать какого-то зловреда навроде майнера, который скрывается ото всех, но почему тогда его видят коньки? Ведь не самая хитрая мониторинговая утилита.

Stress я запускала, в общем, вывод коньков похож на вывод htop. Да и вообще я иногда сравниваю их выводы и все более-менее похоже.

vasek	# 3 года, 8 месяцев назад
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Привожу только для интереса. Если использовать для мониторинга sysdig, то можно вообще прийти в ужас 1. Сумма по всем cpu - все как обычно, изредка незначительные всплески - привожу вывод одной top десятки (выбрал с наибольшими значениями) `CPU% Process PID -------------------------------------------------------------------------------- 3.04% htop 18496 2.03% sysdig 18432 2.03% tilix 15987 1.01% Xorg 463 0.00% systemd 422` примерно совпадает с выводом top 2. А вот если посмотреть вывод sysdig только для одного cpu (cpu0), то можно прийти в ужас - привожу 2 top десятки 2.1 нормальный вывод `CPU% Process PID -------------------------------------------------------------------------------- 1.99% tilix 15987 1.00% spectrwm 467 1.00% at-spi2-registr 543 1.00% Xorg 463 0.00% oosplash 14889 0.00% systemd 422` 2.2 самый максимальный вывод `CPU% Process PID -------------------------------------------------------------------------------- 3369.28% tilix 15987 3369.28% Xorg 463 1684.64% sysdig 16852 0.00% systemd 422 0.00% gpm 400` Вот и интерпретируй как хочешь, один плюс - это мгновенный замер и объяснить можно. В твоем случае эта большая нагрузка идет постоянно, но, вероятность большая, что sysdig заметит этот процесс, если он, конечно, имеется. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 8 месяцев назад

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Привожу только для интереса.
Если использовать для мониторинга sysdig, то можно вообще прийти в ужас
1. Сумма по всем cpu - все как обычно, изредка незначительные всплески - привожу вывод одной top десятки (выбрал с наибольшими значениями)

CPU%                Process             PID
--------------------------------------------------------------------------------
3.04%               htop                18496
2.03%               sysdig              18432
2.03%               tilix               15987
1.01%               Xorg                463
0.00%               systemd             422

примерно совпадает с выводом top
2. А вот если посмотреть вывод sysdig только для одного cpu (cpu0), то можно прийти в ужас - привожу 2 top десятки
2.1 нормальный вывод

CPU%                Process             PID
--------------------------------------------------------------------------------
1.99%               tilix               15987
1.00%               spectrwm            467
1.00%               at-spi2-registr     543
1.00%               Xorg                463
0.00%               oosplash            14889
0.00%               systemd             422

2.2 самый максимальный вывод

CPU%                Process             PID
--------------------------------------------------------------------------------
3369.28%            tilix               15987
3369.28%            Xorg                463
1684.64%            sysdig              16852
0.00%               systemd             422
0.00%               gpm                 400

Вот и интерпретируй как хочешь, один плюс - это мгновенный замер и объяснить можно.
В твоем случае эта большая нагрузка идет постоянно, но, вероятность большая, что sysdig заметит этот процесс, если он, конечно, имеется.

Ошибки не исчезают с опытом - они просто умнеют

Koluchka	# 3 года, 8 месяцев назад
Темы: 2 Сообщения: 151 Участник с: 15 октября 2011	Да, с мгновенным замером это вполне объяснимо :) Но sysdig я тоже попробую когда эта штука опять проявится, спасибо.

vasek	# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Насчет фразы - А вообще все серьезные утилиты парсят вывод /proc/stat был не прав, вообщем то все утилиты парсят этот файл, как пример привожу вывода sysdig - для conky `conky (8105) > read fd=5(<f>/proc/stat) size=1024 conky (8105) < read res=1024 data=cpu 36117 145 11151 706674 48449 1785 870 0 0 0.cpu0 8924 34 2759 215636 18839` - для top `top (8192) > read fd=4(<f>/proc/stat) size=1024 top (8192) < read res=1024 data=cpu 37726 145 11731 755914 51976 1865 916 0 0 0.cpu0 9317 34 2898 227712 19958` вот только обрабатывать считанные данные могут по разному (что то учтут, что то не учтут) Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Насчет фразы - А вообще все серьезные утилиты парсят вывод /proc/stat
был не прав, вообщем то все утилиты парсят этот файл, как пример привожу вывода sysdig
- для conky

conky (8105) > read fd=5(<f>/proc/stat) size=1024
conky (8105) < read res=1024 data=cpu  36117 145 11151 706674 48449 1785 870 0 0 0.cpu0 8924 34 2759 215636 18839

- для top

top (8192) > read fd=4(<f>/proc/stat) size=1024
top (8192) < read res=1024 data=cpu  37726 145 11731 755914 51976 1865 916 0 0 0.cpu0 9317 34 2898 227712 19958

вот только обрабатывать считанные данные могут по разному (что то учтут, что то не учтут)

Ошибки не исчезают с опытом - они просто умнеют

Koluchka	# 3 года, 8 месяцев назад
Темы: 2 Сообщения: 151 Участник с: 15 октября 2011	Может в линуксе это вообще единственный штатный механизм получения этой информации? :-)

vasek	# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Koluchka Может в линуксе это вообще единственный штатный механизм получения этой информации? :-) Похоже единственный. В самом /proc/stat информации немного, а вот в файле /proc/PID/stat информации много. Если его распарсить, то получится следующее pid: 1735 tcomm: (firefox) state: R ppid: 476 pgid: 1735 sid: 1735 tty_nr: 0 tty_pgrp: -1 flags: 4194304 min_flt: 2642445 cmin_flt: 5683 maj_flt: 764 cmaj_flt: 19 utime: 603.330000 stime: 79.030000 cutime: 0.050000 cstime: 0.060000 priority: 20 nice: 0 num_threads: 57 it_real_value: 0.000000 start_time: 12.24 16:33 (7143.65s) vsize: 9277476864 rss: 181944 rsslim: 9223372036854775807 start_code: 94802000285696 end_code: 94802000434088 start_stack: 140727716884704 esp: 0 eip: 0 pending: 0000000000000000 blocked: 0000000000000000 sigign: 0000000000001000 sigcatch: 00000000020144ff wchan: 0 zero1: 0 zero2: 0 exit_signal: 0000000000000011 cpu: 1 rt_priority: 0 policy: 0 И для каждого конкретного процесса conky считывает информацию из этого файла. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Koluchka
Может в линуксе это вообще единственный штатный механизм получения этой информации? :-)

Похоже единственный. В самом /proc/stat информации немного, а вот в файле /proc/PID/stat информации много. Если его распарсить, то получится следующее

              pid: 1735
               tcomm: (firefox)
               state: R
                ppid: 476
                pgid: 1735
                 sid: 1735
              tty_nr: 0
            tty_pgrp: -1
               flags: 4194304
             min_flt: 2642445
            cmin_flt: 5683
             maj_flt: 764
            cmaj_flt: 19
               utime: 603.330000
               stime: 79.030000
              cutime: 0.050000
              cstime: 0.060000
            priority: 20
                nice: 0
         num_threads: 57
       it_real_value: 0.000000
          start_time: 12.24 16:33 (7143.65s)
               vsize: 9277476864
                 rss: 181944
              rsslim: 9223372036854775807
          start_code: 94802000285696
            end_code: 94802000434088
         start_stack: 140727716884704
                 esp: 0
                 eip: 0
             pending: 0000000000000000
             blocked: 0000000000000000
              sigign: 0000000000001000
            sigcatch: 00000000020144ff
               wchan: 0
               zero1: 0
               zero2: 0
         exit_signal: 0000000000000011
                 cpu: 1
         rt_priority: 0
              policy: 0

И для каждого конкретного процесса conky считывает информацию из этого файла.

Ошибки не исчезают с опытом - они просто умнеют