AWS 上の Windows インスタンスから Linux インスタンスに移行した .NET (Core 2.0) サービスがあります。インスタンスは 1Gb RAM のマイクロです。
Linux インスタンスに 1Gb の swap 領域を追加し、swappiness=100 も設定しましたが、物理メモリがいっぱいになるとサーバーがフリーズします。プロセス自体がほとんど停止するほど遅くなり、bash で ENTER キーを押しても新しい行が表示されるまでに 10 秒かかることがあります。
実行中、top空きメモリは通常 10、20 MB です。プロセスは 800 MB 以上の RAM を使用しており、スワップは常にほぼ空で、最大 20 MB しか使用していません。1 時間そのままにしていても、それ以上スワップされませんでした。
AWSのディスクとCPUのクレジットはほぼ100%なので、リソースの使用が制限されているわけではありません。また、このようなインスタンスは100個ほどあり、何度も交換しましたが、動作は常に同じなので、問題のようには見えません。悪い例問題。
気になるのは、これが Windows では発生せず、Linux インスタンスでは基本システムに対して約 200 MB 少ないメモリが使用されることです。
Linux がより多くのメモリをスワップに移動するようにするには、swappiness 以外に調整する必要がある設定はありますか?
編集：スワップは cloud-init を通じて正しく設定されており、再起動しても問題なく動作します。
設定：
fallocate -l 1024M /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
sysctl vm.swappiness=100
free -m起動後:
total used free shared buffers cached
Mem: 993 232 760 0 7 152
-/+ buffers/cache: 72 921
Swap: 1023 0 1023
答え1
本当の問題を見つけました。アプリケーションはDocker内で実行されており、AWS は ECS コンテナ内のスワップの使用を意図的にブロックします何らかの理由で。以前は ECS を使用して Docker を管理していなかったため、このブロックは Windows には影響しませんでした。
サポートに問い合わせたところ、コンテナ内のスワップはサポートされておらず、いつサポートされるかもわからないとのことでした。そのため、ECS から移行して、Docker を自分で管理する必要があります。
答え2
まあ、あなたのエラーは実際にはかなり小さいかもしれません。その高い swappiness 値は、一部の OS 構成で問題を引き起こします。15 のような値を試してください。(注意: システムに swap を優先させるのは、ひどい考えです。システムが正常に機能するには、実際の RAM を使用する必要があります。[知らない場合や逆に解釈した場合に備えて、swappiness は swap が使用される前の RAM の空き容量の割合です。したがって、15 は、SWAP パーティションが使用される前に RAM の 85% が使用される必要があることを意味します。])
また、スワップ領域をどのように追加しましたか? 設定を変更しただけで新しいパーティションを作成しなかった場合、または /etc/fstab ファイルにエラーが残っている場合は、スワップを使用できなくなり、システムが存在しない、または書き込みできないものに書き込もうとするため (または、もっと興味深いことが起こる)、使用が困難になります。私はこれらの方法でインストールを何度も壊しました。