|
SSD技术正日渐成熟，容量越来越大，价格越来越便宜，符合摩尔定律，但是内存技术似乎在同样的道路上走得更快。昨晚我想下载几个电影，一共4G多，但是连接上迅雷之后，资源不少，但是速率却成锯齿状，我就不信是网速问题，也不是TCP问题，因为分布式P2P下载的原理和单TCP通道的HTTP以及FTP完全不同，后来用命令查看发现是IO的瓶颈...我的磁盘是这么分配的：SSD：我的SSD容量太小，128G吧，上面放了很多虚拟磁盘之类的，剩下的空间不足3G了。HDD：这是一个1T的物理磁盘，规格就不说了，反正就是会转圈的那种。剩下还有600多G。那么电影只能放在HDD了，然而当时已经12点多了，老婆一直摧着睡，小小也被吵醒了，我看了下载速度大概有1.5M，还不错，但是一下子就下到500K了，然后缓慢增加到1.5M，然后再下降...这不是TCP的问题，请相信，凭着我对网络的理解，这不是TCP的问题，虽然很多教科书上都会说TCP速率会出现锯齿状，但这次绝对不是！我要最短化下载时间怎么办？只要能充满1.5M，那么是绝对可以接受的，剩下的那个电影大概也就半小时左右完毕。我必须快速想到办法，SSD虽然会比较快，但是写入速度也不敢恭维，于是想到了内存！ 我有16G的内存，打开monitor发现剩余7G多！我要赶紧做一个内存盘。可是我在Mac上不知道怎么弄，没关系，搜了一下发现使用hdid命令就可以：hdid+fstyp_hfs(类似Linux的mkfs.ext4之类的)+mount，于是赶紧做了一个内存盘，大小4G的。重新开始下载。速度快了很多！去厨房抽个烟，完成了。然后花了几十秒的时间将电影从内存盘拷贝到了HDD。 虽然这件事完全都是手工操作的，但是事后我却觉得可以通用化。就在刚才，我进行了测试，分别测试了HDD，SSD，Ramdisk的IO性能，当然只是大概的测试，没有使用专业工具，而只是使用了dd+purge而已，不过也可以说明问题。测试平台是我在2011年买的那台Macbook pro，已经很老了，配备了64G的SSD，剩余15G，HDD一共500G左右，内存8G，这配置虽说不上悍，但是对我测试没有问题。我没有用强悍的iMac进行测试是因为我老婆总觉得我在电脑上敲命令就会把它弄坏...再说那台电脑就是个娱乐机，平时我不怎么动它，昨晚是作为技术支持上机操作的，毕竟电影也不是我一个人看...测试结果如下：C/C++，JAVA等语言在虚拟内存地址空间中编程一样。关于第3点，举一个例子，你不是可以用C语言构建一个Tree吗？这棵树的操作都在内存中进行，如果使用Ramdisk，你就可以使用文件系统的目录结构进行同样的操作。你可以将数据库存储概念中的B树等磁盘裸数据结构搬到Ramdisk中，替代自己实现的数据结构。4.将关键服务存放在Ramdisk中，在UNIX中可以mount一个ramfs或者cramfs，然后chroot进去，这样保证所有的磁盘操作都在内存中进行。5....对于怎么做，我觉得不是问题，下周我准备在Mac上做一个实例。实际上在Linux上更为简单，大家都接触过的initrd就是一个ramdisk或者cramdisk，把它做大一些即可。 为何之前没有人这么干呢？原因有很多，主要的我觉得第一是因为内存太贵，还有就是怕断电。不管怎样，现在这些都不是问题了。但这都不是最主要的原因，最主要的原因是人们已经习惯了以下的几个概念：1.人们习惯了CPU寄存器，CPU cacheline，内存，磁盘，网络这个已经存在的分级存储体系，内存只是在page粒度上是磁盘的cache，而不是file粒度的。2.人们觉得数据结构这种东西都是C语言之类的可以直接操作内存的语言必须置入内存才可用的。文件系统作为一种抽象，每一个file被C语言操作，并且操作集都是固定的，文件系统之间所不同的只是文件在磁盘的布局，这个抽象隐藏了磁盘复杂的构造的同时也隐藏了file的数据结构。如果我们把抽象的面纱揭开，考虑一下数据库的操作，拿B树和C语言里面写的树型查找结构相比的话，就会隐约发觉，实际上磁盘里的东西和内存里面的东西都是一样，C语言可以将很多数据结构封装成一个抽象的不让你看见的东西，目前也是这么做的，就像文件系统在UNIX初创时做的那样。
(以上内容不代表本站观点。) --------------------------------- |
本網站是"非商業"(non-commercial)。
