Home » 2013 » January (Page 3)

Percona 將辦 Webinar 說明資料庫讀寫分離時的處理...

MySQL replication 通常是資料庫擴充的第一步,因為架設很簡單。但一般 MySQL replication 的讀寫必須分開 (寫入只能在 master)。

在「Webinar on Read/Write Splitting with PHP」看到 Percona 下星期會辦 Webinar,說明在 MySQL replication 架構下要如何處理讀寫分離。

看起來包括對 replication lag 時的處理 (slave 因為各種原因,導致跟不上 master),有興趣的人可以去報名聽聽看... 雖然是講 PHP,但這個問題在其他的語言也會遇到,聽觀念也應該有幫助。

資料庫裡的浮點數:MySQL 5.1 到 MySQL 5.5 的差異...

Mozilla 最近在升級 MySQL 採「先建後拆」的步驟,發現用 pt-table-checksum 檢查時不一致:「MySQL 5.1 vs. MySQL 5.5: Floats, Doubles, and Scientific Notation」。

後來發現,在 MySQL 5.1 (5.1.65-rel14.0-log Percona Server (GPL), 14.0, Revision 475) 的查詢結果是:(Mozilla 的範例)

mysql> select float_field from db.tbl where id=218964;
+-------------+
| float_field |
+-------------+
| 9.58084e-05 |
+-------------+
1 row in set (0.04 sec)

而在 MySQL 5.5 (5.5.28a-MariaDB-log MariaDB Server) 的查詢結果是:

MariaDB [(none)]> select float_field from db.tbl where id=218964;
+--------------+
| float_field |
+--------------+
| 0.0000958084 |
+--------------+
1 row in set (0.24 sec)

最後是讓 pt-table-checksum 把 float/double 欄位忽略掉。在 comment 有人提出來是在 MySQL 5.5.3 的時候改變的,不過作者蠻意外沒什麼人提到...

ISP 架設 NAT 解決 IPv4 不夠的問題...

Slashdot 上看到 PlusNet 決定測試用 CGNAT (Carrier-grade NAT) 解決 IPv4 不夠的問題:「UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6」。

用超大型 NAT 並不是特別的新聞 (某些 mobile network 上就是這樣做),但 ISP 如果用在一般網路上則很有可能會跟客戶的 NAT device (可能是公司,也可能是家庭) 發生 Private Network 相同而導致問題。

2012 年 4 月的 RFC 6598 (IANA-Reserved IPv4 Prefix for Shared Address Space) 將 100.64.0.0/10 (Shared Address Space) 這個網段保留,拿來給營運 CGNAT 的 ISP 使用:

NetRange:       100.64.0.0 - 100.127.255.255
CIDR:           100.64.0.0/10
OriginAS:
NetName:        SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
NetHandle:      NET-100-64-0-0-1
Parent:         NET-100-0-0-0-0
NetType:        IANA Special Use

在 RFC 裡規定 100.64.0.0/10 只能拿來內部使用不得交換;如果要交換必須要有能力將不同介面的 100.64.0.0/10 當作不同網段 NAT (也就是 CGNAT 會做的事情):

In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.

另外文件裡還定義了使用 100.64.0.0/10 時對 DNS 的過濾。

如果 CGNAT 上不能打洞,那麼很多應用就很苦了 (得靠 UDP hole punching 打洞,這還得在沒有 randomized NAT port 的情況下才打的通),不過非 P2P 的應用應該不會有問題...

會不會做一做之後就維持這個方式?IPv6 遙遙無期... XD

白宮 We the People 提高答覆連署人數

白宮宣佈提昇 We the People 的強制答覆連署上限,將原本 25k 人提昇至 100k 人:「Why We're Raising the Signature Threshold for We the People」。

因為最近參與的人變多太多:

另外白宮給了一份 Infograph,更詳細的說明參與的狀況:

Overview

英國有個 data.gov.uk,美國有個 We the People,再加上昨天看到的 alpha.data.gov (A collection of open data from the government, private sector, and non-profits that are fueling a new economy.),感覺台灣跟世界上的已開發國家愈差愈遠了...

data.gov.uk

alpha.data.gov

最近找人... (然後,KKBOX 正在徵才)

看到布長輩提到:

剛開始用 104 的系統找履歷時,都用一些很爛的關鍵字搜尋:

  • php
  • mysql
  • ccna

