Tag Archives: failure

Backblaze 分析了 2015 年的硬碟故障比率

照慣例,Backblaze 每隔一段時間就會公佈最近的硬碟死亡率,在「Hard Drive Reliability Review for 2015」的這張圖好像說明了不少事情: 不過分開各個容量來看,又有一些不同的地方...

Posted in Computer, Hardware, Murmuring | Tagged , , , , , , , | Leave a comment

Backblaze 2015 年上半年的硬碟穩定度報告出爐了... (又黑了某公司一把)

Backblaze 這次丟出了 2015 年上半年的數據,標題雖然是寫 2015Q2,但文章裡有半年的統計資料:「Hard Drive Reliability Stats for Q2 2015」。 雖然都知道某公司的產品故障率偏高,但這樣是有仇嗎 XDDD 這是統計資料: 另外是 4TB 的歷史紀錄,右邊兩家的數字有點少啊,不過 45 顆硬碟壞一顆不就 2.x% 了嗎,這數字到底是怎麼出來的啊:

Posted in Computer, Hardware, Murmuring | Tagged , , , , , , , , , , , | 1 Comment

Backblaze 公佈硬碟故障率

Backblaze 又丟出了極具爭議性的硬碟故障率資料,直到去年年底為止的數據:「What is the Best Hard Drive?」。 這張圖超黑的 XDDD 不過 Seagate Barracuda 7200.14 (ST3000DM001) 這顆好慘啊,1163 顆的死亡率是 43.1%...

Posted in Computer, Hardware, Murmuring | Tagged , , , , , | Leave a comment

Facebook 因為 Connection Pool 選擇機制,加上系統的複雜性而導致的慘案...

Facebook 的 engineer 寫了一篇文章,說明他們花了超過兩年的時間找到一個 bug:「Solving the Mystery of Link Imbalance: A Metastable Failure State at Scale」。 整個故事是個通靈的故事... Facebook 在底層的架構使用了 Link Aggregation 的規劃,多條線路 channel bonding 在一起連到骨幹上。但發現有時候會卡在某一條線路壅塞而導致 system failure。 於是就一路追下去,從 switch 本身開始懷疑,最後去組織跨部門的研究小組跳下去分析 (通靈)。後來才觀察到是因為 connection pool 的機制本身用的演算法在 Facebook 這個複雜的系統架構下造成的慘案... 當 query burst 發生時,Facebook … Continue reading

Posted in Computer, Database, Hardware, Murmuring, MySQL, Network, Programming, Social, Software | Tagged , , , , , , , , , , , , , , , | 2 Comments

前幾天 Gmail 收信延遲的問題...

前幾天 Gmail 可以正常運作,但一直收不到信的問題由官方發公告出來解釋了:「More On Gmail’s Delivery Delays」。 官方宣稱,這次的問題出自於兩個獨立的網路同時掛掉,造成 Gmail 的收信處理能力大幅下降: The message delivery delays were triggered by a dual network failure. This is a very rare event in which two separate, redundant network paths both stop working at the same … Continue reading

Posted in Computer, Mail, Murmuring, Network | Tagged , , , , , | Leave a comment

RAID5 會遇到的 Multi-disk failure 問題

「How multi-disk failures happen」這篇畫了不少圖解釋在 RAID5 上面偶而會遇到的 Multi-disk failure 問題 (RAID6 也會,風險比較低而已)。 平常壞軌時,RAID 系統不一定會發現,直到 RAID rebuild 時讀過所有的磁區,系統才發現其他壞軌,造成第二顆被標為損壞... (推論到 RAID6 的情況就是再發生一次) 這在 I/O 比較頻繁的 RAID 比較不容易發生 (因為在量小的時候就容易偵測到)。 對於比較閒的系統,應該放個 cron 跑 dd if=/dev/XXX of=/dev/null 嗎?:p

Posted in Computer, Hardware, Murmuring | Tagged , , , , , , | 3 Comments