NetAppファイラー-アイドル状態のファイラーでトリガーされる「最低水準点」のCPが多数
NetApp2240-4ファイラーヘッドを4つ持っています。それらは単一のシャーシ「ボックス内のクラスター」であるため、2つの別個のユニットです。
過去数日間、ほぼ同時に、全員が低水準点の一貫性ポイントを大量に記録し始めました。
ランニング wafl_susp -w私にcp_from_low_water 10 /秒以上の速度でクロックアップします。これが始まる前は、ほぼ完全にcp_from_timer10秒ごとに1の割合で。
2つのボックスが応答しなくなり、再起動されましたが、問題は再び発生しました。それが関連しているとは100％確信していませんが、犯人に関しては合理的な賭けのようです。
他の2つは完全にアイドル状態です。ベースOSといくつかのvfilerがあり、他には何もありません。しかし、それでも-透かしが少ないということは、何らかの理由でメモリが不足していることを示しています。ある種のサービス拒否状態が発生していると想定することしかできません（おそらく「SSHログインの失敗」？）。
誰かがこれをトラブルシューティングする方法についての洞察を提供できますか？特にNetAppの観点から、メモリを占有しているものを抽出する方法に関するヒントを探しています。
チケットを開く-これは システムメモリの不足 があることを示しています。作業がほとんど行われておらず、ボックスが応答しなくなった場合は、何か厄介なことが起こっています。以前、回線のサポートを利用して内部メモリの使用状況を検査するプロセスを説明しましたが、クライアントが独自に行うことは想定されていません。 priv setコマンドを使用して、実行中のプロセスを確認する必要があります。
問題に関してベンダーにケースが開かれました。
低ウォーターマークCPは、メモリ枯渇の結果です： （ベンダーリンク）
低水準点によって引き起こされるCP;日常のハウスキーピングタスクに使用できるメモリの量は十分に少ないため、CPを開始してさらにリリースするのが理想的です。
ベンダーとやり取りするために、「perfstat」を実行しました。これは、パフォーマンス関連のサポート情報を送信できるNetAppのダウンロード可能なツールです。これにより、バグが発生しました ID 69779 （サポートログインが必要）、現在使用していたバージョンのコードに存在し、ONTAP8.2.3で修正されました
具体的には、LDAP認証が失敗した特定のケースでのメモリリーク。 4つのホストすべてが同じアカウントを使用しており、ある時点でロックアウトが作動したため、すべてのホストが不条理な頻度で失敗していました。 （そして、そもそも特に非常に低メモリのシステムでした）。
このバグが存在する他のシステムを調べたところ、発生の兆候がいくつかありましたが、700日以上の稼働時間のシステムでも、わずかな量しか発生していませんでした。
一般に（「diag」コマンドの使用は潜在的に危険であるため、ベンダーに相談せずに細心の注意を払って実行する必要があることに注意してください）-mem_statを調べることで問題を特定できます-2番目の列は 'バイトです'そして' sasl 'を探します。
1306719 5268691008 maytag.ko::sasl_client_new+149
問題がどのレベルで発生するかはわかりません。システムが再びクラッシュしてチェックするのを待っています。ただし、5％を超えるメモリ使用率では、アクションの実行を検討する必要があることをお勧めします。コードの更新と同様に、再起動すると修正されます。
現在、監視体制の一部としてcp_typesとメモリフットプリントをキャプチャしているので、それが発生しているのを観察できます。また、LDAPアカウントのロックアウトの発見についてもう少し積極的になります。