Процесс с загрузкой ЦП 1%, вызывающий среднюю нагрузку 1,5

Использование ЦП и загрузка — разные показатели. На самом деле нагрузка может быть выше 1. ЦП — это реальное время, используемое ЦП, поэтому оно всегда должно быть меньше 100% (, но на нескольких ядрах/ЦП, но вы поняли идею ). Загрузка указывает загрузку :, сколько процессов запущено и ожидает запуска.

Как вы, вероятно, знаете (из обсуждения вашего вопроса ), ввод-вывод обычно является одним из таких ожиданий, поэтому он увеличивает нагрузку. Но у вас также могут быть сигналы/семафоры/блокировки, которые могут вызвать ожидание, и они могут быть просто вызваны одним процессом, который не выполняет ввод-вывод ). Например. если один процесс просыпается каждую секунду, и есть много процессов, ожидающих данных от такого процесса, вы получаете более высокую нагрузку (, равную количеству ожидающих процессов ).

Вы можете рассматривать каналы как ввод-вывод, но mmap и блокировки... классифицируете ли вы как ввод-вывод? Они не будут отображаться в блоке ввода-вывода )bio (, поэтому вы можете не увидеть их во многих статистических данных о нагрузке.

Часто более простой способ обнаружить это :заблокировать процесс и проверить, где он находится. Сделайте это много раз, и вы, надеюсь, увидите, что одна функция блокируется (, и вы можете обнаружить ее гораздо чаще, чем другие функции ).

У меня возникла та же проблема на встроенной системе, работающей на i.mx28 с частотой примерно 450 МГц.

htopпостоянно показывал загрузку ЦП на 50% исключительно из-за одной из задач swupdate.

При просмотре mongoose_interface.cваше 100-миллисекундное наблюдение сработало при чтении этого в концеstart_mongoose():

                mg_mgr_poll(&mgr, 100);

Экспериментально я изменил 100 на 1000, и после перекомпиляции и перезапуска загрузка ЦП снизилась примерно до 2% от swupdateпотоков, как показано в htop.

Как уже было сказано, это было экспериментально, так как цифры показались мне слишком уж совпадением. Я не исследовал, возникают ли какие-либо побочные эффекты.

Поскольку задачи как в состоянии R, так и в состоянии D вносят свой вклад в загрузку Linux, вы можете выполнить выборку всех потоков в вашей системе в любом из этих состояний. Например:

for x in {1..100} ; do ps -aeos,user,comm,wchan | grep "^[RD]" ; sleep 0.1 ; done | sort | uniq -c | sort -nbr | head -20

Пример вывода ниже, вам нужно игнорировать верхнюю строку, показывающую, что ваш собственный psпроцесс всегда активен -, так как именно он выполняет всю выборку:

# for x in {1..100} ; do
>   ps -aeos,user,comm,wchan | grep "^[RD]"
>   sleep 0.1
> done | sort | uniq -c | sort -nbr | head -20

    100 R root     ps              -
      3 R oracle   oracle_14047_li -
      2 R root     rcu_sched       rcu_gp_kthread
      2 R root     rcu_sched       -
      2 R root     kworker/1:2-eve -
      2 R oracle   perl            -
      2 R oracle   ora_vktm_lin19c hrtimer_nanosleep
      2 D root     md10_raid10     md_super_wait
      2 D oracle   ora_ckpt_linprd md_write_start
      1 R redis    redis-server    -
      1 R oracle   ora_vktm_linprd hrtimer_nanosleep
      1 R oracle   ora_m001_linprd -
      1 D root     xfsaild/dm-18   rq_qos_wait
      1 D oracle   ora_mz00_lin19c x64_sys_io_destroy
      1 D oracle   ora_lg00_lin19c inode_dio_wait
      1 D oracle   ora_dbrm_lin19c msleep

Если вы не используете старое ядро, вам следует запускать его от имени пользователя root, поскольку более новые ядра маскируют значения WCHAN процессов других пользователей.

Вы можете пойти дальше (, но не с ps ), вы можете попробовать /proc/PID/syscallи /proc/PID/stack, чтобы получить информацию о системном вызове и трассировке стека ядра. Для этого я написал инструмент под названием Linux Process Snapper (psn).таким образом, вы можете выполнять довольно расширенную детализацию таких проблем с производительностью, не прибегая к трассировке ядра:

[tanel@linux01 ~]$ sudo psn -G syscall,wchan

Linux Process Snapper v0.18 by Tanel Poder [https://0x.tools]
Sampling /proc/syscall, stat, wchan for 5 seconds... finished.


=== Active Threads ==========================================================================================

 samples | avg_threads | comm             | state                  | syscall         | wchan                 
-------------------------------------------------------------------------------------------------------------
     511 |      255.50 | (kworker/*:*)    | Disk (Uninterruptible) | [kernel_thread] | blkdev_issue_flush 
     506 |      253.00 | (oracle_*_l)     | Disk (Uninterruptible) | pread64         | do_blockdev_direct_IO 
      28 |       14.00 | (oracle_*_l)     | Running (ON CPU)       | [running]       | 0                     
       1 |        0.50 | (collectl)       | Running (ON CPU)       | [running]       | 0                     
       1 |        0.50 | (mysqld)         | Running (ON CPU)       | [running]       | 0                     
       1 |        0.50 | (ora_lgwr_lin*c) | Disk (Uninterruptible) | io_submit       | inode_dio_wait        
       1 |        0.50 | (oracle_*_l)     | Disk (Uninterruptible) | pread64         | 0                     
       1 |        0.50 | (oracle_*_l)     | Running (ON CPU)       | [running]       | SYSC_semtimedop       
       1 |        0.50 | (oracle_*_l)     | Running (ON CPU)       | [running]       | read_events           
       1 |        0.50 | (oracle_*_l)     | Running (ON CPU)       | read            | 0                     
       1 |        0.50 | (oracle_*_l)     | Running (ON CPU)       | semtimedop      | SYSC_semtimedop       

Вы можете пойти гораздо глубже, соответствующая запись в блоге находится здесь:

• Устранение неполадок с высокой загрузкой системы Linux при низкой загрузке ЦП