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

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

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

第三篇 新年了

隨著圣誕和新年的來(lái)臨，我們準(zhǔn)備從另外一個(gè)方面來(lái)改變和優(yōu)化系統(tǒng)以提高網(wǎng)站的性能和響應(yīng)速度。（從以往看來(lái)節(jié)日期間是我們流量比較小的時(shí)候，人們更愿意花時(shí)間跟家人團(tuán)聚而非泡在社區(qū)里）

×××，再次回到memcaced的優(yōu)化上來(lái)了。通過(guò)debug發(fā)現(xiàn)了我們 memcache封裝的問(wèn)題（它是負(fù)責(zé)通過(guò)key來(lái)自動(dòng)查找社區(qū)名和用戶名，或者社區(qū)名或用戶名），許多在memcached的查找都失敗了。查找本身并 沒(méi)有失敗，而是從memcached中返回的對(duì)象實(shí)例有部分“失敗”了。

這句話什么意思？也就是說(shuō)花費(fèi)時(shí)間很長(zhǎng)的計(jì)算結(jié)果被放到了緩存中，但是重新從緩存中獲得它們的時(shí)候失敗了。結(jié)果再次從新計(jì)算（這時(shí)memcache封裝里面的一個(gè)回退機(jī)制）。因此沒(méi)有達(dá)到我們認(rèn)為的節(jié)省時(shí)間、降低負(fù)載的效果。

然而，這個(gè)跟先于對(duì)象定義的Ruby聲明的類沒(méi)有關(guān)系，顯然和返回的marshalled數(shù)據(jù)有關(guān)。在Google上面搜索了這個(gè)錯(cuò)誤信息沒(méi)發(fā)現(xiàn)任何明顯犯同樣錯(cuò)誤的人，也沒(méi)有任何解決辦法。

（譯者評(píng)：看看別人解決問(wèn)題的過(guò)程比知道優(yōu)化技巧這樣的結(jié)果更加重要，比如作者也走過(guò)很多盲目的彎路，但這些彎路也是思考問(wèn)題的方式）

通過(guò)查看Debian的更新日志提到了一些 Ruby 1.8.4關(guān)于marshalling，并一次同時(shí)在Rubyonrails.org’s download page 看到了如下信息：

We recommend Ruby 1.8.4 for use with Rails. Ruby 1.8.2 is fine too, but version 1.8.3 is not.

因此升級(jí)了Ruby，我們從升級(jí)到了1.8.4，重新編譯了所有C擴(kuò)展的的包，比如Ruby-MySQL和RMagick，然后上線看看。

結(jié)果是沒(méi)有變化！

接著在一月的第三個(gè)星期，Robot Coop 發(fā)布了他們的memcache-client 庫(kù)，作為Ruby-Memcache的替代，現(xiàn)在后者的開(kāi)發(fā)停止多時(shí)了。

使用新的memcache-client庫(kù)系統(tǒng)運(yùn)行得非常流暢。它甚至做了我們自己封裝的memcached包裝器的大部分工作，請(qǐng)大家為Robot Coop的工作歡呼三次，太偉大了！

由于有了如此好性能的memcahced我們冒險(xiǎn)向前走了另外一步。我們將session的存儲(chǔ)從 ActiveRecordStore（讀Mysql表的存儲(chǔ)）移到了memcached中。我們希望通過(guò)這樣做也是為了減少前面所述的Master- Master模式中只有一個(gè)線程往另一個(gè)Master中寫的壓力。同時(shí)，這樣也能將每次請(qǐng)求頁(yè)面而需要到數(shù)據(jù)庫(kù)的比例比11月份上線時(shí)減少了1/3。

