it-swarm-ja.com

perf割り込みに時間がかかりすぎたが、perfがインストールされていない

サーバーがときどきクラッシュし始めるので、dmesgを確認しました。そこで私は次の行を読みました:

perf interrupt took too long (2528 > 2500), lowering kernel.perf_event_max_sample_rate to 50000

数回表示されます。
perfがパフォーマンス分析ツールであることを覚えており、インストールしたことを覚えていません。だから私はチェックしました:

~$ dpkg -l *perf*
dpkg-query: no packages found matching *perf*

私の質問:

  • これは迫り来る嵐の兆候ですか?この行が数回来てから、rcu_sched detected stallsで始まるスタックダンプがあるため
  • これらはどこから来たのですか?
7
Martin B.

このメッセージはLinuxカーネルからのものです。より正確には perf_duration functionlinux/kernel/events/core.c

static void perf_duration_warn(struct irq_work *w)
{
    printk_ratelimited(KERN_INFO
        "perf: interrupt took too long (%lld > %lld), lowering "
        "kernel.perf_event_max_sample_rate to %d\n",
        __report_avg, __report_allowed,
        sysctl_perf_event_sample_rate);
}

私はあなたが正確に何を意味するのかわかりません:

これは嵐の兆候ですか?

しかし、私はあなたのデバイスの1つに問題を疑っています。

PS:注意深く読むと、コードにメッセージがperf: interrupt took too longですが、メッセージはperf interrupt took too long。コロンはカーネルバージョン4.6で追加されました。

4
Ortomala Lokni

しばらくの間、デスクトップシステムに同様のメッセージが表示されました。無停電ディスクI/O(D内のps)で1つまたは複数のコアが数分以上ストールした後に表示されます。デッドロックにつながるI/Oスケジューリングの競合状態が疑われますが、これをデバッグする方法がわかりません。 CFQの代わりに適切なディスクのデッドラインスケジューラに切り替えると役立つようです。

# echo deadline > /sys/block/sdX/queue/scheduler 

私はそれを使ってスケジューリングの短い一時停止を観察しましたが、デッドラインスケジューラの2番目のキューは長いストールを軽減するようです。

誰かがこれについてもう少し光を当てることができれば、私もそれを感謝します。

編集

rcu_schedエラー/警告が関連しているかどうかはわかりませんが、可能性は十分にあります。カーネルの設定が異なるため、取得できません。

1つのコアが停止している場合、psで表示されるのは

$ ps axu | grep ' D'
dirk      4720 13.0  5.1 1615772 842444 pts/3  Dl+  07:27  24:54 iceweasel -P default

i/Oを行っていたプロセスのために。 Dは、man psによると、「割り込み不可能なスリープ(通常はI/O)」を意味します。

3
dirkt