常说的数据库I/O

这是51cto上的一篇文章,下载下来的,看了觉得还是不错的,怕以后给搞丢了,就转到这里来了,方便以后看。     

目前web的应用大多都以I/O密集型为主,而存储技术的发展远没有计算机中其他系统发展迅速,尽管也有不少高端存储设备,但是价格的昂贵,不是一 般大众能享受的起的。而基于现状更多是我们使用一般SAS盘结合应用使用不同的  RAID组合,来实现我们平民化存储,为了得到更好的性能,那么和I/O相 关的调整优化是必不可少的。

  对于我们数据库调优来说,磁盘I/O优化是首屈一指的调优重点,我们都知道木桶原理,短板绝对整体的好坏,而数据库系统中这个短板正是由于我们 使用的硬件设备里最弱的磁盘所导致。很多时候,我们会发现系统中I/O累得要死,而CPU却在那里空闲等待,主要是由于I/O执行响应时间太长,处理读写 的速度远远赶落后于CPU的处理速度,这时我们会尽可能的让操作放到内存中进行,由磁盘与CPU的关系,转变成内存与CPU的关系。但是,我们始终不能回 避磁盘I/O的弱点,优化是必须的。

  对于数据库在日常应用中的特点,我们可以有很多想法。

  1. 随机读写的负载可以通过增加硬盘的个数实现扩展。

  2. 对于顺序读写带来的压力,可以通过选择带宽相对高一些的磁盘来解决。

  3. RAID 5和RAID 10都是不错的原则对于数据库应用来说。

  4. 当然,基于自身业务的关键程度与成本双重考虑,Fusion-io卡(读与写的性能俱佳)和SSD(优秀的随机读),都未尝不是一个理想的选择。

  5. 在操作系统中,I/O Scheduler的调度模式选择deadline对于数据库应用是有利的。命令:echo deadline > /sys/block//queue/scheduler

  6. 操作系统中nr_requests参数,可以提高系统的吞吐量,似乎越大越好,但是该请求队列的也不能过大,因为这样会消耗大量的内存空间。该值的调整需 要综合多处因素,比如: 文件系统、sheduler类型、io的特点。命令: echo xxx > /sys/block//queue/nr_requests,nr_requests的大小设置至少是/sys/block//device /queue_depth的两倍,所以,修改nr_requtests的时候要注意。

  7. 系统目录/sys/block//queue下还有一个预读的参数read_ahead_kb,这个参数增大只会对顺序读的操作有提升,而数据库这类应用中多数是随机读;通过命令hdparm -t /dev/sda{,,}可以测试修改后预读的效果。

你可能感兴趣的:(编程大白)