strace

手把手教你用Strace诊断问题 发表于 2015-10-16 早些年，如果你知道有个 strace 命令，就很牛了，而现在大家基本都知道 strace 了，如果你遇到性能问题求助别人，十有八九会建议你用 strace 挂上去看看，不过当你挂上去了，看着满屏翻滚的字符，却十有八九看不出个所以然。本文通过一个简单的案例，向你展示一下在用 strace 诊断问题时的一些套路。 如下真实案例，如有雷同，实属必然！让我们看一台高负载服务器的 top 结果： top 技巧：运行 top 时，按「1」打开 CPU 列表，按「shift+p」以 CPU 排序。 在本例中大家很容易发现 CPU 主要是被若干个 PHP 进程占用了，同时 PHP 进程占用的比较多的内存，不过系统内存尚有结余，SWAP 也不严重，这并不是问题主因。 不过在 CPU 列表中能看到 CPU 主要消耗在内核态「sy」，而不是用户态「us」，和我们的经验不符。Linux 操作系统有很多用来跟踪程序行为的工具，内核态的函数调用跟踪用「strace」，用户态的函数调用跟踪用「ltrace」，所以这里我们应该用「strace」： shell> strace -p <PID> 不过如果直接用 strace 跟踪某个进程的话，那么等待你的往往是满屏翻滚的字符，想从这里看出问题的症结并不是一件容易的事情，好在 strace

因为最近接手的项目是基于嵌入式Linux openwrt的，一开始以为会跟之前的服务器开发没什么大的区别，但是遇到问题去分析的时候才发现，工具链还是有些差别的，openwrt的netstat是属于一个叫做busybox的工具集的，这个工具集是专门提供给嵌入式Linux，它的参数很简单，居然没有Linux下netstat的-p选项，因此当我想查看是哪些进程在监听哪些端口时，发现只能查看有哪些监听端口，无法得知是属于哪个进程的，lsof也没有-i选项。 但是有时候排查问题又必须知道哪个进程监听了某个端口，因此就想搞清楚Linux下的netstat是怎么实现可以查看监听端口属于哪个进程呢。 首先想法就是去下载busybox的源代码，但是感觉代码太多了，费时费力，于是灵机一动想到Linux下的另一个工具strace（追踪程序调用的系统调用），通过strace来查看netstat执行时都做了什么操作。 谢谢@Dlemon的提示，特别说明一下： 只有当netstat加了-p参数需要展示进程id时才会有下面getdents这个函数调用，因为此时需要展示进程id，而/proc/net/tcp或者/proc/net/udp中没有包含进程id，只能去/proc目录下遍历。 截取了strace输出的某一段，可以看到，调用open以及readlink遍历了/proc/3055/fd/目录下的所有文件

问题 我们都知道 MySQL 的 Table Cache 是表定义的缓存，江湖上流传着各种对这个参数的调优方法。 本期我们通过实验来验证 Table Cache 的作用。 实验 我们先创建一个测试数据库： 建一张空表： 建立一个连接，检查一下会话的初始状态： 在另一个窗口，开启 strace 追踪 MySQL 服务器的文件操作： 在 MySQL 中 select 新创建的表： 检查状态： 看到该操作没命中 table cache。查看 strace，确实发现 mysqld 进程打开了表结构文件（test_tbl.frm），如果我们在 strace 中也抓获 read 事件（参数改为 "-e file,read"），那可以看到 mysqld 确实读取了表结构文件。 我们再次在该会话中进行 select： 可以看到开始命中 table cache 了。在 strace 的输出中，也没有抓到新的文件操作。 可以看出 table cache 的作用，就是节约读取表结构文件的开销。 那不命中 table cache，一定会有读取表结构文件的开销么？ 我们开一个新的会话，这里增加了一个标识来区分会话： 在新会话中进行 select，查看状态： 看起来确实 table cache 没有命中，也就是说 table cache 是针对于线程的，每个线程有自己的缓存，只缓存本线程的表结构定义

一、分析总结 系统是应用的运行环境，系统的瓶颈会导致应用的性能下降； 而应用的不合理设计，也会引发系统资源的瓶颈。 （1）CPU 性能分析 （2）内存性能分析 （3）磁盘和文件系统 I/O 性能分析 （4）网络性能分析 （5）应用程序瓶颈分析 1）strace，观察系统调用； 2）perf 和火焰图，分析热点函数； 3）动态追踪技术，来分析进程的执行状态。     二、优化总结 （1）CPU 优化 核心在于排除所有不必要的工作、充分利用 CPU 缓存并减少进程调度对性能的影响。 1）把进程绑定到一个或者多个 CPU 上，充分利用 CPU 缓存的本地性，并减少进程间的相互影响。 2）为中断处理程序开启多 CPU 负载均衡，以便在发生大量中断时，可以充分利用多 CPU 的优势分摊负载。 3）使用 Cgroups 等方法，为进程设置资源限制，避免个别进程消耗过多的 CPU。同时，为核心应用程序设置更高的优先级，减少低优先级任务的影响。 （2）内存优化 核心是解决内存使用的问题，如 可用内存不足、内存泄漏、Swap 过多、缺页异常过多以及缓存过多等。 1）除非有必要，Swap 应该禁止掉。这样就可以避免 Swap 的额外 I/O ，带来内存访问变慢的问题。 2）使用 Cgroups 等方法，为进程设置内存限制。这样就可以避免个别进程消耗过多内存，而影响了其他进程。对于核心应用，还应该降低

