【实例分享】访问后端服务超时,银河麒麟服务器操作系统分析及处理建议

本文主要是介绍【实例分享】访问后端服务超时,银河麒麟服务器操作系统分析及处理建议,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1.服务器环境以及配置

【机型】

处理器:

Intel 32核

内存:

128G

整机类型/架构:

x86_64虚拟机

【内核版本】

4.19.90-25.22.v2101.kylin.x86_64

【OS镜像版本】

kylin server V10 SP2

【第三方软件】

开阳k8s

2.问题现象描述

前端机器访问后端容器超时,业务中断。

3.问题分析

3.1. 网络环境拓扑

centos前端访问腾讯负载均衡CLB的9083端口,CLB从k8s集群的20个节点中选择一台将前端的访问请求转发到其30170端口,转发节点再将前端的访问请求转发到提供所需服务的worker node,由worker node的pod为前端提供服务。

3.2. 2月20日网络数据包文件分析

hive.n920e1nodap0050.0220.pcap为2月20日复现问题时在转发节点n920e1nodap0050捕获的网络数据包文件。

转发节点n920e1nodap0050,tcp stream 171为前端和后端之间的TCP连接。

前端发送给转发节点的783号包的seq为2879,tcp data len为4。

图 2

前端发送给转发节点的784号包的tcp data len为1398, IP首部带有不允许分片的flag。

图 3

图 4

前端发送给转发节点的785号包的tcp data len为1307。

图 5

转发节点发送给前端的786号包的ack为2883,这正好是783号的seq+len。说明,后端pod收到了783号包,786号包是对783包的ack。

图 6

786号包带有TCP选项SACK,向发送端(前端)报告了一个空缺,后端pod还未收到seq为2883到4280(长度为1398)的数据,即784号包,就已经收到了seq为4281到5587(长度为1307)的数据,即785号包。

图 7

前端收到786号包后,了解到后端pod已经收到了785号包,但是没有收到784号包,于是重传784号包,重传多次,均未收到后端pod对该包的ack,最终导致TCP连接中断。

图 8

图 9

3.3. 2月29日网络数据包文件分析

n920e1infap0001.0229.pcap为2月29日复现问题时在转发节点n920e1infap0001捕获的网络数据包文件。tcp stream 59为转发节点和后端pod之间的TCP连接。

图 10

转发节点发送给后端pod的864号包包含seq从2939到2942长度为4的tcp data。

图 11

转发节点发送给后端pod的865号包包含seq从4341到5073长度为733的tcp data。还未发送seq为2943到4340长度为1398的tcp data,就已经发送了seq从4341到5073长度为733的tcp data。因次,wireshark给865号包打上了”TCP Previous segment not captured”的提示。和2月20日的情形一致,后端pod均未收到长度为1398的tcp data。

图 12

3.4 长度为1398的tcp data丢包原因分析

由3.2部分的分析可知,后端转发节点的eth0网卡收到了frame len为1464,tcp len为1398的tcp数据包,但是后端pod并未收到。由3.3部分的分析可知,后端转发节点的eth0网卡并未将tcp len为1398的tcp数据包转发给后端pod。

后端转发节点的eth0网卡收到前端发送的数据包之后,在转发给后端pod前,会先交给后端转发节点的tunl0网卡处理(设置IP头部数据等)。

因此,tcp len为1398的tcp数据包是在转发节点的tunl0网卡的接收或者转发过程中丢失的。

小包可以成功接收,但收不到大包,一个常见的原因是IP数据报的长度超过了网卡的mtu。

tcp len为1398的tcp数据包的IP数据报的长度为20(IP首部长度)+32(TCP首部长度)+1398(应用数据)=1450。

图 13

k8s集群节点的tunl0网卡的mtu为1440,小于tcp len为1398的IP数据报的长度1450。由图 4可知,前端发送的数据包IP首部带有不允许分片的flag。因此,该数据包会在转发节点的tunl0网卡接收过程中被drop掉。

图 14

4.问题分析结果

前端机器访问后端容器超时的原因是: 前端发送的长度超过后端转发节点的tunl0网卡的mtu的IP数据报在传输过程中被后端转发节点的tunl0网卡drop,前端多次重传,均收不到对该类包的ack,最终导致TCP连接中断。

5.后续计划与建议

