Tag: ssd

Amazon EBS 的 io2 給了不少新消息...

Amazon EBS 的另外一個新推出的東西，是針對 io2 的改善：

前面兩則消息可以一起看，主要是推出了 EBS Block Express，有著效能上的提昇：

Built on our new EBS Block Express architecture that takes advantage of some advanced communication protocols implemented as part of the AWS Nitro System, the volumes will give you up to 256K IOPS & 4000 MBps of throughput and a maximum volume size of 64 TiB, all with sub-millisecond, low-variance I/O latency. Throughput scales proportionally at 0.256 MB/second per provisioned IOPS, up to a maximum of 4000 MBps per volume. You can provision 1000 IOPS per GiB of storage, twice as many as before. The increased volume size & higher throughput means that you will no longer need to stripe multiple EBS volumes together, reducing complexity and management overhead.

目前因為是 preview 階段，想要用的人需要申請測試。要注意目前支援的區域有限 (不像這次推出 gp3 的時候就是全區)，而且需要搭配 r5b 的機器：

The preview is currently available in the US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Europe (Frankfurt) Regions. During the preview, we support the use of R5b instances, with support for other Nitro-powered instances in the works.

第三則消息則是在講 io2 的 IOPS 的折扣，針對購買 32K IOPS 以上的部份會有 30% 折扣：

Now, with the new tiered pricing structure, the first 32,000 IOPS provisioned on a volume are charged at the current base rate ($0.065 per provisioned IOPS-mo) and the second tier between 32,001 and 64,000 is charged at a 30% lower rate ($0.046 per provisioned IOPS-mo).

針對前面提到的 preview 版本 (EBS Block Express)，因為可以超過 64K IOPS，這個部份的價錢會更低，再疊一次 30% 的折扣：

Furthermore, for customers who have even higher performance requirement than currently supported by a single io2 volume today, we are previewing io2 volumes that run on EBS Block Express, the next generation of our block storage architecture. io2 Block Express volumes can be provisioned to deliver peak IOPS of 256,000. For these volume, any IOPS provisioned over 64,000 IOPS will be charged at a further 30% lower rate than the second tier ($0.032 per provisioned IOP-mo for IOPS over 64,000). This lowers the effective rate to $0.038 per provisioned IOPS on a volume provisioned with 256,000 IOPS.

算是要衝效能的人用的，目前平常應該還是會用 gp2 或是 gp3 的 SSD...

Amazon EBS 推出了 gp3

今年的 AWS re:Invent 又開始了，不過因為疫情的關係，這次是線上為主... 這邊先來整理一下 Amazon EBS 相關的更新。

首先是推出了新的 gp3 類型，也是 SSD 類：「New – Amazon EBS gp3 Volume Lets You Provision Performance Apart From Capacity」。

每 GB 單位成本比 gp2 低 20%：

Today I would like to tell you about gp3, a new type of SSD EBS volume that lets you provision performance independent of storage capacity, and offers a 20% lower price than existing gp2 volume types.

然後直接給你 3000 IOPS 與 125MB/sec，有需要更高的話可以「加購」：

gp3 is designed to provide predictable 3,000 IOPS baseline performance and 125 MiB/s regardless of volume size. It is ideal for applications that require high performance at a low cost such as MySQL, Cassandra, virtual desktops and Hadoop analytics. Customers looking for higher performance can scale up to 16,000 IOPS and 1,000 MiB/s for an additional fee. The top performance of gp3 is 4 times faster than max throughput of gp2 volumes.

但照「Amazon EBS volume types」這邊的列表可以看到，要注意 gp2 可以 burst 的 throughput (250MB/sec) 比 gp3 的 baseline (125MB/sec) 高。

也因為這樣，可以把一些 random access 比較多的 /data 這類的 EBS 換過去，但如果是要大量 sequential access 的也許就不適合了。

IOPS 的部份，1TB 以下的 gp2 換過去應該是沒什麼太大問題，因為在 gp2 的時候是 1GB 給 3IOPS，所以 1TB 以下的 gp2 都低於 3000IOPS。

轉移的部份可以在 AWS 的 console 上直接 migrate 到 gp3：

