systemtap

1. 安装 SystemTap 1. 首先安装内核开发包和调试包: # rpm -ivh kernel-debuginfo-common-($version).rpm # rpm -ivh kernel-debuginfo-($version).rpm # rpm -ivh kernel-devel-($version).rpm 其中 $version 使用 linux 命令 uname -a 查看，需要保证内核版本和上述开发包版本一致才能使用 systemtap。 centos 7 的 debuginfo 相关 rpm 包可以在如下链接下载： debuginfo.centos.org/7/x86_64 。 kernel-devel-uanme-r 的 rpm 在该链接中下载： kernel-devel-uname-r 2. 安装 systemtap # yum install -y systemtap # ... # 测试systemtap安装成功否： # stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}' # 出现如下信息表示安装成功： Pass 1: parsed user script and 472 library scripts using 239992virt/41844res

3 月，跳不动了？>>> 大家先看一下二个 命令 ，假如huge_dump.sql文件很大，然后猜测一下哪种导入方式效率会更高一些? # 命令 1，管道导入 shell > cat huge_dump.sql | mysql -uroot; # 命令2，重定向导入 shell> mysql -uroot < huge_dump.sql; 大家先看一下上面二个命令，假如huge_dump.sql文件很大，然后猜测一下哪种导入方式效率会更高一些? 这个问题挺有意思的，我的第一反应是：没比较过，应该是一样的，一个是cat负责打开文件，一个是bash 这种场景在MySQL运维操作里面应该比较多，所以就花了点时间做了个比较和原理上的分析： 我们先构造场景： 首先准备一个程序b.out来模拟mysql对数据的消耗： int main(int argc, char *argv[]) while(fread(buf, sizeof(buf), 1, stdin) > 0); return 0; } $ gcc -o b.out b.c $ ls|./b.out 再来写个systemtap 脚本 用来方便观察程序的行为。 $ cat test.stp function should_log(){ return (execname() == "cat" || execname() == "b.out"

3 月，跳不动了？>>> 如果遇到 MySQL 慢的话，你的第一印象是什么，如果MySQL 数据库性能不行，你是如何处理的？ MySQL 慢怎么办 如果遇到 MySQL 慢的话，你的第一印象是什么，MySQL 数据库如果性能不行，你是如何处理的？ 我咨询了一些同行, 得到了以下反馈： 第一反应是再试一次 第二个反应是优化一下 SQL 第三个反应是调大 buffer pool，然后开始换硬件了，换一下 SSD 最后实在不行了找个搜索引擎搜索一下“MySQL 慢怎么办”。 如果大家用的是国内的搜索引擎的话，搜索引擎会推荐某某知道或者某某乎, 推荐一些 MySQL 调优经验, 调大参数 A, 调低参数 B, 诸如此类，类似的网站能告诉你 MySQL 慢怎么办。 我们来分析一下这些现象背后隐藏的意义： 如果再试一次能够成功的话, 意味着你可能碰到了不可复现的外界因素的影响，导致 MySQL 会慢。 如果优化 SQL 能解决，就意味着 SQL 的执行复杂度远远大于它的需求复杂度。 如果调大 buffer pool 能解决，就意味着 MySQL 碰到了自身的某些限制。 如果换 SSD 能解决，那么意味着服务器资源受到了一定的限制。 如果需要搜索引擎，意味着调优这事已经变成了玄学。 本文向大家分享我对 MySQL 慢的诊断思路，以及向大家介绍系统观测工具。 MySQL 慢的诊断思路 MySQL

3 月，跳不动了？>>> 前些日子，监控显示线上偶尔发生请求两秒超时的情况。解决这个问题前前后后花了不少时间，也走了一些弯路。这里记录下来备忘。 前期分析 首先需要了解一下我们的服务： 我们的服务是一组无状态的前端服务器加上有状态的后端存储层。 这些服务都部署在腾讯云黑石服务器上面。 第一件事是要定位问题出现在前端还是后端。通过日志，我们发现在出错时间段里，每个前端服务器都有报错，并且出错请求都是发往同一后端服务器的。由此可见，问题出现在后端服务上。 接下来，需要分析出错的特征。通过日志发现错误都是因为前端两秒超时导致，而后端在前端超时之后事实上是完成了请求。因为是存储服务，我们自然在第一时间就查看了磁盘的情况。果然，在出错时，磁盘的 io.util 非常高( sar -dp 的输出，从第4列开始分别是 tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util )： 需要注意的是： io.util非常高，且只持续了2~3秒 几乎所有盘的io.util都高 io的tps和吞吐并不高 另外，还发现了另外一个规律：单台机器，大概每12小时左右会出现io.util高，并伴随着超时出错： 问题排查 快速排查 我们做了一些快速排查，试图以比较小的代价找到问题的根源： 查看系统的定时任务 查看系统日志 查看存储服务代码中的定时任务 可惜

