mzhan017的博客

这个kprobetrace类似基于事件的tracepoint（跟踪点）。不过这个是基于kprobes(kprobe and kretprobe)。所有kprobe可以探测的地方，都可以使用这个kprobetrace功能。也就意味着，除了带有__kprobes/nokprobe_inline 关键字的函数，还有带有标记NOKPROBE_SYMBOL的函数外，所有的其他函数都可以做kprobetrace。而且是可以动态做探测，不像tracepoint，是静态编译在内核模块里。

这个参数是三元值，第一个min是系统给TCP分配的最小页数；pressure，如果分配超过这个值，就进入一种pressure的状态。如果达到max，就会分配失败。对应一个全局变量：tcp_memory_pressure，记录进入pressure的jiffies。但是这里没有写进入pressure 模式，会做什么操作。这个参数的初始化，和现有内存的量有关系。关系比例是下面这个。如果大于hard limit/大于最大值会。trace event 牵扯的函数。

perf 工具可以使用 --switch-output 参数来实现对 record 生成的文件进行定期的轮转（rotate）。文件将被命名为 perf.data, perf.data.1, perf.data.2，依此类推。按文件大小轮转： 你也可以通过 --switch-output 指定文件的大小上限，达到指定大小后会进行文件轮转。这个命令每 10 秒轮转输出文件，生成文件 perf.data, perf.data.1, perf.data.2，依此类推。这将为每个 60 秒的记录生成一个新文件。

这个是使用libbpf的一个例子；

这里带有尖括号黑体的48比较关键，指的就是当前指令。把前后相关的二进制代码段打印出来了。最近看到一个内核函数，可以帮助dump进程的stack数据。看着很有用，可以使用。其他的都比较正常的打印，一眼就可以看出意思。

在这个示例中，my_netdev_event 函数会在网络设备被注销（NETDEV_UNREGISTER）时打印一条信息。通过 register_netdevice_notifier 和 unregister_netdevice_notifier 函数注册和注销通知块。在 Linux 内核中，有关网络设备（net-device）的事件注册机制，允许用户在网络设备的状态发生变化（例如设备被删除、添加或修改）时接收通知。这个机制确保了当网络设备发生变化时，内核模块或应用程序可以及时收到通知并进行相应处理。

在shell里使用ctrl+c的时候，是发送了一个信号：SIGINT interrupt。

按照long所占的内存，存放一个bitmap。比如下面这个cpu的cpumask。

内核内嵌的gcov功能，默认是不打开。如果打开，同事需要enable debug_fs，然后才能查看相关的profile数据。第一次看到这个在内核里的功能。

这里的Symbol列现实的地址是减了一个__executable_start的偏移量。所以不要把symbol显示的地址串当成真的地址。去做addr2line的反编译源代码地址。

这个原因是，通过比对每个format的magic数值，或者其他的信息，来看是否属于某个format，如果都不符合，就会出现这个错误。说明kernel的coredump文件，dump的有些问题。

经过调查发现是内核将ESP解开之后，如果是tunnel模式，内核又重新将skb丢给了interface去做处理。这样tshark/tcpdump就可以抓住了。抓到包之后，可以方便的分析问题，省去在wireshark里解码的问题。根据这个描述，看着是正常的，

因为内核里相关的结构体里有一个标记为：inet_bind_bucket.fastreuse，如果这个端口上的所有的socket都是reuse，这个标记为就一直生效，这样就一直不走conflict函数，也就不会产生什么特别的影响。这个时候就有可能出现问题，而且使用的这个端口，还是一个临时的端口，在net.ipv4.ip_local_port_range之内的一个临时端口。第一个是，如果有一个socket的设置SO_REUSEADDR函数调用失败，setsockopt，而且继续后面的bind操作；

再一次说明，使用sipp做性能测试时，需要注意的一个问题：一定要将相关的xml脚本文件，需要放到git repo里，需要使用版本控制的机制来管理，不能每次碰到问题，都是有脚本上的些许区别。每次都需要花费很多精力，时间去调查问题，到底是在哪里？然后就看为什么socket个数使用的多了，最后发现是sipp使用的脚本和之前不一样，其中的一个超时时间设置比之前的短了，导致超时重新发起业务时，老的socket需要一定的time-wait时间来终止，导致最终的新的socket，做bind-conflict。

无意看到这个启动延迟分析，虽然现在还没遇到类似的问题，但是可以放在这里。看着有很多的工具可以用。其实systemd也提供了一个工具，来查看systemd服务启动的一个时间分析。