最近找起來比較有心得了,用這些關鍵字:

  • github & bitbucket
  • slideshare & speakerdeck
  • 各 conference 的名字

還有一些相關領域的關鍵字拿來找也還蠻不錯的...

另外最後宣傳一下,敝公司找人,包括 client 開發與 server 開發都有缺。(我主要是 server 的部份,client 的部份我會轉給我同事)

有興趣可以用 gslin at kkbox.com 聯絡... (不過話說回來,我下星期去日本,cc 一份給 hr at kkbox.com 會比較好)

分散式系統的建言...

「分散式系統」(Distributed System) 是個老詞彙,但跟最近當紅詞彙「雲」、「NoSQL」常常相關。也因此「雲」與「NoSQL」常常遇到的都是分散式系統遇到 (並且討論過) 的問題...

而「Notes on Distributed Systems for Young Bloods」這篇寫的好血淚 XDDD 除了講理論面的東西以外,也把實務面會遇到的問題拿出來講...

首先要先知道「Fallacies of Distributed Computing」,在分散式系統裡,能假設的事情實在太少,要處理的事情太多。而「CAP theorem」也是個必讀的主題,從 Amazon 丟出「Dynamo: Amazon's Highly Available Key-value Store」這篇經典的 paper 後讓更多人知道這個理論。

熟悉上面兩個主題後,接下來就是血淚史... XD

garbage collection pauses make masters “disappear”

啊,GC 讓 master 不見... (NameNode... XDDD)

Writing robust distributed systems costs more than writing robust single-machine systems.

Robust, open source distributed systems are much less common than robust, single-machine systems.

這兩條... XD

Oh, and Paxos really is very hard to implement

Paxos... XD

If you can fit your problem in memory, it’s probably trivial.

(噴飯)

“It’s slow” is the hardest problem you’ll ever debug.

連問題都找不到嗎... XD

撇開這些碎碎念的部份,就算對 distributed system 沒那麼熟,這篇文章也提到了很多「解決的方向」以及「關鍵字」讓你找資料,對於實際操作時會有很大的幫助。

CPU Branch Prediction 的成本...

在公司搞定一個速度最佳化的問題,想到之前在 Stack Overflow 上有看到 CPU branch prediction 的問題 (跟我解的問題應該沒關係,只是剛好想到),把文章找出來...

出自 Stack Overflow 上有人詢問某段 C++ 程式為什麼加上 sort 後快多了:「Why is processing a sorted array faster than an unsorted array?」。

發文者的範例程式已經簡化到很容易理解:先產生一個 32Kytes 的 array,然後裡面塞亂數。

接下來把每個 byte 當作 unsigned char,要找出這個 array 裡面所有值大於等於 128 的元素,把這些元素的值加起來。

原發文者發現,如果先把這個 array 排過再計算,十萬次只要 1.93 秒,但如果不排就直接計算需要 11.54 秒,時間差不多是原來的六倍。

回答的人答的相當詳細,還給了一個 branchless 的 hack 來解這個問題 (於是就不需要先 sort),很值得一看。

Munin 的設定...

Munin 是套資源監視軟體。跟其他資源監視軟體不一樣的地方?畫面漂亮啊 XDDD 拿台堆各種雜物的 database 來看:

Munin screenshot

等到 Munin 監視超過二十台時就會很明顯感覺到很吃資源,再多的時候就會開始罵三字經,罵完後拆一台獨立的機器跑,以免跑個 vim 都要卡三秒... XD

這時候就是該調整了:

  • munin.conf 的 graph_strategy 與 html_strategy 都改成 cgi,告訴 Munin 在更新時只要更新 rrd 資料,而圖片與 html 的資料讓 cgi 做就好,這可以大幅減少 i/o rate。
  • rrdcached 跑起來,讓 rrd 資料寫入次數更少。rrdcached 的預設參數要記得調整。
  • 將網站本來用 CGI 的部份改成 FastCGI,其實對 nginx 之類的 web server 反而是簡化了 (因為 nginx 內建只支援 FastCGI 而不支援 CGI)。

另外有些討厭的地方,strategy 設定不能放到 includedir 裡,一定得放 munin.conf 本體,這對於自建 ports 的人有點麻煩... (得用 pkg-install 與 @unexec 去堆設定,可以參考 ports-mgmt/portconf/etc/make.conf 的作法)

Archives