另外通過(guò)Robot Coop memcache 客戶端我們可以有理由去跨多臺(tái)機(jī)器做分布式緩存。memcached對(duì)于我們大部分的機(jī)器無(wú)論是在內(nèi)存消耗上，還是CPU使用上都是非常不錯(cuò)的。
我們臨時(shí)將所有機(jī)器都配置上memcache來(lái)應(yīng)對(duì)它的連接數(shù)問(wèn)題。為什么說(shuō)是臨時(shí)的？因?yàn)槲覀冇袀€(gè)登錄問(wèn)題需要debug出來(lái)。有時(shí)侯我們不能去再次使用我們自己的機(jī)器。用戶像是坐在一個(gè)很大的公司中，有太過(guò)敏感的防火墻和內(nèi)容過(guò)濾器，以至于其它人不能再登錄進(jìn)來(lái)。
許多問(wèn)題隨之被發(fā)現(xiàn)了，他們甚至沒(méi)有看見(jiàn)我們種的且將過(guò)期時(shí)間設(shè)置為2010年的cookies。為了讓他們看見(jiàn)，我們甚至嘗試換個(gè)cookie名字（這樣做是為了想避免一個(gè)自己的胡亂猜測(cè)，什么以session命名的cookies會(huì)在瀏覽器關(guān)閉的時(shí)候就自動(dòng)過(guò)期）
（譯者評(píng)：笑可笑之人，有時(shí)候找不到問(wèn)題，不就是根據(jù)自己一點(diǎn)點(diǎn)經(jīng)驗(yàn)去胡亂嘗試么？這也是技術(shù)的一部分）

多臺(tái)機(jī)器分布式的memcached的配置和session的存儲(chǔ)有過(guò)什么聯(lián)系么？哦，天知道？最后沒(méi)有人清楚的記得當(dāng)用戶登錄正常時(shí)，是不是我們只是做了將用memcached做session存儲(chǔ)這一件事讓它的好的。（這一個(gè)改變對(duì)于我們系統(tǒng)減輕了許多壓力）

為 了簡(jiǎn)化調(diào)試（也為了減少潛在的隱患）我們又返回去用單臺(tái)機(jī)器配置一個(gè)memcached和一個(gè)MySQL的做法。memcached放在一臺(tái)（只做數(shù)據(jù)同 步和廣告服務(wù)）比較空閑的數(shù)據(jù)庫(kù)服務(wù)器上。順便提一下memcached的配置非常簡(jiǎn)單。經(jīng)常需要去變的參數(shù)是分配的內(nèi)存大小，需要記住的是分配的內(nèi)存可 以很大，但memcached也必須去調(diào)度這么大的內(nèi)存空間。到了一定時(shí)候它將會(huì)到達(dá)它的極限。我們當(dāng)前給memcache了1024M的內(nèi)存空間，這個(gè) 對(duì)于文本信息綽綽有余。

這是基于我們系統(tǒng)7周時(shí)間的memcached的統(tǒng)計(jì)數(shù)據(jù)。（不要問(wèn)過(guò)關(guān)于二進(jìn)制字節(jié)的讀寫比率，我認(rèn)為這是顛倒的？？？）

get_misses: 59,571,775
get_hits: 235,552,563
total_connections: 2,002,697
bytes_read: 79,799,051,834
bytes_written: 734,299,301,670
curr_items: 1,421,982
total_items: 76,452,455
cmd_set: 76,453,343
cmd_get: 295,124,338
bytes: 717,612,826登錄的錯(cuò)誤也在不久以后解決了，原因是當(dāng)關(guān)閉瀏覽器的時(shí)候cookie就過(guò)期了。無(wú)論什么原因？這個(gè)問(wèn)題的解決沒(méi)有太多的邏輯推理。僅僅是找一種便于管理的
折中辦法才行。
（譯者評(píng)：對(duì)稱是種美，與其將cache散落到各處，不如簡(jiǎn)單點(diǎn)讓一臺(tái)沒(méi)有壓力的機(jī)器單獨(dú)來(lái)承擔(dān)。不對(duì)稱也是一種美，兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，只在一臺(tái)上裝了
memcached）

出現(xiàn)新的訪問(wèn)速度變慢的問(wèn)題

在一月份的前半個(gè)月我們一天就可以支撐110萬(wàn)的流量，此時(shí)的流量達(dá)到了95G。接著到了一月份的后半個(gè)月系統(tǒng)出現(xiàn)問(wèn)題，幾乎不能工作了。雖然以前我們所做的所有修改和調(diào)優(yōu)（原本這些都非常好），但我們碰到了新問(wèn)題，發(fā)現(xiàn)系統(tǒng)在變慢。

是 正常的變慢，還是糟糕的變慢？實(shí)際上是不好的變慢。到了一月份的最后一周變得跟去年11月份一樣慢了。為什么會(huì)這樣？哦，這是一個(gè)好問(wèn)題。我們已經(jīng)優(yōu)化了 系統(tǒng)的每一個(gè)部分（如果你讀完了這一系列文章，你也應(yīng)該清楚）。在過(guò)去的幾周內(nèi)，事情看上去都不錯(cuò)，但現(xiàn)在我們又回到了開(kāi)始時(shí)那樣。

