Ubuntu18.04全体ではないRAMが使用されますが、2 / 4GBのスワップが使用されます。
そのため、最新のカーネル更新を含む最新のすべてを使用してLEMPを実行するUbuntu Server 18.04を最適化するために懸命に取り組んでおり、SSHの応答性に若干の遅延があることに気づきました。
私の考えはRAMとSWAPの使用法 https://imgur.com/a/cRbnv8r
上記のリンクには、無料の-m、htop、vmstatのスクリーンショットがあります。ここで何が起こっているのか完全にはわかりません。RAM全体が使用されているわけではありませんが、2GBを超えるSWAPが使用されていますか？...
ここには2つの可能性があります。
- 私は実際にRAMを使い果たしており、ubuntuはこの2GBスワップを大量に使用しており、重要なタスクのために少量の空きメモリを保持しています。
- 私は実際には多くのRAMを使用しておらず、ubuntuはパフォーマンスを向上させるためにSWAPを使用しているだけです。
しかし、私には疑問があります。誰かがここで正しい理解を示してくれるといいのですが。
また、かなり前のことですが、SWAPをできるだけ少なくするために、swappinessを5に、vfs_cache_pressureを50に設定しました。
この状況がSSHの速度低下の原因である可能性がありますか？例：
ターミナルのローカルPCにパスワードを入力する-できるだけ速く入力でき、機能します
sSH経由でリモートサーバーにパスワードを入力する-無効なパスワードが表示されるので、できるだけ速くパスワードを入力できません。
パスワードの入力中にShiftキーを使用していますが、SSHが遅いときに無効なパスワードを入力することはありません。
あなたの場合、プログラムだけでなく、ほとんどのメモリが使用されているように見えます。一般に、Linuxは、バッファとページキャッシュ用のメモリを残すために、プログラムの一部をスワップアウトすることを好みます。
これは直感に反しているように見えるかもしれませんが、実際にはパフォーマンスが大幅に向上します。ディスクとの通信は、メモリとの通信よりも数桁遅くなる傾向があるため、ディスクキャッシュをメモリに保持すると、パフォーマンスが大幅に向上します。これは正常であり、swappinessやキャッシュプレッシャーを調整する必要はありません。また、これらの設定に加えた変更を元に戻す必要があります。
SSH経由で入力するときに遅延が発生する理由は、ネットワークの問題が原因である可能性があります。 SSHをインタラクティブに使用する場合は、待ち時間を短くする必要があります。つまり、送信できるデータの量がはるかに少ない場合でも、パケットをできるだけ早く送信することが最も重要です。どこかで、パケットが往復するのに必要以上に時間がかかっています。
これが当てはまる理由はたくさんありますが、その多くはサーバーの場所によって異なります。遠くにあると、レイテンシーが高くなります。また、途中でネットワークが混雑している場合は、多少の遅れも見られます。
この種の問題のトラブルシューティングに通常使用するツールはmtrです。 mtr -t YOUR_SERVERを実行して、遅延の問題があるかどうかを確認できます。
遅延の問題がない場合は、サーバーのメモリが不足していることが問題である可能性がありますが、その場合の解決策は、カーネルパラメータをいじくり回すのではなく、メモリを追加することです。サーバーのメモリ容量を大幅に超えており、追加するか使用量を減らす必要があることは、イメージから明らかです。