5

Web サイトの負荷が大幅に増加したため、redis サーバー インスタンスが (8 つのコアのうちの 1 つで) 100% の CPU に達し、タイムアウトが発生したため、redis は現在ピーク負荷に苦しんでいます。

クライアント ソフトウェアを ServiceStack V3 (BookSleeve 1.1.0.4 から) に更新し、redis サーバーを 2.8.11 (2.4.x から) にアップグレードしました。ServiceStack.Redis を使用するHarbour.RedisSessionStateStoreが存在するため、ServiceStack を選択しました。以前は BookSleeve と一緒に AngieList.Redis を使用していましたが、それでも 100% を経験しました。

マスター/スレーブ ツリーとして構成された 8 つの redis サーバーがあります。セッション状態のための1つのサーバー。その他はデータキャッシュ用です。それぞれ 2 つのスレーブに接続された 2 つのマスター/スレーブを持つ 1 つのマスター。

サーバーは、100% の CPU で詰まり始めるピーク時に約 600 のクライアント接続を保持します。

パフォーマンスを向上させるために何ができるでしょうか?

シャーディングおよび/または StackExchange Redis クライアント (私の知る限り、利用できるセッション状態クライアントはありません...)。

それとも他の何かでしょうか?セッション サーバーも 100% に達し、他のサーバーには接続されていません (データとネットワークのスループットが低い)。


更新 1: redis-cli INFO の分析

Redis 2.8 を一晩実行した後の INFO コマンドの出力を次に示します。

# Server
redis_version:2.8.11
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:7a57b118eb75b37f
redis_mode:standalone
os:Linux 2.6.32-431.11.2.el6.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.7
process_id:5843
run_id:d5bb838857d61a9673e36e5bf608fad5a588ac5c
tcp_port:6379
uptime_in_seconds:152778
uptime_in_days:1
hz:10
lru_clock:10765770
config_file:/etc/redis/6379.conf

# Clients
connected_clients:299
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

# Memory
used_memory:80266784
used_memory_human:76.55M
used_memory_rss:80719872
used_memory_peak:1079667208
used_memory_peak_human:1.01G
used_memory_lua:33792
mem_fragmentation_ratio:1.01
mem_allocator:jemalloc-3.2.0

# Persistence
loading:0
rdb_changes_since_last_save:70245
rdb_bgsave_in_progress:0
rdb_last_save_time:1403274022
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

# Stats
total_connections_received:3375
total_commands_processed:30975281
instantaneous_ops_per_sec:163
rejected_connections:0
sync_full:10
sync_partial_ok:0
sync_partial_err:5
expired_keys:8059370
evicted_keys:0
keyspace_hits:97513
keyspace_misses:46044
pubsub_channels:2
pubsub_patterns:0
latest_fork_usec:22040

# Replication
role:master
connected_slaves:2
slave0:ip=xxx.xxx.xxx.xxx,port=6379,state=online,offset=272643782764,lag=1
slave1:ip=xxx.xxx.xxx.xxx,port=6379,state=online,offset=272643784216,lag=1
master_repl_offset:272643811961
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:272642763386
repl_backlog_histlen:1048576

# CPU
used_cpu_sys:20774.19
used_cpu_user:2458.50
used_cpu_sys_children:304.17
used_cpu_user_children:1446.23

# Keyspace
db0:keys=77863,expires=77863,avg_ttl=3181732
db6:keys=11855,expires=11855,avg_ttl=3126767

更新 2: temproxy (シャーディング)

temproxyという興味深いコンポーネントを発見しました。このコンポーネントは、私が理解しているように、複数の redis インスタンスにまたがってシャードすることができます。

これは CPU の負担を軽減するのに役立ちますか?

プログラミング時間は大幅に節約できますが、各サーバーに 3 つの追加インスタンスを構成するには、まだ多少の労力が必要です。ですから、作業を開始する前に、誰かがこの解決策を確認または暴言を吐いてくれることを願っています.

4

3 に答える 3

3

最初に行うことは、確認する(または任意の数の行を選択する) ことです。これにより、重要な時間がかかっslowlog get 50た最後のコマンドが表示されます。50あなたがしていることのいくつかが単に時間がかかりすぎている可能性があります。何か入っていると心配ですslowlog。通常、数日おきにアイテムが表示されます。大量のアイテムが常に表示される場合は、サーバーで実際に何を行っているかを調査する必要があります。絶対にやってはいけない致命的なことは ですがkeys、他にもあります。

次に行うことは、キャッシュです。バックエンドに到達する前にショートサーキットされたリクエストは無料です。redis を広く使用していますが、ローカル メモリも無視しているわけではありません。

于 2014-06-20T07:31:45.637 に答える
3

アプリケーション内に問題が見つかりました。キャッシュ内の更新されたデータに関するローカル メモリ キャッシュへの通信は、redis チャネルのサブスクリプションを通じて実現されました。

ローカル キャッシュがフラッシュされるたびに、アイテムの有効期限が切れたり、アイテムが更新されたりするたびに、メッセージがすべて (35) の Web サーバーに送信され、さらに多くのアイテムの更新が開始されました。

更新されたキーのメッセージを無効にすると、状況が 10 倍改善されました。

ネットワーク帯域幅は 1.2 Gbps から 200 Mbps に低下し、CPU 使用率は、これまでの負荷の 150% で 40% であり、極端な計算と更新の瞬間です。

于 2014-06-24T09:08:43.217 に答える