建议联系k8s厂商或客户侧k8s环境管理员,适当调整集群节点的tunl0网卡的mtu。

这篇关于【实例分享】访问后端服务超时,银河麒麟服务器操作系统分析及处理建议的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1054185

相关文章

Nginx分布式部署流程分析

《Nginx分布式部署流程分析》文章介绍Nginx在分布式部署中的反向代理和负载均衡作用,用于分发请求、减轻服务器压力及解决session共享问题,涵盖配置方法、策略及Java项目应用,并提及分布式事... 目录分布式部署NginxJava中的代理代理分为正向代理和反向代理正向代理反向代理Nginx应用场景

Linux云服务器手动配置DNS的方法步骤

《Linux云服务器手动配置DNS的方法步骤》在Linux云服务器上手动配置DNS(域名系统)是确保服务器能够正常解析域名的重要步骤,以下是详细的配置方法,包括系统文件的修改和常见问题的解决方案,需要... 目录1. 为什么需要手动配置 DNS?2. 手动配置 DNS 的方法方法 1:修改 /etc/res

Linux创建服务使用systemctl管理详解

《Linux创建服务使用systemctl管理详解》文章指导在Linux中创建systemd服务,设置文件权限为所有者读写、其他只读,重新加载配置,启动服务并检查状态,确保服务正常运行,关键步骤包括权... 目录创建服务 /usr/lib/systemd/system/设置服务文件权限:所有者读写js,其他

Redis中的有序集合zset从使用到原理分析

《Redis中的有序集合zset从使用到原理分析》Redis有序集合(zset)是字符串与分值的有序映射,通过跳跃表和哈希表结合实现高效有序性管理,适用于排行榜、延迟队列等场景,其时间复杂度低,内存占... 目录开篇:排行榜背后的秘密一、zset的基本使用1.1 常用命令1.2 Java客户端示例二、zse

Redis中的AOF原理及分析

《Redis中的AOF原理及分析》Redis的AOF通过记录所有写操作命令实现持久化,支持always/everysec/no三种同步策略,重写机制优化文件体积,与RDB结合可平衡数据安全与恢复效率... 目录开篇:从日记本到AOF一、AOF的基本执行流程1. 命令执行与记录2. AOF重写机制二、AOF的

解决docker目录内存不足扩容处理方案

《解决docker目录内存不足扩容处理方案》文章介绍了Docker存储目录迁移方法:因系统盘空间不足,需将Docker数据迁移到更大磁盘(如/home/docker),通过修改daemon.json配... 目录1、查看服务器所有磁盘的使用情况2、查看docker镜像和容器存储目录的空间大小3、停止dock

Java服务实现开启Debug远程调试

《Java服务实现开启Debug远程调试》文章介绍如何通过JVM参数开启Java服务远程调试,便于在线上排查问题,在IDEA中配置客户端连接,实现无需频繁部署的调试,提升效率... 目录一、背景二、相关图示说明三、具体操作步骤1、服务端配置2、客户端配置总结一、背景日常项目中,通常我们的代码都是部署到远程

5 种使用Python自动化处理PDF的实用方法介绍

《5种使用Python自动化处理PDF的实用方法介绍》自动化处理PDF文件已成为减少重复工作、提升工作效率的重要手段,本文将介绍五种实用方法,从内置工具到专业库,帮助你在Python中实现PDF任务... 目录使用内置库(os、subprocess)调用外部工具使用 PyPDF2 进行基本 PDF 操作使用

MyBatis Plus大数据量查询慢原因分析及解决

《MyBatisPlus大数据量查询慢原因分析及解决》大数据量查询慢常因全表扫描、分页不当、索引缺失、内存占用高及ORM开销,优化措施包括分页查询、流式读取、SQL优化、批处理、多数据源、结果集二次... 目录大数据量查询慢的常见原因优化方案高级方案配置调优监控与诊断总结大数据量查询慢的常见原因MyBAT

分析 Java Stream 的 peek使用实践与副作用处理方案

《分析JavaStream的peek使用实践与副作用处理方案》StreamAPI的peek操作是中间操作,用于观察元素但不终止流,其副作用风险包括线程安全、顺序混乱及性能问题,合理使用场景有限... 目录一、peek 操作的本质:有状态的中间操作二、副作用的定义与风险场景1. 并行流下的线程安全问题2. 顺