某业务系统由于连接数限制导致间歇性访问慢故障分析案例

本文详细分析了一个由服务器连接数限制引发的应用间歇性缓慢故障案例,从网络拓扑、故障现象、分析过程到最终解决方法,全面展示了如何通过数据包捕获和故障定位技巧,深入理解并解决此类问题。故障表现为部分内部办公主机在访问特定业务系统时出现打开主页慢、登录慢或页面不显示的情况,间歇性出现且多次刷新后可恢复正常。通过分析发现,服务器对特定源端口的TCP连接请求进行了管理性禁止,导致连接建立尝试时间延长,引起访问缓慢。文章最终通过修改服务器设置解决了这一问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

文章出处:http://www.vants.org/?post=125


【说在之前】:

1,该案例为端系统设置连接数限制导致的应用间歇性缓慢故障,在实际工作环境下,我们更容易遇到的是中间系统对连接数限制导致的一些访问异常,令人头疼的是,并不是所有开启连接数限制功能的中间系统在丢包后都会向源主机发送ICMP差错报文,这会给大家分析定位带来难度,大家在实际工作中需要留意;

2,该案例涉及到的知识点主要为“ICMP主机管理性禁止差错报文”和“连接数限制”,关于ICMP主机管理性禁止差错报文,大家可参考本博客《ICMP通讯管理性过滤禁止差错报文(type 3,code 13)》一文,虽然“type 3,code 10”与“type3,code 13”有些差异,但是差别不大,可以借鉴;关于连接数相关知识点,大家可参考本博客《连接数相关知识》一文;

【我的案例】:

1 故障环境

网络拓扑:


说明:
1,内部办公机器都是192.168.1.0/24段的,内部办公主机通过防火墙做NAT,转换为X.X.X.138访问互联网;
2,内部办公服务器的地址为192.168.1.191,其通过防火墙映射为公网地址X.X.X.139对外提供6888端口的web服务。
业务访问流程:
       内部办公机器都是通过NAT后的公网地址X.X.X.138访问办公服务器的公网地址X.X.X.139。其流程如下图所示: 


2 故障现象

       故障现象主要表现为:
1,部分内网办公主机经常出现打开主页慢、登录慢或者某些页面不显示的情况,如下图所示: 


                                  打开主页时的长时间等待页面截图 


                                     登录时长时间等待页面截图

2,这些故障现象间歇性出现,有时多刷新几次页面后,打开的速度会恢复正常。
3,外网用户访问业务系统一直正常,该故障已经持续数月。

3 故障分析

       通过故障现象,我们可以看出,这是比较典型的部分系统出现问题的案例,由于其不具备全体的故障特征,又是间歇性的发生,因此,此类故障按照常规的分析方法很难找到真正的故障原因,我们还是先在客户端抓取一下故障时交互的数据包,站在数据包的角度来分析一下可能的原因。


1,找一台出现故障的主机192.168.1.167,捕获其打开主页面缓慢时的数据包。

2,查看缓慢时的数据交互情况,如下图所示: 


我们通过delta tima值可以看到,这个交互的过程存在较大的延时,并且我们发现,在交互的过程中存在数个“ICMP主机通讯管理性禁止”的差错报文,这些报文都是X.X.X.139发给故障主机192.168.1.167的。

3,我们双击其中一个ICMP主机通讯管理性禁止报文,查看其封装的被过滤的原报文相关信息,如下图所示:


我们发现,被X.X.X.139管理性过滤掉的报文是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文。

4,我们再结合上下数据包交互的情况,我们可以发现,这个ICMP主机通讯管理性禁止报文的前一个报文正是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文,如下图所示: 


       这充分说明当故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求时,被服务器管理性过滤禁止了。

5,那么服务器为什么会管理性禁止故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求报文呢?难道服务器上设有针对源端口为4075的禁止访问策略吗?服务器显然没有做这种针对源端口过滤的必要,另外,我们还发现除了故障主机以源端口4075访问服务器的SYN报文被管理性禁止外,还有其他源端口的SYN请求报文被服务器管理性禁止,如下图所示: 


     这里被服务器禁止的报文的源端口有4078、4083、4086等。
       另外,通过上图中的“delta time”值,我们也可以发现正是这些报文导致了故障主机在建立新的TCP连接之前花费了数秒的连接建立尝试时间(SYN重传时间,大家可参考本博客《TCP重传》一文),从而导致了页面打开缓慢的现象出现