Linux - yum update更新失败解决方案 yum update更新一半挂掉了，解决方案 yum update更新一半挂了，会有很多软件包留在仓库，引起各种各样的问题 首先 yum clean all 安装 package-cleanup工具，有下面命令就不需要安装了，有的系统会自带 yum install yum-utils 然后更新一下仓库 package-cleanup --cleandupes 现在yum 应该就恢复正常了 继续yum update 可能会有问题，没有请忽略 根据提示是systemtap这个软件引起的， rpm -qa |grep systemtap 所以我暂时卸载掉了他的几个包 rpm -e systemtap-2.8-10.el7.x86_64 systemtap-devel-2.8-10.el7.x86_64 发现问题解决 这个软件貌似是监控程序，卸载不会引起问题，待观察中 再次更新仓库： package-cleanup --cleandupes 重新安装systemtap yum install -y systemtap 成功 引用： https://blog.csdn.net/qq_25611295/article/details/81081833 来源： https://www.cnblogs.com/1285026182YUAN/p

在学习sysytemtap的过程中，我们需要常常查阅它的文档，也就是以下这个网站。 [Systemtap官方文档](https://sourceware.org/systemtap/documentation.html) 通常来说，里面的函数足以完成操作系统老师布置的一切任务。你的作业只需调用里面的函数。 对于作业中的打印进程生命周期，只需根据要求不断加入探针probe即可。 方法简单无脑，机械根据实验说明中给出的表格官网查找相关指针，调用即可。但是对于英语阅读能力差的人来说挺痛苦。 而对于编写脚本 task_struct.stp，打印 task_struct 相关信息，我们首先要明白task_struct位于sched.h中。task_struct的指针关系可自行查找相关博客。代码如下： 主要原理为通过不断调用基础的get_prev_task和get_next_task函数获取task的sibiling和parent，通过@cast指针在task_struct结构中获取相关信息，通过调用官网查来的函数获取file_struct中的file信息。 来源： CSDN 作者： 琪琪说她在努力 链接： https://blog.csdn.net/weixin_40996519/article/details/104572606

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 我的应用程序在Linux上作为后台进程运行。 它目前在终端窗口的命令行中启动。 最近一个用户正在执行该应用程序一段时间，它神秘地死了。 文本： 杀害 在终端上。 这发生了两次。 我问是否有人在不同的终端使用kill命令来杀死进程？ 没有。 在什么条件下Linux会决定杀死我的进程？ 我相信shell显示“已杀死”，因为该进程在收到kill（9）信号后死亡。 如果Linux发送了kill信号，系统日志中是否会有消息说明它被杀的原因？ #1楼 用于限制资源 的 PAM模块 完全导致了您描述的结果：我的进程神秘地死于控制台窗口上的文本 Killed 。 在 syslog 和 kern.log中 都没有日志输出。 顶级 程序帮助我发现，在一分钟的CPU使用后，我的进程被杀死了。 #2楼 我最近遇到了这个问题。 最后，我发现我的进程在自动调用Opensuse zypper更新后被终止。 禁用zypper更新解决了我的问题。 #3楼 尝试： dmesg -T| grep -E -i -B100 'killed process' -B100 表示杀戮发生前的行数。 在Mac OS上省略 -T 。 #4楼 正如dwc和Adam Jaskiewicz所说，罪魁祸首可能是OOM杀手。 但是，接下来的问题是：如何防止这种情况发生？

个人认为此文对动态追踪的东西介绍比较宽泛，但可用于指导学习动态追踪技术知识。特此转载。原文地址: http://openresty.org/posts/dynamic-tracing/#rd?utm_source=tuicool&utm_medium=referral 动态追踪技术漫谈 关于作者 大家好，我是章亦春，网名 agentzh。很多朋友可能是通过我做的一些开源项目了解到我的，比如我创立的 OpenResty 开源项目，再比如我编写的很多 Nginx 的 第三方模块 ，我从大学时代就开始贡献的 Perl 开源模块 ，以及最近一些年写的很多 Lua 方面的库。我的兴趣比较广泛，喜欢抽象层次很高也比较花哨的东西，比如函数式和逻辑式编程语言；同时又对很底层的东西非常感兴趣，比如操作系统、Web 服务器、数据库、高级语言编译器等系统软件；尤其喜欢构建和优化较大规模的互联网应用系统。 什么是动态追踪 我很高兴能在这里和大家分享动态追踪技术（Dynamic Tracing）这个主题，对我个人来说也是一个很激动人心的话题。那么，什么是动态追踪技术呢？ 动态追踪技术其实是一种后现代的高级调试技术。它可以帮助软件工程师以非常低的成本，在非常短的时间内，回答一些很难的关于软件系统方面的问题，从而更快速地排查和解决问题。它兴起和繁荣的一个大背景是，我们正处在一个快速增长的互联网时代，作为工程师