
[root@node3 /]# time dd if=/dev/sda2 of=/dev/null bs=8k count=524288
524288+0 records in
524288+0 records out
4294967296 bytes (4.3 GB) copied, 37.4222 seconds, 115 MB/s
real 0m37.497s
user 0m0.036s
sys 0m1.320s
copy了4.3G的数据,平均速度为115M/s
[root@node3 /]# hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 284 MB in 3.00 seconds = 94.55 MB/sec
[root@node3 /]# hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 292 MB in 3.02 seconds = 96.82 MB/sec
读了将近300M的数据,平均速度大约为95M/s
经过以上的测试数据大体估算该磁盘的性能大约为100M/s
1.1 top
1.2 vmstat
r 表示可运行进程数目,数据大致相符;而b表示的是 uninterruptible 睡眠的进程数目;swpd 表示使用到的虚拟内存数量,跟 top-Swap-used 的数值是一个含义,而如手册所说,通常情况下 buffers 数目要比 cached Mem 小的多,buffers 一般20M这么个数量级;io 域的 bi、bo 表明每秒钟向磁盘接收和发送的块数目(blocks/s);system 域的 in 表明每秒钟的系统中断数(包括时钟中断),cs表明因为进程切换导致上下文切换的数目。
说到这里,想到以前很多人纠结编译 linux kernel 的时候 -j 参数究竟是 CPU Core 还是 CPU Core+1?通过上面修改 -j 参数值编译 boost 和 linux kernel 的同时开启 vmstat 监控,发现两种情况下 context switch 基本没有变化,且也只有显著增加 -j 值后 context switch 才会有显著的增加,看来不必过于纠结这个参数了,虽然具体编译时间长度我还没有测试。资料说如果不是在系统启动或者 benchmark 的状态,参数 context switch>100000 程序肯定有问题。
1.3 pidstat
如果想对某个进程进行全面具体的追踪,没有什么比 pidstat 更合适的了——栈空间、缺页情况、主被动切换等信息尽收眼底。这个命令最有用的参数是-t,可以将进程中各个线程的详细信息罗列出来。
-r: 显示缺页错误和内存使用状况,缺页错误是程序需要访问映射在虚拟内存空间中但是还尚未被加载到物理内存中的一个分页,缺页错误两个主要类型是
-s:栈使用状况,包括 StkSize 为线程保留的栈空间,以及 StkRef 实际使用的栈空间。使用ulimit -s发现CentOS 6.x上面默认栈空间是10240K,而 CentOS 7.x、Ubuntu系列默认栈空间大小为8196K
1.4 其他
while :do ps -eo user,pid,ni,pri,pcpu,psr,comm | grep 'ailawd'sleep 1done
2.1 iostat
3.1 netstat
➜ ~ netstat -antp #列出所有TCP的连接
➜ ~ netstat -nltp #列出本地所有TCP侦听套接字,不要加-a参数
3.2 sar
3.3 tcpdump
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)