Home » 2013 » October (Page 3)

Facebook 的 InnoDB patch 讓 table scan 速度變快...

Facebook 的 Database Engineering team 實作了 patch,讓 InnoDB 在 table scan 的速度大幅提昇:「Making full table scan 10x faster in InnoDB」。

第一個 patch 叫做 Logical Readahead。第二個 patch 是針對 async i/o 的改善 (Submitting multiple async I/O requests at once)。

引用文章內的幾段話就知道這幾個 patch 的功力了:

Logical backup size is much smaller. 3x-10x size difference is not uncommon.

備份出來的資料會變小,而且宣稱 1/3 到 1/10 不是罕見情況... -_-

With logical readahead, our full table scan speed improved 9~10 times than before under usual production workloads. Under heavy production workloads, full table scan speed became 15~20 times faster.

然後 table scan 的速度會快非常多... 10 倍?如果是平常就很操的 database 會更明顯?

如果這幾個 patch 如果沒有什麼問題,可以預期會被 merge 到 PerconaMariaDB,至於 Oracle 官方的 source tree... 有的話當然很好,沒有的話也很正常?

關於 Linux 的 Disk I/O 調整...

Twitter 上看到 tka 的 retweet,介紹了 Linux 下 Disk I/O 的調整:「PostgreSQL: Linux kernel I/O tuning」。

文章裡介紹了三種 scheduler,NOOP、CFQ、Deadline,其中 CFQ 是系統預設值。

其實 MySQL 的結論也差不多,Percona 在 2009 年的時候做過 benchmark,就直接看圖講故事吧:「Linux schedulers in tpcc like benchmark」。


數字愈大愈好。

noop 與 deadline 相當接近,對於 i/o bound 的人都應該要調整 :p

Percona Server 第一個 5.6 上 GA 版本...

UpdatePercona 自己也寫了一篇「A closer look at Percona Server 5.6」可以參考看看。

Percona 推出 Percona Server 5.6.13-61.0,是 5.6 的第一個 GA 版本:「Percona Server 5.6.13-61.0 first GA release is now available」。

這等好久了,MySQL 官方有給出「What's New in MySQL 5.6」,對我來說其中有幾個亮點需要測試:

效能

至少不能比現在的效能差。

對 memcache protocol 的支援

這是 5.6 的新功能,可以透過 memcache protocol 存取 InnoDB 的資料。如果可行,可以用在 HA memcache protocol 架構。

Time-Delayed Replication

看起來應該很有用,但一時間想不到可以用在哪裡... 應該是 vm 裡面多架幾台 slave 丟著?

Percona 版的修正

Twitter branch 的 Statement Timeout 看起來是個頗有趣的項目?可以想看看用在哪裡...

Overall...

總結來說,測試機測過後,先用在 DBRD + Heartbeat 的系統上 (只換一台,如果發現 5.6 版不好用,可以 downgrade),如果沒問題就再測試 memcache protocol,然後接下來就是等 Percona XtraDB Cluster 也出 5.6 版?

避免文件大量 Reflow...

今天的 Hacker News 文摘上看到關於 Reflow 的問題:「Preventing 'layout thrashing'」。

Reflow 指的是改變 DOM 後造成的畫面重新計算以及 render。

Google 有給過一些資訊:「Minimizing browser reflow」,Mozilla 也有給「Notes on HTML Reflow」,不過這兩篇都是概念性的文章...

文章的作者寫了 FastDom,把 read 與 write 包起來一起處理 (read 一包,write 一包),不過這樣寫的時候就要小心當下真正的 DOM 的值了...

不過如果只是處理 ordering 的問題,叫 FastDom 好像怪怪的...

Google 開源的 lmctfy...

前幾天看到 Google 開源的 lmctfy (這名字還頗惡趣味,是「Let Me Contain That For You」的縮寫),是這樣介紹的:

lmctfy is the open source version of Google’s container stack, which provides Linux application containers.

看了一下說明,看起來跟 Docker 有點像啊?再查了查網路上的資料,發現有人更早之前寫過了:「lmctfy:Google的开源Linux容器」。

如果是在 Ubuntu 12.04 上,需要 3.3 或 3.8 的 Linux kernel。不過目前 Docker 還夠用,應該不會花時間去研究這個...

NSA 與 GCHQ 對抗 Tor 的方式

衛報網站上公開了 NSA (美方) 以及 GCHQ (英方) 如何對抗 Tor 的方式,包含了內部的投影片:「'Tor Stinks' presentation – read the full document」。

投影片上可以看到,居然還有 workshop 可以參加...

下面列出這份投影片的內容,要注意這是 2012 年的資訊了。

事實的介紹

先說明了不可能辨識出所有 Tor 使用者,只能透過人工找出少數的使用者。

接下來說明了目前的概況。目前只能掌握少數的 Tor 節點,其中 entry node 與 exit node 會是辨識出 Tor 使用者的重點,如果能夠增加這些節點的數量,會對於辨識有很大的幫助。

要如何分析這些資訊

透過 cookie 的交叉比對,有機會將 Tor 使用者與真實世界的流量連接起來,像是透過 DoubleclickID 這個值。

接下來是想辦法建立資料庫,將 IP 與時間點的對應建立起來。利用這些資訊才有辦法知道這個 IP 的情況。

技術分析

接下來可以看到各種技術分析。包括對 Hidden Service 的攻擊 (2012 年當時沒有進度),另外試著用 Timing Attack 攻擊 (2012 年當時也沒有進度,不過有在研究了)。

另外在 AWS 上建立節點也是 2012 年當時就進行的項目。

攻擊 Tor

各種攻擊手段,包含了如果有 ISP 可以配合攔截封包時的作法。以及攻擊不屬於自己的節點的方式。再來就是有沒有辦法癱瘓 Tor 節點...

總結

情報單位其實花了非常多力氣研究 Tor,但沒有很好的成果。Tor 算是直接再技術上 (數學上) 抵抗的相當頑強。這部內部文件流出後可以預期會有不少「應用」(只要是英美政府不喜歡的「應用」) 會往上發展。

多增加 Tor 的節點看起來會是目前最直接的抵抗方式,而且這個抵抗方式對於一般人相對容易,達到了擴散容易的效果。

香港開源年會 2013

居然沒跟到這個消息...

香港開源年會 2013」(第一屆!) 將於 10 月 19 日在香港城市大學邵逸夫創意媒體中心舉辦,現在訂機票有點晚,不過還是可以過去交流...

其實有些議程還蠻有興趣去交流的,不過剛好卡到員工旅遊啊... @_@

該來找日本的 conference 了?@_@

Archives