沒有檢查 TCP checksum 的 bug 造成的慘案

Twitter 家的工程師努力通靈找靈異現象,最後發現是 kernel bug 造成 veth 沒檢查 TCP checksum 造成的慘案:「Linux kernel bug delivers corrupt TCP/IP data to Mesos, Kubernetes, Docker containers」。

而隔壁棚 PagerDuty 在 2015 年五月也有遇到類似的問題,不過當時看起來沒找出 root cause,只有提出 workaround 解法暫時避開:「The Discovery of Apache ZooKeeper’s Poison Packet」。

這個 bug 已經被 patch 掉了,之後應該會再 backport 回到舊版 kernel

I’m really impressed with the linux netdev group and kernel maintainers in general; code reviews were quite prompt and our patch was merged in within a few weeks, and was back-ported to older (3.14+) -stable queues on various kernel distributions (Canonical, Suse) within a month.

文章中間有寫找 bug 的過程,可以看到都是在通靈...

CloudFlare 有計劃要放出對 nginx 的 HTTP/2 + SPDY patch

nginx 在 1.9.5 後移除了對 SPDY 的支援,只支援 HTTP/2,剛剛找其他資料的時候在「HTTP/2 is here! Goodbye SPDY? Not quite yet」這邊發現 CloudFlare 的人有打算放 patch,讓 nginx 可以同時支援 HTTP/2 與 SPDY:

同時也可以看到有人抱怨 caniuse 上面的資料與實際使用的情況有蠻大的差距,拿 caniuse 來說服人不太準確。

另外也發現我自己的 blog 有時候 HTTP/2 不會啟用 (透過「HTTP/2 and SPDY indicator」觀察),不知道是什麼原因,也許 nginx 的時候還是有 bug?

nginx 宣佈了 Early Alpha 版本的 HTTP/2 支援

nginx 宣佈了 Early Alpha 的 HTTP/2 支援:「Announcing an Early Alpha Patch for HTTP/2」。

除了警告這是早期版本不應該用在 production 上,另外也說明了目前的 patch 會讓 SPDY 失效:

Applying this patch removes the SPDY module from the NGINX codebase and replaces it with the HTTP/2 module. After applying this patch, you can no longer configure NGINX to use SPDY.

而在這之後也不會讓 HTTP/2 與 SPDY 同時並存:

This will also be the case for the production-ready release of the HTTP/2 implementation in both NGINX and NGINX Plus. SPDY is being deprecated by Google in early 2016, so there is no need to support both.

但從 HTTP/2 的支援度SPDY 的支援度來看,行動裝置都還不支援 HTTP/2,但 iOS 8.4 以及 Android 3+ 都已經支援 SPDY 了,這樣看起來非常的傷啊...

不知道到年底會有什麼其他解決方案出現...

Open Source 版本的「不重開機更新 Linux Kernel」,kSplice 的替代方案

一般的 Linux Kernel 更新需要重開機,其中有個商用方案 kSplice 可以做到這點,不過這需要付錢給 Oracle

Slashdot 上看到 Live Patching 功能的 Open Source 方案前進了一大步:「Live Patching Now Available For Linux」,對應的 Git 記錄在「Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching」這邊。

RedHatSUSE 都各自實做了對應的版本,而這次 Linus 是在 Kernel 內引入對應的 API,讓 Userland 的程式可以實現對應的功能:

It provides a basic infrastructure for function "live patching" (i.e. code redirection), including API for kernel modules containing the actual patches, and API/ABI for userspace to be able to operate on the patches (look up what patches are applied, enable/disable them, etc).

可以馬上想到的是,之後更新 MySQL 就不用重熱 InnoDB 的 data 了,來繼續關注進展...

歷史上的爆炸記錄?

在「a brief history of one line fixes」列出了許多經典的問題...

裡面最有印象的還是 2008 年 Debian OpenSSL 問題,也因為這個問題影響太嚴重,後來預設會安裝 openssl-blacklist 這個套件,在連線時檢查是不是有問題的 key...

然後 Android memset() 那個很精彩啊 XDDDDDDDDDDD

JSON Patch...

