*redis-cli、Redisコマンドライン インタフェース

redis-cliはRedisコマンドライン インタフェースで、直接端末からRedisにコマンドを送信し、サーバによって送信される応答を読み込むことができる単純なプログラムです。

2つの主要なモードがあります: ユーザがコマンドを入力して応答を受け取るREPL (Read Eval Print Loop) の対話的なモード; コマンドがredis-cliの引数として送信され、実行され、標準出力に表示されるもう1つのモード。

対話的なモードでは、redis-cli は良い入力体験を提供するために基本的な行編集機能を持ちます。

しかし redis-cli はそれだけではありません。プログラムを特別なモードにするためにプログラムを起動するために使えるオプションがあります。これにより redis-cli は、スレーブのシミュレーションや、マスターから受信したレプリケーションストリームの出力、Redis サーバのレイテンシのチェック、レイテンシのサンプルと頻度の統計や ASCII アートのスペクトログラムなど多くの複雑なタスクを確実に実行できます。 many other things.

このガイドでは、最も単純なものから始めてより高度なものまで、redis-cliの様々な側面をカバーします。

Redisを大規模に使うつもりか、既にそうしている場合は、redis-cliを大いに使う良い機会です。いくらか時間を掛けてそれに慣れることは非常に良い考えです。あなたがコマンドライン インタフェースの全てのトリックを知れば、Redisでより効果的に働くことができるでしょう。

*コマンドラインの使い方

単にコマンドを実行し標準出力に応答を出力させるのは、redis-cliの別の引数として実行するコマンドを入力するだけの簡単さです:

$ redis-cli incr mycounter
(integer) 7

コマンドの応答は "7" です。Redisの応答は型付けされている(文字列、配列、整数、NULL、エラーなど)ので、括弧の間に応答の型が表示されます。しかし、redis-cliの出力が別のコマンドの入力として使われなければならない場合や、それをファイルにリダイレクトしたい場合には、良い考えでは無いでしょう。

実際のところ、redis-cli は標準出力がtty(基本的には端末)であることを検出した場合には、人間が読みやすいようにする追加の情報のみを表示します。そうでなければ、以下の例のような生の出力モードを有効にします:

$ redis-cli incr mycounter > /tmp/output.txt
$ cat /tmp/output.txt
8

この場合、CLIが出力がもう端末に書き込まれていないことを検出したため、(integer)が出力から省略されました。--raw オプションを使って端末であっても生の出力を強制することができます:

$ redis-cli --raw incr mycounter
9

同様に、ファイルへの書き込み、あるいは他のコマンドへのパイプの中で、--no-rawを使って人間が読みやすい出力を強制することができます。

*ホスト、ポート、パスワードとデータベース

デフォルトでは、redis-cli は 127.0.0.1 ポート 6379 のサーバに接続します。ご想像の通り、コマンドライン オプションを使ってこれを簡単に変更することができます。異なるホスト名あるいはIPアドレスを指定するには、-hを使ってください。異なるポートを設定するには、-pを使ってください。

$ redis-cli -h redis15.localnet.org -p 6390 ping
PONG

インスタンスがパスワードで保護されている場合は、-a <password>オプションによってAUTH コマンドを明示的に使う必要無しに認証を行うことができます:

$ redis-cli -a myUnguessablePazzzzzword123 ping
PONG

または、REDISCLI_AUTH 環境変数を介して redis-cli にパスワードを指定することができます。

最後に、-n <dbnum> オプションを使ってデフォルトの数値 0 以外のデータベース番号に操作のコマンドを送信することができます:

$ redis-cli flushall
OK
$ redis-cli -n 1 incr a
(integer) 1
$ redis-cli -n 1 incr a
(integer) 2
$ redis-cli -n 2 incr a
(integer) 1

この情報の一部または全部は-u <uri> オプションおよび有効なURIを使って提供することもできます:

$ redis-cli -u redis://p%40ssw0rd@redis-16379.hosted.com:16379/0 ping
PONG

*SSL/TLS

