最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

见识下postgreSQL的强悍,对比下mysql的低能

[复制链接]
发表于 2015-6-17 10:01:22 | 显示全部楼层 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
最近帮朋友升级了论坛,把数据库换成了postgreSQL,运行有一周。通过前后对比才发现pgsql性能有多强悍,或者说mysql有多低能。
论坛地址: www.ifxtx.com
网络带宽:100M独享
论坛流量:日均IP 8K,日均PV 35K
论坛程序:dz7.2
论坛数据:用户15万,主题32万,回帖502万,数据库3G左右
系统配置:
  web server 为 DELL 2950III  4核*双CPU E5320 1.86GHz,8G内存,SAS组RAID5,Centos6.2 X64,nginx,php-fpm,xcache
  db server 为 DELL 2950III 4核*双CPU E5320 1.86GHz,8G内存, SSD盘 * 3 做RAID5,Centos6.2 X64,postgresql 9.1,mysql5.1
  webold server 为 DELL R710 , 8G内存, SAS组的RAID5,Win2003,Mysq 5.1,IIS

之前论坛是 webold 上面跑也跑数据库,论坛相当慢,首页打开时常需要12秒多。IIS经常挂掉需要定期重启。后来启用了db服务器,并且加大了dz数据调用频率,系统负载有所下降。首页打开非缓存时在7秒左右。不过IIS还是时常抽风。询问得知mysql连接数要开到1000以上才能保证论坛不出现“数据库无法连接”的白板。不过我发现实际开的是7000!

因为数据库实在不给力,遂决定使用高效的pgsql做替换尝试。

于是使用web + db的组合方式。web上php-fpm开了150个最大进程,前端是nginx开了4个进程;db上只跑pgsql,开了500个最大连接。一番折腾测试结果还不错,于是在上周六做了系统切换。经过这段时间性能监控,对于pgsql的表现非常满意。说非常而不是极其满意这是因为之前对pgsql有一定了解,所以对其相比mysql的优异性能表现没太多意外。但对于从未接触过mysql之外的人来说也许会震惊的!

论坛在线简要对比,在线人数2K+(session有效时间30分钟), 以登录用户测试:

项目webold + db(mysql)web + db(pgsql)
index非缓存刷新大约7秒(非缓存清空)2秒左右(清空所有缓存包括模板)
index缓存刷新大约1秒30-40ms
forumdisplay主题列表100-200ms30-120ms (与版块主题数量有关)
post帖子内容页100-200ms30-50ms左右(不分缓存与否)

除了在版块主题列表上差距不大之外,其他项目差别非常明显。并且pgsql各项数据与在调试阶段无流量压力时的值没啥差别!
为啥调试阶段的数据库性能表现与上线后没啥差别呢? 除了pgsql程序本质优秀之外还有个重要因素:pgsql是行锁,而dz默认采用的mysql是myisam表锁。流量越大表锁对性能的影响越恶劣。具体解释请看这儿 http://www.discuz.net/thread-2934412-1-1.html

下面是21点论坛高峰期服务器状况截图:
这些是webserver的



这些是dbserver的状况:



这是nginx的状况以及webserver连接数:




如果以上数据只是让你觉得流量不小,服务器性能比较好,所以服务器压力不大。那么就再看一张图:


上图是跑在webserver上面的pgsql连接池程序pgbouncer ,设定的非性能最佳的trasaction模式而是session模式。但实时连接数如此之低,没超过10个,是不是让你震撼了呢?你再回头看看上面 db-top.png 这张图中postgres进程数量作相互对证,就知道pgsql有多强悍了吧。
以前mysql要开1000个连接,这并不代表mysql可以处理1000个这么多个连接请求,而反倒是因为它太慢处理不了不能及时处理完论坛而只能增加最大连接数让被阻塞的连接请求处于队列中,从而用户在打开页面时不会出现mysql数据库无法连接的错误页面,而是一直等待罢了。
而pgsql因为处理效率高性能出色,所以可以尽快处理完web请求从而接受新的请求,于是总的连接数反倒是减小了。小得连我吃惊的地步。上线后做过(短时间)极端测试,把pgbouncer允许连接数和pgsql最大连接数改到30个,论坛也运作正常。可见截图数据可信。

总而言之,如果你是新论坛,数据量不超过100万,那么用mysql没啥性能问题(表损坏除外)。但如果论坛已经上线运行已久,数据量过百万上千万,那么除非用硬件去堆否则mysql的低能表现会让你头疼甚至崩溃。

所以用DX2,2.5慢如蜗牛的站长们不要吐嘈dz。dz只是功能太多而已,根本原因在于mysql太垃圾,无法应付dz的复杂查询以及高流量而已。




附注:以上数据那么漂亮,除了因为pgsql实在是太出色之外,还因为我对dz代码在各个方面做了相当的优化。极大减小了数据库压力。详细在此 http://www.oschina.net/question/126398_36342

附注2:以前服务器最高跑到90M带宽,日IP 30K。后来被关站几个月,再为cn备案问题不得已换了几次域名,折腾一番导致现在流量下降不少。不少老会员还没找到新庙门……

附注3:这可是dz7.2没有memcache机制哟!做过xcache测试,版块内页打开在30ms左右,帖子内页在16-30ms左右,看来memcache在高流量下对性能有提升,在目前流量下提升不明显。
楼主热帖
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-3-29 23:51

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表