2018-12-04【D5补卡】
我的系统是centos7，上次实战用 perf top -g -p pid没有看到函数名称，只能看到一堆十六进制的东西，然后老师给了解决方法，我转述下：
分析：当没有看到函数名称，只看到了十六进制符号，下面有Failed to open /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.4, continuing without symbols 这说明perf无法找到待分析进程所依赖的库。这里只显示了一个，但其实依赖的库还有很多。这个问题其实是在分析Docker容器应用时经常会碰到的一个问题，因为容器应用所依赖的库都在镜像里面。
老师给了两个解决思路：
（1）在容器外面构建相同路径的依赖库。这种方法不推荐，一是因为找出这些依赖比较麻烦，更重要的是构建这些路径会污染虚拟机的环境。
（2）在容器外面把分析纪录保存下来，到容器里面再去查看结果，这样库和符号的路径就都是对的了。
操作：
（1）在Centos系统上运行 perf record -g -p <pid>，执行一会儿（比如15秒）按ctrl+c停止
（2）把生成的 perf.data（这个文件生成在执行命令的当前目录下，当然也可以通过查找它的路径 find | grep perf.data或 find / -name perf.data）文件拷贝到容器里面分析:
docker cp perf.data phpfpm:/tmp
docker exec -i -t phpfpm bash
$ cd /tmp/
$ apt-get update && apt-get install -y linux-perf linux-tools procps
$ perf_4.9 report
注意：最后运行的工具名字是容器内部安装的版本 perf_4.9，而不是 perf 命令，这是因为 perf 会去跟内核的版本进行匹配，但镜像里面安装的perf版本有可能跟虚拟机的内核版本不一致。
注意：上面的问题只是在centos系统中有问题，ubuntu上没有这个问题展开 3 78
2018-11-30Day 5，干活满满啊，谢谢老师啊。
今天总结如下：
1、Linux并发(任务并行)的实质：Linux 作为一个多任务操作系统，将每个 CPU 的时间划分为很短的时间片，再通过调度器轮流分配给各个任务使用
2、cpu的维护，通过实先定义的节拍率(内核用赫兹HZ标示)触发时间判断(全局变量jiffies记录)。
3、节拍率是内核态运行，属于内核空间节拍率；用户空间节拍率( USER_HZ)是一个固定设置
[root@dbayang ~]# grep 'CONFIG_HZ=' /boot/config-$(uname -r)
CONFIG_HZ=1000
4、/proc/stat 提供的就是系统的 CPU 和任务统计信息； /proc/[pid]/stat展示进程的CPU和任务统计信息
5、cpu的使用率={1-(idle_time/total_cpu_time)}/sample_time
6、性能分析工具给出的都是间隔一段时间的平均 CPU 使用率，所以要注意间隔时间的设置。top默认为3s，ps使用的是进程运行时间。
7、top、vmstat、mpstat等命令种关于cpu性能相关指标的含义
8、pidstat命令含义
9、perf
以前用到的一堆[n]trace分析工具，perf的直观易用，这是今天最大的收获，作为dba对数据库的分析也很有的，么么哒。
perf top、perf record、perf report
对进程进行跟踪分析其调用perf top -g -p <mysqlpid>
10、今天用到测试工具：ab展开作者回复: 👍 课代表的总结很全面
53
2018-11-30【D5】打卡
干货满满
使用Markdown整理成了笔记， 配合目录查回顾，会方便很多
https://www.zybuluo.com/Gugoole/note/1354842 32
2018-11-30老师，我的也是无法定位到具体的函数，都是16进制显示的 26- 2018-11-30【day5】打卡
早晨六点半起来跟着专栏在虚拟机上搞，这个案例能完整跟下来也是不容易，还需要docker，个人认为，这种实战的课，一定要上手，光看是不行的。愿自己能坚持下去。 12 
2018-12-01内核如果没有perf package的话，可以从git下载源码安装
https://askubuntu.com/questions/50145/how-to-install-perf-monitoring-tool/306683
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git （大约2.5G 左右）
cd linux/tools/perf
make （可能缺flex，bison等，需自行安装）
cp perf /usr/bin
perf --version展开作者回复: 感谢分享
8
2018-11-30iowait所耗费的时间，应该不算到cpu使用率里面吧？ 如果是这样的话，上面计算cpu使用率 除去idle以外的时间都算，是不是有问题？ 8
2018-11-30cpu使用率，就是cpu被使用的比例，也就是空闲之外的使用比例。
对我来说，发现cpu使用率高后，先跟老师一样用perf来抓取cpu消耗栈，很容易发现瓶颈。
另外，我一般用mpstat -P ALL 来看各个cpu核心的使用率情况，因为top之类的看的是系统总使用率，不一定能发现问题，特别是多进程或者多线程应用作者回复: 👍
8
2018-12-02执行perf top -g -p （php-fpm进程号），发现不了sqrt函数作者回复: 只看到地址而不是函数名是由于应用程序运行在容器中，它的依赖也都在容器内部，故而perf无法找到PHP符号表。一个简单的解决方法是使用perf record生成perf.data拷贝到容器内部 perf report。
1 7- 2018-12-01每天上班地铁听一遍，下班地铁听一遍，晚上做实验
作者回复: 👍
1 6 
2018-11-30『D6打卡』
还没有操作实验，看了内容，先占个位置。 5
2018-11-30老师，问个问题，我按您的文档，我使用perf top -g -p 进程ID 怎么无法查看php-fpm的调用关系，出不来哪个函数较用较高的CPU？ 以下是我的显示结果，您帮我看看为什么显示的是0x7fd...
1、开始压力测试
ab -c 10 -n 10000 http://bjdsj-test-11-58:10001
2、查看调用关系 perf top -g -p 39826
Samples: 80K of event 'cycles', Event count (approx.): 29700884257
+ 93.02% 0.69% php-fpm [.] 0x00000000008c296e
0x7fd84a21c96e
0x7fd84a21d323
0x7fd84a185f94
0x7fd84a0d66fc
0x7fd84a325642
0x7fd842a702e1
0x6cb6258d4c544155
+ 23.35% 0.38% php-fpm [.] 0x00000000008c4a7c
+ 5.60% 5.60% libm-2.24.so [.] 0x000000000002127e
+ 4.22% 0.00% php-fpm [.] 0x000000000098dd97
+ 2.54% 2.54% php-fpm [.] 0x000000000094ede0
+ 1.96% 1.96% php-fpm [.] 0x0000000000681b9d
+ 1.58% 1.58% php-fpm [.] 0x0000000000815e70
+ 1.52% 1.51% php-fpm [.] 0x000000000094eddc
+ 1.48% 1.48% php-fpm [.] 0x00000000008cd729
+ 1.32% 1.32% php-fpm [.] 0x00000000008c4ae5
+ 1.21% 1.21% php-fpm [.] 0x000000000098dc03
+ 1.04% 1.04% php-fpm [.] 0x0000000000681b99
Failed to open /opt/bitnami/php/lib/php/extensions/opcache.so, continuing without symbols展开 4
2019-02-09老师，弱弱的请教下怎么用docker安装您那个nginx和php环境和程序，我以前没用过docker，刚学的，见谅。作者回复: 按照文中的步骤操作就可以
3- 2019-01-07老师你好 我写了一个python死循环 代码如下
def wangfang():
while True:
i =1
wangfang()
使用perf top命令 无法抓取到该循环的函数, 老师能解释一下吗展开 3 
2018-11-30[D5打卡]
以前只会用top看CPU使用率，发现占用高的进程了再针对性的分析，比如c程序就用prof，局限性很高，
今天了解到可以用perf，直接看进程内函数调用栈和各函数的cpu使用率。
以前看到%sys过高，系统中断数过高的判断方法更搞笑，挨个杀可疑进程。
现在直接用pidstat就是了。
——————
最近在某云服务器上就遇到了诡异的事情，cpu空闲75%，%iowait不到1，系统中断数一直比较稳定，vmstat中的r正在运行和等待队列也还正常，但是系统每隔1小时23分，负载load1：就会从平常的0.2升高到8甚至是12的情况。好在每次持续时间较短，约2分钟，load5的值还可以接受。
争取最近能把原因查出来，早点把学费赚回来，哈哈😄
—————
虽然之前学k8s专栏时ubuntu 18.04 和docker都配好了，但是最近手上事情有点多，还是先解决手上的事情吧。老师见谅哈。展开作者回复: 很多线上问题其实跟这个类似，等到你登陆服务器的时候性能问题已经结束了，这样在线分析就看不出哪里导致的问题，只有从平均负载这种反应历史的指标看出一些问题。
这种情景下，就需要监控系统的配合，记录下历史的系统和进程的性能指标。并且，这个case只有load1高，所以监控的间隔时间也需要比较精细。 3
2018-12-15我安装的ubuntu 18.04 live server版本，使用如下指令安装的perf：
apt install linux-tools-generic作者回复: 👍 谢谢分享安装方法
1 2- 2018-12-04为什么iowait高会导致cpu使用率高，还有例子中定位函数关系链那里sqrt那里看只有3.97%，怎么就确定是这个引起的。 2
- 2018-12-02使用perf 只能分析到16进制的地址，无法显示函数名称
作者回复: 只看到地址而不是函数名是由于应用程序运行在容器中，它的依赖也都在容器内部，故而perf无法找到PHP符号表。
2 - 2018-12-02[Day6打卡]
文章前面（查询 man proc 就可以），木有这么个命令吧？作者回复: man是Linux最基本的命令
2 
2018-12-02用sysbench测试cpu性能，然后利用perf 找到具体哪个进程的哪个函数在消耗CPU
gjw@gjw:/etc/apt$ sysbench --threads=1 --time=600 cpu run
sysbench 1.1.0 (using bundled LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
查看sysbench进程
ps -egjw@gjw:~$ ps -ef | grep sysbench
gjw 31921 1294 77 11:20 pts/0 00:04:39 sysbench --threads=1 --time=600 cpu run
perf top获取进程信息：
sudo perf top -g -p 31921
Samples: 824 of event 'cycles:ppp', Event count (approx.): 618842235
Children Self Shared Object Symbol
+ 100.00% 100.00% sysbench [.] cpu_execute_event
然后在sysbench源码中查看cpu_execute_event 函数：
gjw@gjw:~/soft/sysbench-master$ grep -r cpu_execute_event
Binary file src/tests/cpu/libsbcpu.a matches
Binary file src/tests/cpu/libsbcpu_a-sb_cpu.o matches
src/tests/cpu/sb_cpu.c:static int cpu_execute_event(sb_event_t *, int);
src/tests/cpu/sb_cpu.c: .execute_event = cpu_execute_event,
src/tests/cpu/sb_cpu.c:int cpu_execute_event(sb_event_t *r, int thread_id)
Binary file src/sysbench matches
gjw@gjw:~/soft/sysbench-master$ vi src/tests/cpu/sb_cpu.c
int cpu_execute_event(sb_event_t *r, int thread_id)
{
unsigned long long c;
unsigned long long l;
double t;
unsigned long long n=0;
(void)thread_id; /* unused */
(void)r; /* unused */
/* So far we're using very simple test prime number tests in 64bit */
for(c=3; c < max_prime; c++)
{
t = sqrt((double)c);
for(l = 2; l <= t; l++)
if (c % l == 0)
break;
if (l > t )
n++;
}
return 0;
可以看到该函数在计算素数，由此完成了一个cpu使用率很高的案例分析展开作者回复: 很详细的分析步骤，感谢分享👍
2