sql >> データベース >  >> NoSQL >> Redis

監視する必要のある6つの重要なRedisモニタリングメトリクス

    Redis は、非常に高速なパフォーマンスを提供するインメモリデータベースです。これにより、パフォーマンスが懸念される場合に、ディスクベースのデータベースの魅力的な代替手段になります。パフォーマンスに敏感なアプリケーションを強化するために、Redis™*用のScaleGridホスティングをすでに使用している可能性があります。 Redisのデプロイが正常で、要件を満たしていることをどのように確認しますか?監視するRedis™の監視指標と、これらの重要なサーバー指標を監視して正常性を確保するためのツールを知る必要があります。 Redisシェルでinfoコマンドを実行すると、Redisはデータベースメトリックの大きなリストを返します。これらから関連するメトリックのスマートな選択を選択できます。また、これらは、システムの正常性を確保し、発生する可能性のあるパフォーマンス関連の問題の根本原因分析を迅速に実行するのに役立ちます。

    このブログ投稿には、監視する重要なデータベースメトリックがリストされています。データベースのパフォーマンスの観点から各メトリックを確認し、それらに関連する一般的な問題と解決策について説明します。

    1。パフォーマンスメトリック:スループット

    スループットは、サーバーが特定の期間に実行しているデータベース操作の数を示します。これは、アプリケーションのワークロードとそのビジネスロジックに依存します。スループットの履歴を確認することで、サーバーの負荷のパターンを推測できます。ピーク負荷、ピーク負荷の頻度、ピーク負荷の時間枠、平均負荷など。

    infocommandstats 」を実行すると、Redisサーバーで実行されるすべてのコマンドのスループットメトリック値を収集できます。 」。

    127.0.0.1:6379> info commandstats
    # Commandstats
    cmdstat_get:calls=797,usec=4041,usec_per_call=5.07
    cmdstat_append:calls=797,usec=4480,usec_per_call=5.62
    cmdstat_expire:calls=797,usec=5471,usec_per_call=6.86
    cmdstat_auth:calls=147,usec=288,usec_per_call=1.96
    cmdstat_info:calls=46,usec=902,usec_per_call=19.61
    cmdstat_config:calls=2,usec=130,usec_per_call=65.00
    cmdstat_eval:calls=796,usec=36950,usec_per_call=46.42
    cmdstat_command:calls=796,usec=8578,usec_per_call=10.78
    

    Redisは、さまざまなコマンドを接続、サーバー、クラスター、汎用などにグループ化します。Redis™のScaleGridモニタリングは、さまざまなコマンドのスループットを上記のグループの1つに集約します。スループットは積み上げ面グラフとして表され、各色付きの領域の高さがコマンドのグループのスループットを提供します。

    スループットの低下は、通常、サーバーが取得するクエリが少ないことを示している可能性があります。また、高価なクエリなど、潜在的な問題を示している可能性もあります。同様に、スループットの向上は、サーバーでの集中的なワークロードとより大きなレイテンシーを意味します。

    2。メモリ使用率

    メモリはRedisのパフォーマンスにとって重要なリソースです。 使用済みメモリ アロケータ(標準libc、jemalloc、またはtcmallocなどの代替アロケータ)を使用してRedisによって割り当てられる合計バイト数を定義します。

    info memory 」を実行すると、Redisインスタンスのすべてのメモリ使用率メト​​リックデータを収集できます。 」。

    127.0.0.1:6379> info memory
    # Memory
    used_memory:1007280
    used_memory_human:983.67K
    used_memory_rss:2002944
    used_memory_rss_human:1.91M
    used_memory_peak:1008128
    used_memory_peak_human:984.50K
    

    Redisが最大メモリ制限なしで構成されている場合、メモリ使用量が最終的にシステムメモリに達し、サーバーが「メモリ不足」エラーをスローし始めることがあります。それ以外の場合、Redisは最大メモリ制限で構成されていますが、 noeviction ポリシー。これにより、サーバーはキーを削除しないため、メモリが解放されるまで書き込みができなくなります。このような問題の解決策は、最大メモリといくつかのエビクションポリシーを使用してRedisを構成することです。この場合、メモリ使用量が最大に達すると、サーバーはエビクションポリシーを使用してキーのエビクトを開始します。

    メモリRSS (常駐セットサイズ)は、オペレーティングシステムがRedisに割り当てたバイト数です。 「memory_rss」と「memory_used」の比率が約1.5より大きい場合は、メモリの断片化を示しています。断片化したメモリは、サーバーを再起動することで回復できます。

    3。キャッシュヒット率

    キャッシュヒット率は、キャッシュ使用の効率を表します。数学的には、(合計キーヒット数)/(合計キーヒット数+合計キーミス数)として定義されます。

    info stats 」コマンドはkeyspace_hitsを提供します & keyspace_misses 実行中のRedisインスタンスのキャッシュヒット率をさらに計算するためのメトリックデータ。

    127.0.0.1:6379> info stats
    # Stats
    .............
    sync_partial_err:0
    expired_keys:10
    evicted_keys:12
    keyspace_hits:4
    keyspace_misses:15
    pubsub_channels:0
    pubsub_patterns:0
    .............
    

    キャッシュヒット率が約0.8未満の場合、要求されたキーのかなりの量が削除されるか、期限切れになるか、まったく存在しません。 Redisをキャッシュとして使用している間は、このメトリックを監視することが重要です。ほとんどのリクエストがディスクからデータをフェッチしているため、キャッシュヒット率が低いとレイテンシが大きくなります。これは、アプリケーションのパフォーマンスを向上させるために、Redisキャッシュのサイズを増やす必要があることを示しています。

    4。アクティブな接続

    接続数は限られたリソースであり、オペレーティングシステムまたはRedis構成のいずれかによって適用されます。アクティブな接続を監視すると、ピーク時にすべてのリクエストを処理するのに十分な接続があることを確認できます。

    5。削除/期限切れのキー

    Redisはさまざまな排除ポリシーをサポートしています これは、メモリ使用量が最大制限に達したときにサーバーによって使用されます。このメトリックの永続的な正の値は、メモリをスケールアップする必要があることを示しています。

    127.0.0.1:6379> info stats
    # Stats
    ..............
    sync_partial_err:0
    expired_keys:0
    evicted_keys:0
    keyspace_hits:0
    keyspace_misses:0
    pubsub_channels:0
    pubsub_patterns:0
    ..............
    

    RedisはTTLをサポートしています (存続時間)各キーのプロパティ。関連するTTLが経過すると、サーバーはキーを削除します。アプリケーションがこのプロパティを定義しない場合、期限切れのデータがメモリに蓄積されます。正のメトリック値は、期限切れのデータが適切にクリーンアップされていることを示します。

    6。レプリケーションメトリクス

    「connected_slaves」 メトリックは、スレーブサーバーのマスターへの到達可能性を通知します。サーバーの読み取り負荷によっては、スレーブに到達できない場合、読み取りの待ち時間が長くなる可能性があります。

    127.0.0.1:6379> info replication
    # Replication
    role:master/slave
    connected_slaves:0/master_slave_io_seconds_ago:0
    master_repl_offset:0
    ..............
    

    master_slave_io_seconds_ago ’メトリックは、スレーブとマスター間の通信中に経過する時間を示します。このメトリックの値が高い場合は、マスター/スレーブの問題またはネットワークの問題を示している可能性があります。さらに、スレーブは古いデータを提供します。

    結論

    データベースサーバーの状態とパフォーマンスを適切に把握するための重要な指標のいくつかについて説明しました。特定のデータベースサーバーとユースケースに関連する他のものが存在する可能性があります。 「info」コマンドで報告されたすべての指標を確認して理解することをお勧めします。

    Redis™デプロイ用のAWSホスティングの管理についてサポートが必要な場合は、[email protected]またはTwitter@scalegridioまでメールでお気軽にお問い合わせください。


    1. Express.jsとは何ですか?

    2. MongoDBにコレクションが存在することを確認してください

    3. mongo:リターンはcount()と等しくありません

    4. MongoDBoplogを変更して再生します