这个参数就是为了在CPU于延迟直接做trade-off的一个参数，在Redhat的性能文档里有提，如果相应的计数有增加，就需要调整这个参数。下面这个修改是，将原来的固定值改成了可修改的一个值。后来又改了一次，防止HZ小于1000时出现问题。这个里面有关于这个参数的调整。

导致没有日志输出，根本看不出来是谁做的reboot。说在应用程序里直接调用glibc库函数reboot。这个reboot的过程和直接从命令行的reboot。如果想调查是谁调用了reboot，应该怎么做？而这个库函数调用的是内核提供的系统调用。这个reboot更直接，更迅速。

总体来说还是IPv6层的MTU的限制，导致ESP层的代码逻辑更高。所以根据这个最小值的设置，我们就需要给出一个说明，在使用xfrm/esp的时候，最小的IPv6 MTU的设置不能是1280，而是1280+espHeader。产生这个错误的原因和一个commit相关，下面这个commit说了一个情况，就是对端的MTU设置为最小1280，会导致ip6_setup_cork函数返回EINVAL。将ipv6的MTU设置为1300，然后从在IPv6层之上再添加一个ipsec/esp层。

最近遇到一个问题，虽然应用层使用的系统调用send已经返回成功，而且没有错误日志产生，也没有errno的设置。那是不是代表一定是没有问题？从抓包的结果看，虽然上层应用已经显示发出去，但是实际抓包的时候，还是没有在接口上抓到相应的包！esp_output_done，这个函数调用xfrm_output_resume，而这个函数的返回值却没有进行处理，造成丢失错误的情况。通过调查看代码发现，内核对于ipsec的处理过程中，send系统调用，所调用的内核代码的函数链里，有可能将这个err丢失。

这样就可以严重怀疑是内核或者硬件问题，但是具体是什么问题，就必须有深厚的内核与硬件知识。如果没有，最好的方式是升级，内核与硬件。但是在现实生活种，就是有这么奇怪的结果。有一次遇到这个代码段被非法改了。

这里提到一个情况，会导致guest层VMhang住；算是不同类型数据的比较导致的一个问题。所以对于很多用户来说，如果存在这个问题，就只能及时找准一个提供商，尽快做升级。

最近看到一个case是，如果VMware主机出现问题，可能导致虚拟机运行时，出现各种异常的问题。由于寄存器的值出现异常，导致crash。可以作为作为一个问题分析的参考。

但是从ip link 来看没有no-carrier的状态，但是这个link的状态却一直是down的状态。今天从同事那里学到一个例子，说网卡的ethtool状态是好的，link 的状态也是up的状态。这就非常的合理了，如果网卡的firmware是好的，硬件状态可以为正常。网卡对应的网卡驱动选择的版本不对应导致的down。而驱动版本不合适，就会导致上层的down的状态。

如果不是最近遇到一个问题，一个bcc-tools使用的问题，又带着看了一看bcc里有这么一段代码。如果不出什么其他意外，就是到死也不会知道这个内核模块的用处是什么。

如果抛开，“INET peer storage”这个标题，这个参数的解释第一句还以为是和内存相关的参数。虽然和内存是有关联！这里的storage只是INET peer可以存储多少个peer的storage。如果超过这个量，就会主动删除掉比较旧的记录。这个一般人应该用的非常少，因为个人电脑，很难说会达到这么多的peer量。inet_peer_threshold，默认值就是64K。

但是这种讨生活的姿势其实是非常的卑微，有时候非常的打击参与者的积极性。不得不说微软的这种闭源模式的成功，非常的明显。虽然闭源，也可以达到自己想要的创新，而且做到了独大，表象就是很多功能，说改就改，做的非常大气，不容许别人的质疑，这也算是闭源的优势。在Redhat提供的系统里，有很多patch相关的文件，在很多开源的软件之上，又做了一层红帽自己的代码更改，或者是安全相关，或者是fix相关。Linux内核的利用，有很大一部分是要做剪裁功能，来缩减内核所占的空间，以适应嵌入式环境的种种场景。高山容石，不畏其大！

最近使用bcc-tools的时候注意到，bcc-tools（eBPF相关软件）的使用版本和内核的版本紧密程度非常高。修改为了tcp_drop_reason；在drop的同时带有drop的原因，方便debug问题。tcpdrop脚本的例子；tcp_drop函数被。

所以如果程序中一直都是小内存申请，然后使用，再申请，再使用，可能这个程序就用不到实际的巨页优势。这个函数给出的注释非常的少。因为第一眼看这些个条件确实有些迷惑。

thp_fault_fallback：is incremented if a page fault fails to allocate a huge page and instead falls back to using small pages. 这里说的是allocate失败的时候才计数，上面这个代码还没到allocate的阶段，只是判断是否合适使用，如果不合适，也会fallback。而且有相关的fall-back的计数。最近在总结之前THP引出的一个问题，发现了一个让人迷惑的问题，记录总结一下过程。

node和numa算是强挂钩关系了。和node相关的，几乎全部是numa。所以不要疑惑node和numa的强关联性。

如果有很多的client使用一个NAT服务IP，可能出现链接的问题。因为每个client的时间不统一，这样导致TCP带有的timestamp在远端看起来有些滞后，滞后之后就会被认为是不安全的链接。表象是有些链接连接超时，断断续续的。解决方法就是在NAT的环境里，去掉timestamp的选项。

在这个特定的情境中，ip_no_pmtu_disc 参数的值为0表示启用路径 MTU 发现，而不是禁用。这种设定可能会引起一些混淆，因为通常我们期望一个布尔类型的参数，值为1表示启用，值为0表示禁用。在这里，0 表示启用路径 MTU 发现，可能与一些人的直觉相悖。这个参数的迷惑性在于双重否定，字面意思是关闭PMTU发现的功能。这种设定可能会使人感到困惑，特别是对于不熟悉该参数含义的人。通常，为了避免混淆，文档和配置界面应该提供清晰的说明，以确保用户能够正确理解参数的含义和所代表的状态。

就这个对比问题的发生情况，我们有几个怀疑点，一个是就是人与人的不同，另一个是抓的地方不一样，经过缜密的分析，环境的问题不大，倒是人的差别不小。因为大家对于tcpdump的使用习惯非常的不同，现场由于对现场产品的操作的高要求，可能会考虑所抓包的大小问题，当然是期望在抓取文件比较小的时候，同时可以定位问题；而研发的这种潜意识要小一些，不是将磁盘空间的大小排在第一位，而是将调查问题的原因考虑在第一位。最近又遇到一个类似的问题，也是在tcpdump抓到的包里没有找到应该看到的包，搞得很迷惑。

看着非常有价值来做分析，比如查看当前socket的一些时间，计数上的统计，可以帮助分析问题。当然这个是瞬时的一个数据，但是也可以作为分析的基础。从TCP的使用手册上看，这个选项的作用是返回一个结构体数据。2.4 就引入了，其实大家可以用起来这个选项。ss -i 参数也是使用这个选项。

这个结构体的定义是基本相同，除了linux/if.h里在最后多了一个结构体变量（16个字节）。也就是最终传递给linux内核的内容，内核还是可以匹配，只要不使用多出来的这个变量。上面这个编译错误最终是被解决了，就是怎么放这两个文件都没有问题，顺序无关，order-free。这两个头文件，如果已经存在net/if.h话，后续linux/if.h 里的某些定义会失效。最近看到一段代码改动，用net/if.h替换了linux/if.h。那唯一的好处是，如果是堆上存放这个类型变量，占用的内存小。

这个和网卡的event-notify是一样的逻辑，内核看到有什么事情发生，可以通知到用户，然后用户可以根据自己的需求做一些处理。第一次看到，记录一下算是可以日后可以用到的功能。

【代码】Linux: sysctl: rp_filter;包到了内核，没有到socket，火星包martia。

有一种情况是：当IP6的地址处于tentative的时候，就会返回这个错误。下面的是bind的调用的时候会check地址的flag。如果是tentative就返回：err = -EADDRNOTAVAIL;

可能的原因是，功能单一，作用不是很明显。而且即使可以知道哪里有delay，还需要依靠其他的工具继续做调试。但是这个工具，可以给出一个概览出来，其实还是比较适合做debug用。下面的count值是每个类型实际的执行情况。可以在内核启动的cmdline里加入这个参数来，取消延迟计数的功能。

10099 tgkill(10025, 10110, SIGRT_7 ，如果根据这个SIGRTMIN来算的话，这个值是39.glibc提供的SIGRTMIN是 34，glibc为pthread 预留了两个signal。比如下面这个信号根据linux里的值来算，就是SIGRTMIN+7， = 39.这里的39意思是指SIGRTMIN+5；而不是 SIGRTMIN+7.这里的注释也说了，从用户侧来说，这个值可能会变；从Linux的源代码看，这个值可以是：32。