獨立遊戲創作者推出 Linux 版的好處

標題不知道怎麼下,大概就是這樣...

Hacker News 首頁上翻到的,以這個 upvote 數量來看,應該會收到今天的 Hacker News Daily 上:「Despite having just 5.8% sales, over 38% of bug reports come from Linux (reddit.com)」。

作者是一位獨立遊戲開發者,在兩年前推出了「ΔV: Rings of Saturn」這款遊戲,並且也發佈了 Linux 版。

作者先就數字來比較,他賣出了 12000 套,其中 700 套是 Linux 玩家;另外他收到了 1040 個 bug report,其中大約 400 個是從 Linux 玩家回報的:

As of today, I sold a little over 12,000 units of ΔV in total. 700 of these units were bought by Linux players. That’s 5.8%. I got 1040 bug reports in total, out of which roughly 400 are made by Linux players.

That’s one report per 11.5 users on average, and one report per 1.75 Linux players. That’s right, an average Linux player will get you 650% more bug reports.

看文章時可能會覺得「Linux 玩家真難伺候」,但實際上作者講到,這 400 個 bug 裡面只有 3 個 bug 是平台相關的 (只會發生在 Linux 上),其他的 bug 其實是所有平台都會發生:

A lot of extra work for just 5.8% of extra units, right?

Wrong. Bugs exist whenever you know about them, or not.

Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone[.]

原因是 Linux 社群在參與各種 open source project 養成的習慣,會盡可能把各種資訊講清楚,並且找出可以重製問題的方式:

The thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!

But that’s not all. The report quality is stellar.

與一般玩家的回報方式完全不同,Linux 玩家很習慣就會附上基本的環境資訊,系統紀錄,甚至有時候還會包括 core dump 與 reproducible steps:

I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed.

And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.

不知道有沒有遇到回報 GDB 資訊的...

很特別的分享 XDDD

EnterpriseDB 買下 2ndQuadrant

算是 PostgreSQL 社群裡面的大事情,看到大老在討論 EnterpriseDB (EDB) 買下 2ndQuadrant 的事情:「Community Impact of 2nd Quadrant Purchase」,這兩家公司都是 PostgreSQL 社群裡面重量級的台柱。

先翻了一下新聞稿,兩邊的官方新聞稿分別是「How EDB Became the Leader in the Postgres Market」與「How EDB Became the Leader in the Postgres Market」。

回到原來的文章,裡面提到了 core team 的不成文規定,這個部份可以從 Contributor Profiles 這邊看到目前 core team 有五位成員,Peter Eisentraut 來自 2ndQuadrant,而 Bruce Momjian (這是文章作者自己) 與 Dave Page 則是來自 EnterpriseDB:

First, there is an unwritten rule that the Postgres core team should not have over half of its members from a single company, and the acquisition causes edb's representation in the core team to be 60% — the core team is working on a solution for this.

裡面有提到目前正在找辦法解決中,但不知道目前會怎麼解決,讓出位置可能是一個方法,加到七個人應該也是個方法,反正方法不算少,就等著看...

另外他提出來的兩個問題我覺得都還好,就是併購本來就會發生的事情。

這次的併購算是 PostgreSQL 社群裡面蠻熱鬧的事情,雖然是商業公司之間的併購,但社群這邊應該也會有不少變化...

AMD Ryzen Threadripper 3990X 在 Windows 上的效能

John Carmack 注意到在 AMD Ryzen Threadripper 3990X 上因為 Windows 的 group limit 限制而造成效能問題:

但這點可以透過打散到兩個 group 改善 (workaround) 而提昇速度:

然後順便看了一下目前 CPU Benchmark 網站上對於高階 CPU 的跑分數據「PassMark - CPU Mark High End CPUs)」,可以看到 AMD 最近真是香噴噴的,用 3950X (16C/32T,105W) 殺 Intel 目前最高分的 W-3275M (28C/56T,205W),然後那個價差:

Intel 的 14nm 牙膏繼續擠...

Amazon EC2 推出 G4 系列機器

這次 Amazon EC2 更新了 G 系列的機器,其實會特地寫文章主要是在複習 P 系列與 G 系列的差異 (每次都記不起來到底哪個是給科學運算用的):「Now Available – EC2 Instances (G4) with NVIDIA T4 Tensor Core GPUs」。

EC2 上的 GPU Instances 分成兩條線在發展,一條是 P 系列,另外一條是 G 系列,都是使用 Nvidia 的產品線。

從「Amazon EC2 Instance Types」這邊的「Accelerated Computing」可以看到每條產品線用了哪些型號 (扣掉 FPGA 的 F1):

  • P3:Up to 8 NVIDIA Tesla V100 GPUs, each pairing 5,120 CUDA Cores and 640 Tensor Cores
  • P2:High-performance NVIDIA K80 GPUs, each with 2,496 parallel processing cores and 12GiB of GPU memory
  • G4:NVIDIA T4 Tensor Core GPUs
  • G3:NVIDIA Tesla M60 GPUs, each with 2048 parallel processing cores and 8 GiB of video memory

