MySQL MyISAM / PHP 高并发优化经验

原创 2012年03月30日 11:20:38

最近做的一个应用,功能要求非常简单,就是 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 关闭这个功能吧


相关文章推荐

MySQL MyISAM/InnoDB高并发优化经验

最近做的一个应用,功能要求非常简单,就是 key/value 形式的存储,简单的 INSERT/SELECT,没有任何复杂查询,唯一的问题是量非常大,如果目前投入使用,初期的单表 insert 频率约...

MySQL MyISAM/InnoDB高并发优化经验

转自:http://cache.baiducontent.com/c?m=9d78d513d99c0aee1bb3837e7c01a1670e2582744ca0c7647ec392388414505...
  • hzqhbc
  • hzqhbc
  • 2013年08月26日 15:05
  • 599

MySQL MyISAM/InnoDB高并发优化经验

最近做的一个应用,功能要求非常简单,就是 key/value 形式的存储,简单的 INSERT/SELECT,没有任何复杂查询,唯一的问题是量非常大,如果目前投入使用,初期的单表 insert 频率约...

【高并发简单解决方案】redis缓存队列+mysql 批量入库+php离线整合

【高并发简单解决方案】redis缓存队列+mysql 批量入库+php离线整合

高并发简单解决方案-redis缓存队列+mysql 批量入库+php离线整合

高并发简单解决方案-redis缓存队列+mysql 批量入库+php离线整合

PHP_MySQL高并发加锁事务处理

1、背景: 现在有这样的需求,插入数据时,判断test表有无username为‘mraz’的数据,无则插入,有则提示“已插入”,目的就是想只插入一条username为‘mraz’的记录。 2、一般...
  • mlx212
  • mlx212
  • 2016年05月20日 16:02
  • 4620

记录PHP、MySQL在高并发场景下产生的一次事故

事故描述 在一次项目中,上线了一新功能之后,陆陆续续的有客服向我们反应,有用户的个别道具数量高达42亿,但是当时一直没有到证据表示这是,确实存在,并且直觉告诉我们,这是不可能的,就一直没有在意,直到...
  • looksun
  • looksun
  • 2015年02月28日 08:37
  • 2381

【高并发简单解决方案】redis队列缓存 + mysql 批量入库 + php离线整合

需求背景:有个调用统计日志存储和统计需求,要求存储到mysql中;存储数据高峰能达到日均千万,瓶颈在于直接入库并发太高,可能会把mysql干垮 问题分析 思考:应用网站架构的衍化过...

linux下nginx服务应用总结(2)--突破10万高并发的nginx性能优化经验(含内核参数优化)

转载:http://www.cnblogs.com/kevingrace/p/6094007.html 在日常的运维工作中,经常会用到nginx服务,也时常会碰到nginx因高并发导致的性能瓶颈...

nginx-php-fpm 高并发配置优化

http://blog.sina.com.cn/s/blog_62dc53a401016t3p.html
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:MySQL MyISAM / PHP 高并发优化经验
举报原因:
原因补充:

(最多只允许输入30个字)