银河麒麟操作系统的博客

这表明设备sdb和sdc发生了I/O错误。另外，日志中还出现了rejecting I/O to offline device的消息（例如：sd 3:0:0:1: rejecting I/O to offline device），这通常意味着设备已经离线，无法再进行I/O操作。sdb和sdc设备应该对应sd 3:0:0:0和sd 3:0:0:1，查看当前收集的sosreport中的lsscsi命令，由于相隔的时间太过久远，没有3:0:0:0和3:0:0:1相关的设备，变为了5:0:0:0和5:0:0:1。

2、分析时间2的vmcore-dmesg日志，kswapd0在CPU8上尝试回收页面，页面回收涉及过多的TLB刷新操作，可能当时系统环境内存存在压力，页面回收过程中需要同步更新TLB，导致smp_call_function_many被频繁调用，而某些CPU又存在超售，最后导致软锁。从日志中可以看到，这是一次软锁的问题，kswapd0在CPU#8 上，内核态运行时消耗了过多的 CPU 时间，未能及时释放CPU导致其他任务无法运行。查看CPU0上的硬件中断情况，在该CPU并没有硬中断，所以没有出现中断风暴。

综合分析，虚拟机系统内部原因可能性很低，虽然虚拟机内部的驱动程序错误或配置问题可能导致I/O问题，但同时影响到两个不同的虚拟磁盘，并且有print_req_error和rasdaemon的硬件错误报告，这种可能性非常之低。问题根源是底层存储的I/O错误，print_req_error和rasdaemon的报警都指向了底层的硬件或存储层面的问题，而且/dev/vda1和/dev/vdb都出现了I/O错误，说明不是单个磁盘或文件系统的问题。// 由于发生了I/O错误，EXT4文件系统中止了其日志操作。

虚拟机部署v10sp2系统，宿主机为欧拉定制系统。虚拟机运行Vastbase数据库软件，在03:10:04数据库执行了对表dwd_rq_jg_xjjl_all_delta_1824281295409119232（对应物理文件11747991）的删除操作，08:00:17数据库将数据写入表t_yh（对应物理文件11749618），在次日08点，读取表t_yh时异常。同时由于虚拟机的数据存储过程涉及到宿主机及网络存储，不排除数据库存在故障，或云平台存储故障，导致数据丢失，还需数据库厂商及云平台厂商进一步排查。

由此可知，由于使用team0（roundrobin ）模式，虚拟机arp广播报文，经vnet0进入网桥，此时网桥mac学习到虚拟机的mac地址对应vnet0的port，此时fdb表是正确的。V10SP2系统，使用kvm运行虚拟机，如果是物理机两个网口做成一个team，然后team接网桥，虚拟机再通过这个网桥连接网络，这种方式网络会有问题。实际测试下来，确实会发现网络不通，此时如把team1从网桥删掉，换成物理网口，网络就可以正常使用，单独配置team，也可以正常使用。物理机/虚拟机/云/容器。

更多银河麒麟操作系统产品及技术讨论，欢迎加入银河麒麟操作系统官方论坛了解更多银河麒麟操作系统全新产品，请点击访问麒麟软件产品专区：https://product.kylinos.cn开发者专区：https://developer.kylinos.cn文档中心：https://document.kylinos.cn处理器：整机类型/架构：x86_64【内核版本】【OS镜像版本】

对比每个ConsumeMessageT线程cpu使用率，两套环境比较接近，最高都在12%左右，但是统计多个时间点活动的ConsumeMessageT进程数量，hygon_kylin环境中有107-135个，intel_redhat上只有71-105个，猜测cpu使用率可能跟测试程序拉起的ConsumeMessageT线程数有关，具体可能跟测试程序关系更大。针对intel_kylin组合业务耗时特别高的问题，分析1000线程数业务测试具体数据，如下图，copy事务最高耗时达到781s，平均4s多。

【银河麒麟高级服务器操作系统】服务器卡死后恢复系统日志丢失-分析及处理全过程

日志中出现的问题表明在这个过程中，内存链表操作发生了损坏，导致内核警告,且伴随提示丢失了40多万行的内核日志信息，记录的情况也已经不是问题的第一现场，出现链表检测错误告警后并不会进行修复，在接下来使用到问题链表时，依旧会出发告警情况。日志系统进行预分配，需要在tmpfs中进行，且伴随内存页的迁移情况，其中伴随page->lru链表的告警的信息输出，由于日志系统存储在tmpfs中，也造成一定的hang住情况，丢失了不少内核信息，也丢失了问题第一现场。分析sa日志，磁盘读写延迟非常高。

