Tag: io

今年三月的時候 Limelight Networks 買了 Edgecast，改名為 Edgio

查資料的時候才發現的新聞，Limelight Networks 買下 Edgecast，改名為 Edgio：「Limelight to Acquire Yahoo’s Edgecast, Creating Global Leader in Edge Enabled Software Solutions」，然後 NASDAQ 代碼從 LLNW 改成 EGIO。

不過本來 Edgecast 本來在台灣是有點的 (跟 HiNet 合作)，現在看起來在 network map 上面沒出現了：

不過直接抓 www.edgecast.com 還是可以看到是中華的機房：

  2.|-- 168-95-170-94.hinet-ip.hi  0.0%    10    2.0   3.0   1.5  11.4   3.0
  3.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  5.|-- 220-128-24-53.hinet-ip.hi  0.0%    10    7.0   6.8   6.4   7.7   0.4
  6.|-- 211-20-238-81.hinet-ip.hi  0.0%    10    6.1   6.9   6.1   9.7   1.0
  7.|-- 152.195.35.156             0.0%    10    7.1   6.7   6.3   7.4   0.4

但 edg.io 看起來是丟去新加坡：

  2.|-- SNUH-3302.hinet.net        0.0%    10    1.8   2.6   1.2  11.4   3.1
  3.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- pcpd-4101.hinet.net        0.0%    10    1.8   2.2   1.8   3.0   0.4
  5.|-- pcpd-4001.hinet.net        0.0%    10    2.2   2.6   2.1   3.3   0.4
  6.|-- ix-ae-17-0.tcore1.svw-sin  0.0%    10   48.6  50.7  48.6  61.7   4.0
  7.|-- if-be-45-2.ecore2.esin4-s 60.0%    10   49.1  48.7  48.1  49.1   0.4
  8.|-- if-be-10-2.ecore2.svq-sin  0.0%    10   52.3  50.7  49.3  55.1   1.8
  9.|-- 117.121.251.241            0.0%    10   49.7  50.1  49.5  50.6   0.4
 10.|-- 208.69.180.13              0.0%    10   49.6  49.9  49.0  51.8   0.8

再找機會研究看看...

Firefox 的 RCWN (Race Cache With Network)

前幾天 Hacker News 上看到「When network is faster than browser cache (2020) (simonhearne.com)」這則 2020 的文章，原文在「When Network is Faster than Cache」這邊，講 Firefox 在 2017 年導入了一個特別的設計，除了會在 cache 裡面抓資料以外，也會到網路上拉看看，有機會從網路上抓到的資料會比 cache 先得到，這個功能叫做 RCWN (Race Cache With Network)：「Enable RCWN」。

開頭就先提到了有人回報 Firefox 上的 RCWN 似乎沒有明顯效果：「Tune RCWN racing parameters (and make them pref-able)」。

On my OSX box I'm seeing us race more than we probably need to:

Total network request count: 5574
Cache won count 938
Net won count 13

That's racing almost 16% of the time, but only winning 1.3% of the time. We should probably back off on racing a bit in this case, at least.

16% 的 request 決定 RCWN 兩邊打，但裡面只有 1.3% 是 network 比 cache 快。

不過作者決定試著再多找看看有沒有什麼方向可以確認，但測了很多項目都找不到哪個因素跟 cache retrieval time 有直接相關，反而在看看 Chromium 時發現 Chromium 是透過限制連線數量，降低 I/O 造成的問題：

It turns out that Chrome actively throttles requests, including those to cached resources, to reduce I/O contention. This generally improves performance, but will mean that pages with a large number of cached resources will see a slower retrieval time for each resource.

看起來就是個簡單粗暴的 workaround...

GitHub 宣佈在 github.io 上抵制 FLoC

