一個(gè)RoR的站點(diǎn)性能優(yōu)化的故事(2)

原文鏈接: http:///articles/2006/03/20/the-adventures-of-scaling-stage-2

中文鏈接: http:///2009/08/01/00/12/一個(gè)ror的站點(diǎn)性能優(yōu)化的故事2.html

圣誕節(jié)前

11月份，仍然還在舊系統(tǒng)的框架下，一些新的想法還是出的比較慢。

這并不能說是一次失敗，我們嘗試將一些可能的影響性能的因素都做了調(diào)整。

首先，我們用源碼重新編譯 了Ruby，而不是使用Debian系統(tǒng)提供的二進(jìn)制包。Debian有些時(shí)候基于某種考慮打了一些不太正規(guī)的補(bǔ)丁。在某些情況下，這樣不失為一種好辦 法，然而為了性能，我們還是從源碼重新安裝了Ruby，甚至安裝了專為i686優(yōu)化過的libc6包。

與此同時(shí)，我們還將Debian提供的Mysql二進(jìn)制包，改成了Mysql官方提供的安裝包，并且將版本從5.0.16升級(jí)到5.0.17。

（譯者評(píng)：Debian/Ubuntu這類linux發(fā)行版中，還是自己編譯吧）

一般說來，Mysql5已經(jīng)被證明是非常穩(wěn)定的產(chǎn)品。我們?cè)?jīng)碰到過一點(diǎn)點(diǎn)數(shù)據(jù)同步復(fù)制 的問題（master-master中有出現(xiàn)重復(fù)自增ID的情況，這個(gè)在5.0.19中已經(jīng)修復(fù)了這個(gè)bug），但有時(shí)候Mysql數(shù)據(jù)庫每秒中查詢達(dá)到 2000-3000次的時(shí)候，后臺(tái)守護(hù)進(jìn)程經(jīng)常會(huì)在幾個(gè)月內(nèi)崩潰一兩次。

讓我們具體談?wù)凪ysql吧

如果針對(duì)數(shù)據(jù)庫的配置錯(cuò)誤或者優(yōu)化不好的話，它很容易拖慢整個(gè)系統(tǒng)。有許多書都是專門講數(shù)據(jù)庫優(yōu)化的比如whole books和 webinars 。我在這里就簡(jiǎn)單的介紹一下。

eins.de利用了Mysql的 全文檢索 Full TEXT來做搜索功能。MyISAM存儲(chǔ)引擎不能支持事務(wù)。你可以用InnoDB和MyISAM兩種引擎結(jié)合起來用。

解決問題有一下幾個(gè)辦法：

1.另買一臺(tái)數(shù)據(jù)庫服務(wù)器，用MySIAM類型的表，然后從類型是InnoDB的 Master數(shù)據(jù)庫表中（我聽說Flickr是這么做的）。然而這樣就需要仔細(xì)的設(shè)計(jì)程序，得以突破Rails的局限性，Rails不能很好的區(qū)分讀數(shù)據(jù) 庫和寫數(shù)據(jù)庫。即便能這么弄，我們也不會(huì)走這條技術(shù)路線，因?yàn)槲覀儧]有預(yù)算來買第三臺(tái)數(shù)據(jù)庫服務(wù)器。

2.不去使用全文檢索， 可以使用類似Ruby-Odeum 這樣的搜索引擎。這里面比較頭疼的是，如何讓數(shù)據(jù)庫地更新時(shí)，同時(shí)搜索引擎索引也重建索引保持?jǐn)?shù)據(jù)同步。這條路我們也不選擇。

這樣我們最終使用了一種混合的方式。

當(dāng)前，可用的內(nèi)存有4G，將它分成InnoDB和MyISAM兩部份。2/3的內(nèi)存給InnoDB用（因?yàn)檫@系統(tǒng)主要的表用的是InnDB，還用于緩存MyISM表的索引數(shù)據(jù)）

剩下的1/3是給MyISAM的。另外，我們使用了查詢SQL結(jié)果的大緩存，也就是Mysql中的query cache。(這個(gè)參數(shù)是否被用起來了可以通過Mysql的show status命令來看)

我們數(shù)據(jù)庫參數(shù)設(shè)置如下：

key_buffer=700M

myisam_sort_buffer_size=128M

query_cache_size=64M

innodb_buffer_pool_size=1600M

如果前端的分發(fā)器是單個(gè)服務(wù)器，并且是持久連接，數(shù)據(jù)庫連接數(shù)的參數(shù)設(shè)置就沒有什么必要了。

繼續(xù)進(jìn)行應(yīng)用服務(wù)器的優(yōu)化

對(duì)于系統(tǒng)進(jìn)行反復(fù)的研究找出一共有多少請(qǐng)求是非常有用的。這個(gè)是沒有“一勞永逸”的解決辦法。一般說來，你需要包含系統(tǒng)高峰時(shí)期并且不能當(dāng)機(jī)，如此大量的線程并行運(yùn)行以至于機(jī)器變慢，這是因?yàn)閷?duì)于CPU來說線程相互之間是阻塞的。

以前我們?cè)诿颗_(tái)服務(wù)器上設(shè)置20個(gè)并發(fā)時(shí)，系統(tǒng)的負(fù)載一般都是在30或30以上。事情進(jìn)展的非常順利，我們降低了并發(fā)數(shù)量。這樣的效果非常明顯。

