Из-за значительного увеличения нагрузки на наш веб-сайт Redis теперь борется с пиковой нагрузкой, поскольку экземпляр сервера Redis достигает 100% загрузки ЦП (на одном из восьми ядер), что приводит к тайм-аутам.
Мы обновили наше клиентское программное обеспечение до ServiceStack V3 (из BookSleeve 1.1.0.4) и обновили сервер Redis до 2.8.11 (из 2.4.x). Я выбрал ServiceStack из-за существования Harbour.RedisSessionStateStore, в котором используется ServiceStack.Redis. Раньше мы использовали AngiesList.Redis вместе с BookSleeve, но и с ним мы испытали 100 %.
У нас есть восемь серверов Redis, настроенных как главное/подчиненное дерево. Один единственный сервер для состояния сеанса. Остальные предназначены для кеша данных. Один ведущий с двумя ведущими/ведомыми, подключенными к двум ведомым устройствам каждый.
Серверы удерживают около 600 клиентских подключений на пике, когда они начинают забиваться при 100% загрузке процессора.
Что мы можем сделать, чтобы повысить производительность?
Клиент Sharding и/или StackExchange Redis (насколько мне известно, клиент состояния сеанса не доступен...).
Или это может быть что-то другое? Сеансовый сервер также работает на 100% и не подключен ни к каким другим серверам (пропускная способность данных и сети низкая).
Обновление 1: анализ ИНФОРМАЦИИ redis-cli
Вот вывод команды 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 (шардинг)
Я обнаружил интересный компонент под названием twemproxy. Этот компонент, насколько я понимаю, может шардить по нескольким экземплярам Redis.
Поможет ли это разгрузить процессор?
Это сэкономило бы нам много времени на программирование, но все же потребовало бы некоторых усилий для настройки 3 дополнительных экземпляров на каждом сервере. Поэтому я надеюсь, что кто-нибудь сможет подтвердить или опровергнуть это решение до того, как мы приступим к работе.
