关于MYSQL在LINUX下使用RAM存储的方案

r_a

具体的想法是这样的，
1）在服务噐的内存4GB中，划出1GB做MYSQL的文件目录，格式为ramfs.
2) MYSQL启动后，所有读写操作都在内存中进行（BINLOG除外）。因大幅减少了磁盘IO，所以提高了整体效率。
3）为了保证数据安全，可在本机或另一服务噐再设置SLAVE DB。

可适用于数据量不大，并发访问较高的DB环境。

请大家多提意见，谢谢。

mageguoshi

我也曾经有过这样的考虑，不过没实践过，数据完整是个大问题

yueliangdao0608

你不用划分，直接用LINUX自己映射的tmpfs就可以了。

而且不知道你的表引擎是什么？如果是MYISAM和HEAP，那没有必要，如果是INNODB，到是可行。

r_a

谢谢二楼的提醒，请问你所提到的“数据完整”的问题，具体表现或影响在哪里？

谢谢三楼。我所用的DB引擎是INNODB。
还有两点还有点不解，恳请指教：
1）如果选用MYISAM，也能降低磁盘IO吧。
2）关于ramfs和tmpfs
“原理上看来，ramfs只使用物理内存，而tmpfs工作在虚拟内存这一层面，也就是可以同时使用物理内存和交换分区。”

以上的DB架构未经实际应用过，所以可靠性有待进一步证实。有空我会做个初步的测试对比，也欢迎大家多提意见。谢谢。

gogo407

原帖由 r_a 于 2009-3-8 13:43 发表
谢谢二楼的提醒，请问你所提到的“数据完整”的问题，具体表现或影响在哪里？

谢谢三楼。我所用的DB引擎是INNODB。
还有两点还有点不解，恳请指教：
1）如果选用MYISAM，也能降低磁盘IO吧。
2）关于ramfs ...

泼点冷水，不太看好
1.数据你确保始终小于1G？
2效率有多大提升？，我觉得与其这样还不如加点内存，改点SQL，做点缓存

r_a

做了以下测试。


1.测试环境： Dual Xeon E5310 + RAM 4GB + SCSI 146GB
             Gentoo 2.6.27 + Mysql 5.1.31(Innodb)               
2.测试工具：super-smack               
3.测试程序：对测试表执行以下操作
(1)Select (2)Update (3)Select+Update               
4.测试在以下DB结构下的表现：               
    (A)内存库，binlog写入磁盘           
    (B)磁盘库，binlog写入磁盘           

5. 测试结果
（1）select 在两种DB结构下，表现相近。略

（2）update (200个并发线程，各执行1000次update请求)
（A）内存库环境下的结果：
CPU：40％
IO wait: 1%
平均每秒处理的请求数：10478.35  
total time：19.117s   
（B）磁盘库环境的结果：
CPU：1％
IO wait: 6 ％
平均每秒处理的请求数：120.56   
total: 27m39.011s   

（3）与（2）相似。略。

小结： 从以上单表测试的结果来看，采用内存库对性能提高还是很明显的。

bs

现有的瓶颈在哪里，楼主的目的是什么？

yueliangdao0608

原帖由 r_a 于 2009-3-10 23:06 发表
做了以下测试。


1.测试环境： Dual Xeon E5310 + RAM 4GB + SCSI 146GB
             Gentoo 2.6.27 + Mysql 5.1.31(Innodb)               
2.测试工具：super-smack               
3.测试程序：对测 ...

磁盘跟内存比？

有意义吗？

r_a

原帖由 bs 于 2009-3-11 09:17 发表
现有的瓶颈在哪里，楼主的目的是什么？

实际应用环境可能是：
1个DB服务器，支持5至8个WEB服务器。
在某些时段的并发访问很高，会引起DB服务器的IO瓶颈。
又因DB本身不大，现在约300M。后期增长也不快。
综合以下因素，所以才考虑用内存库来实现。

r_a

原帖由 yueliangdao0608 于 2009-3-11 09:44 发表



磁盘跟内存比？

有意义吗？

这个测试，只是验证在内存库环境下的SQL更新操作效率高这方面。

但就整体方案的稳定性，安全性等方面的验证，请大家多提意见。欢迎拍砖。

[ 本帖最后由 r_a 于 2009-3-11 12:44 编辑 ]