先罗列一些工作中用得比较多的系统检测工具吧,top、ps、iostat、vmstat、free (-m)、tcpdump…
1.磁盘io相对于内存读写是巨慢无比的,数据库操作也是,所以在一些io密集的程序里面可以用内存映射、memcached来进行优化
2.就个人理解来描述一下磁盘访问
cpu访问文件数据时,先在cpu cache和memory查找,没找到就通知io子系统去磁盘加载(数据以内存内的形式加载,一个内存页一般是4kb)(MPF,major page fault)
如果在内存(写缓存buffer,读缓存cached)中可以找到就不用有磁盘操作了(MnPF,minor page fault)
后者速度快多了,所以在频繁的io操作后内存中有很多空间用于缓存磁盘数据,这时候如果看到free的空间不足并不表示机器真的内存不足,当有内存需求时内核会释放这些用于磁盘缓存的内存空间,下图中cached就是缓存所占的空间,内存实际剩余是free+buffers+cached = 117+10+508。但是如果Swap used很多就表示系统内存真的很紧张,使用交换分区的速度很慢,因为它是保存在磁盘上的。
- www.linuxidc.com@linuxidc:~$ free -m
- total used free shared buffers cached
- Mem: 1889 1771 117 0 10 508
- -/+ buffers/cache: 1252 636
- Swap: 4766 282 4484
3.内存页类型:
read page:只读,包括库文件之类的
dirty page(write page):写过需要同步到磁盘的数据,我想在fprintf之后紧接着调用fflush()之类的函数应该可以从这里写回磁盘
anonymous page:跟磁盘文件无关,归某些进程所有,内存不足时这些数据可能掉入Swap
4.计算IOPS(每秒响应的磁盘io次数):
假如磁盘的RPM是10000(RPM,Revolutions Per Minute,每分钟旋转圈数)
则,磁盘的RD(Rotational Delay,旋转半圈的毫秒数)是(1/(10000/(60*1000)))/2=3
加上磁头的DS(Disk Seek,磁头寻道的毫秒数)平均是3MS
加上2MS延迟
最终的IOPS是8ms,内核每次的io请求磁盘需要8ms来完成,就是10000RPM的磁盘每秒可以提供大约125次IOPS
根据
5.实际io情况要根据程序来考量,邮件服io数据小而请求频繁,属于Random IO,流媒体服务io数据大而请求频度低,属于Sequential IO
前者对iops要求比较高,后者对读写大量数据能力(KB per request, (rkB/s)/(r/s)或者(wkB/s)/(w/s))要求比较高
当用top或者iostat查看发现iowait比较高时说明有io瓶颈
- www.linuxidc.com@linuxidc:~$ iostat -kdx 2
- Linux 3.0.0-14-generic (HP) 2012年01月08日 _x86_64_ (4 CPU)
- Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
- sda 0.60 2.08 2.86 1.20 65.79 37.79 51.09 0.37 91.11 34.56 225.77 14.59 5.92
- Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
- sda 0.00 0.00 2.00 0.00 64.00 0.00 64.00 0.02 9.00 9.00 0.00 5.00 1.00
- Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
- sda 0.00 0.50 0.50 1.00 2.00 6.00 10.67 0.01 9.33 8.00 10.00 9.33 1.40