cyclictest 简介

1. cyclictest 简介以及安装

1.1 cyclictest 简介

      cyclictest 是什么? 看名字应该就能大致猜出来它是一种 test 程序,Cyclictest的维基主页这么介绍它“Cyclictest is a high resolution test program, written by User:Tglx, maintained by User:Clark Williams ”,也就是它是一个高精度的测试程序,Cyclictest 是 rt-tests 下的一个测试工具,也是rt-tests 下使用最广泛的测试工具,一般主要用来测试使用内核的延迟,从而判断内核的实时性。

1.2 cyclictest 安装

1.2.1 基于包管理软件安装

Debian / Ubuntu 系统下可以直接使用apt-get install rt-tests 来安装cyclictest。

1.2.2 git 仓库源码安装

      使用Linux最大的好处就是我们可以下载软件的源码,学习、编译以及使用,所以如果使用上述方法直接安装使用,如果你觉得有的问题不懂或者出现问题你也没办法解决,所以从开发者的角度而言,下载安装软件还是下载源码包编译后使用比较好。

(1) 首先拷贝cyclictest的Git 仓库

#  git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git

(2) 进入git仓库

#  cd rt-tests 

(3)创建一个分支,比如我们起名叫testing

#  git branch testing    

(4)转到testing分支,之后我们做的步骤都不会对主分支有影响,这是我们在电脑上使用 git 仓库的常用方法

#  git checkout testing  

(5)查看我们当前在哪个分支

#  git branch     

  master * testing

(6)在次我们使用make编译

#  make         

编译时我们会遇到缺失numa.h 的错误提示,在此我建议童鞋们安装使用apt-file 来解决此类错误(有了apt-file,遇到这类错误我们就知道如何解决而不是一味的上网找别人的解决方法),主要步骤如下:     #  sudo apt-get install apt-file                   // 安装apt-file     #  apt-file update                                      // 类似于apt-get ,apt-file也需要根据系统配的源来更新一个库     #  apt-file search numa.h                         // 使用apt-file search 搜索我们缺失的文件

libhwloc-dev: /usr/include/hwloc/linux-libnuma.h          libnuma-dev: /usr/include/numa.h                                // 在搜索到的结果中,我们发现这个包叫做 libnuma-dev 应该就是我们需要安装的包 linux-headers-3.2.0-4-amd64: /usr/src/linux-headers-3.2.0-4-amd64/include/config/acpi/numa.h linux-headers-3.2.0-4-amd64: /usr/src/linux-headers-3.2.0-4-amd64/include/config/amd/numa.h

....      #  apt-get install libnuma-dev                   // 使用apt-get 安装libnuma-dev 包

2. cyclictest 的使用及参数简介

对于Cyclictest的使用我们得先了解它的各个参数的含义,所以在你开始使用之前,请你看一下 cyclictest --help 中提到的各个参数!这将对你使用有很大的帮助。

2.1 cyclictest的简单使用及结果分析

如果你只是想玩玩这个工具,那么对于维基主页上提到的tglx 使用的测试命令来测测你的电脑性能:

#  sudo ./cyclictest -t1 -p 80 -n -i 10000 -l 10000

注:在rt-tests的路径下,我们可以使用 ./cyclictest 来运行cyclictest, 而在别的目录下,我们就需要指定 cyclictest的路径来使用,比如说 /home/long/rt-tests/cyclictest ,或者你也可以直接将 rt-tests的路径下的 cyclictest 拷贝到 /bin/ 下,以后就可以直接使用 cyclictest 而不需要指定路径了!!

比如在我的电脑上,我使用这个命令测试的结果如下:

# /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.38 0.29 0.26 1/381 5595     T: 0 ( 5592) P:80 I:10000 C:  10000 Min:      2 Act:   15 Avg:   15 Max:     195

输出结果含义: T: 0 序号为0的线程 P: 0 线程优先级为0 C: 9397 计数器。线程的时间间隔每达到一次,计数器加1 I: 1000 时间间隔为1000微秒(us) Min: 最小延时(us) Act: 最近一次的延时(us) Avg:平均延时(us) Max: 最大延时(us)

所以我们当前的机器上最小延时为2,平均为15,最大的为 195。

