系统技术非业余研究

最近有同学反映在某些新机器上做性能调优的时候， 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…

看图不说话：

我们在系统调优或者定位问题的时候，经常会发现多线程程序的效率很低，但是又不知道问题出在哪里，就知道上下文切换很多，但是为什么上下文切换，是谁导致切换，我们就不知道了。上下文切换可以用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…

有时候在看系统代码的时候，我们很难从源码中看出我们感兴趣的函数是如何被调用的，因为调用路径有可能太多。用户空间的程序gdb设断点是个好的方法，内核的就麻烦了。这时候systemtap可以帮忙, 比如:
Read more…

在规划服务器的内存使用的时候经常需要知道应用在理想情况下会使用多少的pagecache, 我们好预先把这个内存预留出来.

这个值操作系统没有提供可查看的管道,我们只能自己写个脚本来实现.

下面的systemtap脚本每隔N秒显示下当前os下头10个文件占用多少的pagecache, 降序排列.

Read more…

Linux下异步IO是比较新的内核里面才有的，异步io的好处可以参考这里.
但是文章中aio_*系列的调用是glibc提供的，是glibc用线程+阻塞调用来模拟的，性能很差，千万千万不要用。

我们今天要说的是真正的原生的异步IO接口. 由于这几个系统调用glibc没有提供相应的封装，所以libaio来救急了：
Read more…