На днях node-exporter зарелизил версию 1.9.0, где среди изменений мне бросилось в глаза: - [FEATURE] pressure: add IRQ PSI metrics [#3048] В обсуждении к MR был комментарий от @SuperQ: Nice, it's too bad CONFIG_IRQ_TIME_ACCOUNTING is recommend to be off so very few people will benefit from this by default. Что за рекомендации такие и кого они аффектят? ————— Для начала чуть теории 📖 Обработчики прерываний бывает двух типов: аппаратные (Hard IRQ) и программные (SoftIRQ). Hard IRQ вызываются устройствами (диск, клавиатура, сеть и т. д.) и немедленно обрабатываются процессором. Они могут прервать любой код, поэтому их обработку делают минимальной, чтобы быстрее освободить CPU для других задач. SoftIRQ обрабатывает прерывания асинхронно в контексте ядра, не блокируя CPU. Поэтому ему отдают наиболее длительные этапы обработки. В CPU Usage нагрузка от Hard IRQ отображается в %irq, а от SoftIRQ в %softirq. ————— Теперь вернемся к изначальному вопросу. Оказывается %irq отображается только при включённой опции CONFIG_IRQ_TIME_ACCOUNTING, иначе он всегда равен нулю. В redhat-like дистрибутивах эта опция включена, тогда как в debian и им подобным её по умолчанию отключают! # mpstat 1 Linux 5.10.0-20-amd64 02/18/2025 _x86_64_ (8 CPU) 11:28:51 PM CPU %usr %nice %sys %iowait %irq %soft %steal %idle 11:28:52 PM all 40.15 0.00 1.38 0.00 0.00 0.63 0.00 57.84 11:28:53 PM all 28.81 0.00 1.78 0.25 0.00 0.51 0.13 68.53 11:28:54 PM all 35.29 0.00 2.25 0.00 0.00 0.25 0.00 62.20 11:28:55 PM all 17.68 0.00 1.14 0.00 0.00 0.38 0.25 80.56 11:28:56 PM all 16.31 0.00 1.99 0.00 0.00 0.25 0.25 81.20 # mpstat -I ALL 1 11:32:53 PM CPU intr/s 11:32:54 PM all 18466.00 11:32:55 PM all 11983.00 11:32:56 PM all 14019.00 %irq нулевой, хотя кол-во прерываний десятки тысяч. А дальше самое интересное. Если CONFIG_IRQ_TIME_ACCOUNTING отключена, нагрузка от Hard IRQ никуда не исчезнет (кэп🙂), а учитывается как: 1. если прерывание произошло в user mode, то время его обработки будет учтено как %user того процесса, который выполнялся до прерывания. 2. если прерывание произошло во время выполнения процесса в system mode, его обработка будет засчитана в %sys этого процесса. 3. если прерывание произошло во время выполнения фоновых задач ядра (kworker, ksoftirqd), то его обработка будет засчитана в %sys системы В итоге точность анализа загрузки CPU снижается, что может вводить в заблуждение. Говорят, что погрешность может достигать 5–7%! А это хорошо бы проверить😉 Судя по документации ядра, опцию отключают из-за её небольшого влияния на производительность: Select this option to enable fine granularity task irq time accounting. This is done by reading a timestamp on each transitions between softirq and hardirq state, so there can be a small performance impact. If in doubt, say N here. И это проверим:) P.S. Подробнее, с примерами про подсчет irq читай в блоге Танел Подера. #cpu #kernel