最初にいくつかの環境の詳細:
ハードウェア:
インテルサーバーボードS2600GZ
2 x Intel Xeon CPU E5-2620
64GB DDR3 RAM
4TB LVMボリュームを備えたIntelRAIDコントローラーRS2BL(LSI SAS2108)SASディスク
ソフトウェア:
Ubuntu 12.04.4 LTS/Linux 3.11.0-24-汎用x86_64(最新の更新あり)
qemu/KVM(libvirt)と6つのVM(状況にもかかわらず問題なく実行)
glusterfsサーバー3.4.5(正常に動作しているようです)
他のいくつかのlightweghtソフト(例:bind9、keepalived、openvpnなど)
[〜#〜] no [〜#〜]カスタム/実験的/自家製ソフトウェア!
すでに長い間、Ubuntuサーバーの1つで非常に奇妙な問題が発生しています。定期的にsyslogに次のような「割り当ての失敗」メッセージが殺到します。
Aug 28 07:00:18 srvname kernel: [4210234.157335] irqbalance: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:19 srvname kernel: [4210234.711173] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:20 srvname kernel: [4210235.938599] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:34 srvname kernel: [4210250.307283] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:51 srvname kernel: [4210267.170359] irqbalance: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:01:02 srvname kernel: [4210278.625530] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:01:19 srvname kernel: [4210295.671569] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
メッセージは約30秒ごとにログに記録され、実際の状況を反映しています。このログスニペットに示されているプロセスは実際に失敗しています(たとえば、zabbixエージェントはzabbixサーバーへのデータ送信に失敗します)。しかし、それは氷山の一角にすぎません。このメモリの枯渇が進行している間/proc
ディレクトリを読み取る必要のあるプロセス(例:ps
、top
、mpstat
など)は、読み取りに失敗したために起動直後にクラッシュし(/proc
もls
で手動で一覧表示できません)、このイベントはすぐにログに記録されます同じ次数4の割り当て失敗エラーでsyslogに送信します。
これで十分な空き容量がありますRAM(合計サイズの1/4)ですが、ブロックごとにチェックすると、4次のブロックは本当に使い果たされています。[〜#〜]しかし[〜#〜]、私が本当に理解できないのは[〜#〜]なぜ[ 〜#〜]これらのプロセスは実際にそのような大きなブロックを要求しますか?別のほぼ同一の(ハードウェアとソフトウェアによる)サーバーがあります-次数4のブロックも使い果たされています-そしてそれは気分が良いです、順序4の割り当ての失敗はありません!さらに、この同一のサーバーは[〜#〜]はるかに[〜#〜]より重い負荷がかかっています。
「(高次の)割り当ての失敗」の症状について何度もWebを深く検索しましたが、何も関係がないようです。さまざまなsysctlパラメーター(たとえば、いくつかの記事で提案されているように、vm.min_free_kbytes
、vm.vfs_cache_pressure
など)を試してみましたが、何も役に立ちません。最終的に、これらすべての変更がロールバックされ、sysctl設定のほとんどがシステムのデフォルトになりました。また、echo
ingを/proc/sys/vm/compact_memory
および/proc/sys/vm/drop_caches
に試しましたが、明らかな(または長期的な)影響はありませんでした。長期間の消耗の後、突然、それ自体ですべてが正常になります(メモリが最適化され、4ブロックが使用可能になり、/proc
も使用可能になります)が、長くはありません-しばらくすると期間はすべて最初からやり直します。再起動は(完全に断片化されていないメモリのために)より長い期間役立ちますが、最終的にはすべてが同じになります...
一般に、説明されている動作によって引き起こされる(私たちが認識している)唯一の実際の問題は、サーバーリソースをリモートで監視および管理できないことです。 (zabbix)、またはローカル(ps
、top
、mpstat
など)。
私が理解している限り、4次ブロックの欠如は、Linuxでのメモリの通常の通常の状態です。プロセスが一般的にそのようなブロックを要求するべきではないというだけです(特に他のサーバーでそれを行わないプロセス)。誰かがそのような行動の原因となる可能性があるものについて何か考えを持っているなら、私たちは何をチェックすることができますか、どこを掘るのですか?必要に応じて追加情報を提供する準備ができています。
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1319244 は、これがカーネルバグであることを示唆しており、ごく最近リリースされたばかりのTrustyの修正があります。申し訳ありませんが、現在問題を解決することはできません(私にも影響しますが、まったく同じ動作です)。
これはハードウェアの問題ではありませんか?もし私があなたなら、RAMを疑うでしょう。 memtestなどを実行してみてください。