linux监控命令 01 ------ iostat 02/03 ------ meminfo/free 04 ------ mpstat 05 ------ netstat 06 ------ nmon 07 ------ pmap 08/09 ------ ps/pstree 10 ------ sar 11 ------ strace 12 ------ tcpdump 13 ------ top 14 ------ uptime 15 ------ vmstat 16 ------ wireshark 来源： oschina 链接： https://my.oschina.net/u/4344048/blog/4304955

这世界有10种人，一种人懂二进制，另一种人不懂二进制。 ——鲁迅 大家好，我是良许。 二进制文件是我们几乎每天都需要打交道的文件类型，但很少人知道他们的工作原理。这里所讲的二进制文件，是指一些可执行文件，包括你天天要使用的 Linux 命令，也是二进制文件的一种。 Linux 系统给我们提供了非常多用于分析二进制文件的工具，不管你在 Linux 下从事的是何种工作，知道这些工具也会让你对你的系统更加了解。 在本文中，将介绍几种最常用的用于分析二进制文件的工具及命令，这些工具在大部分发行版里可以直接使用，如果不能直接用的话，可以自行安装。 file file 命令用于分析文件的类型。 如果你需要分析二进制文件，可以首先使用 file 命令来切入。我们知道，在 Linux 下， 一切皆文件 ，但并不是所有的文件都具有可执行性，我们还有各种各样的文件，比如：文本文件，管道文件，链接文件，socket文件，等等。 在对一个文件进行分析之前，我们可以首先使用 file 命令来分析它们的类型。当然除此之外，我们还可以看到一些其它信息。 $ file /bin/pwd /bin/pwd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux

生产多次遇到文件描述符（fd）泄露相关的问题， 文件描述符泄漏一般引起 的现象是文件句柄数（封面图）/tcp alloc（上图）增长。文章分为两部分介绍文件描述符相关内容，第一部分介绍文件描述基础知识，第二部分通过实际案例进行剖析。 一. 文件描述符相关基础知识 什么是文件描述符？ 内核利用文件描述符来访问文件, 打开现存文件或新建文件（建立）时，内核会 返回一个文件描述符，读写文件也需要使用文件描述符来指定待读写的文件。所有 执行I/O操作(包括网络socket操作)的系统调用都通过文件描述符 ​ 最大文件描述符介绍 系统最大文件描述符限制 sysctl -a | grep fs.file-max （查看系统最大描述符） echo “fs.file-max=1610270” >> /etc/sysctl.conf（修改最大描述符） sysctl -p（立即生效） 用户级最大文件描述限制 ulimit -n （查看用户最大描述符） echo “* hard nofile 65535” >> /etc/security/limits.conf echo “* soft nofile 65535” >> /etc/security/limits.conf 代表所有用户，支持具体用户（优先级高，不受影响）。文件修改即生效，退出 或打开新终端执行ulimit -n即看到修改效果

本文来自: PerfMa技术社区 PerfMa(笨马网络)官网 概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12)，发现一个系统老是被OS Kill掉，是内存泄露导致的。在查的过程中，阴差阳错地发现了JVM另外的一个Bug。这个Bug可能会导致大量物理内存被使用，我们已经反馈给了社区，并得到快速反馈，预计在OpenJDK8最新版中发布(JDK11中也存在这个问题)。 PS：用户的那个问题最终也解决了，定位下来算是C2的一个设计缺陷导致大量内存被使用，安全性上没有得到保障。 找出消耗大内存的线程 接下来主要分享下这个BUG的发现过程，先要客户实时跟踪进程的情况，当内存使用明显上升的时候，通过/proc/<pid>/smaps，看到了不少64MB的内存分配，Rss也基本消耗完了。 7fd690000000-7fd693f23000 rw-p 00000000 00:00 0 Size: 64652 kB Rss: 64652 kB Pss: 64652 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 64652 kB Referenced: 64652 kB Anonymous: 64652 kB AnonHugePages: 0 kB Swap:

进程监控类命令 本篇全是命令介绍 , 笔者把各个命令的都实验一遍 , 给同学们看看 . 一. PSTREE 命令 pstree - display a tree of processes 选项 : 　　-p 显示进程的 PID 　　-T 隐藏线程信息 　　-u 显示切换过程 　　-H PID 高亮显示指定 PID 进程的父进程 示例 : 二. PS 命令 ps - report a snapshot of the current processes. 选项 : PS 有三种风格的选项写法 : 　　BSD 风格写法 ps aux 　　UNIX 风格写法 ps -ef 　　GNU 风格写法 ps --pid PID BSD 风格选项 : 　　a 显示所有与终端有关的进程 　　x 显示所有与终端无关的进程 　　u 显示进程所有者相关的信息 　　f 命令列把相关的进程显示成进程树 　　k 对属性进行排序 , 属性前加上 - 表示倒序 　　o 选择显示的字段 pid cmd psr ni(nice) pri rtprio tid class %cpu %mem user ruser euser 等等 　　euser 表示显示有效用户字段 　　ruser 表示显示真是用户字段 　　psr 表示显示 CPU 与进程的绑定关系 　　pcpu CPU 的利用率 　　ppid 父进程的 PID