systemtap

上个礼拜我就想喷eBPF了，由于周末时间实在太紧，就准备拖延一周，但还是立了个flag，先发了个朋友圈： ebpf就像牛皮藓一样，已经遍布在linux内核的各个角落，每个调用点都看上去很随意，毫无规划，让人觉得好像自己觉得哪里需要这么一个调用点并不很难… 但实际上如果你真的去尝试在某处加一个ebpf调用点时，就会觉得这件事和清除牛皮藓的过程非常类似，修改散落在各个目录的多个文件，还得重新编译，大概率失败，还要重新做一次，很难一次做干净，当你好不容易成功了，会有一种“不过如此”的嗟叹… 我曾将ebpf比做扩散的癌细胞，这个比喻没有给人密集恐惧的效果，所以我换成了牛皮癣。该存在ebpf调用点的地方一个也没有，没必要ebpf的地方到处都是，这些点还在持续增加，迄至5.11内核，ebpf已经有大三十个点了，依然在毫无规划地疯长着… eBPF是个创新，但人们明显狂热过度了，ebpf增加调用点也过于随意，太业务导向了，损坏了内核的内聚性，远远比不上当初netfilter的五个hook点以及qdisc这种经过良好设计的机制，另外还有一个问题，netfilter的五个hook点上如果部署了ebpf点，其实就能解决大部分性能问题，然而直到现在都没有，感觉是社区矫枉过正了，真的彻底把netfilter当成了旧时代的象征，把马杀掉的同时，轮子也不要了 人们都像虫子一样在这里你争我抢，吃的都是良心

目录 背景 一、安装pg_stat_statements 二、加载pg_stat_statements模块 三、配置pg_stat_statements采样参数 四、创建pg_stat_statements extension 五、分析TOP SQL pg_stat_statements输出内容介绍 最耗IO SQL 最耗时 SQL 响应时间抖动最严重 SQL 最耗共享内存 SQL 最耗临时空间 SQL 六、重置统计信息 慢SQL到底慢在哪里？ 七、慢SQL、TOP SQL优化示例 八、常见优化点汇总 参考 背景 数据库是较大型的应用，对于繁忙的数据库，需要消耗大量的内存、CPU、IO、网络资源。 SQL优化是数据库优化的手段之一，优化什么SQL效果最佳呢？首先要了解最耗费资源的SQL，即TOP SQL。 从哪里可以了解数据库的资源都被哪些SQL消耗掉了呢？ 资源分为多个维度，CPU，内存，IO等。如何能了解各个维度层面的TOP SQL呢？ pg_stat_statements插件可以用于统计数据库的资源开销，分析TOP SQL。 一、安装pg_stat_statements 如果您使用的是云数据库，跳过安装，到create extension 部分。 pg_stat_statements是PostgreSQL的核心插件之一。可以在编译PostgreSQL时安装，也可以单独安装。

https://github.com/openresty/openresty-systemtap-toolkit https://sourceware.org/systemtap/langref/ https://github.com/brendangregg/FlameGraph 参考ngx-sample-lua-bt 现代linux 动态追踪技术 主要是基于 ebpf systemtap 是 动态追踪的前端， 技术原理是 编译一个 类似c的脚本 生成 内核模块， 来监控用户空间的lua程序 对openResty的脚本改造两点， 1： 去掉nginx相关函数的 probe 探针 2：如何获取LuaState 状态机的方法 调整， 可以使用程序内部的 全局变量定义 if(\@defined(\@var("globalL", "$lua_path"))) { L = \@var("globalL", "$lua_path") } 对timer 采样也可以调整 timer.profile 每个CPU周期 timer.ms 是 定时毫秒 动态追踪核心： 定义probe 探针位置 定义timer 采样 在timer中判断 PID 进程ID， 来确定自己要观察的程序 timer.s 观察总时长后结束 systemtap 的堆栈格式是 一次堆栈每层 文件:行号 总共出现次数 fix-bt 之后

这会儿不是工作日，这会儿是周六。 systemtap就是一个kprobe的DSL，本质上完成的是同一类工作，kprobe用起来比较麻烦，还要自己编写编译内核模块，相比而言，stap就方便很多。 既然kprobe可以修改内核结构体的内容，那么也就可以修改网络数据包咯，前面的文章描述了如何迷惑程序员的抓包行为，本文展示一下如何实现一个NAT端口转换逻辑，代码如下： # ! / usr / bin / stap - g % { # include <linux/tcp.h> # include <linux/ip.h> % } // 将来源于100.100.100.2的访问端口12345的流转换到访问22 function port_transform ( skb : long , type : long ) % { struct sk_buff * skb2 = ( struct sk_buff * ) STAP_ARG_skb ; struct iphdr * iph ; struct tcphdr * th ; iph = ip_hdr ( skb2 ) ; if ( iph -> protocol != IPPROTO_TCP ) return ; th = ( struct tcphdr * ) ( ( unsigned char * ) iph + ( iph -> ihl

首先参照https://www.cnblogs.com/wdw984/p/13330074.html，来进行如何安装Centos和离线下载rpm包。 离线下载jemalloc，上传到CentOS的/data/rpm/jemalloc目录 因为redis6.0.5推荐使用jemalloc管理内存，所以我们先安装jemalloc，按照以下顺序安装rpm包 rpm -ivh audit-libs-python- 2.8 . 5 - 4 .el7.x86_64.rpm rpm -ivh scl-utils- 20130529 - 19 .el7.x86_64.rpm rpm -ivh checkpolicy- 2.5 - 8 .el7.x86_64.rpm rpm -ivh libsemanage-python- 2.5 - 14 .el7.x86_64.rpm rpm -ivh libcgroup- 0.41 - 21 .el7.x86_64.rpm rpm -ivh python-IPy- 0.75 - 6 .el7.noarch.rpm rpm -ivh setools-libs- 3.3 . 8 - 4 .el7.x86_64.rpm rpm -ivh policycoreutils-python- 2.5 - 34 .el7.x86_64.rpm rpm -ivh rh

来自 Linux Rootkit如何避开内核检测的 Rootkit在登堂入室并得手后，还要记得把门锁上。 如果我们想注入一个Rootkit到内核，同时不想被侦测到，那么我们需要做的是精妙的隐藏，并保持低调静悄悄，这个话题我已经谈过了，诸如进程摘链，TCP链接摘链潜伏等等，详情参见： https://blog.csdn.net/dog250/article/details/105371830 https://blog.csdn.net/dog250/article/details/105394840 然则天网恢恢，疏而不漏，马脚总是要露出来的。如果已经被怀疑，如何反制呢？ 其实第一时间采取反制措施势必重要！我们需要的只是占领制高点，让后续的侦测手段无从开展。 我们必须知道都有哪些侦测措施用来应对Rootkit，常见的，不外乎以下： systemtap，raw kprobe/jprobe，ftrace等跟踪机制。它们通过内核模块起作用。 自研内核模块，采用指令特征匹配，指令校验机制排查Rootkit。 gdb/kdb/crash调试机制，它们通过/dev/mem，/proc/kcore起作用。 和杀毒软件打架一样，Rootkit和反Rootkit也是互搏的对象。 无论如何互搏，其战场均在内核态。 很显然，我们要做的就是： 第一时间封堵内核模块的加载。 第一时间封堵/dev/mem，

来自 《Linux动态为内核添加新的系统调用》 先来个满满的回忆： https://blog.csdn.net/dog250/article/details/6446192 2011年写这篇文章的时候，我的女儿小小还没有出生。 评价一下这篇文章，总体写得还不错，但排版不行。时间如白驹过隙，快十年过去了，今天我来旧事重提。 添加新的系统调用 ，这是一个老掉牙的话题。前段时间折腾Rootkit的时候，我有意避开涉及HOOK劫持系统调用的话题，我主要是想来点新鲜的东西，毕竟关于劫持系统调用这种话题，网上的资料可谓汗牛充栋。 本文的主题依然不是劫持系统调用，而是添加系统调用，并且是动态添加系统调用，即在不重新编译内核的前提下添加系统调用，毕竟如果可以重新编译内核的话，那实在是没有意思。 但文中所述动态新增系统调用的方式依然是老掉牙的方式，甚至和2011年的文章有所雷同，但是 这篇文章介绍的方式足够清爽！ 我们从一个问题开始。我的问题是： Linux系统中如何获取以及修改当前进程的名字？？ 你去搜一下这个topic，一堆冗余繁杂的方案，大多数都是借助procfs来完成这个需求，但没有直接的让人感到清爽的方法，比如调用一个getname接口即可获取当前进程的名字，调用一个modname接口就能修改自己的名字，没有这样的方法。 所以，干嘛不增加两个系统调用呢： sys_getname:

　　一个基于 Linux 操作系统的服务器运行的同时，也会表征出各种各样参数信息。通常来说运维人员、系统管理员会对这些数据会极为敏感，但是这些参数对于开发者来说也十分重要，尤其当你的程序非正常工作的时候，这些蛛丝马迹往往会帮助快速定位跟踪问题。 　　这里只是一些简单的工具查看系统的相关参数，当然很多工具也是通过分析加工 /proc、/sys 下的数据来工作的，而那些更加细致、专业的性能监测和调优，可能还需要更加专业的工具(perf、systemtap 等)和技术才能完成。 　　 一、CPU和内存类 　　 1.top命令 　 　 　　第一行：load average：在多处理器系统上，负载与可用处理器核心数相关。 单核系统上的“100％利用率”标记为1.00，双核即2.00。因此，平均负载为14.00和24核，您的服务器远远不会过载。 　　第二行：统计了系统的任务状态信息。running 很自然不必多说，包括正在 CPU 上运行的和将要被调度运行的；sleeping 通常是等待事件(比如 IO 操作)完成的任务，细分可以包括 interruptible 和 uninterruptible 的类型；stopped 是一些被暂停的任务，通常发送 SIGSTOP 或者对一个前台任务操作 Ctrl-Z 可以将其暂停；zombie 僵尸任务，虽然进程终止资源会被自动回收，但是含有退出任务的

Linux系统是一个让人感觉卡顿的系统，先别怼，让我说完： 卡顿的原因在于Linux内核的调度器从来不关注业务场景！ Linux内核只能看到机器而不愿意看到应用。它倾向于自下而上从CPU角度提高吞吐，而不是自上而下从业务角度提高用户体验。 拟人来看，Linux是一个好程序员，但不是一个好经理。 万事必有因缘，Linux就是一个程序员发起一帮程序员折腾起来的，几乎没有穿西装的经理之类的人参与。 程序员天天挂在嘴边的就是性能，时间复杂度，cache利用率，CPU，内存，反之，经理每天吆喝的就是客户，客户，客户，体验，体验，体验！ 前天晚上下班回到住处已经很晚，姓刘的副经理请教了我一个问题，说是他在调试一个消息队列组件，涉及到生产者，消费者等多个相互配合的线程，非常复杂，部署上线后，发现一个奇怪的问题： 整个系统资源似乎被该组件的线程独占，该消息队列组件的效率非常高，但其系统非常卡顿！ 我问他有没有部署cgroup，cpuset之类的配置，他说没有。 我又问他该消息队列组件一共有多少线程，他说不多，不超过20个。 我又问…他说… … 我感到很奇怪，我告诉刘副经理说让我登录机器调试下试试看，他并没有同意，只是能尽可能多的告诉我细节，我来远程协助。 … 我并不懂消息队列，我也不懂任何的中间件，调试任何一个此类系统对我而言是无能为力的，我也感到遗憾