If you’re currently using gp2, you can easily migrate your EBS volumes to gp3 using Amazon EBS Elastic Volumes, an existing feature of Amazon EBS. Elastic Volumes allows you to modify the volume type, IOPS, and throughput of your existing EBS volumes without interrupting your Amazon EC2 instances.

像是這樣：

但照「Amazon EBS volume types」這邊的列表，gp3 可以是開機硬碟，但是改不過去啊 XDDD

Update：剛剛發現文件被修正了，看起來不能當開機硬碟...

不知道哪邊搞錯了，過幾天看看吧 XDDD

在 Hacker News 上看到 Raspberry Pi 400 使用心得

在 Hacker News 看到 Raspberry Pi 400 的使用心得：「I've now played with a Raspberry Pi 400 for a week and here are my conclusions」，先前在「Raspberry Pi 400」這邊有提到 Raspberry Pi 400，主要就是一台 Raspberry Pi 4 Model B 的主機，但跟鍵盤整合在一起。

在文章裡提到了 Raspberry Pi 4 可以 USB Boot 後帶來的改變 (參考之前寫的「Raspberry Pi 4 可以透過 USB 開機了」這篇)，主要是透過 USB3 外接硬碟可以讓讀寫速度大幅提昇 (尤其是 SSD)，這一直都是 Raspberry Pi 上面用 SD card 的問題，看起來唯一的問題還是 CPU 的速度還是沒有像目前常見的 x86-64 強。

If you give it fast enough "disk" storage it really moves. I plugged in a Kingston brand 120GB SSD on a USB3 adapter. hdparm -t gave 292MB/s read speed and the default LXDE environment was really crisply responsive, with even a first launch of Chromium taking less than two seconds. With such good storage, the only real limitation is that heavy Javascript stuff is too slow - 5+ seconds to switch between folders in Chrome, or for the thumbnail gallery to appear in Youtube. Also, video calling is marginal. Aside from that the CPU is fast enough.

另外討論裡面也有人希望 Raspberry Pi 考慮引入 eMMC 或是提供 M.2 界面改善讀寫速度，不過我覺得 SD card 的設計算是 Raspberry Pi 當初的方向，本來就有取捨，不太可能什麼都做進去...

回到作者的心得，雖然 USB3 轉 SSD 看起來 i/o 速度快不少，但我好像主要不是遇到 i/o 速度問題，反倒是最近 chromium 的硬體解碼好像有些進度，也許看影片有機會用硬體處理 (至少一部份？)，希望至少可以輕鬆看 1080p60 啊...

Amazon EBS 推出新的 io2 類型

Amazon EBS 保障 IO 效能的版本 Provisioned IOPS io1 進化了，推出了 Provisioned IOPS io2：「New EBS Volume Type (io2) – 100x Higher Durability and 10x More IOPS/GiB」。

目前先看了一下美國與新加坡的價錢，應該都還是一樣，看起來這次主要是功能性上的進步，有兩個比較顯著的改變。

第一個是每 GB 可以租用的 IOPS 數量上升了，io1 是 50 IOPS，在 io2 給到 500 IOPS；不過最大值不變，都還是 64k IOPS。這個看起來對於追求 IOPS 的人彈性增加不少，不過算了一下成本差距應該是還好，以最大的 64k IOPS 來算，光 IOPS 的費用就要 USD$4160/month，而最低的空間租量上，io1 租 1280 GB (USD$160/month) 與 io2 租 128 GB (USD$16/month) 在這個部分只能算零頭了...

第二個是持久性 (durability)，從 io1 的 99.9% 到 io2 變成 99.999% 了，這邊應該主要是受益於這十年 SSD 技術的進步。我猜本來的 io1 其實也拉高不少，只是 SLA 合約上沒有增加而已...

應該還是會守在 gp2 上，便宜大碗，不過效能的保證少了些，對於一般性的應用來說應該是夠用。

MyRocks/MariaDB 的 tuning 過程

看起來應該是找 Percona 的人幫忙轉移到 MyRocks 上，然後整理出來的成功案例：「The Road Story of a MyRocks/MariaDB Migration」。

看起來是跑在獨立機器上，而不是雲端的虛擬機上，所以不是想 scale up 就可以把硬體規格拉上去 (說不定記憶體插槽已經滿了之類的...)：

Replicas run on bare metal servers, usually Dual Xeon E5 v3 or v4, with 192 GB to 384 GB of RAM.