與上篇一樣,都是在「Please. Don't Patch Like An Idiot.」這篇裡看到的:「JavaScript Object Notation (JSON) Patch」(RFC 6902)。

配合 JSON Pointer (RFC 6901) 的語法,下面的操作很清楚表示了想要做什麼:

[
    { "op": "test", "path": "/a/b/c", "value": "foo" },
    { "op": "remove", "path": "/a/b/c" },
    { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
    { "op": "replace", "path": "/a/b/c", "value": 42 },
    { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
    { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
]

再加上 HTTP header 裡的 If-Match 可以用來處理起始版本,test 也可以阻擋某些異常狀況,基本的都有了?接下來應該找 Canonical JSON 的方案,這樣可以直接拿 hash 的值當版本?

Google 將發現安全問題的獎勵延伸到 Open Source 專案上...

Slashdot 上看到 Google 將發現安全問題的獎勵從自家產品延伸到 Open Source 專案上:「Google Offers Cash For Security Fixes To Linux and Other FOSS Projects」。

官方的公告在「Going beyond vulnerability rewards」,規則則是在「Patch Rewards – Application Security – Google」。

初期限制在這些專案上:(直接複製過來)

  • Core infrastructure network services: OpenSSH, BIND, ISC DHCP
  • Core infrastructure image parsers: libjpeg, libjpeg-turbo, libpng, giflib
  • Open-source foundations of Google Chrome: Chromium, Blink
  • Other high-impact libraries: OpenSSL, zlib
  • Security-critical, commonly used components of the Linux kernel (including KVM)

獎勵金額從 USD$500 到 USD$3133.7,這邊的 31337 應該是出自「Leet」吧...

這算是一種回饋社群的方式...

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... 有的話當然很好,沒有的話也很正常?

結果 Vim 7.3 出 patch level 1000 了...

前情提要:「Vim 7.4 準備中...」,本來以為會在 1000 出現前出 Vim 7.4。

結果剛剛在 Twitter 上看到「http://ftp.vim.org/pub/vim/patches/7.3/7.3.1000」出現,這是哪招... XD

Bram Moolenaar 該不會自暴自棄決定等 9999 的時候再出 Vim 7.4 吧... XD

維基百科英文版與德文版的資料庫 (條目最多的兩個語言) 從 MySQL 轉移到 MariaDB 了...

維基百科官方宣佈兩個條目最多的資料庫 (英文與德文) 已經從 MySQL (有 FB patch 的版本) 轉移到 MariaDB 5.5 了:「Wikipedia Adopts MariaDB」。

維基百科的資料庫從 MySQL 4.0 升級到 MySQL 5.1 時花了不少功夫轉換 (可以想像出來,這兩個版本的差距...),然後這次再到這次的 MariaDB 5.5 就輕鬆不少。

在文章內有提到因為維基百科是 read-heavy site,大多數前端的負荷都在 squid 層擋下來,實際到後端的量則是再透過 Redismemcached 打散負荷。不過即使做了這麼多層 cache,英文版資料庫在尖峰時間還是有 50k qps 的量在跑。

尖峰時間這 50k qps 的量有 80% (也就是 40k qps) 是打散到兩台不同地點的 slave 上,平均的 query response time 是 0.2ms,95% 則是 50ms (好高),其他的 20% 是寫入 master 需求,或是因寫入 master 時需要一致性 (也就是要避免 replication lag 造成的問題)。

這次升級到 MariaDB 5.5.30 是先準備一台新機器,然後在 load balancer 上換掉其中一台 slave (先建後拆),如果 MariaDB 真的有問題也可以馬上 rollback 回來。另外用 pt-query-digest 取樣分析 query 的狀況。

這是成果:

For our most common query type, 95th percentile times over an 8-hour period dropped from 56ms to 43ms and the average from 15.4ms to 12.7ms. 50th percentile times remained a bit better with the 5.1-facebook build over the sample period, 0.185ms vs. 0.194ms. Many query types were 4-15% faster with MariaDB 5.5.30 under production load, a few were 5% slower, and nothing appeared aberrant beyond those bounds.

第一台觀察一陣子沒問題後,接下來一台一台換掉。然後發公告慶祝 :p