GitHub 的公告簡單明瞭，也不用你操作，直接在 github.io 上抵制 FLoC：「GitHub Pages: Permissions-Policy: interest-cohort=() Header added to all pages sites」，在「[Feature request] Set HTTP header to opt out of FLoC in GitHub Pages」這邊有些討論，另外在 Hacker News 上的討論也可以看一下：「GitHub blocks FLoC across all of GitHub Pages (github.blog)」。

不過不確定為什麼 custom domain 的就不加上去，可能微軟內部的法務團隊討論出來的結果？

All GitHub Pages sites served from the github.io domain will now have a Permissions-Policy: interest-cohort=() header set.

Pages sites using a custom domain will not be impacted.

AWS 宣佈提昇 Amazon EFS 的最低效率

AWS 宣佈提昇 Amazon EFS 的最低效率：「Amazon Elastic File System increases file system minimum throughput」。

第一段裡的幾個數字差不多就是重點了：

Amazon Elastic File System (Amazon EFS) file systems using the default bursting throughput mode now have a minimum throughput of 1 MiB/s. All EFS bursting mode file systems (regardless of size) can drive 100 MiB/s of throughput, and file systems with more than 1TiB of Standard class storage can drive 100 MiB/s per TB when burst credits are available. This change increases the minimum throughput from 50KiB/s per GiB of Standard class storage to a fixed minimum of 1 MiB/s for file systems with less than 20 GiB of Standard class storage, when burst credits are exhausted.

本來最低保證效率是每 GB 提供 50KB/sec，也就是要使用到 20GB 才會提供 1MB/sec，現在對於不到 20GB 的使用者，直接拉高到固定 1MB/sec。

這對於剛開始用的使用者會方便一些，不過 EFS 主要還是方便在不同機器上共享，效率上還是本機掛 EBS 好很多 (因為 OS 可以 cache)。

先前在 AWS 上把 /home 丟到 EFS 上面，結果因為 i/o 都需要透過網路的關係，編 pyenv 超慢，後來找一天把東西都丟回 EBS 上，速度快多了...

Percona 分析在 AWS 上跑 Percona XtraDB Cluster 的效能 (I/O bound)

Percona 的人分析了在 Amazon EC2 上跑 Percona XtraDB Cluster (PXC) 效能 (I/O bound)：「Best Practices for Percona XtraDB Cluster on AWS」。

先看他們做出來的圖：

直接跳到結論的地方。如果資料可以掉，用 i3 本地 storage 的效能是最好的，如果要資料不能掉，用 EBS 的 Provisioned IOPS SSD (io1) 的效能會比 General Purpose (gp2) 好很多。

另外 instance type 的選擇上，避免用 {i3,r4}.large，因為測試出來發現 {i3,r4}.xlarge 的效能好不只一倍。

不過 Aurora 的 Multi-master 已經在 Preview 了啊，如果 Percona 的人拿到帳號的話，應該會有單位成本的效能比較可以看...

Microsoft 與 GitHub 合作，將會把 GVFS 移植到 Linux 與 Mac 上

Microsoft 與 GitHub 合作將本來只有在 Windows 上可以用的 GVFS 移植到 Linux 與 Mac 上：「Microsoft and GitHub team up to take Git virtual file system to macOS, Linux」。

GVFS 是解決微軟內部自己在用 Git 的痛處，因為微軟的 repository 都... 有... 點... 肥... (畢竟有不少產品發展了很久)。

目前 Git 的操作是卡在 I/O 與 memory cache 的限制上：

Also, Git wasn't designed for a codebase that was so large, either in terms of the number of files and version history for each file, or in terms of sheer size, coming in at more than 300GB. When using standard Git, working with the source repository was unacceptably slow. Common operations (such as checking which files have been modified) would take multiple minutes.

GVFS 的想法是有用到的部份再真的去拉，藉此大幅減少 I/O 需求...

Stream 對 .io 的感冒

Stream 的人寫了一篇「Why Stream Stopped Using .IO Domain Names for Production Traffic」表達他們對 .io 的感冒...