$uname -a               // 我们可以使用 “ uname -a ” 看到我们系统目前使用的内核版本 Linux wheezy 3.2.51-trace #8 SMP Thu Nov 21 12:34:04 CST 2013 x86_64 GNU/Linux

$ cat /boot/config-3.2.51-trace |grep CONFIG_PREEMPT_RT    // 我们再打开 /boot 下面的当前内核的config信息查看目前这个内核是否打上实时补丁,结果显示并没有。所以在一个普通的内核下测的 Min:      2 Act:   15 Avg:   15 Max:     195 这样的数据算是不错的了!

$ cat /boot/config-3.10.17-trace-rt12 |grep CONFIG_PREEMPT_RT    // 而在我 /boot 目录下的另外一个打好实时补丁的内核中 CONFIG_PREEMPT_RT_BASE=y # CONFIG_PREEMPT_RTB is not set CONFIG_PREEMPT_RT_FULL=y             // 判断一个内核是否是实时内核,请看config 下有没有此项

我得到的cyclictest 运行结果是这样的:  

T: 0 ( 5592) P:80 I:10000 C:  10000 Min:      1 Act:  1 Avg:   2 Max:     9

:-),运行的结果有目共睹,在以后的博客中我会介绍关于Linux 内核的实时补丁。

2.2 cyclictest 的参数介绍 

      关于cyclictest 的各个参数具体含义建议大家还是用时间具体看看 cyclictest --help 的信息(参考资料【2】为我的师兄对--help下的每个参数的解释,大家也可以看看!)我这只介绍几个常用的。

-p PRIO --prio=PRIO       最高优先级线程的优先级  使用时方法为: -p 90 /  --prio=90 -m       --mlockall        锁定当前和将来的内存分配 -c CLOCK --clock=CLOCK     选择时钟  cyclictest -c 1                            0 = CLOCK_MONOTONIC (默认)                            1 = CLOCK_REALTIME -i INTV  --interval=INTV  基本线程间隔,默认为1000(单位为us),下面介绍原理的时候会提到 -l LOOPS --loops=LOOPS     循环的个数,默认为0(无穷个),与 -i 间隔数结合可大致算出整个测试的时间,比如 -i 1000  -l 1000000 ,总的循环时间为1000*1000000=1000000000 us =1000s ,所以大致为16分钟多。 -n       --nanosleep       使用 clock_nanosleep -h  HISTNUM    --histogram=US    在执行完后在标准输出设备上画出延迟的直方图(很多线程有相同的权限)US为最大的跟踪时间限制,这个在下面介绍实例时可以用到,结合gnuplot 可以画出我们测试的结果图。 -q       --quiet         使用-q 参数运行时不打印信息,只在退出时打印概要内容,结合-h HISTNUM参数会在退出时打印HISTNUM 行统计信息以及一个总的概要信息。 -f       --ftrace          ftrace函数跟踪(通常与-b 配套使用,其实通常使用 -b 即可,不使用 -f ) -b USEC  --breaktrace=USEC 当延时大于USEC指定的值时,发送停止跟踪。USEC,单位为谬秒(us)。

2.3 推荐参数以及结果实例

dslab@wheezy:~$ sudo cyclictest -p 90 - m -c 0 -i 200 -n -h 100 -q -l 1000000

我们使用 -p 90给cyclictest 赋优先级90,使用-m参数锁定内存分配,使用  -c 0指定使用默认的MONOTONIC 时钟, -i 200 指定一个循环为200us,结合 -l 1000000为总共1000000个循环,此外-n 为使用nanosleep 而不是简单的sleep,-q为在运行时不打印即时信息,-h 100 为总共统计100个信息在最后的结果中。  # /dev/cpu_dma_latency set to 0us

---------------------------------------------------(下面都是结束测试/终端测试后打印的信息,这就是 -q 的功效!) # Histogram 000000 000000 000001 111448              -- 延时为1us的在1000000次循环中占111448次(下面每行都是这个意思) 000002 060272 000003 000714 000004 000344 000005 000231 000006 013170 000007 155289 000008 601393 000009 044880 000010 005348 000011 001821 000012 001444 000013 000945 000014 000538 000015 000376 000016 000344 .....

