亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: Foursquare 長達(dá) 11 小時(shí)的宕機(jī) [打印本頁]

作者: cu_Cbear 時(shí)間: 2012-02-22 15:58
標(biāo)題: Foursquare 長達(dá) 11 小時(shí)的宕機(jī)

Foursquare 長達(dá) 11 小時(shí)的宕機(jī)

本文轉(zhuǎn)載自著名博客DBA Notes，F(xiàn)oursquare是目前最流行的LBS應(yīng)用，就像在MongoDB官網(wǎng)上看到的一樣，其底層應(yīng)用了MongoDB進(jìn)行一些重要數(shù)據(jù)的存儲。而最近的長達(dá)11小時(shí)宕機(jī)，正是由于MongoDB的問題導(dǎo)致的。

原文鏈接：http://www.dbanotes.net/arch/foursquare_outage.html

前幾天 Foursquare 經(jīng)歷了長達(dá) 11 個(gè)小時(shí)的宕機(jī)，沒錯(cuò)，11 個(gè)小時(shí)。網(wǎng)站官方的解釋是 Shard 負(fù)載不均勻造成后續(xù)的連鎖反應(yīng)。很多人都知道 Foursquare 在線的 DB 是 MongoDB，今天又看到 10gen (MongoDB的開發(fā)與支持團(tuán)隊(duì))的 Eliot Horowitz 在得到 Foursquare 許可后，通過郵件組詳細(xì)介紹了宕機(jī)的過程：Foursquare outage post mortem，不用說，也有為 MongoDB 辟謠的意味在里面。

讀罷 10gen 團(tuán)隊(duì)的介紹（或者說解釋）之后，發(fā)現(xiàn)這是一個(gè)很好的研究樣本。值得分享。

為了提高響應(yīng)速度，F(xiàn)oursquare 使用 MongoDB 存儲 Check-in 的數(shù)據(jù)已經(jīng)有一段時(shí)間了。這部分?jǐn)?shù)據(jù)的數(shù)據(jù)庫起初跑在一個(gè) 66GB 內(nèi)存的 Amazon EC2 單實(shí)例上（全部在內(nèi)存里），兩個(gè)月前，出于對容量增長的考慮，遷移到兩臺 Shard 集群上。每個(gè) Shard 機(jī)器都是 66GB 內(nèi)存，為了冗余，每個(gè) Shard 都有復(fù)制到 Slave 實(shí)例。遷移的目標(biāo)是所有的 Check-in 數(shù)據(jù)都保存在內(nèi)存中。數(shù)據(jù)根據(jù) ID 分成 200 個(gè) Shard 分片，兩臺機(jī)器各占一般，也就說聯(lián)機(jī)數(shù)據(jù)在每臺機(jī)器上各使用 33GB 的內(nèi)存。兩個(gè)月相安無事。

問題來了，因?yàn)?Shard 算法導(dǎo)致的數(shù)據(jù)分散不均衡，其中一臺(Shard0)數(shù)據(jù)增長到 67GB(另外一臺 50GB)，超過了 66GB 的限制，讀寫部分分散到磁盤上，性能急劇下降。從而，網(wǎng)站宕機(jī)。

首先嘗試增加第三臺 Shard 機(jī)器，上線后開始遷移，讀取從三臺進(jìn)行，Shard0 的數(shù)據(jù)遷移到 5% 的時(shí)候，但是寫操作還是讓 Shard0 宕機(jī)了。這個(gè)時(shí)候發(fā)現(xiàn)Shard0 存在數(shù)據(jù)碎片(data fragmentation)，即使數(shù)據(jù)遷移走，還是會占用原來的內(nèi)存。每個(gè)Check-in 文檔大約占用 300 字節(jié)，而 MongoDB 是 4KB 的頁(Page)，也就說十幾個(gè)文檔會填滿一個(gè)頁，而遷移 5% 反而造成了頁更加稀疏，并不是將頁全部刪除。

這個(gè)時(shí)候已經(jīng)到了第二天，隨著網(wǎng)站全面宕機(jī)，技術(shù)團(tuán)隊(duì)開始用 MongoDB 的 repairDatabase() 功能來對數(shù)據(jù)庫進(jìn)行壓縮，因?yàn)閿?shù)據(jù)庫太大和 EBS 慢，也因?yàn)?repairDatabase() 不能充分利用多核CPU 的能力，這個(gè)過程耗費(fèi)了 4 個(gè)小時(shí)。之后這 5% 的內(nèi)存空間終于釋放出來，系統(tǒng)重新上線。

隨著 Shard0 修復(fù)，第三臺成功上線，進(jìn)而添加了更多的 Shard 服務(wù)器，現(xiàn)在數(shù)據(jù)已經(jīng)更加的均衡，通過在Slave上運(yùn)行 repairDatabase()，然后將其切換到 Master ，每臺 Shard 內(nèi)存占用縮減到 20GB左右。整個(gè)故障時(shí)間已經(jīng)延續(xù)了 11 小時(shí)之多。

產(chǎn)生問題的主要原因就是系統(tǒng)過載，前面介紹每臺 Shard 承載原來 50% 的壓力，到了問題發(fā)生的時(shí)候，單臺 Shard 的負(fù)載已經(jīng)超過 Shard 之前的系統(tǒng)負(fù)載，這時(shí)候已經(jīng)積重難返了，在容量的臨界點(diǎn)增加新系統(tǒng)資源，必然導(dǎo)致更多的停機(jī)時(shí)間。暴露了 Foursquare 團(tuán)隊(duì)在容量規(guī)劃方面的不足之處，或許也因?yàn)闃I(yè)務(wù)增長太快了吧。另外，內(nèi)存碎片化的問題在沒有宕機(jī)之前，技術(shù)團(tuán)隊(duì)?wèi)?yīng)該沒考慮過這個(gè)問題，如果文檔的大小超過 4K，碎片化問題就不嚴(yán)重了，這是特定應(yīng)用場景造成的特定問題。10Gen 現(xiàn)在已經(jīng)著手研究如何進(jìn)在線壓縮(online compaction)。再次，Shard 鍵值的順序和插入順序是不同的，這造成了遷移數(shù)據(jù)的時(shí)候 Chunk 的遷移不是連續(xù)的。

這個(gè)過程給我們的啟示是：最近 NoSQL 已經(jīng)成為一個(gè)熱詞，類似 MongoDB 這樣的新事物當(dāng)然值得嘗試，但是不能冒進(jìn)，因?yàn)轳{馭起來并非易事。僅僅能夠使用是不夠的，系統(tǒng)沒出問題一切都好，一旦出了異常，有足夠的技術(shù)力量(設(shè)想一下 Foursquare 得不到 10gen 團(tuán)隊(duì)的支持會如何?) 支持么？在極端情況下如何控制？如果回答不了這個(gè)問題，那么還應(yīng)該暫緩。最好的辦法就是…”等待”。

給我的另一個(gè)感慨是 Amazon 在云計(jì)算領(lǐng)域已經(jīng)真的成為一個(gè)贏家，而且越來越得到 Web 2.0 Startup的信賴。前面說的 66GB 內(nèi)存，應(yīng)該指的是EC2 的 “High-Memory Double Extra Large Instance”，可提供的最大內(nèi)存是 68.4 GB 。CPU 和內(nèi)存能力都是可以接受的，存儲方面的性能似乎還有點(diǎn)不足，也就是其中的 EBS ，指的是 Amazon Elastic Block storage。

作者: 清風(fēng)鳥兒 時(shí)間: 2012-02-24 17:32
謝謝分享

歡迎光臨 Chinaunix (http://72891.cn/)