たった1つの問題が発生しました。通知は、ディスク使用量（読み取り/書き込み）が多すぎることから始まりました。 長い間、問題は時間不足のため解決できませんでしたが、CPU使用率が200％を超える統計を伴う不可解な障害が発生しました。 多くの倒錯の後、問題が見つかり、その解決策が見つかりました。
問題は、スワップが使用されたことです。 参考：256Mbスライス（つまり、RAM）、apache2、mod_wsgi、django、postgresqlをすべてArch Linuxに搭載しています。
知らない人のために、スワップサイズは
free -m
コマンドで表示できます（ちなみに、 良い eng 記事 ）。
そのため、入り口には写真があります。
キャッシュされた使用済み共有バッファの合計 メンバー：256251 4 0 1 26 -/ +バッファ/キャッシュ：224 31 スワップ：511 227 284
ご覧のように、swapが使用されています...これはすでに悪いことです。 スワップ-HDDによるRAMの不足を補おうとする試みに他なりません。 つまり OSがデータがRAMに収まらないことを認識すると、データをハードドライブにスワップします。 ご存知のように、RAMはHDDよりもはるかに高速ですが、それはポイントではありません-ハードディスクには独自の読み取り/書き込みリソースがあります（可動部分のため）。これが、スラッシュホストがスワップを使用するためにカスタマイズされている理由です。
今より具体的に。 まだdjangoをmod_pythonで使用している場合-最後のものを投げてください。 WSGIの場合、詳細。
Apacheをチューニングしても十分な結果が得られなかったため、WSGI設定を掘り下げることにしました。 WSGIDaemonProcessディレクティブに興味があります （ ところで 、VirtualHostにあります）。 最も単純なケースでは、プロセスの名前のみを受け入れますが、これは微調整には不十分です。
ほとんどの場合、スタックサイズオプションに興味があります。 デフォルトでは、ストリームごとに8MBです。 つまり プロセスごとに15スレッドでも、15 * 8 = 120 Mbになります。 少なからず同意します。 mod_wsgiのマニュアルでは、VPSではこの値を512kb（524288バイト）に減らすことができ、既に4Mbになっていると述べています。 これで、WSGIDaemonProcessは次のようになります。
WSGIDaemonProcess mysite maximum-requests=200 stack-size=524288
ここで、maximum-request = 200は、プロセスが再起動されるまでのリクエストの数です。 これは、メモリリークが存在する場合に役立ちます。再起動中、プロセスメモリは元の状態に戻ります。
原則として、受け入れられる結果以上のものを達成したため、そこで停止しました
キャッシュされた使用済み共有バッファの合計 メモリ：256203 53 0 2 29 -/ +バッファ/キャッシュ：170 85 スワップ：511 6 505
これで十分でない場合は、いくつかのオプションに注意する必要があります。
- threads-プロセスごとのスレッド数（デフォルトでは15）
- inactivity-timeout-プロセスが非アクティブと見なされ、再起動されるまでの時間。 めったに訪れないサイトに適し、定期的にメモリを消去できます。
- processes-プロセスの数（デフォルトは1）
また、忘れないでください
WSGIPythonOptimize 2
なぜなら 最初は0です（つまり、最適化なし）。
さて、それですべてです、コメントは大歓迎です:)
Retta経由