通過簡(jiǎn)單的計(jì)算，我們從一天PV數(shù)量計(jì)算出整個(gè)的監(jiān)聽數(shù)量。eins.de那時(shí)大概每天100萬PV，所有的用戶都在同一個(gè)時(shí)區(qū)，訪問遍布在一天的14個(gè)小時(shí)中（從早上9點(diǎn)到晚上11點(diǎn)）。我們?cè)僮鲆粋€(gè)簡(jiǎn)單的計(jì)算：

1M page requrest / 14 hours = 20 requests per second

假設(shè)系統(tǒng)平均處理每個(gè)頁面請(qǐng)求都會(huì)少于1秒中，那么我們需要20個(gè)并發(fā)進(jìn)程來監(jiān)聽請(qǐng)求。以上計(jì)算是根據(jù)平均值進(jìn)行的，為了能夠處理高峰時(shí)的峰值，我們將每臺(tái)應(yīng)用服務(wù)器的監(jiān)聽數(shù)目從10減小到7，這樣四臺(tái)應(yīng)用服務(wù)器加起來一共有28個(gè)監(jiān)聽，應(yīng)該能滿足當(dāng)前壓力的要求。

（譯者評(píng)：一般峰值是平均值的5-10倍，根據(jù)各自的網(wǎng)站特點(diǎn)來確定）

另外，每臺(tái)機(jī)器上安裝的Rails從0.14.4逐步升級(jí)到了1.0.雖然這對(duì)性能不一定有幫助，但是說不定是有用的。

到了11月中旬，據(jù)報(bào)道Linux 內(nèi)核2.6對(duì)于性能、內(nèi)存管理和進(jìn)程管理等等都是非常好的，因此我們將所有的系統(tǒng)的內(nèi)核從2.4.27升級(jí)到了2.6.14。

大家對(duì)這個(gè)內(nèi)核升級(jí)對(duì)性能的提升將信將疑，后來根據(jù)監(jiān)控軟件Cacti的顯示，系統(tǒng)升級(jí)后確實(shí)提高了不少。數(shù)據(jù)庫服務(wù)器雖然提高不少，但應(yīng)用服務(wù)器的負(fù)載卻

下降得非常明顯。記錄顯示內(nèi)核的升級(jí)使得系統(tǒng)在高峰時(shí)期的負(fù)載從8降到了5。

升級(jí)內(nèi)核所取得的效果讓我們有了些興奮，我們繼續(xù)所做的事情是將應(yīng)用服務(wù)器的壓力再次給到兩臺(tái)數(shù)據(jù)庫服務(wù)器上。在此以前，所有的壓力都是由一臺(tái)機(jī)器支撐的，另外一臺(tái)只是安靜的呆在那兒復(fù)制主力數(shù)據(jù)庫的數(shù)據(jù)，僅僅是主力壞了它來頂上的災(zāi)難恢復(fù)而存在的。

我們沒有去考慮haproxy的災(zāi)難恢復(fù)，只是簡(jiǎn)單的將請(qǐng)求按照2：1的比率分配到兩臺(tái)數(shù)據(jù)庫服務(wù)器上。

在寫的壓力很大的時(shí)候，偶爾會(huì)出現(xiàn)兩臺(tái)數(shù)據(jù)庫同步不能跟上的問題，直到 一臺(tái)的寫處理完才能恢復(fù)。如果碰上幾秒鐘這種倒霉的事情，一個(gè)用戶可能一次請(qǐng)求在一臺(tái)數(shù)據(jù)庫服務(wù)器上，而另外一次則在另一臺(tái)上，這樣就比較尷尬。舉一個(gè)最 糟糕的例子，AJAX開始的時(shí)候請(qǐng)求了一臺(tái)機(jī)器，而后AJAX執(zhí)行的操作卻從另外一臺(tái)獲得，數(shù)據(jù)是不同步的造成了混亂。

為了減少寫操作，我們經(jīng)用戶證明發(fā)現(xiàn)在用戶沒有獲取任何有用數(shù)據(jù)的時(shí)候，系統(tǒng)不僅通過ActiveRecordStore 更新了session，而且更新了用戶的在線狀態(tài)表和token數(shù)據(jù)。事實(shí)是，雖然多個(gè)MySQL線程能夠更新多張表（甚至能通過InnoDB的行級(jí)鎖來 一次更新一張表里面的多行），但是你只能有一個(gè)線程來處理將所有的寫操作寫到另外一臺(tái)服務(wù)器上。這個(gè)問題困擾了我們不止一次。

另外，我們將緩存memcached在兩個(gè)數(shù)據(jù)庫上移來移去以更好的分?jǐn)倷C(jī)器的壓力，讓另外一臺(tái)機(jī)器來處理廣告信息phpAdsNew（譯者評(píng)：一個(gè)廣告投放系統(tǒng)）

在11月底，我們完成了以上這些事情，到目前為止我們已經(jīng)多次達(dá)到了百萬PV的情況，流量每天已經(jīng)達(dá)到了85G。

整個(gè)系統(tǒng)配置如下:

到此系統(tǒng)調(diào)優(yōu)的文章已經(jīng)寫了2/3，后續(xù)文章將會(huì)包括memcached的最佳實(shí)踐，session的優(yōu)化以及更多系統(tǒng)優(yōu)化技術(shù)。