分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

               

http://cookingbsd.blog.51cto.com/5404439/952375

最近幫朋友升級了論壇，把資料庫換成了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在高流量下才對效能有提升，在目前併發流量下提升不明顯。

           

給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow