由于我们网站上的大量负载增加,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%,并且未连接到任何其他服务器(数据和网络吞吐量很低)。
更新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:twemproxy(共享)
我发现了一个有趣的组件twemproxy。据我了解,该组件可以跨多个Redis实例进行分片。
这样有助于减轻CPU负担吗?
这将为我们节省大量编程时间,但仍需要花费一些精力在每台服务器上配置3个额外的实例。因此,我希望有人在我们投入工作之前可以确认或揭穿该解决方案。
我们在应用程序内部发现了一个问题。有关缓存中已更新数据到本地内存缓存的通信是通过redis通道订阅实现的。
每次刷新本地缓存,项目过期或项目已更新时,都会将消息发送到所有(35)个Web服务器,依次开始更新更多项目等。
禁用更新密钥的消息使我们的情况提高了10倍。
网络带宽从1.2 Gbps下降到200Mbps,在极端计算和更新的时刻,我们的负载为150%时,CPU利用率为40%。