組み込み (Arm) Linux 製品で一晩中ロックアップが発生していますが、それを特定するのに問題があります。通常、電源を入れてから問題が発生するまでに 12 ～ 16 時間かかります。sar ロギングを実行できるように sysstat をインストールしました。大量のデータがありますが、結果の解釈に問題があります。
ターゲットには 512Mb の RAM しかなく (1Gb の他のモデルもありますが、この問題が発生する頻度ははるかに低くなります)、eMMC の摩耗を避けるためのディスク スワップ ファイルはありません。
ある種のページング/仮想メモリ イベントが問題を引き起こしています。sar ログでは、pgpin/s、pgnscand/s、pgsteal/s、および majflt/s がすべて着実に増加してから、雪だるま式に異常なレベルに達します。これにより、CPU のレベルがそれに応じて高くなります (デュアル コア Arm チップでは 30 ～ 60)。同時に、frmpg/s の値は非常にマイナスになり、campg/s は非常にプラスになります。結果として、システムは一度に大量のキャッシュ ページを割り当てようとしています。なぜこれになるのかわかりません。
その後、ターゲットは、リブートされるか、誰かがメインの GUI プロセスを強制終了するか、クラッシュして再起動されるまで、基本的にロックされます (常に実行され、通常、製品ですべての重大な作業を行うモノリシック GUI アプリケーションがあります)。ネットワークはシャットダウンし、telnet は永久にブロックされ、/proc ファイルシステムのクエリや top のようなそれに依存するものも同様です。このテストにおけるメイン アプリケーションのメモリ割り当てプロファイルは、ファイルからデータを読み取り、OpenGL ES 2.0 を使用して LRU 内のビデオ メモリ (メイン RAM と共有) にテクスチャとしてキャッシュすることによって支配されます。ほとんどの場合、単一のファイル (サイズは約 50Mb) にアクセスしますが、突然新しいファイルを使用する必要があり、その 50Mb すべてを一度にキャッシュしようとすると、トリガーされる可能性があると思います。私は持っていない
奇妙なことに、実際の空き RAM とキャッシュ RAM のレベルでは明らかなメモリ不足が示されません (100Mb 以上の空き RAM と 40Mb のキャッシュ RAM を使用してメイン アプリケーションを強制終了する際に、oom-killer が急降下するのを見たことがあります)。メイン アプリケーションのメモリ使用量は、かなり安定しているように見える VmRSS 値で、かなり適切に動作しているように見えます。Valgrind は、操作中に発生する進行性のリークを発見していません。
この動作は、システムが必死にディスクにスワップアウトし、結果としてすべての動作が遅くなるように見えますが、これがフリー <-> キャッシュ RAM 交換システムで既知の効果であるかどうかはわかりません。
私の問題は表面的には質問に似ています: Linux はメモリの初期化時にカーネルの CPU 使用率が高いですが、その問題はディスク スワップ ファイル管理によって引き起こされているようです。ただし、ダーティ ページのフラッシュは、私の問題ではもっともらしいようです。
/proc/sys/vm の下にあるさまざまな vm ファイルをまだ試していません。vfs_cache_pressure とおそらく swappiness は、いくつかの調整の良い候補に思えますが、ここで試してみるのに良い値についての洞察が欲しいです。vfs_cache_pressure は、10000 ではなく 200 に設定することの違いが定量的にどうなるかについて、明確に定義されていないようです。
もう 1 つの興味深い事実は、それが漸進的な問題であるということです。初めて効果が現れるまでに 12 時間かかる場合があります。メインのアプリを強制終了して再起動すると、その後 3 時間ごとに発生するようです。ただし、キャッシュを完全に削除すると、これが押し戻される可能性があります。
sar -A の完全な出力である sar1.log と、free/cache mem、CPU 負荷、MainGuiApp メモリ統計、および -B と- 真夜中から午前 3 時 40 分までの興味深い期間の R sar 出力:
https://drive.google.com/folderview?id=0B615EGF3fosPZ2kwUDlURk1XNFE&usp=sharing
要約すると、ここでの私の最善の計画は何ですか? vm を調整してページをより頻繁にリサイクルし、バーストを少なくしますか? ログデータが与えられた場合でも、何が起こっているかについての私の仮定は有効ですか? このメモリ使用モデルを処理するより賢い方法はありますか?
ご協力いただきありがとうございます。
2013 年 6 月 5 日更新: ブルート フォース アプローチを試し、1 時間ごとに 3 を drop_caches にエコーするスクリプトを作成しました。これは現在、システムの安定した状態を維持しているようで、sar -B の統計はフラットな部分にとどまり、重大な障害はほとんどなく、0.0 pgscand/s です。ただし、キャッシュ RAM を非常に低く保つことで、カーネルがユニバースをキャッシュ RAM に追加しようとする問題が軽減される理由がわかりません。