這次遇到的主要的問題是發現效能跟不上。另外在文章裡面沒寫到，但可以猜到的是，他們目前不打算改架構，而是想要藉由改善資料庫的效能來解決問題：

The servers were close to their limits and were slow to catch up with replication after a maintenance period

後面可以看到不少過程，主要是重新編一份 MariaDB，讓 MyRocks 支援 Zstandard (MyRocks 支援 Zstandard，不過 MariaDB 內的 MyRocks 不知道為什麼關掉了...)，這點大幅降低了空間的佔用。

另外是遇到 OOM 問題，在改用 jemalloc 解決記憶體用量的問題後就解決了 (這個在使用 InnoDB 的時候也算是標配了)。

不過在「Increased Read Load Over Time」那段還是看到了 workaround：

The read load was still rising a bit but at a much smaller pace. Instead of hours, it was days. That’s kind of expected given the workload and we were already planning for periodic manual compactions.

目前看起來 MyRocks 的強項主要是在省資源，但缺點就是有不少眉眉角角得小心處理。這樣的話，一般應該還是會先用 InnoDB，真的搞大了再考慮要不要換過去...

Cloudflare 的另外一個策略：不熱門的資料只放到記憶體內

前陣子的文章，Cloudflare 將不熱門的資料放到記憶體內，不寫到磁碟裡面：「Why We Started Putting Unpopular Assets in Memory」。

主要的原因是這些不熱門的資料常常是一次性的，寫到 SSD 裡面反而浪費 SSD 的生命。而且這樣做因為減少了寫入，反而可以讓 SSD 的讀取變快：

The result: disk writes per second were reduced by roughly half and corresponding disk hit tail latency was reduced by approximately five percent.

這個想法還蠻特別的，但好像印象中之前有人有提過類似的方法...

Anyway，這個想法不只在 CDN 這邊可以用到，對於有 memory + storage 架構的 cache system 也可以套用類似的道理，而要怎麼決定哪些 object 要寫到磁碟裡面的演算法就是重點了...

題外話，剛剛因為突然想到，瞄了一下 Squid，發現連 HTTPS 都還沒上...

幫 2011 年的 Mac Mini 換 SSD

這台 Mac Mini 是我第一個蘋果產品 (退伍後在 PIXNET 的時候買的)，當時本來想在上面寫些東西，不過後來就一直當個終端機在用而已，到這幾年他的定位就是放在客廳當個播放器 (像是開 Twitch 或是 YouTube 在看)。

不過每次用都覺得開 Google Chrome 開的很慢，就興起將硬碟換成 SSD 硬碟的念頭了。至於記憶體，當初在買 Mac Mini 的時候應該是已經升級過，裡面是兩條 4GB 了，網路上是有人提到可以支援兩條 8GB，不過以目前客廳的用法，應該是用不到...

先對價錢做了一些功課，如果是自己處理，打算換成美光的 Crucial MX500，在 24h 是賣 $2,099 (不過後來是剛好有去光華一趟，就在光華買回來)，然後打電話問一下有提供更換服務的店家，500GB SSD 是 $3,500 換到好，1TB SSD 則是 $6,000。

以 500GB 的價錢倒是沒有到不能接受，但也不是能馬上就說 ok 的價位，還是得看一下有多麻煩才能決定要怎麼做。

所以就跑去看了一下 YouTube 上換 SSD 的影片，看起來只要有對應的螺絲起子，應該是可以自己換完。而我之前就有準備六角螺絲起子，應該是可以換下來：

實際拆的時候才發現，不只需要正六角的螺絲起子 (H 系列)，還需要星狀的螺絲起子 (T 系列)，本來想在 24h 下單隔天再來弄，突然想到這種東西在水電五金行應該有，當時才晚上八點，就跑去外面找了一組 (價錢也比 24h 便宜)，回來繼續拆...

有了正確的工具，拆開就簡單不少，反倒是裝回去折騰一陣子... 在裝有 WiFi 天線的那塊板子的四顆螺絲時卡了一個小時 (一直都只鎖的上去三顆)，最後本來是打算少鎖一顆螺絲，結果在準備放棄的時候突然暴力法把四個孔位都卡進去了，就順利把四顆螺絲都鎖上去...

