Tag: ssd

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 量比較大的時候。

Amazon EBS (gp2) 提昇效能...

AWS 宣佈提昇了 Amazon EBS (gp2) 的效能：「Amazon EBS Increases Performance of General Purpose SSD (gp2) Volumes」。

本來上限是 10k IOPS，現在提升到 16k IOPS 了。另外最大傳輸速度也從 160 MB/sec 提升到 250 MB/sec：

Today we are announcing a 60% improvement in performance of General Purpose SSD (gp2) Volumes from 10,000 IOPS to 16,000 IOPS and from 160 MB/s to 250 MB/s of throughput per volume.

應該還是維持 3 IOPS per GB 的設計，但這對於想要用 gp2 堆效能的人來說算是好消息，可以用更大的空間堆出更多 IOPS 了... (像是「Percona 的人接受 AWS 的建議，重新測試了 Percona XtraDB Cluster 在 gp2 上的效能...」這篇)

EBS 可以動態擴充 Magnetic Volume 的大小了...

AWS 宣佈可以動態擴充 EBS (Magnetic Volume) 的大小了：「Amazon EBS Extends Elastic Volumes to Support EBS Magnetic (Standard) Volume Type」。EBS (Magnetic Volume) 被歸類到前個世代的產品，意外的把這個功能支援了前個世代的產品...

前世代的 Magnetic Volume 與 Throughput Optimized HDD (st1) & Cold HDD (sc1) 來比較起來貴了一些，但可以當作開機空間，另外低消只有 1GB (而 st1 與 sc1 是 500GB)，不過如果與 General Purpose SSD (gp2) 比的話，只要 I/O 有點量，整體的價錢就會超過 gp2，目前看起來還是用 gp2 會好一些...

Amazon EC2 補產品線：M5 也有 NVMe 的 SSD local disk 可以用了

Amazon EC2 對 M5 instance 推出了帶 NVMe SSD 的版本：「EC2 Instance Update – M5 Instances with Local NVMe Storage (M5d)」。先推出歐美的區域：

M5d instances are available in On-Demand, Reserved Instance, and Spot form in the US East (N. Virginia), US West (Oregon), EU (Ireland), US East (Ohio), and Canada (Central) Regions. Prices vary by Region, and are just a bit higher than for the equivalent M5 instances.

算是 M3 系列的後繼產品？對應到四年前推出的 m3.medium 是 1 vCPU、3.75GB RAM 以及 8GB SSD (不過 m3.large 就變成 2 vCPU、7.5GB RAM 與 32GB SSD，硬碟的部份多了不少)。

這樣 M5 就更全面了...