最近、カーネル メモリ アロケータが原因である可能性がある非常に奇妙な問題に遭遇しました。最初は、C++ コードにある種のメモリ バグがあるのではないかと疑っていましたが、実際の動作を見ると、おそらくコードのバグによるものではないと思います。かなり奇妙ですが、これが問題の私の最良の説明です。
マシンの /dev/shm 領域にファイルを書き込み、上書きするアプリケーションがあります。プログラムの開始時に、書き込み対象のすべてのファイルのファイル ポインターを宣言し、継続的に上書きします。これらのポインターはすべて、プログラムの開始時に作成されます。
コードを実行すると、次のことがわかります。最初のメモリ使用量は、システム全体の 4.3% まで跳ね上がります (一番下を見てください)。これは、実行可能ファイルを起動したときに発生します。その後、コードが何かを開始する前に、CPU 使用率は 40 ～ 50% 前後で推移します。この約 2 ～ 3 分後、メモリ使用量は 5.0% になり、それ以上の増加はありません。これが発生すると、CPU 使用率は 5 ～ 15% に低下します。これは、プログラムが通常実行される範囲です (データが渡される速度による)。
プログラムの起動時にメモリを使用してバックグラウンドで何かが起こっていますが、それが何であるかを理解できません。最新の x86_64 でシステムメモリ (1.2GB) の 5% を割り当てるのに 2 ～ 3 分もかからないように感じます。サーバ。この奇妙な起動の後、プログラムは通常問題なく実行されることに注意してください。
ただし、今日、プログラムが /dev/shm に書き込むファイルの数を増やす必要があり、それに応じてポインターの数も増やす必要がありました。そして、ここで問題が発生します。起動手順中に、CPU 使用率が突然 100% に跳ね上がり、そこにとどまります。これは、アプリケーションの大幅な速度低下につながり、許容レベルを下回るため、大きな問題です。これと実行可能な実行可能ファイルの唯一の違いは、書き込むファイルの数です。具体的に言うと、ファイルの数を 1345 から 1350 に増やしました。実際、この 100% CPU の問題を開始するには、1346 を 1 つ上回るだけで十分です。
私はここで何を扱っているのか本当に途方に暮れています。おそらく、SLAB/SLUB アロケータに問題があるのではないかと疑っています (私のシステムは 2.6.35 カーネルの Centos 5.8 です)。これを解決する方法についてのアイデアやヒントは大歓迎です。