Linux系统很重要的一个性能提升点就是它的Pagecache， 因为内存比IO快太多了，所以大家都想进办法来利用这个cache。 文件系统也不例外，为了达到高性能，文件读取通常采用预读来预测用户的行为，把用户可能需要的数据预先读取到cache去，达到高性能的目的。
Linux各个发行版readahead的实现差异很大，我们这里重点讨论2.6.18, RHEL 5U4发行版的行为.文件预读的实现主要在mm/readahead.c中，代码才603行。 预读的流程大概是这样的，用户需要文件页面的时候入口函数do_generic_mapping_read会委托page_cache_readahead来进行处理。它首先判断用户的IO是顺序的还是随机的,如果是随机的就没啥好预读. 如果是顺序的话，那么预读算法会根据用户上一次读取的页面的使用情况评估出预读的窗口，决定要读多少页面。读页面的模块会先检查要读取页面在pagecache里面是否已经存在，如果不存在的话就需要发起IO请求，读取相应的页面。还有个路径就是在文件mmap缺页的时候filemap_nopage调用do_page_cache_readahead进行预读, 不过这个路径在通常的环境里概率不高.
这个预读的关键参数有3个: 用户的req_size, 预读算法评估出来的nr_to_read,以及实际上IO读取的页面数actual。
接下来我们就是要查看系统是如何运作的，所以我首先写了个systemtap脚本叫做ratop.stp来获取这些数据：
Read more…
我们在调优IO 密集型的应用是通常需要知道IO的使用情况. 但是iostat只能知道系统全局的,iotop只能知道每个应用的, 我们有时候需要细化到每个应用对每个设备的使用情况. 比如说mysql数据库我们通常把日志和数据分开到不同的设备, 那我们需要知道数据读写多少,日志读写多少,分开的了解.
目前还没有工具能够很轻松的了解. 幸运的是systemtap自己带的disktop可以帮我们做到,位于/usr/share/doc/systemtap/examples/io/disktop.stp.
Read more…
最近有同学反映在某些新机器上做性能调优的时候， oprofile 有时抓不到数据，我之前也遇到这个情况，很是无语，今天特地验证了下。
# 我们的操作系统和机器配置大概是这样的：
$sudo aspersa/summary
# Aspersa System Summary Report ##############################
Date | 2011-03-31 16:26:05 UTC (local TZ: CST +0800)
Hostname | my031226.sqa.cm4
Uptime | 10:00, 4 users, load average: 0.00, 0.78, 5.29
System | Huawei Technologies Co., Ltd.; Tecal RH2285; vV100R001 (Main Server Chassis)
Service Tag | 2102317716N0AA000062
Release | Red Hat Enterprise Linux Server release 5.4 (Tikanga)
Kernel | 2.6.18-164.el5
Architecture | CPU = 64-bit, OS = 64-bit
Threading | NPTL 2.5
Compiler | GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-44).
SELinux | Disabled
# Processor ##################################################
Processors | physical = 2, cores = 12, virtual = 24, hyperthreading = yes
Speeds | 24x2400.151
Models | 24xIntel(R) Xeon(R) CPU X5670 @ 2.93GHz
Caches | 24x12288 KB
..
$sudo rm -f /root/.oprofile/daemonrc
$sudo opcontrol --setup --no-vmlinux
$sudo opcontrol --init
$sudo opcontrol --reset
$sudo opcontrol --start
Using 2.6+ OProfile kernel interface.
Using log file /var/lib/oprofile/samples/oprofiled.log
Daemon started.
Profiler running.
$sudo opcontrol --status
Daemon running: pid 9253
Separate options: none
vmlinux file: none
Image filter: none
Call-graph depth: 0
#这里喝杯茶，让子弹飞一会儿
$sudo opcontrol --shutdown
Stopping profiling.
Killing daemon.
$opreport
opreport error: No sample file found: try running opcontrol --dump
or specify a session containing sample files
$tree /var/lib/oprofile/samples/current/
/var/lib/oprofile/samples/current/
0 directories, 0 files
确实是没抓到sample文件！
经过无数次的分析和判断，再加上goolge大神的帮助，找到问题的根源了:
Read more…
晚上 雕梁 说要找个工具来调查下unix域套接字的发送和接受情况，比如说A程序是否送出，B程序是否接收到，他找了tcpdump ,wireshark什么的，貌似都不支持。
这时候还是伟大的systemtap来救助了。 因为所有的socket通讯都是通过socket接口来的，任何family的通讯包括unix域套接都要走的，所以只要截获了socket 读写的几个syscall 就搞定了.
systemtap发行版本提供了个工具socktop， 位于 /usr/share/doc/systemtap/examples/network/socktop, 是个非常方便的工具, 干这个事情最合适了。
Read more…
我们在系统调优或者定位问题的时候，经常会发现多线程程序的效率很低，但是又不知道问题出在哪里，就知道上下文切换很多，但是为什么上下文切换，是谁导致切换，我们就不知道了。上下文切换可以用dstat这样的工具查看，比如：
$dstat
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
9 2 87 2 0 1|7398k 31M| 0 0 | 9.8k 11k| 16k 64k
20 4 69 3 0 4| 26M 56M| 34M 172M| 0 0 | 61k 200k
21 5 64 6 0 3| 26M 225M| 35M 175M| 0 0 | 75k 216k
21 5 66 4 0 4| 25M 119M| 34M 173M| 0 0 | 66k 207k
19 4 68 5 0 3| 23M 56M| 33M 166M| 0 0 | 60k 197k
#或者用systemtap脚本来看
$sudo stap -e 'global cnt; probe scheduler.cpu_on {cnt<<<1;} probe timer.s(1){printf("%d\n", @count(cnt)); delete cnt;}'
217779
234141
234759
每秒高达200k左右的的上下文切换， 谁能告诉我发生了什么? 好吧，latencytop来救助了!
它的官网：http://www.latencytop.org/
Skipping audio, slower servers, everyone knows the symptoms of latency. But to know what’s going on in the system, what’s causing the latency, how to fix it… that’s a hard question without good answers right now.
LatencyTOP is a Linux* tool for software developers (both kernel and userspace), aimed at identifying where in the system latency is happening, and what kind of operation/action is causing the latency to happen so that the code can be changed to avoid the worst latency hiccups.
它是Intel贡献的另外一个性能查看器，还有一个是powertop,都是很不错的工具.
Read more…
在运行stap的时候,经常会发现在脚本结束运行的时候打出了很多无预期的东西,仔细一看都是些全局变量的dump, 这个问题比较烦人.
我来演示下:
Read more…
我们在使用脚本收集系统信息的时候经常会用到map这样的数据结构存放结果,但是stap脚本在使用过程中经常会提升说”ERROR: Array overflow, check MAXMAPENTRIES near identifier ‘a’ at test.stp:6:5″ 类似这样的信息,然后脚本就自动退出了.
这是stap运行期为了避免用户滥用系统资源做出的保护,为了安全性牺牲下方便,但是会给我们需要长期运行的脚本造成很大的麻烦,所以我们演示下如何来回避这个事情:
Read more…
Recent Comments