主要是因為 9/20 爛掉的情況不太妙。第一個是 .io 爛掉了兩個小時 (以月來算 SLA 就等於直接掉了 0.2% uptime，變成不到 99.8%)，第二個是爛掉時 server 傳回的不是 SERVFAIL，而是 NXDOMAIN：

The outage lasted for almost 2 hours, during which 1/5th of DNS queries for any .getstream.io record would fail.

他們的解法是改到 .com 上，畢竟影響的時候應該會修得比較快。另外文章裡也有延伸提到 Amazon Route 53 爛掉時要怎麼辦，如果他們真的決定要解決的話，應該是會拿出像「StackOverflow 對於多 DNS 商的同步方式...」或是「GitHub 也自己搞了一套管理多家 DNS 的程式...」的搞法吧。

不過這的確是當初選 .io 沒預料到的...

用 4.5+ 的 Linux Kernel 限制 I/O 速度

在「Using cgroups to limit I/O」這邊看到作者試著用 cgroups 限制 I/O 速度。

作者前面花了不少篇幅解釋 cgroups v1 無法正確限制 I/O 速度，後面就在講 cgroups v2 怎麼做：

So, in order to limit I/O when this I/O may hit the writeback kernel cache, we need to use both memory and io controllers in the cgroups v2!

這會需要 4.5+ 的 kernel，可能會需要手動更新，或是直接使用比較新的 distribution：

Since kernel 4.5, the cgroups v2 implementation was marked non-experimental.

然後照抄就可以了 (不過這邊的指定都需要 root，作者用 $ 表示 shell 有點怪)：

# mount -t cgroup2 nodev /cgroup2
# mkdir /cgroup2/cg2
# echo "+io" > /cgroup2/cgroup.subtree_control
# echo "8:0 wbps=1048576" > io.max
# echo $$ > /cgroup2/cg2/cgroup.procs

然後就可以跑 dd 測試速度了，同時間也可以跑 iostat 看。

Linux 下 RAID1 的 SSD 會有讀取不平均問題

在「Unbalanced reads from SSDs in software RAID mirrors in Linux」這邊看到作者看 S.M.A.R.T. 數據時發現兩顆 SSD 硬碟組成的 RAID1 有很明顯的讀取不平均的問題：

242 Total_LBAs_Read [...] 16838224623
242 Total_LBAs_Read [...] 1698394290

原因是因為 Linux 對 RAID1 的 SSD 有不一樣的演算法：

The current state of RAID1 read balancing is kind of complex, but the important thing here in all kernels since 2012 is that if you have SSDs and at least one disk is idle, the first idle disk will be chosen.

2016 時演算法就更激進了，變成非 SSD 會：

In kernels with the late 2016 change, this widens to if at least one disk is idle, the first idle disk will be chosen, even if all mirrors are HDs.

加上 SSD 很快，這造成 loading 幾乎都在第一顆上... 這對 SSD 應該是還好啦 (理論上 SSD 的讀取不傷壽命)，不過還是有點怪就是了。

Facebook 把 InnoDB 換成 MyRocks 的計畫

在「Migrating a database from InnoDB to MyRocks」這邊講到了 Facebook 把 MySQL 的 InnoDB 換成 MyRocks 的計畫。

Facebook 已經大量導入全 Flash 的環境，於是現在 InnoDB (Compressed) 的情況類似於這樣：

可以看到空間是最大的問題 (Space-bound)，而非 CPU 或是 I/O，這在純 Flash 的機器上還蠻有可能的，因為純 Flash 能提供的 I/O capacity 超高，加上 Facebook 把 MySQL 當作後端儲存設備而已，CPU 的使用量可以預期不高...

然後他們估算 MyRocks 可以省下一半的空間，於是有可能變成：

不過對於一般單位來說，這些前提就未必成立了... 但還是可以看到 Mark Callaghan 花不少力氣在調校一般性的效能，希望讓使用者多一點...