デフォルトでは、redis-cli は Redis を制御するためにプレーンな TCP 接続を使います。--tls--cacert または --cacertdir を使って SSL/TLS を有効にし、信頼されたルート証明書バンドルまたはディレクトリを設定します。

目的のサーバでクライアント側の証明書を使った認証が必要な場合は、--cert--key を使って証明書と対応する秘密鍵を指定できます。

*他のプログラムからの入力を取得

他のコマンド(基本的に標準入力から)から入力を受け取るためにredis-cliを使うことができる2つの方法があります。1つはstdinから読み込んだペイロードの最後の引数として使うことです。例えば、Redisのキーに/etc/servicesファイルの内容を設定するには、私のコンピュータの場合、-x オプションを使うことができます:

$ redis-cli -x set foo < /etc/services
OK
$ redis-cli getrange foo 0 50
"#\n# Network services, Internet style\n#\n# Note that "

上のセッションの最初の行にあるように、SET コマンドの最後の引数は指定されていません。引数は単に実際の値を持たないSET fooで、キーに値を設定したいと思っています。

代わりに、-x オプションが指定され、ファイルはCLIの標準入力にリダイレクトされます。そのため、入力が読み込まれ、それがコマンドの最後の引数として使われます。これはスクリプトに役立ちます。

違うやり方は、テキストファイルに書かれた一連のコマンドをredis-cliにフィードすることです:

$ cat /tmp/commands.txt
set foo 100
incr foo
append foo xxx
get foo
$ cat /tmp/commands.txt | redis-cli
OK
(integer) 101
(integer) 6
"101xxx"

commands.txt内の全てのコマンドは、それらがユーザによって入力されたかのようにredis-cliによって次々に実行されます。必要であれば文字列はファイルの中で引用符で囲むことができます。そのため、1つの引数に空白あるいは改行あるいは他の特殊文字を含めることができます:

$ cat /tmp/commands.txt
set foo "This is a single argument"
strlen foo
$ cat /tmp/commands.txt | redis-cli
OK
(integer) 25

*同じコマンドの連続実行

実行の合間にユーザが指定した休止を持つ同じコマンドを指定回数実行することが可能です。これは様々な状況、例えば同じキーの内容あるいはINFO フィールドの出力を継続的に監視したい場合や、(新しい項目を5秒ごとにリストにプッシュするなど)繰り返し書き込みイベントをシミュレートしたい場合に役立ちます。

この機能は2つのオプションによって制御されます: -r <count>-i <delay>。1つ目はコマンドを実行する回数を指定し、2つ目は異なるコマンドの呼び出しの間の遅延を秒単位で指定します(100ミリ秒を意味するために0.1などのような10進数を指定する機能があります)。

デフォルトでは、間隔(あるいは遅延)は0に設定されるため、コマンドは単純に出来る限り早く実行されます:

$ redis-cli -r 5 incr foo
(integer) 1
(integer) 2
(integer) 3
(integer) 4
(integer) 5

同じコマンドを永遠に実行するには、カウントとして-1 を使います。そのため、RSSメモリサイズを時間の経過とともに監視するには、以下のようなコマンドを使うことができます:

$ redis-cli -r -1 -i 1 INFO | grep rss_human
used_memory_rss_human:1.38M
used_memory_rss_human:1.38M
used_memory_rss_human:1.38M
... a new line will be printed each second ...

*redis-cliを使った大量データの挿入

redis-cliを使った大量の挿入は、それ自体が価値のあるトピックのため、別のページで説明されます。大量の挿入のガイドを参照してください。

*CSV出力

Redisから外部プログラムに素早くデータをエクスポートするために、redis-cli を使いたいことがあります。これはCSV (カンマ区切りの値)出力機能を使って実現することができます:

$ redis-cli lpush mylist a b c d
(integer) 4
$ redis-cli --csv lrange mylist 0 -1
"d","c","b","a"

現在のところ、このようにDB全体をエクスポートすることはできませんが、CSV出力の1つのコマンドを実行することができます。

*Lua スクリプトの実行