先還是把系統(tǒng)結(jié)構(gòu)圖圖畫出來(lái)吧，這樣清楚些，不如從圖中找問(wèn)題。（譯者評(píng)：我就是在機(jī)器上傻看數(shù)據(jù)，退一步看看整個(gè)架構(gòu)更容易發(fā)現(xiàn)問(wèn)題）
我 們首先發(fā)現(xiàn)是整個(gè)系統(tǒng)全部變慢，甚至有時(shí)候不能訪問(wèn)，但所有的機(jī)器壓力還是很小，應(yīng)該說(shuō)是太小了。調(diào)整lighttpd的fastcig。debug發(fā)現(xiàn) 偵聽(tīng)雖被指定去處理連接，但是它坐在那里一動(dòng)不動(dòng)。當(dāng)有一般的請(qǐng)求焊死在那里，這再明顯不過(guò)是說(shuō)它不能響應(yīng)所有的請(qǐng)求。

（對(duì)于這些似乎你很眼熟，我以前在寫過(guò)一篇文章叫“溫柔地殺死我”）

使 用tpcdump來(lái)監(jiān)控偵聽(tīng)端口的流量，什么也沒(méi)有，沒(méi)有一個(gè)字節(jié)通過(guò)管道。使用strace來(lái)看看那些忙一些的偵聽(tīng)在干什么，它們?cè)趙ait，也沒(méi)有做 任何事情。郁悶的是，如果你重啟lighttpd或者×××，最終和開(kāi)始看到的一樣。我的同事對(duì)防火墻做了各種配置，我開(kāi)始調(diào)整應(yīng)用服務(wù)器和 lighttpd代 理服務(wù)器的/proc的參數(shù)，我猜測(cè)是到了某個(gè)參數(shù)的上限。用netstat也發(fā)現(xiàn)有幾百個(gè)連接在那些管道中，狀態(tài)都是 TIME_WAIT和CLOSE_WAIT，很像遭受了synflooed攻擊。但這是我們內(nèi)部機(jī)器，不會(huì)被外面看到。下一步，根據(jù)公共可利用的資源來(lái)調(diào) 整/proc中的參數(shù)，具體如下：

echo "1024 65535" > /proc/sys/net/ipv4/ip_local_port_range
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
echo 1800000 > /proc/sys/net/ipv4/tcp_max_tw_buckets
echo 256000 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 1024 > /proc/sys/net/core/somaxconn
echo "128000 200000 262144" > /proc/sys/net/ipv4/tcp_mem
echo 2097152 > /proc/sys/fs/file-max
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

不要在家使用這些命令，因?yàn)樗稽c(diǎn)都沒(méi)有幫到我們。請(qǐng)求始終停在那，網(wǎng)站的性能讓人看上去惡心。另外一個(gè)人企圖在每個(gè)應(yīng)用服務(wù)器上都啟動(dòng)一個(gè)lighttp
（這樣來(lái)代替遠(yuǎn)程的fastcgi偵聽(tīng)），然后放一個(gè)lighttp的負(fù)載均衡的方向代理在前面。事實(shí)證明系統(tǒng)還是慢。
剩下比較“土”的辦法，我寫了一個(gè)腳本來(lái)搜索所有的可用偵聽(tīng)，如果它們?cè)谝欢ㄖ芷趦?nèi)沒(méi)有響應(yīng)，就kill它。被kill的請(qǐng)求會(huì)有Rails的spinner/spawner很快的重新
啟動(dòng)，lighttpd只是多花幾秒鐘來(lái)重新連接socket。雖然對(duì)于業(yè)務(wù)來(lái)說(shuō)不能持續(xù)的來(lái)監(jiān)控它們了。
這個(gè)方法雖然看上去不漂亮，但它工作的很好，并且讓我們熬過(guò)了一月來(lái)到了二月，配置如下：

剩下最后一篇是關(guān)于系統(tǒng)擴(kuò)展性的問(wèn)題，也總結(jié)一下，哪些有幫助，哪些沒(méi)有，同時(shí)展望一下將來(lái)系統(tǒng)調(diào)優(yōu)的計(jì)劃。