DSCP（DifferentiatedServicesCodePoint，差分服务代码点）是一种用于网络报文优先级分类的标记，使用每个数据包IP头部的TOS字段进行标识，通过不同的编码值来区分不同优先级。网卡品牌是：Mellanox，有多个优先级缓存区（8个，优先级0-7）。通过mlnx_qos工具将不同DSCP绑定到不同优先级缓存区，以设置具备不同DSCP的报文走哪个优先级缓存区。服务器业务访问很慢，可能存在网卡丢包，交换机侧有收到反压帧（有反压帧，说明服务器网卡的接收缓存区可能满了）。

【银河麒麟高级服务器操作系统】服务器异常重启故障分析及处理建议

在高并发压测下出现这种问题，推测是应用程序端问题，建议应用端排查，如全连接队列长度由 net.core.somaxconn和listen(fd, backlog) 的backlog两者最小值决定，如果listen函数传参backlog太小会导致这种现象。sar -B -f sa27，查看内存回收情况，问题发生期间，没有进行内存回收，可见内存资源是够的。sar -rh -f sa27，查看内存使用情况，问题发生期间，还存在空闲内存，且可用内存较多。物理机/虚拟机/云/容器。外网/私有网络/无网络。

现象描述：使用银河麒麟高级服务器操作系统执行两次dd用例后，表现不一致。基于上述的现象，猜测第一次dd没有等待数据完全落盘就结束了；而第二次dd是等待数据落盘之后才结束。

现象：systemd做init的容器中journal服务修改日志存储位置无效。经分析发现：镜像中缺少qrencode包，该包是journal日志服务所需要的。本文结合实际案例，给出来建议的解决方案。

追踪Linux系统的内存使用一直是个难题，人们试着把能想到的各种内存消耗都加在一起，kernel text、kernel modules、buffer、cache、slab、page table、process RSS…等等，却总是与物理内存的大小对不上，这是因为Linux kernel并没有滴水不漏地统计所有的内存分配，kernel动态分配的内存中就有一部分没有计入/proc/meminfo中。

现象：目前服务器系统重启进维护模式，尝试挂盘进救援模式后，想查看日志和故障现象，发现chroot进不去，查看lvm分区后，发现400g的分区pvs显示unknown。此次现象由于直接再扩展分区创建物理卷导致，过程中会擦除dos分区表签名被擦除，并且扩展分区本身是不能直接被使用的，故导致此问题。

现象描述：裸金属物理服务器开机卡在EFI stub页面，无法正常进入系统。本文进行详细分析，并给出了处理建议。

现象描述：重点系统投产，TCP的连接数猛增，现在已经到15000个网络连接，需要评估下操作系统的瓶颈，如何优化可保证业务不会出行例如somaxconn，backlog等问题。

现象描述：pod飘逸后挂载失败，通过"blkid -o udev /dev/dm-35命令和lsblk命令查看不到文件系统属性， 手动mount 挂载时，提示指定文件系统类型，mount -t ext4 后可正常挂载和访问。本文进行了复现并给出了详细分析结果与建议。

现象描述：安全基线在银河麒麟高级服务器操作系统V10 sp2和V10 sp3能生效，在V10 sp1-0518系统版本上添加如上内容未生效。系统测试分析情况，可知，在银河麒麟高级服务器操作系统V10系统中，限制实现只有属于wheel组的用户才被允许使用su命令来切换到root用户这个安全基线功能，是需要在/etc/pam.d/su配置文件的pam_wheel.so模块后面，通过追加use_uid这个模块配置参数实现的。

了解全新产品，请点击访问产品信息产品名称银河麒麟高级服务器操作系统（海光版）V10ISO环境信息主机型号虚拟机systemd崩溃，后续systemd连接异常，systemctl失败。需要查明systemd崩溃原因根据sosreport中的messages信息，systemd发生了coredump，收到了信号SIGQUIT。见图2.1.1图2.1.1使用gdb分析systemd的coredump文件，显示systemd是收到了SIGQUIT后发生的coredump。并未调用错误处理函数。

