文章归档

关于SSD测试的几篇文章(推荐阅读)

这两天看到了多篇关于SSD在MySQL中的应用的测试, 感觉非常不错..

SSD Deployment Strategies for MySQL
View more presentations from Yoshinori Matsunobu.

下面的内容摘自上面来自slideShare的pdf文件.
基本结论如下

SSD is extremely good at random reads
SSD is very good at random writes
HDD is good enough at sequential reads/writes
No strong reason to use SSD for sequential writes

简单翻译

SSD 有非常好的随机读能力
SSD 有很好的随机写能力
HDD 对于顺序读写的场景来讲已经足够好
没有很好的理由来使用SSD到顺序写的场景

其他几篇不错的关于此的文章.
An Overview of Flash Storage for Databases
How Solid state Technologies are Transforming MySQL Server Performance and [...]

作为二级缓存的SSD应用

SSD的特性是,随机IO非常好,随机写比较好,顺序写很不好, 单纯使用SSD作为数据库存储虽然效果可能非常好,在目前的$/GB的情况下, 可能还是显得不是很经济..而使用其作为二级缓存则可以充分利用其离散读性能,又可以尽可能避免其设计上的相对糟糕的写性能, 从而达到对SSD的充分使用.

目前已经有很多伟大的公司尝试使用SSD作为二级缓存来解决传统磁盘所无法实现的对于业务高IOPS的需求..

下面是几个我所了解到的应用.

Facebook的工程师Paul Saab今天在MySQLFacebook发布了Facebook使用SSD作为MySQL二级缓存的信息. Releasing Flashcache

We built Flashcache to help us scale InnoDB/MySQL, but it was designed as a generic caching module that can be used with any application built on top of any block device. For InnoDB, when the working set does not fit in the InnoDB buffer pool, read latency is [...]

闪存表空间 VS 数据库Flash Cache

本文翻译自Guy Harrison的blog: Flash tablespace vs. DB Flash Cache, 这是他写的关于Flash Cache系列文章的最后一篇,另外还会翻译两篇Kevin Closson写的关于Flash Cache的相关文章.
之前两篇关于Flash Cache的文章如下:

数据库Flash Cache(II)
使用Oracle 11GR2 数据库Flash Cache

闪存表空间 VS 数据库Flash Cache

在这篇文章中,我将根据我最近针对使用SSD作为数据文件的存储以及使用Oracle 11GR2数据库Flash Cache所做的测试,给出一份两者的性能对比.
有时,我的整个职业生涯看上去都是在等待旋转磁盘的终结.这项技术是如此古老,能力限制如此明确,如此机械.因此,SSD作为一种数据库存储介质越来越可行(Oracle 11GR2已经直接支持这一点),这个事实令人振奋.
使用SSD作为数据库存储的一部分确实会产生很大的问题,但是,理解闪存SSD的性能特征却是非常重要的,它可以帮助我们确保不会不当地使用它.
SSD有以下两个特征:

基于闪存的SSD使用与常见的USB盘相似的闪存技术,这种USB盘已经在小容量移动数据存储领域替代软盘.闪存RAM比较便宜,提供不需要电池备份的持久存储,因此其耗电量也很低.
基于DDR RAM的SSD使用本质上与服务器核心内存差别不大的内存模块.这种RAM需要有持久存储(如磁盘或闪存RAM)和内部电池来支撑.在发生电力故障的时候,电池可以提供足够的电力来保证可以将RAM内存中的内容写到持久存储.

DDR SSD非常昂贵(以及$$/GB这个级别),以致于目前无法作为专业的数据库设备使用.但是,基于闪存的SSD磁盘越来越称为机械磁盘的一个可行的替代选项.

读,写以及擦写操作

闪存盘存储是按照页(一般为4K)以及块(一般为256K)来组织的.对于读操作来讲,闪存盘可以从单个页(page)快速返回结果.往一个页中写数据要慢很多(可能要慢10倍).然而,只有在块中刚好有一个空闲的页的往页写才能达到这个速度.如果我们需要往整个块写数据,必须先清除块内的内容才可以.维基百科关于SSD的条目给出了下面这个关于查找/写以及擦写的时间:

