5

由于我们网站上的大量负载增加，redis 现在正努力应对峰值负载，因为 redis 服务器实例达到 100% CPU（在八个内核之一上）导致超时。

我们已将客户端软件更新到 ServiceStack V3（来自 BookSleeve 1.1.0.4）并将 redis 服务器升级到 2.8.11（来自 2.4.x）。我之所以选择 ServiceStack，是因为存在使用 ServiceStack.Redis的Harbour.RedisSessionStateStore 。我们之前将 AngiesList.Redis 与 BookSleeve 一起使用，但我们也体验到了 100%。

我们有八个配置为主/从树的 redis 服务器。用于会话状态的单个服务器。其他用于数据缓存。一个主站有两个主站/从站，每个从站连接到两个从站。

当服务器以 100% 的 CPU 开始阻塞时，它们会在峰值时保持大约 600 个客户端连接。

我们可以做些什么来提高性能？

分片和/或 StackExchange Redis 客户端（据我所知，没有可用的会话状态客户端......）。

或者它可能是别的东西？会话服务器也达到 100%，并且没有连接到任何其他服务器（数据和网络吞吐量很低）。

更新一：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：twemproxy（分片）

我发现了一个有趣的组件，叫做twemproxy。据我了解，这个组件可以跨多个 redis 实例进行分片。

这会有助于减轻 CPU 的负担吗？

它会为我们节省大量的编程时间，但在每台服务器上配置 3 个额外的实例仍然需要一些努力。所以我希望有人能在我们投入工作之前确认或揭穿这个解决方案。

4

3 回答 3

3

首先要做的是查看slowlog get 50（或选择任意数量的行）——这显示了最后一个50花费大量时间的命令。可能是您正在做的某些事情花费的时间太长。如果我在里面看到任何东西，我会很担心slowlog——我通常每隔几天就会看到一些东西。如果您经常看到很多项目，那么：您需要调查您在服务器上实际执行的操作。永远不要做的一件致命的事情是，但还有其他事情。keys

接下来要做的是：缓存。在到达后端之前被短路的请求是免费的。我们广泛使用redis，但这并不意味着我们也忽略了本地内存。

于 2014-06-20T07:31:45.637 回答
3

我们在应用程序中发现了一个问题。我们缓存中的更新数据与本地内存缓存的通信是通过 redis 通道订阅实现的。

每次刷新本地缓存、项目过期或项目更新时，消息都会发送到所有 (35) 个网络服务器，这些服务器又开始更新更多项目等。

禁用更新密钥的消息将我们的情况改善了 10 倍。

网络带宽从 1.2 Gbps 下降到 200 Mbps，CPU 利用率为 40%，在极端计算和更新时刻我们目前的负载为 150%。

于 2014-06-24T09:08:43.217 回答
3

如果您还没有这样做，我的第一个简单建议是至少关闭 Master 上的所有 RDB 或 AOF 备份。当然，如果您的奴隶仍在保存到磁盘，他们可能会落后。有关RDB 转储成本的概念，请参阅此内容

另一件事是确保您正在流水线化所有命令。如果您要单独发送许多可以分组到管道中的命令，您应该会看到性能提升。

此外，这篇 SO 帖子对分析 Redis 有一个很好的答案

有关您的用例和数据结构的更多信息将有助于确定您是否可以对您实际使用 Redis 的方式进行简单的更改，从而为您带来改进。

编辑：为了回应您的最新评论，请注意，每次您的从属设备失去连接并重新连接时，它都会与主设备重新同步。在以前的 Redis 版本中，这总是完全重新同步，因此非常昂贵。显然，在 2.8 中，从站现在能够请求仅对由于断开连接而丢失的数据进行部分重新同步。我不太了解细节，但是如果您的主服务器或您的任何从服务器不在 2.8.* 上并且您的连接不稳定，那么通过不断强制您的主服务器重新同步，这可能会真正损害您的 CPU 性能奴隶。更多信息在这里

于 2014-06-19T23:12:36.013 回答