6,这个现象具有明显的针对TCP的随机性的过滤特性,因此,我们很容易就可以联想到是否是服务器在TCP传输层存在某些检测过滤机制?而在传输层最为常见的就是TCP连接数限制了。
       一般而言,在服务器上实现针对单IP访问服务器的TCP连接数进行限制是一件简单的事情,一个独立的IP只允许与服务器建立少量的TCP连接,这对于那些对外提供服务的服务器来说是一种较为常见的防护措施,在正常情况下,单个客户端与服务器的正常交互所需要的TCP连接数并不是很多,而限制的数值一般都会高于正常的需求,但是在有些情况(如经过NAT或代理后对业务的访问)下,这将导致问题的产生。

7, 上述推理非常合理,我们通过检查服务器的相关设置,验证了我们的分析和推论结果。

8, 分析结论:
       这个故障是由于业务服务器端设置了针对单IP访问连接数限制功能,而内部办公网主机都是通过防火墙NAT地址转换后对业务服务器进行访问,这直接导致在业务访问高峰时,出口NAT IP地址访问业务服务器的连接数超出限制,业务服务器对后续的TCP连接建立请求发出ICMP差错报文,等一些TCP连接释放后,才允许新建TCP连接,这导致访问业务系统非常缓慢。并且这种特性决定了故障现象表现为间歇性发生。

4 故障解决

       通过修改服务器Apach对单一IP地址的连接数的限制后,故障得到解决。



<think>好的,用户问会不会是电源电流供电不够导致系统在Supervivi引导后内核加载驱动但最终重启的问题。我需要先回顾之前提供的排查指南,看看电源问题是否已经被涵盖。 之前的指南第五部分提到了电源与时钟稳定性,其中核心电压跌落测试和时钟源干扰排查。用户现在具体问的是电流不足的可能性,而之前重点在电压波动,所以可能需要更详细地解释电流的影响。 用户可能是硬件方面的开发者或爱好者,他们可能在排查过程中已经检查了驱动、内存和文件系统,但问题依旧存在,所以转而怀疑电源问题。深层需求可能是想确认电源规格是否足够,或者是否有测量电流的方法。 首先需要确认电流不足是否会导致重启。当系统功耗超过电源供应能力时,电压会被拉低,可能触发欠压保护,导致复位或重启。这时候不仅仅是电流的问题,而是电压稳定性,但根源可能是电流不足。 接下来要列出可能的电源问题点,比如电源额定电流不足、电源线或连接器阻抗过大、瞬态电流需求未被满足。需要指导用户如何测量实际电流,使用万用表或示波器捕捉启动时的电流变化。 同时要提供解决方法,比如更换更高功率的电源,检查电源路径上的元件,添加去耦电容等。还需要提醒用户注意电源设计是否符合芯片要求,特别是像S3C2440这类处理器的功耗特性。 可能还需要区分冷启动和运行中的问题,因为启动瞬间的电流峰值可能更高,如果电源响应不够快,会导致电压跌落。这时候需要检查电源的动态响应能力,而不仅仅是静态电流输出。 此外,用户可能在问题中遇到间歇性重启,这可能与温度有关,因为电源在高负载下发热可能导致效率下降,从而电流供应能力降低。需要建议用户在不同温度条件下测试。 最后要总结电源电流不足的可能性,并建议用户进行系统性排查,结合电压和电流的测量,同时考虑其他硬件因素,综合判断。</think>--- ### 电源电流不足可能导致系统重启的详细分析与排查方法 #### 一、 **电源电流不足的可能性分析** 1. **直接表现** - **系统功耗突增时触发重启**:当内核加载驱动(如 USB、GPU、网络等)时,外设开始工作,电流需求骤增。 - **典型场景**: - 驱动初始化阶段开启高功耗外设(如 LCD 背光、4G 模块) - 多核 CPU 同时进入高负载状态 - 存储设备(如 eMMC、SD 卡)读写时峰值电流上升 2. **核心芯片的电流需求** - **以 S3C2440 为例**: | 工作模式 | 典型电流 | 峰值电流 | |----------------|----------|-----------| | 空闲状态 | 80mA | - | | 全速运行 | 250mA | 500mA* | | 外设全开 | 400mA+ | 1A+ | \* 注:峰值电流可能持续数十毫秒,劣质电源可能无法响应瞬态需求。 --- #### 二、 **确认电流不足的硬件检测方法** 1. **动态电流测量** - **工具要求**: - 高精度数字万用表(建议采样率 > 1kHz) - 电流探头 + 示波器(观测瞬态电流波形) - **测量步骤**: 1. 串联测量:断开开发板电源正极,将万用表切换到 **10A 直流档** 串联接入电路 ![串联测量示意图](https://via.placeholder.com/300x150?text=Current+Measurement) 2. 触发抓取:在 Supervivi 启动时记录电流变化,重点关注 **内核解压** 和 **驱动初始化** 阶段的电流峰值 2. **关键判断指标** - **电源额定电流**:若标称值 ≤ 系统实测峰值电流 → 供电不足 - **电压跌落阈值**:当电流突增导致核心电压(如 1.2V)跌落超过 **7%** → 触发 CPU 复位 --- #### 三、 **电源路径问题排查** 1. **PCB 走线瓶颈** - **风险点**: - 电源走线过细(如 < 2mm 线宽)导致阻抗过大 - 过孔过多(如 > 3 个)增加路径电阻 - **验证方法**: - 测量 **电源输入端** 和 **CPU 电源引脚** 之间的压差 - 正常值:≤ 0.1V @ 1A 负载 2. **滤波电容失效** - **典型故障**: - 钽电容击穿 → 短路保护触发重启 - 电解电容 ESR 增大 → 无法抑制瞬态电流需求 - **检测命令**(需硬件支持): ``` # 在 U-Boot 或 Supervivi 中测试电源稳定性 power_test -v # 监控核心电压波动 ``` --- #### 四、 **针对性解决方案** 1. **升级电源方案** - **选型建议**: | 系统总功耗 | 推荐电源类型 | 冗余设计 | |------------|--------------------|----------| | < 2W | LDO 稳压器 | 30% | | 2W~5W | DC-DC 开关电源 | 50% | | > 5W | 多相 PWM 控制器 | 70% | - **示例改造**: 将 AMS1117-3.3 替换为 TPS5430(最大输出 3A),并增加 220μF 低 ESR 陶瓷电容 2. **优化功耗配置** - **内核启动参数调整**: ``` # 关闭非必要外设(如 USB Host、HDMI) setenv bootargs ... nohdcp nousb ``` - **动态频率调节**: ```c // 在驱动代码中限制外设时钟 clk_set_rate(spi_clk, 1000000); // 降低 SPI 时钟频率 ``` --- #### 五、 **典型案例分析** **案例:4G 模块导致重启** - **现象**:内核加载 `qmi_wwan` 驱动后立即重启 - **检测数据**: - 空闲电流:380mA - 4G 模块激活瞬间电流:1.2A(持续 200ms) - 电源标称值:5V/1A(实际峰值输出能力仅 0.8A) - **根因**:电源无法满足瞬态电流需求 → 电压跌落至 4.3V → CPU 复位 - **修复措施**: 1. 更换为 5V/3A 电源 2. 在 4G 模块电源引脚并联 470μF 电解电容 + 100nF 陶瓷电容 --- ### 结论 电源电流不足 **确实可能导致系统重启**,尤其在驱动加载阶段的外设初始化过程中。建议按以下优先级排查: 1. 测量实际电流波形,对比电源规格 2. 检查 PCB 电源路径阻抗 3. 增加瞬态电流补偿电容 4. 优化软件配置降低峰值功耗 若问题仍存在,可尝试 **断开高功耗外设(如屏幕、4G模块)** 后测试启动流程,以隔离具体故障点。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值