当一个闪存SSD盘渐渐填满数据时,需要清除操作的块级别的写操作的比例逐渐增加,闪存SSD的写性能也相应下降.

TRIM API函数

高端的闪存SSD支持一种叫做TRIM的API,这个功能使得OS可以主动提前清除整个块,从而写操作可以在只有一个页级别的IO内完成.大部分高端的SSD盘还支持一种防磨损算法,这种算法可以在设备上移动热点页以避免块级别出现故障的风险.闪存盘在块变得不可靠之前只支持一定次数的擦写操作,加入磁盘可以自动将热点页在物理存储上移动时,这个缺陷就可以得到缓解.

MLC vs SLC

廉价的闪存盘一般都使用MLC(Multi-Level-Cell)技术,它可以实现在一个单元中存储两位的数据,而使用SLC时一个单元中只能保存一位数据.MLC的效果是以牺牲性能的代价来提高数据密度,特别是写性能.从数据丢失的角度讲,MLC也是更加不可靠的.如果你关心写性能,那么或许你应该避免使用基于MLC的SSD.
通常,如果你想要一个高性能的闪存SSD的话(如果它不是高性能的,干嘛还要它呢?),你就应该选择基于SLC的闪存SSD,并且是支持TRIM API以及有着好的防磨损能力的SSD.在我的测试中,我使用一个Intel X-25 E 32GB的SSD盘.它大概需要600澳元(大概534美元).

读写速度差异的问题

假设大部分数据库都是读比写多,我们还需要担心闪存SSD在查找时间与写时间方面的差异吗?毫无疑问答案是YES.对于一个Oracle数据库来讲,当通过Buffer Cache处理事务活动时,一个设备的读能力与往这个设备的写能力之间有很大的不匹配会非常有害.
这个问题与Buffer Cache中的数据的缓存有关.如果往Buffer Cache中放入数据块比从里面写出简单很多,那么Buffer Cache就很可能会被脏块填满,从而出现free buffer waits等待.下图展示了free buffer waits是如何出现的:

如果使用的是廉价的闪存盘,那么写速度就会比读速度慢更多,最终free buffer waits等待将成为事务活动高峰时期的限制因素.

Oracle数据库Flash Cache

Oracle的数据库Flash Cache提供了另外一种利用闪存SSD的途径. 它不是将整个数据文件放到闪存上,而是将闪存作为二级缓存使用.Flash Cache可以非常大从而加快经常被访问的数据块的读速度.但是,如果闪存盘非常繁忙的话,Oracle就只是尽量少写缓存.这样,我们就可以得到闪存来优化读操作的好处,而不用承担多少写操作带来的损失.
我在前一篇文章中总结了Flash Cache的处理算法,下面是我在那篇文章中使用的图表,它概括了当数据库使用Flash Cache时一个数据块的生命周期.

这个架构的关键点是,只有在DBWR没有超负荷时,它才会往Flash Cache中写入数据块.当DBWR逐渐变得繁忙时,往Flash Cache中的写操作将被忽略(这将会降低Flash Cache的效率),它可以防止Buffer Cache被脏块填满,从而导致free buffer waits等待事件的出现.

闪存盘的读性能

让我们来看在实际操作中它是如何表现的.下面来看当我们针对如下情况执行500,000次随机索引读取时的性能对比:

1. 一个在机械磁盘上的表,不使用Flash [...]

数据库Flash Cache(II)

本文翻译自Guy Harrison的blog: More on the database flash cache, 这是他写的关于Flash Cache系列文章的第二篇, 后面还有一篇对比测试Flash Database与Flash Cache的文章, 我也将翻译出来放到此处, 另外还会翻译两篇Kevin Closson写的关于Flash Cache的相关文章.

数据库Flash Cache(II)