查了資料發現雖然時間點不同,但這四個都列在「Nvidia Tesla」這邊,裡面也沒有太多說明,所以還是看不出來差異,之後要碰到的時候再來還這個知識債好了...

MySQL 8.0-rc 的效能測試

Oracle 的 Dimitri KRAVTCHUK (dim) 做了測試,整理出 MySQL 8.0-rc 與其他版本效能的比較:「MySQL Performance : 2.1M QPS on 8.0-rc」。

不過先不管 MySQL 8.0-rc,這個測試其實也在說 MySQL 在 5.6 到 5.7 的過程中,對於高階伺服器效能改善非常的多 (有非常多 CPU core 的機器):

就更不用說 5.5 版 (甚至已經沒支援的 5.0 & 5.1),差距就更大了...

Percona 對 mysql_query_cache 的測試 (以 Magento 為例)

Percona 的人以現在的觀點來看 mysql_query_cache:「The MySQL query cache: Worst enemy or best friend?」。

起因主要也是懷疑 query cache 是 global mutex 在現在的硬體架構 (主要是 CPU 數量成長) 應該是個負面的影響,但不確定影響多少:

The query cache is well known for its contentions: a global mutex has to be acquired for any read or write operation, which means that any access is serialized. This was not an issue 15 years ago, but with today’s multi-core servers, such serialization is the best way to kill performance.

這邊就有點怪了,PK search 應該是個位數 ms 等級才對 (一般 EC 網站的資料量都應該可以 memory fit),不知道他是怎麼測的:

However from a performance point of view, any query cache hit is served in a few tens of microseconds while the fastest access with InnoDB (primary lookup) still requires several hundreds of microseconds. Yes, the query cache is at least an order of magnitude faster than any query that goes to InnoDB.

anyway,他實際測試兩個不同的 configuration,首先是打開 query cache 的:

再來是關閉 query cache 的:

測試的方式在原文有提到,這邊就不抄過來了。測試的結果可以看到關閉 query cache 得到比較好的 thoughput:

Throughput scales well up to somewhere between 10 and 20 threads (for the record the server I was using had 16 cores). But more importantly, even at the higher concurrencies, the overall throughput continued to increase: at 20 concurrent threads, MySQL was able to serve nearly 3x more queries without the query cache.

跟預期的差不多,硬體的改變使得演算法也必須跟著改,不然就會遇到問題...

支援多 CPU 的 ab:wrk

在「wrk」這邊看到 wrk 這個工具:「Modern HTTP benchmarking tool」。

利用 multi-threading 與 epoll/kqueue 撐出效能:

wrk is a modern HTTP benchmarking tool capable of generating significant load when run on a single multi-core CPU. It combines a multithreaded design with scalable event notification systems such as epoll and kqueue.

Ubuntu Core 與 Snappy Transactional Updates

OSNews 上看到「Announcing Ubuntu Core, with snappy transactional updates」,原文出自 Ubuntu 老大 Mark Shuttleworth 的文章「Announcing Ubuntu Core, with snappy transactional updates!」。

依照官方說明:

Ubuntu Core is a minimal server image with the same libraries as today’s Ubuntu, but applications are provided through a simpler mechanism.

希望提供比較穩定的套件環境,並且讓 app 之間不受干擾執行。系統裡分成 release、framework、app 三種角色,release 就是 Ubuntu Core,而 framework 可以是 Docker,最後的 app 就是自己的應用程式,而 snappy 就是管理這三個的軟體。

Snappy Ubuntu Core 是個 readonly image (裡面大多數的地方都不能寫,只有部份目錄以及用 tmpfs 掛起來的部份可以寫入)。

除了可以在雲端平台上面測試外,還可以用 QEMU 掛起來跑,不過實際測試的時候發現 precise (12.04) 的 QEMU 因為是 1.0 版所以不能跑,要 trusty (14.04) 附的版本才夠新 (2.0 版,需要 1.1+)。

找到 trusty 的機器跑的時候因為是遠端的機器,要多加上 -nographic -curses 的參數:

sudo kvm -m 512 -nographic -curses -redir :8090::80 -redir :8022::22 ubuntu-core-alpha-01.img

然後就可以依照官方文件裡提到的方法連進去了:

ssh -p 8022 ubuntu@localhost

然後就可以照著官方的文件操作一次,我自己沒遇到什麼問題。

看起來是 Ubuntu 自己在推動的一套標準,不知道市場接受度如何 :p

從爆炸的遺跡尋找蛛絲馬跡:在 MySQL crash 後,從 core file 找出當時有哪些 query 在執行

Percona 寫了一篇文章,說明在 MySQL core dump 後,要如何從 core file 撈出當時有哪些 query 在跑:「How to Extract All Running Queries (Including the Last Executed Statement) from a Core File?」。

一年前 Percona 的人也有寫一篇「How to obtain the “LES” (Last Executed Statement) from an Optimized Core Dump?」,今年這篇則是改良版,可以看到操作的方式便簡單了...

雖然大家都不喜歡 MySQL crash,但知道爆炸當時有哪些 query 對於後續的分析有很大的幫助,先紀錄起來,如果真的不幸用到,會比較快找到資料...