2

Metricsを使用して、jetty 8 サーバーにヘルスチェック サーブレットを実装しました。メトリックは、ロード バランサーからポーリングされるだけでなく、定期的 (5 分) にログ ファイルに書き込まれます。さらに、CPU 負荷やメモリ消費などの一部のメトリックが重大な制限に達すると、電子メール通知が送信されます。

これは、CPU 負荷とシステム メモリ消費に最適です。ただし、JVM メモリ消費量を測定するために定義されたメトリックの 1 つは、サーバーが安定して動作しているにもかかわらず、定義されたしきい値の 95% を定期的に超えています。したがって、この特定の指標に関する決定を再考する必要があるかもしれません。ヘルスチェックで使用するのに適した指標ですか? ガベージ コレクターが実行されるまで、Web アプリケーションが定期的にしきい値に達するのは、メモリ リークの兆候ですか?それとも、長時間実行されるすべての Web アプリケーションで予期される正常な動作ですか?

ご意見ありがとうございます。

JVM メモリ ヘルスチェックを実行するコードを次に示します。

Java ランタイム メモリ

    private final Runtime runtime = Runtime.getRuntime();

    Result check() throws Exception {

        final long freeMem = this.runtime.freeMemory();
        // maxMemory() is the value set by the JVM -Xmx (Max HeapSize) parameter
        final long maxMem = this.runtime.maxMemory();
        final long usedMem = maxMem - freeMem;          

        final double value = RatioGauge.Ratio.of(usedMem, maxMem).getValue();
        final double threshold = 0.95;

        if (value < threshold) {
            // Everything OK: Memory usage usage is below the threshold.
        } else {
            // NOT OK: Memory usage is above the threshold.
        }
    }
4

1 に答える 1

0

ベースラインを確立する必要があります。アプリが目的の負荷 (1 秒あたりのリクエスト数、オンライン ユーザー数など) で正常に動作する限り、CPU やメモリの消費は多かれ少なかれ問題ありません。ベースラインを取得したら、コードに機能を追加し、機能によって消費量が減少または増加するかどうかを確認し、それに応じて行動することができます。次に、必要に応じて、機能が追加された後に悪化したコードの場所を最適化します (または、ローカル コードを変更しても問題が解決しないことがわかり、特定の負荷の下で新しい機能をサポートするためにさらに多くのハードウェアが必要になるか、一部を再設計する必要があります)。アプリのコンポーネントとは異なりますが、それは別の話です)。

したがって、最も重要なのは絶対値ではなく (ただし、JVM ヒープ消費量が常に 95%であることは少し心配です)、コード変更間の変化です。

于 2013-06-12T10:57:32.767 に答える