数据一多！速度就慢！我这里讲解MySQL查询优化

当你执行管理员优化的时候，应该紧记以下规则：

· 访问内存中的数据快于访问磁盘上的数据。

· 尽

  作者：吴炳锡　来源：http://www.mysqlsupport.cn/

       对于使用MySQL的用户，对于这个变量大家一定不会陌生。前几年的MyISAM引擎优化中，这个参数也是一个重要的优化参数。但随着发展，这个参数也爆露出来一些问题。

       机器的内存越来越大，人们也都习惯性的把以前有用的参数分配的值越来越大。这个参数加大后也引发了一系列问题。我们首先分析一下query_cache_size

一、块大小的优化

块意为最小的存储单位
假设：Block size 1K
每个分区被格式化后，都会创建很多块
如果一个文件有4K，要使用4个块
即使一个块不到1K，但也会使用1个块
假设：Block size 4K
如果一个文件有4K，只使用1个块
即使一个块不到4K，也会使用1个块，直到填满才使用下一个块

这样我们就可以看到一个现象，如果你的文件很大，而数据块很小，这个文件就会被分割成很小的很多块，这样分割的时间和寻址的时间都会花费比较多的时间，相反如果数据块大点就会减少相应的时间！但并非块越大越好

转载本站文章请注明，转载自：扶凯[http://www.php-oa.com]
本文链接: http://www.php-oa.com/2010/01/03/linux-io-elevator.html

I/O 调度算法再各个进程竞争磁盘I/O的时候担当了裁判的角色。他要求请求的次序和时机做最优化的处理，以求得尽可能最好的整体I/O性能。

linux下面列出4种调度算法

CFQ (Completely Fair Queuing 完全公平的排队)(elevator=cfq)：
这是默认算法，对于通用服务器来说通常是最好的选择。它试图均匀地分布对I/O带宽的访问。在多媒体应用, 总能保证audio、video及时从磁盘读取数据。但对于其他各类应用表现也很好。每个进程一个queue，每个queue按照上述规则进行merge和sort。进程之间round robin调度，每次执行一个进程的4个请求。

Deadline (elevator=deadline)：
这个算法试图把每次请求的延迟降至最低。该算法重排了请求的顺序来提高性能。

NOOP (elevator=noop):
这个算法实现了一个简单FIFO队列。他假定I/O请求由驱动程序或者设备做了优化或者重排了顺序(就像一个智能控制器完成的工作那样)。在有些SAN环境下，这个选择可能是最好选择。适用于随机存取设备, no seek cost，非机械可随机寻址的磁盘。

Anticipatory (elevator=as):
这个算法推迟I/O请求，希望能对它们进行排序，获得最高的效率。同deadline不同之处在于每次处理完读请求之后, 不是立即返回, 而是等待几个微妙在这段时间内, 任何来自临近区域的请求都被立即执行. 超时以后, 继续原来的处理.基于下面的假设: 几个微妙内, 程序有很大机会提交另一次请求.调度器跟踪每个进程的io读写统计信息, 以获得最佳预期.

linux中IO调度方法的查看和设置的方法

查看当前IO

# cat /sys/block/sd*/queue/scheduler
# noop anticipatory deadline [cfq]

设置当前IO
# echo noop > /sys/block/hda/queue/scheduler

对IO调度使用的建议
      Deadline I/O scheduler 使用轮询的调度器,简洁小巧,提供了最小的读取延迟和尚佳的吞吐量,特别适合于读取较多的环境(比如数据库,Oracle 10G 之类).Anticipatory I/O scheduler 假设一个块设备只有一个物理查找磁头(例如一个单独的SATA硬盘),将多个随机的小写入流合并成一个大写入流,用写入延时换取最大的写入吞吐量.适用于大多数环境,特别是写入较多的环境(比如文件服务器)Web,App等应用我们可以采纳as调度.CFQ I/O scheduler使用QoS策略为所有任务分配等量的带宽,避免进程被饿死并实现了较低的延迟,可以认为是上述两种调度器的折中.适用于有大量进程的多用户系统我在生产环境中测试过一台机器本来流量只有350M的样子,有时压力就不行了,流量也上不去了,因为读比较多,所以使用deadline后,流量上升了50M,从流量之类的图上也见到稳定很多.

linux启动时设置默认IO调度
让系统启动时就使用默认的IO方法,只需在grub.conf文件中加入类似如下行
kernel /vmlinuz-2.6.24 ro root=/dev/sda1 elevator=deadline

有关IO的几个内核参数

echo '40'> /proc/sys/vm/dirty_ratio
这个参数控制文件系统的文件系统写缓冲区的大小，单位是百分比，表示系统内存的百分比，表示当写缓冲使用到系统内存多少的时候，开始向磁盘写出数 据。增大之会使用更多系统内存用于磁盘写缓冲，也可以极大提高系统的写性能。但是，当你需要持续、恒定的写入场合时，应该降低其数值，一般启动上缺省是 10。下面是增大的方法：

echo '20' > /proc/sys/vm/dirty_background_ratio
这个参数控制文件系统的pdflush进程，在何时刷新磁盘。单位是百分比，表示系统内存的百分比，意思是当写缓冲使用到系统内存多少的时候， pdflush开始向磁盘写出数据。增大之会使用更多系统内存用于磁盘写缓冲，也可以极大提高系统的写性能。但是，当你需要持续、恒定的写入场合时，应该 降低其数值，一般启动上缺省是 5。下面是增大的方法：

echo '200' > /proc/sys/vm/dirty_writeback_centisecs
这个参数控制内核的脏数据刷新进程pdflush的运行间隔。单位是 1/100 秒。缺省数值是500，也就是 5 秒。如果你的系统是持续地写入动作，那么实际上还是降低这个数值比较好，这样可以把尖峰的写操作削平成多次写操作。设置方法如下：

echo '1000' > /proc/sys/vm/dirty_writeback_centisecs
如果你的系统是短期地尖峰式的写操作，并且写入数据不大（几十M/次）且内存有比较多富裕，那么应该增大此数值：

echo '1500' > /proc/sys/vm/dirty_expire_centisecs
这个参数声明Linux内核写缓冲区里面的数据多“旧”了之后，pdflush进程就开始考虑写到磁盘中去。单位是 1/100秒。缺省是 30000，也就是 30 秒的数据就算旧了，将会刷新磁盘。对于特别重载的写操作来说，这个值适当缩小也是好的，但也不能缩小太多，因为缩小太多也会导致IO提高太快。建议设置为 1500，也就是15秒算旧。当然，如果你的系统内存比较大，并且写入模式是间歇式的，并且每次写入的数据不大（比如几十M），那么这个值还是大些的好。

From：http://zys.8800.org/index.php/archives/391

目标:

单台Cacti服务器，同时监控1000+ Server，50000+ RRD 文件. 保证图表数据的连续和流畅，每一轮数据采集时间控制在3分钟之内。

硬件环境:
Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz  4 cores
4G memory
normal sata disk


优化步骤:

1，优化数据库schema，建立合理的索引

cacti默认的cacti.sql建立的数据库模型，竟然一个Index都没有建。每次执行poller.php的时候，主要的时间，都花费在数据库查询上。使用下面的sql语句，建立一系列索引，弥补默认的cacti.sql中缺乏index的缺点。可以有效的提高poller.php执行的效率，缩短更新RRD文件所需的时间

CREATE INDEX `data_template_data_id` ON `data_input_data` (`data_template_data_id`);
CREATE INDEX `host_id_snmp_query_id_snmp_index` ON data_local (`host_id`,`snmp_query_id`,`snmp_index`);
CREATE INDEX `local_data_id_data_source_name` ON data_template_rrd (`local_data_id`,`data_source_name`);
CREATE INDEX `graph_template_id_local_graph_id` ON graph_templates_item (`graph_template_id`,`local_graph_id`);
CREATE INDEX `local_graph_template_item_id` ON graph_templates_item (`local_graph_template_item_id`);
CREATE INDEX `host_id_snmp_query_id_snmp_index` ON host_snmp_cache (`host_id`,`snmp_query_id`,`snmp_index`);
CREATE INDEX `local_data_id_rrd_path` ON poller_item (`local_data_id`,`rrd_path`);
CREATE INDEX `host_id_rrd_next_step` ON poller_item (`host_id`,`rrd_next_step`);
CREATE INDEX host_id_snmp_query_id ON host_snmp_cache (host_id,snmp_query_id);
CREATE INDEX host_id_snmp_port ON poller_item (host_id,snmp_port);
CREATE INDEX data_source_path ON data_template_data (data_source_path);

2，使用spine替代默认的cmd.php来采集数据

wget http://www.cacti.net/downloads/spine/cacti-spine-0.8.7e.tar.gz
tar zxvf cacti-spine-0.8.7e.tar.gz
cd cacti-spine-0.8.7e

wget http://www.cacti.net/downloads/spine/patches/snmp_v3_fix.patch
wget http://www.cacti.net/downloads/spine/patches/mysql_client_reconnect.patch
wget http://www.cacti.net/downloads/spine/patches/ping_reliability.patch
patch -p1 -N < snmp_v3_fix.patch
patch -p1 -N < mysql_client_reconnect.patch
patch -p1 -N < ping_reliability.patch

./configure –prefix=cacti_install_dir
make
make install

然后编辑cacti_install_dir/etc/spine.conf
修改DB_HOST DB_DATABASE DB_USER DB_PASSWORD几个参数
最后，在cacti的setting->poller页面里，将poller type设置成spine，同时设置spine的Maximum Threads per Process， Number of PHP Script Servers， Script and Script Server Timeout Value几个参数。
通常会把Maximum Threads per Process设置成cpu * 2。在这里，我们设置成8.


3, 重构rra文件的目录结构，为每个device建立单独的rra目录
首先在crontab里禁用poller.php，然后执行cacti_install_dir/cli目录下的structure_rra_paths.php，它会将所有的RRD文件按照device重新分配目录，并修改数据库中的RRD路径，成功执行后，再恢复poller.php的crontab就可以了。
按照上面3个步骤，710台服务器，24000个RRD文件，完成一次poller.php的时间，缩短到50 seconds。实现了最初的目的。

TODO:

在执行poller.php的时候, 监控服务器的load达到了3，通过vmstat查看，显示负载主要在I/O。在目前的情况，如果再出现瓶颈，可以考虑安装Boost插件来进一步提供性能。
cacti主要通过snmp来采集数据，可以引入collected等客户端，提供数据采集的可靠性。