redis-cliは、Redis 3.2以降で利用可能な、Luaスクリプトの新しいLuaデバッグ機能の利用のための徹底的なサポートをします。この機能については、Redis Lua デバッグ ドキュメントを参照してください。

ただし、デバッガを使わなくても、redis-cli を使って、シェルあるいは引数として対話的にスクリプトを入力するよりも快適な方法で、ファイルからスクリプトを実行することができます:

$ cat /tmp/script.lua
return redis.call('set',KEYS[1],ARGV[1])
$ redis-cli --eval /tmp/script.lua foo , bar
OK

RedisのEVAL コマンドはスクリプトが利用するキーのリストと、他の非キーの引数を異なる配列として取ります。EVALを呼び出す時は、キーの数を数値として指定します。ただし、redis-cliと上の--evalオプションを使う場合は、キーの数を明示的に指定する必要はありません。その代わりにキーと引数をカンマで区切るという規則を使います。上の呼び出しで引数としてfoo , bar があるのはそのためです。

そして、fooKEYS 配列を、barARGV 配列を生成します。

簡単なスクリプトを書く時には、--evalオプションが便利です。もっと複雑な作業のためには、Luaデバッガーを使うことが間違いなく快適です。デバッガーは外部ファイルからのスクリプトを実行することもできるため、2つの方法を組み合わせることが可能です。

*対話モード

これまで、Redis CLIをコマンドライン プログラムとして使う方法を探ってきました。これはスクリプトや特定の種類のテストに非常に役立ちますが、ほとんどの人は対話モードを利用してredis-cliで多くの時間を費やします。

対話モードでは、ユーザはプロンプトでRedisコマンドを入力します。コマンドはサーバに送信され、処理され、応答が解析されて読み易いように簡単に描画されます。

対話モードでCLIを実行するのに特別な事は何もありません - 引数無しで起動し、CLIに入ります:

$ redis-cli
127.0.0.1:6379> ping
PONG

文字列 127.0.0.1:6379> はプロンプトです。指定されたRedisインスタンスに接続していることを気付かせます。

接続しているサーバが変わるか、データベース番号0と異なるデータベース上で操作する時に、プロンプトが変わります:

127.0.0.1:6379> select 2
OK
127.0.0.1:6379[2]> dbsize
(integer) 1
127.0.0.1:6379[2]> select 0
OK
127.0.0.1:6379> dbsize
(integer) 503

*接続と再接続の処理

対話モードでconnectコマンドを使うことにより、接続したいhostnameport を指定することで、異なるインスタンスに接続することができます:

127.0.0.1:6379> connect metal 6379
metal:6379> ping
PONG

御覧の通り、プロンプトがそれに応じて変わります。ユーザが到達できないインスタンスに接続しようとすると、redis-cli は切断モードに入り、新しい各コマンドを使って再接続しようとします:

127.0.0.1:6379> connect 127.0.0.1 9999
Could not connect to Redis at 127.0.0.1:9999: Connection refused
not connected> ping
Could not connect to Redis at 127.0.0.1:9999: Connection refused
not connected> ping
Could not connect to Redis at 127.0.0.1:9999: Connection refused

通常切断が検出された後で、CLIは常に透過的に再接続を試みます: 試みが失敗した場合、エラーを表示し切断状態になります。以下は切断と再接続の例です:

127.0.0.1:6379> debug restart
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> ping
PONG
127.0.0.1:6379> (now we are connected again)

再接続が行われた場合、redis-cli は自動的に最後に選択されたデータベース番号を再選択します。しかし、接続に関するその他の全ての状態、もしトランザクジョンの途中だった場合にトランザクションの状態、は失われます:

$ redis-cli
127.0.0.1:6379> multi
OK
127.0.0.1:6379> ping
QUEUED

( here the server is manually restarted )

127.0.0.1:6379> exec
(error) ERR EXEC without MULTI

テストのために対話モードでCLIを使っている場合は、これは通常問題になりませんが、この制限に気を付ける必要があります。

*編集、履歴、補完、ヒント

redis-clilinenoise line editing libraryを使うため、libreadline あるいは他のオプションのライブラリに依存することなく、常に行編集機能を備えています。

実行したコマンドを繰り返し再入力することを防ぐために、矢印キーを(上と下)に押すことで、実行したコマンドの履歴にアクセスすることができます。履歴はCLIを再起動してもHOME環境変数で指定される、ホームディレクトリ内の.rediscli_history と呼ばれるファイル内に保持されます。REDISCLI_HISTFILE 環境変数を設定することで異なる履歴ファイルを使うことができ、それを/dev/nullに設定することで無効にすることができます。

CLIは以下の例のようにTABキーを押すことでコマンド名の補完を行うこともできます:

127.0.0.1:6379> Z<TAB>
127.0.0.1:6379> ZADD<TAB>
127.0.0.1:6379> ZCARD<TAB>

プロンプトで Redis コマンド名を入力すると、CLI は構文ヒントを表示します。この動作は、CLI プリファレンスを介してオンとオフを切り替えることができます。

*プリファレンス

CLI の動作をカスタマイズする方法は2つあります。ホームディレクトリ内のファイル .redisclirc は、起動時に CLI によってロードされます。プリファレンスは CLI セッション中に設定することもできます。その場合、プリファレンスはセッションの期間中のみ持続します。

プリファレンスを設定するには、特別な :set コマンドを使います。CLI でコマンドを入力するか、コマンドを .redisclirc ファイルに追加することで、以下の設定を行うことができます:

  • :set hints - 構文ヒントを有効にします
  • :set nohints - 構文ヒントを無効にします

*同じコマンドをN回実行

コマンド名の先頭に数字を付けることで、同じコマンドを複数回実行することができます:

127.0.0.1:6379> 5 incr mycounter
(integer) 1
(integer) 2
(integer) 3
(integer) 4
(integer) 5

*Redisコマンドに関するヘルプを表示

Redisにはたくさんのコマンドがあり、テストをする時に引数の正確な順番を思い出せないかもしれません。redis-clihelp コマンドを使ってほとんどのRedisコマンドについてのオンラインヘルプを提供します。コマンドは2つの形式で使うことができます:

  • help @<category>は指定されたカテゴリについての全てのコマンドを表示します。カテゴリは以下の通りです: @generic, @list, @set, @sorted_set, @hash, @pubsub, @transactions, @connection, @server, @scripting, @hyperloglog
  • help <commandname> は引数として渡されたコマンドについての特有のヘルプを表示します。

例えば、PFADD コマンドについてのヘルプを表示するには、以下を使います:

127.0.0.1:6379> help PFADD

PFADD key element [element ...] summary: Adds the specified elements to the specified HyperLogLog. 2.8.9から

help は TAB 補完もサポートすることに注意してください。

*端末画面をクリア

対話モードでclear コマンドを使うと端末画面をクリアします。

*操作の特別なモード

これまで、redis-cliの2つの主要なモードを見てきました。

  • Redisコマンドのコマンドラインの実行。
  • 対話的な "REPL-like" の使い方。

しかしCLIは次の章で説明されるRedisに関連するその他の補助的なタスクを実行します:

  • Redisサーバに関する継続的な統計を表示するための監視ツール。
  • 非常に大きなキーについてのRedisデータベースの走査。
  • パターンマッチングを使ったキー空間スキャナ。
  • チャネルを購読するためのPub/Sub クライアントとしての振る舞い。
  • Redisインスタンスで実行されたコマンドの監視。
  • 様々な方法でRedisサーバのレイテンシの調査。
  • ローカルコンピュータのスケジューラのレイテンシの調査。
  • リモートのRedisサーバからRDBバックアップをローカルに転送。
  • スレーブが受信したものを表示するためのRedisスレーブとしての振る舞い。
  • キー 日っとに関する統計を表示するためのLRU作業のシミュレート。
  • Luaデバッガー用のクライアント。

*連続的な統計モード

これはおそらくあまり知られていないredis-cliの機能の1つであり、Redisインスタンスをリアルタイムで監視するために非常に便利です。このモードを有効にするには、--stat オプションが使われます。このモードでのCLIの挙動についての出力は非常に明確です:

$ redis-cli --stat
------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections
506        1015.00K 1       0       24 (+0)             7
506        1015.00K 1       0       25 (+1)             7
506        3.40M    51      0       60461 (+60436)      57
506        3.40M    51      0       146425 (+85964)     107
507        3.40M    51      0       233844 (+87419)     157
507        3.40M    51      0       321715 (+87871)     207
508        3.40M    51      0       408642 (+86927)     257
508        3.40M    51      0       497038 (+88396)     257

このモードでは有用な情報と古いデータポイント間の違いと共に新しい行が毎秒出力されます。メモリ使用量、接続しているクライアントなど何が起きているかを簡単に理解できます。

この場合、-i <interval> オプションは新しい行が出力される頻度を変更するための修飾子として動作します。デフォルトは1秒です。

*翁キーについての走査

この特別なモードでは、redis-cli はキー空間のアナライザとして動作します。大きなキーがないかデータセットを走査しますが、データセットを構成するデータ型についての情報も提供します。このモードは--bigkeys オプションを使って有効にされ、非常に冗長な出力を生成します:

$ redis-cli --bigkeys

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).

[00.00%] Biggest string found so far 'key-419' with 3 bytes
[05.14%] Biggest list   found so far 'mylist' with 100004 items
[35.77%] Biggest string found so far 'counter:__rand_int__' with 6 bytes
[73.91%] Biggest hash   found so far 'myobject' with 3 fields

-------- summary -------

Sampled 506 keys in the keyspace!
Total key length in bytes is 3452 (avg len 6.82)

Biggest string found 'counter:__rand_int__' has 6 bytes
Biggest   list found 'mylist' has 100004 items
Biggest   hash found 'myobject' has 3 fields

504 strings with 1403 bytes (99.60% of keys, avg size 2.78)
1 lists with 100004 items (00.20% of keys, avg size 100004.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
1 hashs with 3 fields (00.20% of keys, avg size 3.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

出力の最初の行で、(同じ型の)以前の大きいキーより大きな新しい各キーが出力されます。要約のセクションはRedisインスタンス内のデータについての一般的な統計を提供します。

プログラムはSCAN コマンドを使うため、操作に影響を与えることなくビジー状態のサーバに対して実行できますが、要求された100個のキーごとに指定された秒数に走査処理を絞るために-i オプションを使うことができます。例えば、-i 0.1 はプログラムの実行をとても遅くしますが、サーバの負荷も極めて少なくするでしょう。

要約は各回ごとに見つかった最大のキーもより綺麗な形式で表示します。もし非常に大きなデータセットに対して実行する場合、初期出力はまさに何らかの興味深い情報をできるだけ早く提供します。

*キーのリストの取得

Redisサーバをブロックしない方法でキー空間を走査(ブロックはKEYS *のようなコマンドを使う時に起きます)、全てのキー名を出力、あるいは特定のパターンでそれらをフィルターすることができます。--bigkeys オプションのようなこのモードは、SCAN コマンドを使います。そのためもしデータセットが変更された場合はキーが複数回報告されるかもしれませんが、もしキーが繰り返しの開始時から存在している場合はキーは失われないでしょう。このオプションを使うコマンドのため、--scan と呼ばれます。

$ redis-cli --scan | head -10
key-419
key-71
key-236
key-50
key-38
key-458
key-453
key-499
key-446
key-371

出力の最初の行だけを出力するためにhead -10 が使われることに注意してください。

走査は--patternオプションを指定した SCAN コマンドの基礎となるパターンマッチング機能を使うことができます。

$ redis-cli --scan --pattern '*-11*'
key-114
key-117
key-118
key-113
key-115
key-112
key-119
key-11
key-111
key-110
key-116

wc コマンドを使って出力をパイプすると、キー名を使って特定の種類のオブジェクトを数えることができます:

$ redis-cli --scan --pattern 'user:*' | wc -l
3829433

*Pub/sub モード

CLIは単純にPUBLISH コマンドを使うことでRedisのPub/Subチャネルにメッセージを発行することができます。PUBLISH コマンドは他のコマンドととても似ているため、これは期待されるものです。メッセージを受信するためにチャネルを購読する事とは異なります - この場合、ブロックしてメッセージを待つ必要があるため、redis-cliでの特別なモードとして実装されます。他の特別なモードと異なり、このモードは特別なオプションを使っても有効になりませんが、対話的あるいは非対話的なモードの両方でSUBSCRIBE あるいは PSUBSCRIBE コマンドを単純に使うだけで有効になります:

$ redis-cli psubscribe '*'
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "*"
3) (integer) 1

reading messages メッセージは、Pub/Sub モードに入ったことを示しています。他のクライアントが何らかのチャネルでメッセージを発行する時、redis-cli PUBLISH mychannel mymessageを使ってできるように、Pub/SubモードのCLIは以下のようなメッセージを表示するでしょう:

1) "pmessage"
2) "*"
3) "mychannel"
4) "mymessage"

