有童鞋分享了unix的五种io模型,留意到里面有一句话“将数据从内核拷贝到用户空间”,怀疑这句话有问题。

unix的五种io模型中,把io读操作分为两个部分:
1、等待数据。
2、将数据从内核拷贝到用户空间。

我以java语言中的实现为例子:

在第三种模型“多路复用”中,第二步的数据读取工作可以是这样的
[code]
SocketChannel socketChannel = (SocketChannel) key.channel();
ByteBuffer dst = ByteBuffer.allocateDirect(1024);//分配的是直接内存
socketChannel.read(dst);
[/code]
数据直接从channel中读取到直接内存,没有从内核空间向用户空间拷贝的过程。

在第五种模型“aio”中,向aio_read函数中传递的缓冲区指针可以是mmap映射出的内存地址,也是内核到内核,没有内核空间向用户空间拷贝的问题。

当然,也可能是我理解有误,欢迎指正~

对mmap的读性能和原生的RandomAccessFile的读性能做了一下对比,从时间上比较,耗时不足之前的400分之一。

直接读536870910大小的物理文件,耗时199532毫秒。
mmap之后,再按再同的频度读相同的数据,耗时484毫秒。

本以为在SSD下测试,RandomAccessFile的性能会好很多,跟mmap方式的差距也会减少,在windows的系统上实测结果大跌眼镜:
等了十分钟,位于SSD磁盘的半个G文件没读完。次数降两个数量级,即512M/100次,得到结果如下
[code]
直接读536870910/100大小的物理文件,耗时10499毫秒。
0: 读(77767859:9)=9(和:2415919095, 耗时:578ms)
1: 读(387167008:8)=8(和:2415919095, 耗时:562ms)
2: 读(457186802:2)=2(和:2415919095, 耗时:546ms)
3: 读(394128468:8)=8(和:2415919095, 耗时:530ms)
[/code]
SSD下的磁盘读比mmap后相差了1816倍,远低于在Linux服务器上的测试结果。

在Windows开发机的普通磁盘上测试结果,磁盘性能略好于SSD
[code]
直接读536870910大小的物理文件,耗时9923毫秒。
0: 读(177389691:1)=1(和:2415919095, 耗时:562ms)
1: 读(390411737:7)=7(和:2415919095, 耗时:578ms)
[/code]

备注一下测试过程和中间的内存和CPU的表现。

- 阅读剩余部分 -

用strace和perf的时候,直接把标准输出重定向到文件,发现无效。
把标准错误输出重定向到文件,才有效果。
比较奇怪,为什么strace和perf要把自己的输出用标准错误,而不是标准输出。

备忘一下重定向输出几个点
>覆盖式重定向。
>>追加式重定向。
1>代表重定向标准输出,1可以省略。
2>代表重定向标准错误。
1>&2代表把标准输出重定向到标准错误。

做互联网的,提到地图,就想到google,然后想到百度。
google的卫星地图在进行拼接的时候,每一块就这种图片:
http://mt3.google.cn/vt/[email protected]&hl=zh-CN&gl=CN&src=app&x=53975&y=24816&z=16&s=Galile
这个x、y是什么呢?就涉及到墨卡托投影,具体含义可以自行百度或google。

- 阅读剩余部分 -