Redis慢速日志显示问题？

我对Redis很陌生，所以如果这个问题太基本，我会提前道歉

我在应用程序中的两个位置使用Redis

我使用两个redis键，并且只增加它们，但是这种情况经常发生，大约每秒10-20次

在一个完全不同的领域，我使用更复杂的集合和散列。实现需要数千项，但不是很频繁，一天几次，这里的延迟不太重要

这是1天后的慢速日志：

信息显示我有很多联系

redis_version:2.4.10
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.6
process_id:1769
uptime_in_seconds:190693
uptime_in_days:2
lru_clock:1725649
used_cpu_sys:386.48
used_cpu_user:200.63
used_cpu_sys_children:3.19
used_cpu_user_children:4.76
connected_clients:12
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:6551904
used_memory_human:6.25M
used_memory_rss:22675456
used_memory_peak:7991472
used_memory_peak_human:7.62M
mem_fragmentation_ratio:3.46
mem_allocator:jemalloc-2.2.5
loading:0
aof_enabled:0
changes_since_last_save:62
bgsave_in_progress:0
last_save_time:1464291307
bgrewriteaof_in_progress:0
total_connections_received:222528
total_commands_processed:2635087
expired_keys:29
evicted_keys:0
keyspace_hits:12056
keyspace_misses:1465
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:1309
vm_enabled:0
role:master
db0:keys=64,expires=2

我已经检查了代码，但我看不出我有这么多连接的原因。大多数使用都是从一个只实例化一次redis连接的文件中完成的。这个文件可能一天调用几千次

我试图理解我是否应该对此感到担忧，以及在实现过程中是否应该采取不同的措施

如果我把这两个部分放在不同的redis DB中，会有什么不同吗

根据我在slowlog中的理解，incr命令的延迟发生在HMSET（和INFO命令）期间。假设我需要处理>10K的项目集，有没有办法避免或最小化关键INCR命令的延迟

这些慢命令是否与大量连接有关

我害怕在应用程序的更多部分进一步使用redis，以防影响到已经在运行的部分的性能

---

任何关于我应该检查什么来进一步分析的建议都是非常受欢迎的

在回答之前，没有什么需要澄清的

• Redis是单线程的。即使你点击并行请求，它也会被一个接一个地处理。其他人将等待
• 增量命令并不繁重，除非 它正在等待执行或阻塞
• Hmset肯定有超过10K的物品，这将是阻塞

回答你的问题：

如果我把这两个部分放在不同的redis DB中，会有什么不同吗

不会的。这与场景中的负载无关

从我在慢语中的理解来看，增量中的延迟 命令在HMSET（和INFO命令）期间发生。假设 我需要处理超过10K的物品，有没有办法 避免或最小化关键INCR命令的延迟

延迟取决于系统中的负载。关键问题是在负载期间发生的问题。你不能控制那里

这些缓慢的命令是否与大量的 联系

仅带电连接的数量很重要。10个带电连接和100个带电连接（每个连接同时运行）之间存在差异

解决方案： HMSET命令是这里的瓶颈，因为它们是阻塞的。对于大于10K的元素，不使用HMSET，而是将它们拆分为100或数千的倍数。尝试不同的数字，找到一个最佳的，并修复该数字。同时升级到更高版本的redis，其性能将优于以前的版本

---

p、 s:Info命令在屏幕截图中花费1750秒，这似乎很不寻常

1）-不在同一进程内的不同DBs中，但当数据不相关时，可以启动第二个redis进程，以便它可以在另一个cpu内核上独立运行（假设大型HMSET也没有使用所有IO资源）。不完全是这样，但类似于感谢你的回答。你能解释一下你所说的“不是为>10K的元素使用HMSET，而是将它们分割成100或数千的倍数”是什么意思吗？我的意思是我有'elem:0'，'elem:1'，'elem:15K'，每个都是散列。我用它来构建一个有15K行的临时表。还有其他方法吗？我想到了在一个散列中包含10k个元素的hmset。如果以上是您保存15k行的情况。每行中有多少列。我是指单个散列中的键和值的数量？它是±10k行，大约10列（每个散列中有10个键和值）。值主要是整数，可能是小字符串。我实际上改变了设计，所以我不再需要这个临时桌子了。我这样问是为了了解将来该做什么。像这样的100K elements临时表是否会产生延迟问题？如果我在添加散列时故意延迟，它能改善slowlog问题吗？