FZ9493【测试人员】

内存数据库及其效率

将MySQL放置到Ramdisk中，考核其效率变化。

数据准备：

从真实论坛中抽取8万条数据，数据库大小为18M

测试程序：

读取——随即选择版面、标签、页数，从数据库中排序取出数据。

写入——在读取测试基础上，每50次读取进行一次Update操作。

正常效率：

进行1000次读取：第一遍15.60413312912 ，第二遍11.677510023117 seconds

进行1000次读取＋写入：第一遍16.505848169327，第二遍16.751178026199 seconds

创建内存盘：

查看可用于Ramdisk的内存大小：

dmesg | grep RAMDISK

16M，太小。修改启动文件，改变大小：

vi /etc/grub.conf

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You do not have a /boot partition. This means that
# all kernel and initrd paths are relative to /, eg.
# root (hd0,0)
# kernel /boot/vmlinuz-version ro root=/dev/cciss/c0d0p1
# initrd /boot/initrd-version.img
#boot=/dev/cciss/c0d0
default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux AS (2.6.9-42.ELsmp)
root (hd0,0)
kernel /boot/vmlinuz-2.6.9-42.ELsmp ro root=LABEL=/ ramdisk_size=1000000
initrd /boot/initrd-2.6.9-42.ELsmp.img
title Red Hat Enterprise Linux AS-up (2.6.9-42.EL)
root (hd0,0)
kernel /boot/vmlinuz-2.6.9-42.EL ro root=LABEL=/
initrd /boot/initrd-2.6.9-42.EL.img

注意，是以K为单位的。

重启，查看是否有效。

# dmesg | grep RAMDISK
RAMDISK driver initialized: 16 RAM disks of 1000000K size 1024 blocksize

绑定内存盘到一个目录：

# mount /dev/ram2 /opt/ram_db -t ramfs

最好不要用ram0，留下给其它临时应用。

（注：

1，如果目录所在盘是ext3的，那么就不要用mk2ef格式内存盘，否则会导致无法mount。

2，通过mount -tmpfs -o size=10M none /mnt/tmp的方法可以动态加载内存，并且灵活限制大小，是更时髦的方法。但是，在启动时指定内存可能会更有保障些。

）

然后，把数据库复制到内存盘中：

tar -cf - * | tar -C ../ram_db -xf -

测试效率：

进行1000次读取：第一遍13.552532196045 seconds ，第二遍12.20893907547 seconds

进行1000次读取＋写入：16.122632026672 seconds

在SQLite中做类似测试，结论相似。

【对较大数据表的测试】

构建200万条主贴数据，表大小为350M。（注意，查询范围与上例测试有所不同，与上例无任何对比关系。仅代表内存与非内存的对比）

常规：7.1019299030304 seconds

内存：6.9220759868622 seconds

结论：

对于不是非常巨大的表，MySQL进行了较好的缓冲处理，性能瓶颈在算法上而不是磁盘操作上，用内存盘性能提升效率有限。

对于过G的巨型表（千万数据 或 有TEXT字段），则其IO瓶颈更明显，是否采用内存能有效加速有待进一步测试。

～～呵呵～～