000096 000002 000097 000002 000098 000002 000099 000002              -- 我们使用 -h 100 ,所以在结果中记录了延时为 0us ~ 99us 的次数 # Total: 000999888 # Min Latencies: 00001       -- 最小延时 1 us # Avg Latencies: 00006       -- 平均延时 6us # Max Latencies: 00463      -- 最大延时463 us,那么我们指定histogram = 100也就是只记录了0us~99us的值而最大延时为463 也就是说肯定有很多此延时超过99 us,那么记录到哪了?答案是,没有记录具体的超过99us的延时值,只在下面记录了超过99us 的延时次数(记录在Overflows),以及第几次超过了(记录在Thread 0)。 # Histogram Overflows: 00112     -- 超过99 us的次数 # Histogram Overflow at cycle number: # Thread 0: 02985 06044 06107 08644 08683 12048 18136 30164 33172 33757 36214 48208 54138 58822 61284 83843 83876 86382 92351 92352 96306 108937 108941 111443 117367 129130 129131 146426 155069 155070 159058 161563 171486 184200 186614 209260 211606 221606 223526 223527 234275 234321 236827 241705 241706 246766 266826 296886 321946 334644 336979 337006 359705 367066 384765 392126 412186 437221 442246 462306 472306 484921 487366 497366 507426 509981 512448 512488 522426 542486 567546 587606 610305 617666 635365 637704 637726 660425 672686 692846 710379 710463 717806 735443 737919 742886 760582 763088 767946 785515 785642 788149 793086 806776 808146 810703 813146 835661 835847 838172 # 00012 others  //这里记录的是第几次循环的延时超过了99us。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏上善若水

005工具及环境之nmap一览

Nmap (“Network Mapper(网络映射器)”) 是一款开放源代码的 网络探测和安全审核的工具。它的设计目标是快速地扫描大型网络,当然用它扫描单个 ...

803
来自专栏极致的Java

MyPerf4J 针对高并发、低延迟应用设计的高性能 Java 性能监控和统计工具

MyPerf4J 为每个应用收集数十个监控指标,所有的监控指标都是实时采集和展现的。

883
来自专栏运维小白

4.10/4.11/4.12 lvm讲

LVM讲解 lvm的优缺点 优势:很方便的扩容和缩容磁盘空间 局限性:,磁盘发生损坏,不易于恢复 ? lvm准备工作 fdisk /dev/sdb n 创建3...

1668
来自专栏性能与架构

HTTP 压力测试工具 wrk

简介 wrk 是一个HTTP压力测试工具,根据官方的介绍,他有2个明显的特点: 集成了多线程设计与事件通知系统(如 epoll、kqueue)提升并发量 可以通...

4557
来自专栏散尽浮华

Linux服务器性能压力测试

对于新采购的服务器,需要进行有必要的性能测试。这里选择UnixBench工具进行性能测试。记录如下: 1)安装使用 下面的脚本使用了最新版UnixBench5....

2807
来自专栏极致的Java

MyPerf4J 针对高并发、低延迟应用设计的高性能 Java 性能监控和统计工具

MyPerf4J 为每个应用收集数十个监控指标,所有的监控指标都是实时采集和展现的。

1044
来自专栏c#开发者

MSMQ消息大于4MB限制的解决办法

MSMQ 消息发送大于 4 导致 System.Messaging.MessageQueueException Mb。 察看本文应用于的产品 社区解决方案免责...

33813
来自专栏菩提树下的杨过

ActiveMQ笔记(6):消息延时投递

在开发业务系统时,某些业务场景需要消息定时发送或延时发送(类似:飞信的短信定时发送需求),这时候就需要用到activemq的消息延时投递,详细的文档可参考官网说...

2125
来自专栏企鹅号快讯

Python爬取网站的一些小技巧

1.最基本的抓站 2.使用代理服务器 这在某些情况下比较有用,比如IP被封了,或者比如IP访问的次数受到限制等等。 3.需要登录的情况 登录的情况比较麻烦我把问...

2055
来自专栏阿杜的世界

Serviceability Agent介绍简单介绍安装使用模式入门示例SA的其他工具参考资料

构建高性能的Java应用过程中,必然会遇到各种各样的问题,像CPU飙高、内存泄漏、应用奔溃,以及其他疑难杂症,这时可以使用Serviceability Agen...

1163

扫码关注云+社区