当今数字化时代，系统安全的重要性不言而喻。为应对网络安全风险、满足用户高等级安全诉求，麒麟软件打造了满足用户高等级安全诉求的 “麒麟安全加固工具”，实现服务器操作系统安全配置的规范化、标准化、制度化，为系统安全打造坚固“金钟罩”！

故障现象：反馈智能运维系统登录页面提示500。初步排查，发现虚机B系统日志显示在系统出现软中断，并持续15分钟时间。虚机C系统日志也有软中断报错，虚机A系统日志无21号日志，因此无法判断是否有软中断报错，影响智能运维系统服务中断。

现象：启nginx服务，但是报了softlock的错误，而且当时负载比较高，资源占用；建议：对于大量内存突然不知所踪，无法在各类内存统计项中找到这类内存黑洞现象，通常都是由于驱动应用、硬件异常或是虚拟化环境宿主机异常导致。建议排查虚拟机问题时间点进行的相关操作以及宿主机虚拟化平台状态。

现象：查看 sosreport 日志中的进程信息，可以看到，xfsaild/sda4为不可中断进程，并且cpu占用高的为abrtd 进程。文中给出了初步处理建议。

银河麒麟高级服务器操作系统 libtirpc-devel 安装问题分析

现象描述：虚机系统ssh无法正常登录，进入虚机控制台，也无法正常登录进入系统。建议：可以ssh登录系统，使用top命令查看发现dbus占用单核cpu为99%，比较高。。建议排查相关应用，查看是否有需要进行检查和优化的方面。

现象描述：生产环境arm V7.6物理机在2024年 4月7号08:49分钟左右宕机（自动重启恢复），生成vmcore文件。处理建议：针对该问题建议应用方排查下相应java进程是否存在对大量小文件的目录进行遍历操作，以及根据实际需求看是否考虑关闭kernel.softlockup_panic。

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

现象描述：某服务器系统升级内核至4.19.90-25.22.v2101版本后仍会触发oom导致java进程被kill。建议：修改watermark_scale_factor的值来调大min、low、high三条内存回收水位线的差距；对于内存碎片化的情况，如果系统内存高碎片化情况较为频繁，条件允许的情况下，我们建议在业务空闲时手动进行异步内存规整。

现象描述：40台虚机强制重启后，其中8台虚机找不到逻辑卷导致启动异常，后续通过pvcreate 修复重建pv，激活vg和lv并修复文件系统后恢复。结合现有日志分析，虚拟机强制重启后，LVM设备上LVM标签丢失导致对应pv，vg无法激活。

现象描述：发现系统日志记录了oom问题，但是当时并没有重启系统，系统cpu急剧增加，最终系统夯死。数据库已提供数据库层面分析报告，需要系统层面再进行问题分析排查。。建议，下次遇到此故障情况，观察swap内存交换分区使用情况，排查异常占用swap的具体进程，再进一步分析。

现象：系统异常卡死，后手动重启系统，恢复的故障环境。日志分析情况：未能通过系统和bmc日志，排查到有效报错信息。因未启用kdump服务，未收集到内核崩溃相关日志，无法判断系统卡死，是否跟系统内核有关。未安装系统性能监控工具sysstat， 没有收集到，系统性能日志，同样无法分析判断，系统卡死，是否跟CPU、内存、磁盘IO等资源异常使用有关。

现象：问题机器系统内存占用长时间90%以上，同时伴随着高iowait，在故障时无法ssh登录，同时也影响生产业务。但之后系统内存占用会突然掉下来，在内存自己掉下来后能ssh登录。

问题现象：服务器里面的容器java程序启动shell脚本执行解压unzip命令，进程一直处于sleep状态，没有执行解压，一直卡着。麒麟软件通过实例分享了处理经验，希望可以帮助到遇到类似情况的小伙伴。

发现云平台查看内存占用与实际内存占用不一致。麒麟软件分享了实例中的处理方式，供小伙伴们参考。

高可用触发服务器异常重启，麒麟软件专业技术人员给出了实际案例中的详细处理流程，希望可以帮助到遇到类似问题的小伙伴。

【实例分享】银河麒麟高级服务器操作系统环境资源占用异常-情况分析及处理方法

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

麒麟软件产品供应链安全能力获双重肯定！5月30日，经北京赛迪认证中心评估，银河麒麟高级服务器操作系统V10和银河麒麟桌面操作系统V10成为首批获得软件供应链安全能力认证产品，并在操作系统类产品中名列前茅。