我非常期待我的高性能Flash SSD(一个Intel X-25E),但同时,我已经在一套便宜的硬件设备上(我的前一篇文章中对此做了说明)做了很多数据库Flash Cache的测试. 有时,在较差的硬件上测试新特性也非常有用,因为你可以观察到一些在高速运行的环境下不会发生的现象.
最初,我天真地认为数据块会被Oracle的服务进程拷贝到Flash Cache中.比如,当我从磁盘读取的时候,同时将数据块放到Buffer Cache与Flash Cache中.然而,通过观察,实际情形可能是, 当数据块将要被刷出Buffer Cache的时候, 由DBWR进程将此数据块从Buffer Cache移入到Flash Cache中.
当然,这是一种更好的处理方式.DBWR可以异步的将数据块写入Flash Cache中,从而用户会话可以获得好处,在数据块写入Flash Cache中的时候不需要进行等待(比从磁盘读取耗费更少的时间).
因此,一个数据块可能有一个如下图的生命周期:

Oracle服务进程从磁盘读取文件的一个数据块,并将其放到Buffer Cache中
如果一个会话在稍后需要访问这个数据块,并且这个数据块仍然在Buffer Cache中,就可以直接从Buffer Cache中读取这个数据块
在这个数据块离开Buffer Cache之前,DBWR将它写入Flash Cache(如果DBWR不是太忙的话)
如果一个会话稍后需要访问这个数据块,并且它还在Flash Cache中的话,就可以从Flash Cache中读取这个数据块(有可能会将这个数据块放回到Buffer Cache中)
如果这个数据块被修改了,DBWR进程最终会将这个数据块写回磁盘.(问题:Flash Cache中那些没有被修改过的数据块会发生什么呢?)

DBWR 与 Flash Cache

从闪存上读取的速度是非常快的,但是往闪存上写就要慢很多了.因此,为了避免性能问题,DBWR进程应该:

1. 不要去写闪存, 除非不得不写,并且
2. 如果有其他更重要的活动的话,一点都不要写闪存.

对于第一点,在数据块将要被刷出Buffer Cache之前,DBWR进程不要填充Flash Cache.也就是说,DBWR不会为了防止数据块将要被刷出Buffer Cache去写这个数据块,而只是这个数据块确实(或许是可能性很高的时候)将要被刷出Buffer Cache的时候才会将其写入Flash Cache.在数据块被写入Buffer Cache的时候,我们没有发现对Flash Cache的写操作, [...]

使用Oracle 11GR2 数据库Flash Cache

本文翻译自Guy Harrison的blog: Using the Oracle 11GR2 database flash cache, 这是他写的关于Flash Cache系列文章的第一篇, 后面还有两篇, 我也将陆续翻译出来放到此处, 另外还会翻译两篇Kevin Closson写的关于Flash Cache的相关文章.

使用Oracle 11GR2 数据库Flash Cache
Oracle最近发布了一个补丁程序,使得你可以在Oracle Enterprise Linux中使用数据库Flash Cache,即使你并没有使用Exadata存储.这个补丁的名字有点隐晦:

8974084:META BUG FOR FLASH CACHE 11.2PL BUGS TO BACKPORT TO 11.2.0.1 OEL

只要安装好这个补丁,你就可以使用任何已存在的flash 设备作为数据库的Flash Cache.下面是我在一个非常旧的服务器与一个非常便宜的usb flash设备上做的初步尝试.相对于更优质的硬件来讲, 测试结果并不具有代表性,但是我认为,它仍然是很有趣的.

安装与配置

如果你也像我一样想在一个USB flash设备上做试验,那么也必须先挂载这个设备.在我的机器上,我创建了一个目录”/mnt/usbflash”,接着在/etc/fstab文件新增了一个如下的条目:
/dev/sda1 /mnt/usbflash vfat noauto,users,rw,umask=0 0 0
在你的系统中,你可能需要将”/dev/sda1″改成其他的设备,这依赖于你如何配置磁盘.然后就可以通过输入”mount /dev/sda1″来挂载这个闪存盘(flash drive).
一旦挂载完毕,就可以通过设置系统参数db_flash_cache_files与db_flash_cache_size来配置flash cache了. 如下是我的相关设置:

注意, 参数DB_FLASH_CACHE_FILE的值必须是一个存储在闪存盘上的文件,而不是这个闪存盘的挂载点本身.
一旦这些参数设置完毕,flash cache就会被激活,并且将充当buffer cache的二级缓存. 当从主缓存移出一个block的时候,它将被移到flash [...]