これはPub/Subの問題をデバッグするのにとても便利です。Pub/Subモードを抜けるには、単純にCTRL-Cを行います。

*Redis内で実行されるコマンドの監視

Pub/Sub モードに似ていて、一旦MONITOR モードを使うと自動的に監視モードに入ります。Redisインスタンスによって受け取られた全てのコマンドが出力されるでしょう:

$ redis-cli monitor
OK
1460100081.165665 [0 127.0.0.1:51706] "set" "foo" "bar"
1460100083.053365 [0 127.0.0.1:51707] "get" "foo"

出力をパイプすることが可能なため、grepのようなツールを使って特定のパターンを監視できることに注意してください。

*Redisインスタンスのレイテンシの監視

Redisはレイテンシが重要である状況でしばしば使われます。レイテンシには、クライアントライブラリからネットワークスタック、Redisインスタンス自身へのアプリケーション内での移動部分が含まれます。

CLIには、Redisインスタンスのレイテンシを調べたり、レイテンシの最大、平均および分布を理解するための複数の機能があります。

基本的なレイテンシのチェックツールは--latency オプションです。このオプションを使ってCLIはPINGコマンドがRedisインスタンスに送信されるループを実行し、応答を得られるまでの時間を計測します。これは秒間あたり100回行われ、統計がコンソール内にリアルタイムで更新されます:

$ redis-cli --latency
min: 0, max: 1, avg: 0.19 (427 samples)

統計はミリ秒単位で提供されます。通常、非常に高速なインスタンスの平均レイテンシは、redis-cli自体を実行しているシステムのカーネルスケジューラによるレイテンシのために、少し過大評価される傾向があります。そのため 0.19以上の平均レイテンシは容易に0.01以下になりえます。しかし、数ミリ秒以上のイベントに関心があるため、これは通常は大きな問題になりません。

時間の経過とともにレイテンシの最大および平均がどのように変化するのかを調べることが役に立つ場合があります。--latency-history オプションはそのような目的のために使われます: --latencyと全く同じように動作しますが、15秒ごと(デフォルト)に新しいサンプリング セッションが最初から開始されます:

$ redis-cli --latency-history
min: 0, max: 1, avg: 0.14 (1314 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.18 (1299 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.20 (113 samples)^C

-i <interval> オプションを使ってサンプリング セッションの長さを変更することができます。

最も先進的なレイテンシの調査ツールですが、経験が浅いユーザにとって解釈がやや困難な、カラー端末を使用してレイテンシのスペクトラムを表示することができます。サンプルの様々な割合を示す色付きの出力と、様々なレイテンシの形状を示す様々なアスキー文字を見ることができるでしょう。このモードは --latency-dist オプションを使って有効にされます:

$ redis-cli --latency-dist
(output not displayed, requires a color terminal, try it!)

redis-cli内で実装されたもう一つの非常に珍しいレイテンシ ツールがあります。それはRedisインスタンスのレイテンシをチェックしませんが、redis-cliを実行しているコンピュータのレイテンシをチェックします。どのようなレイテンシを求めていますか?カーネルスケジューラに固有のレンテンシ、仮想化インスタンスの場合のハイパーバイザー、など。

大部分はプログラマにとって不透明なため、それをintrinsic latency と呼びます。原因となりえる明確なもの全てに関係なくRedisインスタンスのレイテンシが悪い場合は、Redisサーバを実行しているシステム内で直接このモードでredis-cliを実行することで、システムが行うことができる最善のものをチェックすることには価値があります。

固有の待ち時間を計測することで、これが基準であり、Redisはシステムを上回ることができないことが分かります。このモードでCLIを実行するには、--intrinsic-latency <test-time>を使います。テストの時間は秒単位で、redis-cliが現在実行中のシステムのレイテンシをチェックする秒数を指定します。

$ ./redis-cli --intrinsic-latency 5
Max latency so far: 1 microseconds.
Max latency so far: 7 microseconds.
Max latency so far: 9 microseconds.
Max latency so far: 11 microseconds.
Max latency so far: 13 microseconds.
Max latency so far: 15 microseconds.
Max latency so far: 34 microseconds.
Max latency so far: 82 microseconds.
Max latency so far: 586 microseconds.
Max latency so far: 739 microseconds.

65433042 total runs (avg latency: 0.0764 microseconds / 764.14 nanoseconds per run).
Worst run took 9671x longer than the average latency.

重要: このコマンドはRedisサーバを実行するコンピュータ上で実行される必要があり、別のホストでは実行しないでください。Redisインスタンスに接続さえせず、ローカルでのみテストを実行します。

上記の場合、システムは最悪の場合のレイテンシを739マイクロ秒以下にすることができません。そのため、特定のクエリが時々1ミリ秒未満で実行されることを期待することができます。

*RDBファイルのリモートバックアップ

Redisのリプリケーションの最初の同期中に、マスターとスレーブはRDBファイルの形式でデータセット全体を交換します。この機能は、任意のRedisインスタンスからredis-cliを実行しているローカルコンピュータにRDBファイルを転送することを可能にするリモートバックアップ機能を提供するためにredis-cliによって利用されます。このモードを使用するには、--rdb <dest-filename> オプションを使ってCLIを呼び出します:

$ redis-cli --rdb /tmp/dump.rdb
SYNC sent to master, writing 13256 bytes to '/tmp/dump.rdb'
Transfer finished with success.

これは、Redisインスタンスのディザスタ リカバリ RDBバックアップがあることを確認するための、簡単だが効果的な方法です。しかし、このオプションをスクリプトあるいはcronジョブ内で使う場合は、コマンドの返り値を確認するようにしてください。非0の場合、以下の例のようにエラーが起こっています:

$ redis-cli --rdb /tmp/dump.rdb
SYNC with master failed: -ERR Can't SYNC while not connected with my master
$ echo $?
1

*スレーブ モード

CLIのスレーブ モードは、Redis開発者や操作のデバッグに役立つ高度な機能です。レプリカへの書き込みを伝播するためにレプリケーション ストリームの中でマスターが何をスレーブに送信したかを調べることができます。オプション名は単純に --slave です。どのように動作するか:

$ redis-cli --slave
SYNC with master, discarding 13256 bytes of bulk transfer...
SYNC done. Logging commands from master.
"PING"
"SELECT","0"
"set","foo","bar"
"PING"
"incr","mycounter"

コマンドは最初の同期のRDBファイルを破棄してから、受け取った各コマンドをCSV形式で記録します。

幾つかのコマンドがスレーブで正しくレプリケートされていないと思う場合は、これは何が起きているかを調べる良い方法であり、またバグ報告改善するのに役立つ情報です。

*LRUシミュレーションを実行

Redisは LRU 追い出しを使ってキャッシュとしてしばしば使われます。キーの数とキャッシュに割り当てられたメモリの量(maxmemoryディレクティブを使って指定されます)に依存して、キャッシュのヒットとミスの量は変わります。場合によってはヒット率をシミュレートすることはキャッシュを正しく配備するのに非常に役立ちます。

CLIには、要求パターンの80~20%の指数分布を使ってGETとSET操作のシミュレーションを行う特別なモードがあります。これはキーの20%が80%の回数をリクエストされることを意味します。これはキャッシュのシナリオでは一般的な分布です。

理論的には、リクエストの分布とRedisメモリのオーバーヘッドを考慮すると、数式を使用して分析的にヒット率を計算することができる筈です。しかし、Redisは異なるLRU設定(サンプル数)で構成することができ、Redisで近似されるLRUの実装は異なるバージョン間で大きく変わります。同様にキーごとのメモリ量もバージョン間で変わるかもしれません。このツールが作られたのはそのためです: 主な同期はRedisのLRU実装の品質をテストするためでしたが、今では配備のために念頭に置いた設定で指定されたバージョンがどのように振舞うかをテストするのに役立ちます。

このモードを使うには、テストでのキーの量を指定する必要があります。また最初の試行として意味のある maxmemory 設定を構成する必要があります。

重要な注意: Redis設定でのmaxmemory 設定の構成は非常に重要です: もし最大メモリ使用量の上限が無い場合、全てのキーがメモリ内に格納できるため、結果的に100%になるでしょう。あるいは、もしあまりに多くのキーを指定し、かつ最大メモリを指定しない場合は、結果的にコンピュータの全てのメモリが使われるでしょう。また適切な最大メモリ ポリシーを設定する必要があります。ほとんどの場合はallkeys-lruが望ましいです。

以下の例では、100MBのメモリ制限と1000万のキーを使うLRUシミュレーショを設定しました。

警告: テストはパイプラインを使用し、サーバに負荷がかかります。プロダクションのインスタンスでは使わないでください。

$ ./redis-cli --lru-test 10000000
156000 Gets/sec | Hits: 4552 (2.92%) | Misses: 151448 (97.08%)
153750 Gets/sec | Hits: 12906 (8.39%) | Misses: 140844 (91.61%)
159250 Gets/sec | Hits: 21811 (13.70%) | Misses: 137439 (86.30%)
151000 Gets/sec | Hits: 27615 (18.29%) | Misses: 123385 (81.71%)
145000 Gets/sec | Hits: 32791 (22.61%) | Misses: 112209 (77.39%)
157750 Gets/sec | Hits: 42178 (26.74%) | Misses: 115572 (73.26%)
154500 Gets/sec | Hits: 47418 (30.69%) | Misses: 107082 (69.31%)
151250 Gets/sec | Hits: 51636 (34.14%) | Misses: 99614 (65.86%)

プログラムは毎秒毎に統計を表示します。お分かりのように、最初の数秒でキャッシュが生成され始めます。ミス率は後で長い期間に良そうされる実際の数値に安定します:

120750 Gets/sec | Hits: 48774 (40.39%) | Misses: 71976 (59.61%)
122500 Gets/sec | Hits: 49052 (40.04%) | Misses: 73448 (59.96%)
127000 Gets/sec | Hits: 50870 (40.06%) | Misses: 76130 (59.94%)
124250 Gets/sec | Hits: 50147 (40.36%) | Misses: 74103 (59.64%)

59%のミス率はユースケースにとって受け入れられないかもしれません。ですので、100MBのメモリは十分では無いことが分かります。0.5ギガバイトで試してみましょう。数分後に、以下の図のように安定して出力が表示されます:

140000 Gets/sec | Hits: 135376 (96.70%) | Misses: 4624 (3.30%)
141250 Gets/sec | Hits: 136523 (96.65%) | Misses: 4727 (3.35%)
140250 Gets/sec | Hits: 135457 (96.58%) | Misses: 4793 (3.42%)
140500 Gets/sec | Hits: 135947 (96.76%) | Misses: 4553 (3.24%)

従って、500MBを使うと、キーの数(1000万)と分布(80-20の形式)に対して十分うまく行くことが分かります。

TOP
inserted by FC2 system