最近のファームウェアアップデート以降、RAMの問題が発生しており、最終的にRAMが100%消費され、通常のプロセスのRAM使用量がSwapに移されるようになりました。
この問題を解決するにはシステムの再起動が必要で、再起動後は「通常」の使用に戻ります。
詳細：
ファームウェア：QTS 5.2.9.3410
NAS：TS-673A
RAM：32GB ECC
ネットワーク構成：1ポート、タグなし + 2 VLAN
プロセスの通常RAM使用量：7〜16GB
NASの用途：Containerstationホスト → Nextcloud、Plex、Nginx、HomeAssistant（約20コンテナ）
実施したテスト：
実行中のプロセスを減らして安定した7GB使用に調整
時間経過によるRAM使用量を監視
観察結果：
起動直後：7GB使用、2GBバッファ、17GBキャッシュ、6GB空き、0GBスワップ使用
起動4時間後：7GB使用、3GBバッファ、16.5GBキャッシュ、4.5GB空き、0GBスワップ使用
16時間後：9.8GB使用、16.5GBバッファ、5GBキャッシュ、0.7GB空き、0.5GBスワップ使用
バッファが時間とともに増加し、減少しないように見えます。その領域はまずキャッシュから消費され、次に通常のRAM領域がSwapに移されます。
バッファサイズが増加する原因について何か知見がある方はいらっしゃいますか？
ハードウェアとファームウェアの詳細は記載されていますが、どのようなプロセスを実行しているのか、またNASがどのような役割を果たしているのかも教えていただけると非常に助かります。
これらの機器は非常に多用途なので、何が起きているのかは様々です。
QBoostはメモリを解放しますか？
OneCD
3
これらの数値は問題なさそう、もしくは少なくとも標準的です。
おそらくご存知かと思いますが、知らない方のために：
こんにちは。
いいえ。どのアプリを使用していますか？
QVR Pro（QTS 5.2.x以降）を使用している場合、キャッシュのみが使用されます。
私のTS-264 QTS 5.2.9.3451ではバッファに問題はありません。
再起動はQTSアップデートのためでした。
17:00 QVR Proが起動しました
申し訳ありません、元の投稿に追加しました。そしてあなたのために：「NASの使用状況：Containerstationホスト → Nextcloud、Plex、Nginx、HomeAssistant（約20個のコンテナ）」
以前はGPU負荷の高いコンテナ（Viseron（NVR）、CodeProjectAI、Wyoming-Whisper&Piper）もホストしていました。これらは最初にSwap使用量の影響を受けたため、移行しました。
QBoostは私の知る限り使用していません。SSDも搭載されていません。
（編集：今確認しましたがQBoostはインストールされていませんでした。これから何が設定できるか確認してみます）
キャッシュについては予想通りですが、バッファの使用量はそうではありません。同様に、システムが遅くなるほどスワップを消費し始めるのも予想外です。
OneCD
7
アウト・オブ・メモリーキラー（Out-of-Memory Killer）は実際にトリガーされることがありますか？
（より多くのスワップが消費されると）コンテナ内で実行中のプロセスが強制終了され始めます。バッファは高いままです。
現在はQBoostを使用しており、次のような状況です：
これにより、少なくとも再起動の必要は防げています。週末の間は様子を見て、再度問題が発生するか確認します。
NA9D
9
チケットを開くことをおすすめします。適切に終了していないゾンビプロセスが動作していて、RAMを消費している可能性があります。CPU時間でこれが発生するのを見たことがありますし、Hybrid Mountのようなものが大量のRAMを使い始めたこともありました。
チケットを開く前に試せることを提案します。SSHシェルでHTOPをインストールしてください。これはTOPユーティリティのより高機能なバージョンで、どのプロセスが大量のメモリを消費しているかをソートすることができます。
プロセスやアプリを特定したら、App Centerでそれらのプロセスを停止します。これをすべての該当プロセスに対して行ってください。すべてのプロセスを停止したら、NASを再起動します。その後、各アプリを再起動します。この後、RAMの使用状況を監視し、改善されているか確認してください。もし改善されなければ、チケットを開いてください。
この提案をする理由は、単に再起動するだけでは、リソースを消費していた暴走プロセスがすぐに再起動してしまうからです。再起動だけではリセットされません。まず停止してから再起動する必要があります。
QNAPがファームウェアをアップデートする前に警告していることの一つに、長期間稼働している場合はNASを再起動するように、というものがあります。これは守った方が良いでしょう。私は以前このメッセージを無視してファームウェアをアップデートしていましたが、Hybrid Backup SyncがCPU時間を異常に消費し始めたことがありました。一見問題なさそうに見えても、再起動後しばらくするとまたおかしくなりました。QNAPと一緒に作業する中で、アプリを停止してから再起動するという方法を知り、問題が解決しました。これらはすべてファームウェアアップデート後に起こったことです。
それ以来、ファームウェアをアップデートする前に必ず再起動するようにしています。プロセス自体は少し長くなりますが、変な問題が起こるのを防げるようです。
弊社の内部チームでこの問題の再現を試みます。また、最近新しいソフトウェアをインストールされたかどうかお伺いしてもよろしいでしょうか。
別の手がかりがあると思います。
QBoostをインストールしてから挙動がより安定してきたようで、バッファが減少し、今はキャッシュに引き継がれています。
ただし、スワップ使用量が少し増加する前まではそうではありませんでした。スワップはほとんど減少しないようで、次のように推移しました。
0日目＆1日目：0MB
2日目：150MB
3日目：250MB
4日目：500MB
5日目：800MB
6日目：1400MB
7日目：1700MB
8日目：1600MB
現在は8日目です。
ご覧の通り、バッファはまだ大きいままで、なぜこれが増加するのか今は理解できた気がします：USBディスクの使用です。
FWアップデート以降、HBS用にリモートQNapへ接続できなくなったため、暫定措置としてUSBドライブを接続してバックアップを行いました。
これはシステムのファームウェアアップデートの数日前のことです（適切なバックアップなしでアップデートしないでください）。
NVRソフトウェアがこれを悪化させました。NVRも独自の外付けSSDを使用していたためです（内部HDDの読み書きを抑えるため）。NVRを移動してからは、今日一度だけシステムがハングしましたが、ごく短時間でした。その時のスワップ使用量はビジュアルとほぼ同じでしたが、UIが読み込まれずキャッシュ／バッファのバランスが表示されませんでした。
これら二つのバランスを表示するコマンドラインコマンドはありますか？もしあればSSHでログインしてバランスを確認できます。バッファがアプリケーションやキャッシュの領域をすべて使い切ってしまうことが、こういった問題の原因かもしれないと考えています。
さて、システムの遅延の原因が判明しました。他の問題についても、これで説明がつきそうです：
スナップショット（Snapshots）が有効になっていますが、実際には有効にしていません。
英語のフォーラムにスクリーンショットを投稿する前に、UIの言語をオランダ語から英語に切り替えておくのがベストです。
この問題はまだ発生していますか？もしそうであれば、サポートチケットを作成してください。サポートチームがさらにお手伝いします。ありがとうございます！
問題は見つかりました。最終的には、HBSがスナップショットを作成していたこと（完全にディスク上ではなかった）、フォルダサイズのインデックス作成、そしてQBoostがインストールされていなかったことが組み合わさって原因になっていました。
必要な箇所でスナップショットを無効化し、特にフォルダサイズのインデックス作成を無効にしたことで、すべてが劇的に改善しました。
