Из-за значительного увеличения нагрузки на нашем сайте redis теперь борется с пиковой нагрузкой, потому что экземпляр сервера redis достигает 100% CPU (на одном из восьми ядер), что приводит к тайм-аутам.

Мы обновили наше клиентское программное обеспечение до ServiceStack V3 (начиная с BookSleeve 1.1.0.4) и обновили сервер redis до 2.8.11 (начиная с 2.4.x). Я выбрал ServiceStack из-за существованияHarbour.RedisSessionStateStore который использует ServiceStack.Redis. Ранее мы использовали AngiesList.Redis вместе с BookSleeve, но с этим мы также столкнулись на 100%.

У нас есть восемь серверов Redis, настроенных как главное / подчиненное дерево. Один единственный сервер для состояния сеанса tho. Остальные для кеша данных. Один мастер с двумя ведущими / подчиненными, подключенными к двум подчиненным.

Серверы поддерживают около 600 клиентских подключений в пике, когда они начинают засоряться на 100% ЦП.

Что мы можем сделать, чтобы увеличить производительность?

Sharding и / или StackExchange Redis клиент (клиент состояния сеанса, насколько мне известно ...).

Или это может быть что-то еще? Сервер сеансов также достигает 100% и не подключен ни к каким другим серверам (пропускная способность данных и сети низкая).

Обновление 1: анализ redis-cli INFO

Вот вывод команды INFO после одной ночи запуска Redis 2.8.

# 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 (Sharding)

Я обнаружил интересный компонент под названиемtwemproxy, Этот компонент, насколько я понимаю, может использовать Shard для нескольких экземпляров Redis.

Поможет ли это уменьшить нагрузку на процессор?

Это сэкономило бы нам много времени на программирование, но все же потребовалось бы некоторое усилие для настройки 3 дополнительных экземпляров на каждом сервере. Поэтому я надеюсь, что кто-нибудь может подтвердить или опровергнуть это решение, прежде чем мы начнем работу.