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进行测试是因为我老婆总觉得我在电脑上敲命令就会把它弄坏...再说那台电脑就是个娱乐机,平时我不怎么动它,昨晚是作为技术支持上机操作的,毕竟电影也不是我一个人看...测试结果如下:
从结果可以看出,虽然我们都在笃信SSD,然而和内存相比,就没戏了,正如内存无法和三级cache相比,三级cache无法和一级cache相比一样,同样cache都无法和寄存器相比,向着慢速的一端,网络也是无法和本地磁盘相比的,不过目前这一点正在改善,据说TCP/IP已经可以实现远程内存访问了,这无疑得益于万兆网络的流行,当然这是后话了。
如果我们可以将时间,金钱和生命等同起来,就可以算一笔帐,如果说内存比SSD快10倍(保守说),那么也要比SSD贵10倍才可以和SSD等价的,这在几年前来说,SSD要更贵些,可是今天,128G的SSD也就300元左右,说明SSD的价值已经超过了内存。然而事实上,时间和金钱是无能等价的,这是构建分级存储体系的根本原则。
分级存储体系的构建原则并不是让你用128G的内存替代128G的SSD,用512G的SSD替代512G的HDD,而是要将好钢用在刀刃上,有有限的生命时间做最少的最值得做的事情。也正因为如此,CPU的cache容量到达128G的时候,内存就要用T来作单位了。为什么不构建一个内存盘来完成重要的事呢?我的意思是在文件系统的粒度上构建一个内存盘,而不是在文件的粒度上构建,后者在现如今的OS内核中均已实现,就是vfs的cache。构建一个Ramdisk可用作以下用途:
1.进行P2P下载,下得快还不伤硬盘。
2.存放虚拟机虚拟磁盘和虚拟内存,虚拟机的内存可以真正内存化,磁盘IO会明显加速。
3.可以使用bash等脚本在内存中编程,这就好比用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初创时做的那样。
昨晚我想下载几个电影,一共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进行测试是因为我老婆总觉得我在电脑上敲命令就会把它弄坏...再说那台电脑就是个娱乐机,平时我不怎么动它,昨晚是作为技术支持上机操作的,毕竟电影也不是我一个人看...测试结果如下:
从结果可以看出,虽然我们都在笃信SSD,然而和内存相比,就没戏了,正如内存无法和三级cache相比,三级cache无法和一级cache相比一样,同样cache都无法和寄存器相比,向着慢速的一端,网络也是无法和本地磁盘相比的,不过目前这一点正在改善,据说TCP/IP已经可以实现远程内存访问了,这无疑得益于万兆网络的流行,当然这是后话了。
如果我们可以将时间,金钱和生命等同起来,就可以算一笔帐,如果说内存比SSD快10倍(保守说),那么也要比SSD贵10倍才可以和SSD等价的,这在几年前来说,SSD要更贵些,可是今天,128G的SSD也就300元左右,说明SSD的价值已经超过了内存。然而事实上,时间和金钱是无能等价的,这是构建分级存储体系的根本原则。
分级存储体系的构建原则并不是让你用128G的内存替代128G的SSD,用512G的SSD替代512G的HDD,而是要将好钢用在刀刃上,有有限的生命时间做最少的最值得做的事情。也正因为如此,CPU的cache容量到达128G的时候,内存就要用T来作单位了。为什么不构建一个内存盘来完成重要的事呢?我的意思是在文件系统的粒度上构建一个内存盘,而不是在文件的粒度上构建,后者在现如今的OS内核中均已实现,就是vfs的cache。构建一个Ramdisk可用作以下用途:
1.进行P2P下载,下得快还不伤硬盘。
2.存放虚拟机虚拟磁盘和虚拟内存,虚拟机的内存可以真正内存化,磁盘IO会明显加速。
3.可以使用bash等脚本在内存中编程,这就好比用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初创时做的那样。