MySQL MyISAM / PHP 高并发优化经验

22 篇文章 0 订阅

MySQL MyISAM / PHP 高并发优化经验  

最近做的一个应用,功能要求非常简单,就是 key/value 形式的存储,简单的 INSERT/SELECT,没有任何复杂查询,唯一的问题是量非常大,如果目前投入使用,初期的单表 insert 频率约 20Hz(次/秒,我喜欢这个单位,让我想起国内交流电是 50Hz),但我估计以后会有 500Hz+ 的峰值。目前的工作成果,额定功率 200Hz(CPU 占用 10 - 20,load avg = 2),最大功率 500Hz(这时 load avg > 20,很明显,只能暂时挺挺,应该在出现这种负载前提前拆表了)

INSERT DELAYED INTO

从数据的插入开始说起。如果可以容忍结果几秒以后再生效的,可以用 INSERT DELAYED INTO,因为在我的这个结构中不需要对同一个 key 频繁的 INSERT/SELECT,因为 SELECT 我是用 Memcached 挡住了,除非 Memcached 挂了,或者数据实在老到过期了,才会去 SELECT。而且要注意,如果 PHP 不需要关心 MySQL 操作的返回结果,应该使用 unbuffered query,简单的说,在你提交 query 后,不用等待 MySQL 有返回信息就继续执行之后的 PHP 指令,具体用法是用 mysql_unbuffered_query 代替 mysql_query,如果用的 MySQLi 类,应该使用 mysqli->query($sQuery, MYSQLI_USE_RESULT);

如果 SHOW PROCESSLIST,可以看到用户名为 DELAYED 的进程,进程数量等于 INSERT DELAYED 的表的数量,因为表级锁的存在,每个表一条以上的 DELAYED 进程是没有意义的

关于这个功能的 my.cnf 配置有三条,我定为如下值

delayed_insert_limit = 1000
delayed_insert_timeout = 300
delayed_queue_size = 5000

连接

有人说,如果报错连接数过大,你把 max_connections 调大就 OK,如果只这么说而不讲原因,完全是句废话,你调成 1M 肯定不会再报 Too many connections(但应该会报内存溢出之类的),但如果是这样 MySQL 又何必给这个参数?

我看到的一个很有用的公式

key_buffer_size + (read_buffer_size + sort_buffer_size) * max_connections

以前只有很模糊的概念,应该设的很大,但又不能太大,具体多大合适,知道这个就明确了。innoDB 的公式比这个复杂点,一并给出

innodb_buffer_pool_size
+ key_buffer_size
+ max_connections * ( sort_buffer_size + read_buffer_size + binlog_cache_size )
+ max_connections * 2MB

还有一个看起来很有用的参数 back_log,给我一种连接池的感觉,而且它确实在起作用,我不知道如果设大了会占用多少内存,但估计不会很多。

key_buffer_size

很多文章都告诉你越大越好,要为此分配一半左右的物理内存,这么干通常不会出问题,但肯定不是最优的,甚至可以说很无理头——分多少内存应该是根据需求决定,而不是不管什么机器,都砍掉一半内存用作 key_buffer_size ——有的时候可能是不够,还有的时候可能是浪费。

其实最关键的指标,还是看 SHOW GLOBAL STATUS 时的 Key_blocks_unused,只要还有剩余,就说明 key_buffer_size 没用满。有人说看 Key_reads 跟 Key_read_requests 的比值,至少要达到 1:100。这可以作为一个结果来衡量,但不够准确,因为在服务器刚启动的时候,大多数请求都要新建缓存,缓存命中比高不起来,需要运行稳定(几小时后)再观察。我个人建议还是看 Key_blocks_unused

如果不花很长时间在运行中调试,给出一个简单的计算方法,把数据库填满,达到设计时的最大值,看看这时候索引占了多大空间,然后把所有表的索引大小加起来,就是 key_buffer_size 可能达到的最大值,当然,还要留些余地,乘个 2 或 3 之类的。

这是我做测试的时候的 phpMyAdmin 截图,可以看到 key_buffer_size 被浪费了太多

OPTIMIZE TABLE

优化一下有好处,但会锁住表,是否值得做要权衡一下。拿我现在这个表做例子,有 text 字段,700万条记录,1.5G 大小,优化时间约两分钟,优化后性能提升了 50%,同时表的大小变为 1.4G,但随着表的频繁改写,约一天后又恢复到以前的速度,因此在我看来并不值得。

Query Cache

因为每有写操作 Query Cache 都会被清空,除了极特殊的情况(大量读,少量写,但即使这样也应该是多用 memcached 才对)完全没有必要使用这个,把 query_cache_size 设为 0 关闭这个功能吧

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值