2026/9/3 6:04:15
FEATURED · 精选文章 
客户现场有一套基于 TongRDS 2216 的缓存服务运行一段时间后会反复出现连接超时。第一次出现问题时调整配置后服务恢复过了一段时间问题再次出现。第二次同样通过调整参数暂时恢复但没过多久又复发。问题的现象是上层应用大量出现 Redis 连接超时TongRDS 本机也无法正常建立连接最后 TongRDS 进程完全失去响应连jstack都无法正常获取线程栈。这次排查持续了一段时间中间也尝试过一些参数调整。最后通过应用日志 → 本机连接测试 → fd 检查 → JVM 诊断 → 历史问题复盘 → 版本确认最终定位到 2216 版本的问题并通过升级到 2219 解决。下面记录一下整个排查过程。故障现象上层应用大量连接超时最开始是客户反馈业务出现异常。查看console-service日志可以看到大量类似报错redis init failed: dial tcp 10.*.*.*:6379: i/o timeout TaskManager init msg!Dequeue error: UNKNOWN: redis eval error: dial tcp 10.*.*.*:6379: i/o timeoutdial tcp 10.*.*.*:6379: i/o timeout以及redis eval error从日志来看不只是某一个 Redis 操作失败初始化、eval等操作都出现了连接超时。而10.*.*.*:6379正是 TongRDS 服务地址所以第一步需要确认到底是网络问题还是 TongRDS 本身已经无法正常处理连接。先从服务器本机测试为了排除网络链路问题我们直接登录 TongRDS 所在服务器进行测试。进入客户端脚本目录cd /opt/RDS/console/apps/node/bin执行sh Client.sh结果发现本机连接localhost:6379同样失败Error occur when connect to localhost:6379 : connect timed out这个结果非常关键。如果只是业务服务器连接不上 TongRDS可以继续从网络、路由、防火墙等方向排查。但现在连 TongRDS 所在服务器本机访问localhost:6379都出现connect timed out说明问题已经不只是业务侧网络。接下来重点就应该放到TongRDS 进程本身以及服务器资源上。是不是文件描述符耗尽遇到“连接超时 服务逐渐失去响应”我们首先想到的是文件描述符fd问题。因为 Redis/TongRDS 会维护大量网络连接如果 fd 被持续占用达到上限后新连接就无法正常建立。4.1 先看系统整体 fd先查看系统层面的文件描述符使用情况cat /proc/sys/fs/file-nr为了持续观察我们又写了一个简单脚本while true do echo $(date %Y-%m-%d %H:%M:%S) fd_count$(cat /proc/sys/fs/file-nr | awk {print $1}) sleep 10 done运行一段时间后结果基本稳定在 200 左右2026-08-18 17:58:50 fd_count210 2026-08-18 17:59:00 fd_count209 2026-08-18 17:59:10 fd_count203 2026-08-18 17:59:20 fd_count210 2026-08-18 17:59:30 fd_count210从系统整体来看并没有明显的 fd 耗尽现象。但这里很容易产生一个误区系统整体 fd 正常不代表某一个进程的 fd 正常。所以继续往 TongRDS 进程本身看。4.2 再看 TongRDS 进程的 fd先找到 TongRDS 对应的 PIDPID2196845然后监控该进程PID2196845 while true do echo $(date %Y-%m-%d %H:%M:%S) fd_count$(ls /proc/$PID/fd | wc -l) sleep 10 done这次结果完全不一样2026-08-18 16:52:59 fd_count655360 2026-08-18 16:53:11 fd_count655360 2026-08-18 16:53:23 fd_count655360 2026-08-18 16:53:35 fd_count655360后面持续监控基本一直保持在655360这个数字非常值得关注。继续检查进程的文件描述符限制cat /proc/2196845/limits | grep open files如果看到Max open files 655360那么就可以确认TongRDS 进程当前 fd 数量已经达到它的Max open files上限。这时候就能很好地解释为什么新的 Redis 连接无法建立。JVM 到底发生了什么确认进程 fd 已经达到上限之后我们继续往 JVM 内部排查。正常情况下可以通过jstack查看 Java 进程线程状态。执行jstack 2196845 thread_dump.txt结果却直接报错2196845: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding这个结果说明当前 JVM 已经无法正常响应jstack的 attach 请求。可以再尝试jstack -F 2196845 thread_dump.txt如果仍然无法获取有效线程信息就说明当前进程已经处于非常异常的状态猜测Java 进程已经僵死、挂起JVM HotSpot 没有正常初始化 / 已经崩溃。这里有一个经验需要特别注意JVM 出现问题时不要等到进程彻底卡死以后再抓 jstack。如果发现接口开始变慢、连接数异常、fd 持续增长应该趁 JVM 还能够响应的时候及时执行jstack $PID thread_dump.txt必要时同时保留 heap dump 等现场信息。等 JVM 完全卡住以后很多诊断工具也可能无法正常使用。重新复盘前几次故障到这里我们开始重新看前两次问题。因为前两次调整参数后服务都恢复了这些操作可能隐藏着一些规律。第一次出现问题时调整了tables参数tables15 → 2调整之后服务恢复。tables 参数控制 TongRDS 节点可同时打开的数据表最大数量调小可减少多表带来的锁竞争与内存开销降低 CPU 负载。第二次出现问题时又调整了byte相关参数byte100 → 200调整之后服务再次恢复。bytes2 参数用于设置数据表主键 key 允许的最大字节长度调大可避免业务超长 key 触发内部异常逻辑、减少内存碎片。当时看起来像是找到了问题。但问题在于过几天之后故障又回来了。如果一个配置修改是真正解决了根因通常不会出现“过几天再次出现相同问题”的情况。所以这时候需要换一个思路前两次修改参数可能只是降低了资源压力让问题暂时没有那么快暴露出来并不一定真正解决了问题。IdleTimeout 能不能解决第三次故障之前又尝试增加IdleTimeout3600/IdleTimeout希望通过回收空闲连接来降低连接资源占用。但实际运行几天以后问题还是再次出现。这也说明单纯依靠IdleTimeout并没有解决问题。这里需要注意IdleTimeout主要针对的是空闲连接。如果问题涉及的是资源没有正常释放或者某些连接长期处于使用状态那么单纯增加空闲连接回收机制并不一定能够解决。把几个现象串起来到了这里已经有几个比较明确的证据上层应用 ↓ Redis 连接超时 ↓ TongRDS 本机 localhost:6379 也连接超时 ↓ TongRDS 进程 fd 达到 655360 ↓ 655360 与 Max open files 上限一致 ↓ JVM 无法正常响应 jstack再结合前几次tables 调整后恢复 ↓ 过一段时间再次出现 byte 调整后恢复 ↓ 过一段时间再次出现 增加 IdleTimeout ↓ 问题仍然复发基本可以判断这已经不是简单的网络抖动也不像单纯把某一个参数调大或者调小就能解决的问题。更值得怀疑的是2216 版本在特定场景下存在资源释放异常最终导致 TongRDS 进程的 fd 持续增长达到进程上限后无法继续建立连接。至于具体是哪个内部资源没有释放仅凭现场这些信息无法进一步确定需要结合产品源码、内部日志或者厂商对该版本问题的确认。最终解决升级 TongRDS 版本TongRDS 2216 版本存在客户端连接池缺陷相关问题等后续版本已经进行了修复。因此没有继续在原版本上反复调整参数而是直接升级 TongRDS。最终升级TongRDS 2216 ↓ TongRDS 2219升级完成后重新进行业务验证。同时继续观察进程 fdls /proc/$PID/fd | wc -l升级后 fd 数量保持在正常范围并且随着连接建立、释放出现正常波动没有再次出现655360 655360 655360 ...这样的异常状态。业务侧也没有再出现i/o timeout以及 JVM 完全失去响应的问题。这次排查最大的几个经验1. 系统资源正常不代表应用进程正常最开始看到系统 fd 只有两百左右很容易认为 fd 没问题。实际上系统 fd ↓ 正常 TongRDS 进程 fd ↓ 655360所以排查长时间运行的 Java 服务时不能只看系统层面的资源。可以直接检查ls /proc/$PID/fd | wc -l以及cat /proc/$PID/limits | grep open files两者结合起来看更容易发现问题。2. 本机都连不上就不要一直盯着网络查业务服务器连接10.*.*.*:6379超时。第一反应很容易去检查网络 防火墙 路由 安全组但如果登录 TongRDS 所在服务器后localhost:6379同样连接超时那么排查重点就应该转向 TongRDS 自身。这一点在实际排障中非常重要可以减少很多无效排查。3. 参数调整后恢复不代表根因已经解决这次前两次都属于典型的“改完参数就恢复”。但过几天又复发。所以以后遇到这种情况不要只记录改了什么参数 ↓ 服务恢复还应该继续观察为什么这个参数改完可以恢复 恢复以后是否还会复发 资源使用是否继续增长如果问题只是被延后而不是彻底消失就要继续往根因查。4. JVM 诊断信息一定要提前留如果发现 Java 服务已经出现连接大量超时 接口响应变慢 CPU 异常 内存异常 fd 持续增长不要等服务彻底挂死。可以提前执行jstack $PID thread_dump.txt必要时根据现场情况保留jstack heap dump GC 日志 进程 fd 线程数量 CPU 内存 网络连接因为一旦 JVM 完全失去响应很多诊断手段都会失效。以后遇到类似问题可以按照这个顺序排查应用报 Redis 连接超时 ↓ 确认 Redis/TongRDS 服务地址 ↓ 业务服务器测试连接 ↓ 登录 TongRDS 服务器 ↓ 本机 localhost 测试 ↓ 本机也连接不上 ↓ 检查系统 CPU / 内存 / fd ↓ 检查 TongRDS 进程 fd ↓ 检查 Max open files ↓ fd 是否持续增长或达到上限 ↓ JVM 是否还能响应 ↓ 及时抓取 jstack / heap dump ↓ 复盘历史配置修改 ↓ 确认是否存在版本已知问题 ↓ 联系厂商确认 ↓ 必要时升级版本关键命令汇总查看系统 fdcat /proc/sys/fs/file-nr查看指定进程 fdls /proc/$PID/fd | wc -l查看进程 fd 上限cat /proc/$PID/limits | grep open files持续监控进程 fdPID2196845 while true do echo $(date %Y-%m-%d %H:%M:%S) fd_count$(ls /proc/$PID/fd | wc -l) sleep 10 done获取 JVM 线程栈jstack $PID thread_dump.txtJVM 无法响应时尝试jstack -F $PID thread_dump.txt最后这次排查最大的收获不是记住了某一个参数而是以后再遇到类似问题可以换一个思路。连接超时不一定是网络问题系统资源正常也不代表具体进程正常参数调整后恢复更不代表根因已经解决。从应用日志开始一步一步缩小范围最后落到具体进程和具体资源上很多看起来很复杂的问题其实都会慢慢变得清楚。
【TongRDS】2216 连接超时、进程假死问题排查记录
客户现场有一套基于 TongRDS 2216 的缓存服务运行一段时间后会反复出现连接超时。第一次出现问题时调整配置后服务恢复过了一段时间问题再次出现。第二次同样通过调整参数暂时恢复但没过多久又复发。问题的现象是上层应用大量出现 Redis 连接超时TongRDS 本机也无法正常建立连接最后 TongRDS 进程完全失去响应连jstack都无法正常获取线程栈。这次排查持续了一段时间中间也尝试过一些参数调整。最后通过应用日志 → 本机连接测试 → fd 检查 → JVM 诊断 → 历史问题复盘 → 版本确认最终定位到 2216 版本的问题并通过升级到 2219 解决。下面记录一下整个排查过程。故障现象上层应用大量连接超时最开始是客户反馈业务出现异常。查看console-service日志可以看到大量类似报错redis init failed: dial tcp 10.*.*.*:6379: i/o timeout TaskManager init msg!Dequeue error: UNKNOWN: redis eval error: dial tcp 10.*.*.*:6379: i/o timeoutdial tcp 10.*.*.*:6379: i/o timeout以及redis eval error从日志来看不只是某一个 Redis 操作失败初始化、eval等操作都出现了连接超时。而10.*.*.*:6379正是 TongRDS 服务地址所以第一步需要确认到底是网络问题还是 TongRDS 本身已经无法正常处理连接。先从服务器本机测试为了排除网络链路问题我们直接登录 TongRDS 所在服务器进行测试。进入客户端脚本目录cd /opt/RDS/console/apps/node/bin执行sh Client.sh结果发现本机连接localhost:6379同样失败Error occur when connect to localhost:6379 : connect timed out这个结果非常关键。如果只是业务服务器连接不上 TongRDS可以继续从网络、路由、防火墙等方向排查。但现在连 TongRDS 所在服务器本机访问localhost:6379都出现connect timed out说明问题已经不只是业务侧网络。接下来重点就应该放到TongRDS 进程本身以及服务器资源上。是不是文件描述符耗尽遇到“连接超时 服务逐渐失去响应”我们首先想到的是文件描述符fd问题。因为 Redis/TongRDS 会维护大量网络连接如果 fd 被持续占用达到上限后新连接就无法正常建立。4.1 先看系统整体 fd先查看系统层面的文件描述符使用情况cat /proc/sys/fs/file-nr为了持续观察我们又写了一个简单脚本while true do echo $(date %Y-%m-%d %H:%M:%S) fd_count$(cat /proc/sys/fs/file-nr | awk {print $1}) sleep 10 done运行一段时间后结果基本稳定在 200 左右2026-08-18 17:58:50 fd_count210 2026-08-18 17:59:00 fd_count209 2026-08-18 17:59:10 fd_count203 2026-08-18 17:59:20 fd_count210 2026-08-18 17:59:30 fd_count210从系统整体来看并没有明显的 fd 耗尽现象。但这里很容易产生一个误区系统整体 fd 正常不代表某一个进程的 fd 正常。所以继续往 TongRDS 进程本身看。4.2 再看 TongRDS 进程的 fd先找到 TongRDS 对应的 PIDPID2196845然后监控该进程PID2196845 while true do echo $(date %Y-%m-%d %H:%M:%S) fd_count$(ls /proc/$PID/fd | wc -l) sleep 10 done这次结果完全不一样2026-08-18 16:52:59 fd_count655360 2026-08-18 16:53:11 fd_count655360 2026-08-18 16:53:23 fd_count655360 2026-08-18 16:53:35 fd_count655360后面持续监控基本一直保持在655360这个数字非常值得关注。继续检查进程的文件描述符限制cat /proc/2196845/limits | grep open files如果看到Max open files 655360那么就可以确认TongRDS 进程当前 fd 数量已经达到它的Max open files上限。这时候就能很好地解释为什么新的 Redis 连接无法建立。JVM 到底发生了什么确认进程 fd 已经达到上限之后我们继续往 JVM 内部排查。正常情况下可以通过jstack查看 Java 进程线程状态。执行jstack 2196845 thread_dump.txt结果却直接报错2196845: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding这个结果说明当前 JVM 已经无法正常响应jstack的 attach 请求。可以再尝试jstack -F 2196845 thread_dump.txt如果仍然无法获取有效线程信息就说明当前进程已经处于非常异常的状态猜测Java 进程已经僵死、挂起JVM HotSpot 没有正常初始化 / 已经崩溃。这里有一个经验需要特别注意JVM 出现问题时不要等到进程彻底卡死以后再抓 jstack。如果发现接口开始变慢、连接数异常、fd 持续增长应该趁 JVM 还能够响应的时候及时执行jstack $PID thread_dump.txt必要时同时保留 heap dump 等现场信息。等 JVM 完全卡住以后很多诊断工具也可能无法正常使用。重新复盘前几次故障到这里我们开始重新看前两次问题。因为前两次调整参数后服务都恢复了这些操作可能隐藏着一些规律。第一次出现问题时调整了tables参数tables15 → 2调整之后服务恢复。tables 参数控制 TongRDS 节点可同时打开的数据表最大数量调小可减少多表带来的锁竞争与内存开销降低 CPU 负载。第二次出现问题时又调整了byte相关参数byte100 → 200调整之后服务再次恢复。bytes2 参数用于设置数据表主键 key 允许的最大字节长度调大可避免业务超长 key 触发内部异常逻辑、减少内存碎片。当时看起来像是找到了问题。但问题在于过几天之后故障又回来了。如果一个配置修改是真正解决了根因通常不会出现“过几天再次出现相同问题”的情况。所以这时候需要换一个思路前两次修改参数可能只是降低了资源压力让问题暂时没有那么快暴露出来并不一定真正解决了问题。IdleTimeout 能不能解决第三次故障之前又尝试增加IdleTimeout3600/IdleTimeout希望通过回收空闲连接来降低连接资源占用。但实际运行几天以后问题还是再次出现。这也说明单纯依靠IdleTimeout并没有解决问题。这里需要注意IdleTimeout主要针对的是空闲连接。如果问题涉及的是资源没有正常释放或者某些连接长期处于使用状态那么单纯增加空闲连接回收机制并不一定能够解决。把几个现象串起来到了这里已经有几个比较明确的证据上层应用 ↓ Redis 连接超时 ↓ TongRDS 本机 localhost:6379 也连接超时 ↓ TongRDS 进程 fd 达到 655360 ↓ 655360 与 Max open files 上限一致 ↓ JVM 无法正常响应 jstack再结合前几次tables 调整后恢复 ↓ 过一段时间再次出现 byte 调整后恢复 ↓ 过一段时间再次出现 增加 IdleTimeout ↓ 问题仍然复发基本可以判断这已经不是简单的网络抖动也不像单纯把某一个参数调大或者调小就能解决的问题。更值得怀疑的是2216 版本在特定场景下存在资源释放异常最终导致 TongRDS 进程的 fd 持续增长达到进程上限后无法继续建立连接。至于具体是哪个内部资源没有释放仅凭现场这些信息无法进一步确定需要结合产品源码、内部日志或者厂商对该版本问题的确认。最终解决升级 TongRDS 版本TongRDS 2216 版本存在客户端连接池缺陷相关问题等后续版本已经进行了修复。因此没有继续在原版本上反复调整参数而是直接升级 TongRDS。最终升级TongRDS 2216 ↓ TongRDS 2219升级完成后重新进行业务验证。同时继续观察进程 fdls /proc/$PID/fd | wc -l升级后 fd 数量保持在正常范围并且随着连接建立、释放出现正常波动没有再次出现655360 655360 655360 ...这样的异常状态。业务侧也没有再出现i/o timeout以及 JVM 完全失去响应的问题。这次排查最大的几个经验1. 系统资源正常不代表应用进程正常最开始看到系统 fd 只有两百左右很容易认为 fd 没问题。实际上系统 fd ↓ 正常 TongRDS 进程 fd ↓ 655360所以排查长时间运行的 Java 服务时不能只看系统层面的资源。可以直接检查ls /proc/$PID/fd | wc -l以及cat /proc/$PID/limits | grep open files两者结合起来看更容易发现问题。2. 本机都连不上就不要一直盯着网络查业务服务器连接10.*.*.*:6379超时。第一反应很容易去检查网络 防火墙 路由 安全组但如果登录 TongRDS 所在服务器后localhost:6379同样连接超时那么排查重点就应该转向 TongRDS 自身。这一点在实际排障中非常重要可以减少很多无效排查。3. 参数调整后恢复不代表根因已经解决这次前两次都属于典型的“改完参数就恢复”。但过几天又复发。所以以后遇到这种情况不要只记录改了什么参数 ↓ 服务恢复还应该继续观察为什么这个参数改完可以恢复 恢复以后是否还会复发 资源使用是否继续增长如果问题只是被延后而不是彻底消失就要继续往根因查。4. JVM 诊断信息一定要提前留如果发现 Java 服务已经出现连接大量超时 接口响应变慢 CPU 异常 内存异常 fd 持续增长不要等服务彻底挂死。可以提前执行jstack $PID thread_dump.txt必要时根据现场情况保留jstack heap dump GC 日志 进程 fd 线程数量 CPU 内存 网络连接因为一旦 JVM 完全失去响应很多诊断手段都会失效。以后遇到类似问题可以按照这个顺序排查应用报 Redis 连接超时 ↓ 确认 Redis/TongRDS 服务地址 ↓ 业务服务器测试连接 ↓ 登录 TongRDS 服务器 ↓ 本机 localhost 测试 ↓ 本机也连接不上 ↓ 检查系统 CPU / 内存 / fd ↓ 检查 TongRDS 进程 fd ↓ 检查 Max open files ↓ fd 是否持续增长或达到上限 ↓ JVM 是否还能响应 ↓ 及时抓取 jstack / heap dump ↓ 复盘历史配置修改 ↓ 确认是否存在版本已知问题 ↓ 联系厂商确认 ↓ 必要时升级版本关键命令汇总查看系统 fdcat /proc/sys/fs/file-nr查看指定进程 fdls /proc/$PID/fd | wc -l查看进程 fd 上限cat /proc/$PID/limits | grep open files持续监控进程 fdPID2196845 while true do echo $(date %Y-%m-%d %H:%M:%S) fd_count$(ls /proc/$PID/fd | wc -l) sleep 10 done获取 JVM 线程栈jstack $PID thread_dump.txtJVM 无法响应时尝试jstack -F $PID thread_dump.txt最后这次排查最大的收获不是记住了某一个参数而是以后再遇到类似问题可以换一个思路。连接超时不一定是网络问题系统资源正常也不代表具体进程正常参数调整后恢复更不代表根因已经解决。从应用日志开始一步一步缩小范围最后落到具体进程和具体资源上很多看起来很复杂的问题其实都会慢慢变得清楚。 
算法实现与误差优化)
