上篇组播分片报文重组后丢包问题，分析到最后是接口eth0和eth1在同一个广播域，且两个接口都处于混杂模式导致。解决方案是关闭接口的混杂模式。

eth0和eth1在相同的广播域，且开启了混杂模式。业务组播分片报文，在两个接口都会收到。当同一个大包的多个分片在eth0和eth1上产生重组冲突，协议栈会丢包，导致业务收不到。

kmalloc-128 slab内存泄漏定位过程问题现象进展受阻现网排查分析coredump后记问题现象前几天，技术团队告知，线上几台ARM CentOS设备内存占用高，比其他相同设备占用高约200M。查看 free，meminfo和slabinfo后，怀疑是slab kmalloc-128存在内存泄漏。进展受阻我们发现正常设备和内存占用高设备的 kmalloc-128 占用已经超过177万，粗算下来200多M，刚好是多占用的内存大小。//异常设备的slabkmalloc-128

技术那边新遇到个问题，客户那里设备掉电，重启后发现设备无法联网。通过串口登上去发现除了环回口lo，其他所有接口都没有地址了。 尝试重启业务，重启设备还是不行。 尝试手动ifconfig配置ip，结果ifconfig进程崩溃了，提示segement fault。倒是ip address 可以正常查看接口。 起初我怀疑是掉电导致网卡异常，导致配置丢失和ifconfig不能正常工作。于是查看日志信息和网卡信息。没有看到什么线索，...

缘起公司部分项目在部署上通过keepalived实现了了双机热备，通过荣誉和接管，实现高可用性。最近其中一个项目出现了内存耗尽问题，使用<内存问题快速定位工具>定位提示是keepalived进程的rarp socket收报队列挤压了太多数据包导致。 该工具可以快速定位大多数内存问题，详细介绍文档见《内存泄漏定位思路和方法》，在此不再赘述。 分析keepalived我们用的是v2.0.10版本，...

为了便于定位内存问题，使用/proc/meminfo中的一些关键变量值，来计算用户态内存占用，内核态内存占用（包含slab占用和vmalloc占用等），以及黑洞内存占用。(详见内存泄漏定位思路与方法)。公司技术同事使用该方法定位了很多项目内存问题。今天技术同事说有个设备内存占用很高，使用定位方法发现存在隐形内存。我登录设备初步排查了黑洞内存常见的几个怀疑点，没有发现问题。随后我再次查看meminfo确认，发现了一个奇怪的现象。[root@localhost ~]# cat /proc/meminfo

业务模块使用了内核的crypto API来对报文进行加解密。之前使用的是内核自带的 aes，des加解密方式。一切正常，模块的加载卸载也OK。(基于CentOS 3.10.0-514版本)最近为了符合国家密码标准，增加了sm4加解密算法。并在业务模块初始化时，调用crypto_register_alg将sm4算法注册起来。然后使用 crypto_alloc_cipher 创建加密cipher，crypto_cipher_setkey设置加密key。调用 crypto_cipher_encrypt_one

模块卸载失败定位过程一级目录二级目录三级目录查看服务状态查看卸载进程状态查看进程栈信息查看卡住的工作队列查看异常工作队列进程栈强制产生core文件并使用crash工具打开研究lock信息一级目录二级目录三级目录设备重启服务会先卸载业务模块，然后再重新加载。线上有台设备在重启业务时卡住。查看服务状态[root@localhost ~]# systemctl status BSN● BSN.service - APXBSN BSN SERVICE Loaded: loaded (/usr/l

我们业务模块实现了rtt计算机制，通过发送探测request时，使用jiffies_to_msecs(jiffies)记录下发送时间值。收到探测reply时，再使用jiffies_to_msecs(jiffies)记录下接收时间值。作差得到实时的rtt值。后续还会计算平滑srtt值。该机制在x86平台一直运行正常。最近在mips平台上出现了问题。业务模块统计出来的延时为0ms。实际抓包查看发现延时在7ms左右。明显业务模块统计错误。相同代码，在不同平台表现不一样。这是怎么回事？突然想到，我们使用的是

问题现象项目上遇到一个问题，报文交互经常延时过高，客户非常不满。初步抓包分析通过抓包发现问题出在从物理口收包到我们模块处理时。也就是说不是网络中异常导致的延时过高。是我们处理过程中产生的。但是但从抓包很难确认延时产生在什么位置。需要进一步确认。报文打点确认于是对报文进行了处理，使其记录timestamp，然后在各个关键位置判断当前时间和报文timestamp的差值，如果超过一定范围，则通过log打印出来。通过打点，确认问题发生在 业务模块将 报文放入队列，到主线程从队列取包处理时。这部分的简单

docker使用cgroup memory导致的内存泄漏1. 问题现象及分析1.1 问题现象1.2 问题分析2. 解决办法和尝试2.1 升级到修复后的版本。2.2 禁用cgroup的kmem属性。3. 方案无效及分析3.1 确认内核是否支持该选项3.2 新的解决方案太长不看版本1. 问题现象及分析1.1 问题现象公司产品（centos 3.10.0-514）需要用频繁启动docker，每个docker的运行时间不固定，一段时间后设备内存不足。使用内存泄漏分析工具（传送门https://blog.cs

项目中需要使用syslog打印带有换行符’\n’的字符串，期望能够在log里将其分行打印。结果打印出来全在一行内，换行符被以’#012’替代。为了验证问题，简单写了个测试代码：#include <syslog.h>int main(int argc, char *argv[]){ openlog("testlog", LOG_PID, LOG_LOCAL2); syslog(LOG_INFO, "aaaa\nbbbb\n"); closelog();