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

mark35 发布于 2012/07/23 17:05
阅读 31K+
收藏 38
最近帮朋友升级了论坛,把数据库换成了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-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的



这些是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带宽。后来因为cn备案问题不得已换了几次域名,折腾一番导致现在流量下降不少。不少老会员还没找到新庙门……

附注3:这可是dz7.2没有memcache机制哟!做过xcache测试,性能提升不明显,看来memcache在高流量下才对性能有提升,在目前并发流量下提升不明显。


以下是话题补充:

@mark35:下文 【Discuz真实环境中postgres与myisam查询性能对比,还有人说mysql快么】 http://www.oschina.net/question/126398_62129 (2012/07/25 23:21)
@mark35:此站点被无关部门强制关闭3个月,恢复后又因备案问题更换了两次域名,现在启用的是一个全新注册域名,导致流量大减。之前IP近3W,百度6。所以不要看到现在的数据误以为之前负载低。 (2012/07/27 11:14)
@mark35:目前此论坛权重恢复到百度4,google5了。流量继续加大。 (2012/08/03 17:51)
加载中
1
mystar
mystar

lz的说法有点夸张,最近做的应用用的就是mysql,随便说说。我们的应用是写强读弱,有几千个线程持续在做数据的预处理和提交数据库更新工作,峰值需要mysql每秒处理1.5万次写和3-6千次读。 应用是按7x24小时不间断跑的,mysql平均每分钟的写/更新记录超过40万次,读超过10万次。数据库的几张大表的大小在日均500万行记录左右,超过就进行分表,每天增长的数据文件超过20个G。 我相信你的每天 3.5万pv 不管是写还是读,甚至并发请求,都是没法和我们这个比的。

1. mysql 5.1和5.5的性能差距巨大, 我们的应用事物(含多个写/更新和1-2个读)平均处理时间,在3000个请求处理线程的情况下,5.1 是平均150-300ms毫秒,而5.5是25-50ms。这里用的是innodb,innodb的一些参数调整也可以导致性能差异在一个数量级。 mysql并发支持确实比较弱一点,在几个请求线程以内,5.1基本可以做到平均事物执行时间5-10毫秒。

2. 几千个数据库连接显然是不合理的,在使用连接池的情况下, 单数据库的连接数应该严格控制在100以内,极端情况也不要超过200-300。 曾经做个的一个项目,后端用小型机+db2,在连接数达到3000以后,数据库经常满负荷运行,后来优化应用服务器,把数据库连接总数降到100以内以后,数据库就非常轻松了,连接会话的保持和工作线程的切换都是非常占资源的。IBM的工程师曾经告诉我招商银行网上银行的连接数设置也只有150. 曾经某项目开发人员无经验,在性能测试的时候草率的把连接池设置成150,报连接超时或不够的时候又继续往上加,越大越慢,系统无法稳定运行,实际应该20个连接就足够了。

我们初始阶段也只是简单使用连接池,未控制mysql的数据库连接访问,结果出现大问题,连接池越大,mysql响应越慢,经过测试发现,在我们的环境里(4核+8g)mysql的连接数在30左右时拥有最好的并发处理性能, 超过30个性能就大幅度下降,100个以上处理基本全部都阻塞了。

所以额外写了一个连接管理队列,确保处理数据更新的并发线程不超过30个,每个线程分配一个数据库连接,因为mysql整体的吞吐效率提高了,依然可以应付并发3000个处理请求。这方面个人感觉msyql的大并发处理确实不如oracle和db2,但是应用设计上完全可以回避。

在楼主的列子里,因为不了解dz的设计,但是正常这种论坛也应该使用连接池管理连接重用,不应该产生几千个数据库连接的情况。另外我知道dz+mysql,单机对付一天几十万pv的例子大把。

我不是mysql的专家和fans,其实我个人也更偏向于postgres,因为功能更完善,多核环境下性能更好,但是就你这个列子,感觉根本说明不了postgres和mysql的差异。

 

 

 

 

1
君陌
君陌

通读了一遍文章加所有评论,有一事不解

楼主既然知道是因为MyISAM表锁导致写并发大时数据库锁死,又知道innodb是行锁的,为什么没有试过直接采用innodb呢?

虽然我也是pgsql的支持者,但也没有必要如此黑mysql。而且mysql != MyISAM

0
AiryLinus
AiryLinus
我感觉原来的 IIS + MySQL 有问题,性能对比太夸张了点。
13123123
13123123
百兆光钎就做成这种速度。。
13123123
13123123
笑而不语 mysql 做论坛速度非常快竟然说成这样。。
0
mark35
mark35

引用来自“AiryLinus”的答案

我感觉原来的 IIS + MySQL 有问题,性能对比太夸张了点。
最开始单服务器上IIS+mysql的确很多问题。mysql内存占用也不高,但龟速,IIS也时常挂掉。后来把mysql丢dbserver(linux)上数据库还是慢不过比较稳定了,不过IIS还是不稳定。
0
mark35
mark35
晕,怎么发布了就不能编辑了呢
mark35
mark35
回复 @Jimmy_牛牛 : 不是我想说,而是从综合比较以及后续单独对比来看不得不承认。除非是测试环境存在问题。
岳静
岳静
@红薯 @红薯 不好意思搞错了。。
红薯
红薯
回复 @Jimmy_牛牛 : 不是我说的
岳静
岳静
@红薯 怎么能说mysql低能呢,我觉得你应当全面的比较,它们各有各的优点
mark35
mark35
回复 @红薯 : 就是贴图。顶楼那个引用成缩略图,太小看不清。我正在回帖上传原图
下一页
0
mark35
mark35

重新贴图:

web服务器状况

web-top

 

 

 

 

 

0
mark35
mark35

dbserver

 

 

 

0
mark35
mark35

这个是mysql的配置,7000最大连接啊!

mark35
mark35
回复 @俞慧涛 : 我不管7000的设置是否正确。但我的测试是在无外部数据请求0压力的环境做的,这个时候你觉得7000和70的设置有区别么,会影响测试结果么??
mark35
mark35
回复 @俞慧涛 : mysql5.5没用过,好不好只有等我用同样的数据测试了才知道。
Raynor1
Raynor1
@mark35 不管是怎么样的商业数据库.还算你的POSTGRESQL.都有这一层..
Raynor1
Raynor1
@mark35 底层实现中SQL中.MYSQL PROXY会过滤一层给你写的SQL作优化.而MYSQL5.1版本中的优化器并不是很完善.所以会发现你在用复杂你查询的时候性能是不怎么样.但是在5.5后面ORACLE对MYSQL有作过查询优化所以会快不少.POSTGRESQL9.1已经是近两年的东西了.对应的也是MYSQL的5.5版本.
mark35
mark35
回复 @俞慧涛 : 我实在笑得受不了了,mysql那简陋寒酸的explain真有人当宝啊~~~
下一页
0
IdleMan
IdleMan
表级锁?!惨不惨
Raynor1
Raynor1
回复 @mark35 : 数据量大不会分表转成INNODB呀.
mark35
mark35
只有表锁无行锁,在高并发读写时会杯具的
返回顶部
顶部