接下來就是先開機進入 macOS Recovery 確認硬碟有被抓到，確認有被抓到以後，就可以準備重裝系統，這時候我拿 MBPR 下載 10.13 (High Sierra，這台 Mac Mini 能支援的最新版)，生出 USB 隨身碟裝機，然後插回 Mac Mini 重開機就可以裝系統了：

裝完後的開機速度很明顯快不少，裝軟體的速度也是，另外再打開一些網站看一看，冷啟動的速度都改善很多。

算是趁連假的時候整理一下硬體，還蠻有趣的...

家裡電腦裝 Ubuntu 18.04

上個禮拜四家裡的桌機開不了機，找了一天發現是系統的 SSD 掛掉了，就買了張 M.2 SSD，然後計畫順便把本來的 Ubuntu 16.04 升級到 Ubuntu 18.04，但 Ubuntu 18.04 把預設的界面從 Unity 換成 GNOME (然後披上 Unity 的皮)，加上前陣子系統從 Intel 平台換到 AMD，整個狀況變得超混亂之後，就變成一連串踩地雷的過程...

最一開始是 UEFI + LUKS 的安裝問題，本來想裝到 M.2 SSD 上面，但 Ubuntu 18.04 的 grub-install 就是硬寫到 /dev/sda 不能改：「“Unable to install GRUB in /dev/sda” when installing GRUB」，照著這篇的 workaround 用還是不行，最後放棄，直接生一顆 SATA SSD 接到 SATA Port 1，把 M.2 當作資料碟。

硬體相關的問題：

軟體相關的問題：

  • 目前不支援從 GUI 設定 PPPoE 的網路 (沃槽)，幾種方式裡面我推薦用 pppoeconf 設定會比較好，然後可以改 /etc/ppp/options 加上 IPv6 的設定。
  • 本來想裝 gnome-shell-extension-system-monitor 觀察系統狀態，但會造成系統超級卡，關掉後就變成普通的卡 (後來就找到 Intel I211-AT 的那個問題了)。

現在至少是堪用的程度了，接下來就是不斷的補各種設定...

AWS 上用空間買 IOPS 的故事...

在「A web performance issue」這邊講到 Mozilla 的系統產生效能問題，後續的 trouble shooting 以及解決問題的方案。

這個系統跑在 AWS 上，在一連串確認後發現是 RDS 所使用的 EBS 的 IOPS 滿了：

After reading a lot of documentation about Amazon’s RDS set-up I determined that slow downs in the database were related to IOPS spikes. Amazon gives you 3 IOPS per Gb and with a storage of 1 Terabyte we had 3,000 IOPS as our baseline. The graph below shows that at times we would get above that max baseline.

然後大家對於解法都差不多，因為 Provisioned IOPS 太貴，所以直接加大空間換 IOPS 出來 (因為 General SSD 裡 1 GB 給 3 IOPS)：

To increase the IOPS baseline we could either increase the storage size or switch from General SSD to Provisioned IOPS storage. The cost of the different storage type was much higher so we decided to double our storage, thus, doubling our IOPS baseline. You can see in the graph below that we’re constantly above our previous baseline. This change helped Treeherder’s performance a lot.

然後再設警告機制，下次就可以提前再拉昇：

In order to prevent getting into such a state in the future, I also created a CloudWatch alert. We would get alerted if the combined IOPS is greater than 5,700 IOPS for 6 datapoints within 10 minutes.

不過 General SSD 的 IOPS 是沒有 100% 保證的，只有這樣寫：

AWS designs gp2 volumes to deliver 90% of the provisioned performance 99% of the time.

大多數的情況應該是夠用啦...

AWS 的 EBS 預設型態改為 GP2 (SSD)

AWS 宣佈 EBS 的預設型態從 Standard 變成 GP2：「EBS default volume type updated to GP2」。

包括 web console 與 API 的預設值都改成 GP2：

The AWS console defaults to GP2 in all regions. On July 29th the default EBS volume type was updated in thirteen regions from Standard to GP2. Now AWS API calls for volume, image, and instance creation also default to GP2 in all regions.

GP2 是 SSD，所以可以提供比較低的 latency，而另外一個用 GP2 的好處是 i/o 的費用已經含在內了 (Standard 會另外收取費用)，對於成本估算會比較簡單一些，尤其是 i/o 量比較大的時候。