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

概述  最近帮朋友升级了论坛，把数据库换成了postgreSQL，运行有一周。通过前后对比才发现pgsql性能有多强悍，或者说mysql有多低能。 论坛地址： www.ifxtx.com 网络带宽：100M独享 论坛流量：日均IP 8K，日均PV 35K 论坛程序：dz7.2 论坛数据：用户15万，主题32万，回帖502万，数据库3G左右。 系统配置：   web server 为 DELL 2950 最近帮朋友升级了论坛，把数据库换成了postgresql，运行有一周。通过前后对比才发现pgsql性能有多强悍，或者说MysqL有多低能。
论坛地址： www.ifxtx.com
网络带宽：100M独享
论坛流量：日均IP 8K，日均PV 35K
论坛程序：dz7.2
论坛数据：用户15万，主题32万，回帖502万，数据库3G左右。
系统配置：
web server 为 DELL 2950III4核*双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！

650) this.width=650;" alt="" src="http://img.jb51.cc/vcimg/static/loading.png" src="http://static.oschina.net/uploads/space/2012/0723/172938_vI2R_126398.png">

因为数据库实在不给力，遂决定使用高效的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-50ms
forumdisplay主题列表	100-200ms	30-120ms （与版块主题数量有关）
post帖子内容页	100-200ms	30-50ms左右（不分缓存与否）

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

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

650) this.width=650;" alt="" width="300" src="http://img.jb51.cc/vcimg/static/loading.png" src="http://static.oschina.net/uploads/img/201207/23173543_MFaC.jpg">

650) this.width=650;" alt="" width="300" src="http://img.jb51.cc/vcimg/static/loading.png" src="http://static.oschina.net/uploads/img/201207/23173543_0Ipx.jpg">

650) this.width=650;" alt="" width="300" src="http://img.jb51.cc/vcimg/static/loading.png" src="http://static.oschina.net/uploads/img/201207/23173544_ba1p.jpg">

650) this.width=650;" alt="" width="300" src="http://img.jb51.cc/vcimg/static/loading.png" src="http://static.oschina.net/uploads/img/201207/23173545_QAAj.jpg">

这些是dbserver的状况：

650) this.width=650;" alt="" width="300" src="http://img.jb51.cc/vcimg/static/loading.png" src="http://static.oschina.net/uploads/img/201207/23173545_i5r8.jpg">

650) this.width=650;" alt="" width="300" src="http://img.jb51.cc/vcimg/static/loading.png" src="http://static.oschina.net/uploads/img/201207/23173546_DMby.jpg">

650) this.width=650;" alt="" width="300" src="http://img.jb51.cc/vcimg/static/loading.png" src="http://static.oschina.net/uploads/img/201207/23173546_u8Ct.jpg">

这是Nginx的状况以及webserver连接数：

650) this.width=650;" alt="" width="274" src="http://img.jb51.cc/vcimg/static/loading.png" src="http://static.oschina.net/uploads/img/201207/23173546_BlsQ.jpg">

650) this.width=650;" alt="" width="187" src="http://img.jb51.cc/vcimg/static/loading.png" src="http://static.oschina.net/uploads/img/201207/23173546_hfWD.jpg">

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

650) this.width=650;" alt="" width="300" src="http://img.jb51.cc/vcimg/static/loading.png" src="http://static.oschina.net/uploads/img/201207/23173547_3X6x.jpg">

上 图是跑在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带宽。后来因为cn备案问题不得已换了几次域名，折腾一番导致现在流量下降不少。不少老会员还没找到新庙门…… 附注3：这可是dz7.2没有memcache机制哟！做过xcache测试，性能提升不明显，看来memcache在高流量下才对性能有提升，在目前并发流量下提升不明显。 总结

以上是内存溢出为你收集整理的见识下postgreSQL的强悍，对比下mysql的低能全部内容，希望文章能够帮你解决见识下postgreSQL的强悍，对比下mysql的低能所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。