DigitalOcean 默默的推出了 3GB RAM 的方案

是在 Twitter 上看到這則 tweet 才發現 DigitalOcean 多了 3GB 的方案:

如果去翻資料,可以看到官網是在 2017/11/082017/11/15 中間增加的...

看規格可以看出來記憶體很多,但 CPU 與 SSD disk 空間都不是很多,有種 Amazon EC2 裡 R 系列機器的感覺,但卻沒放到 High Memory 的列表內 (DigitalOcean 已經有推出 High CPU 與 High Memory 的機種了),應該是入門款的想法?

不過價錢還是比同業貴不少... (相比於 LinodeVultr)

ElastiCache 支援 r4.* 了

每年 AWS re:Invent 要到的時候就會有很多新的消息出來,Amazon ElastiCache 的團隊應該也是配合著這一波放出消息:「Amazon ElastiCache Now Supports the R4 Node Family」。

包括了 memcachedRedis 都支援了:

Amazon ElastiCache now supports R4 node types. R4 nodes are optimized for latency sensitive and memory intensive workloads. They come in six sizes, providing 12.3GiB to 407GiB of available in-memory capacity. By setting up a 15-shard cluster for Redis, you can scale up to 6.1TiB of in-memory capacity. For Memcached, you can set up a 20-node cluster to support up to 8.14 TiB in-memory workloads. Equipped with the Intel Broadwell processor, and improved networking, R4 node family offers superior performance over the popular R3 node family.

這兩個應用都是看記憶體吃飯的...

RDS (MySQL/MariaDB) 支援 t2、r4 以及 m4 的新機種

這個大家等好久了,尤其 MySQL 常遇到需要用記憶體換效能的情境:「Amazon RDS for MySQL and MariaDB Supports R4, T2 and M4 Instance Types」。

先前 t2 最大只能開到 t2.large (8GB RAM),對於需要大量記憶體運算的 SQL query,就有機會被 MySQL 使用 filesort 寫到硬碟裡面暫存了。這次支援這些 instance type,開發環境至少有選擇可以開到 t2.2xlarge (32GB RAM) 跟他拼。

r4 應該是正式環境期待已久的 instance type 了。r3 最大是 r3.8xlarge (244GB),跟 r4 最大的 r4.16xlarge (488GB) 剛好差了一倍。

m4 就比較微妙了,順便補上去的感覺... 不過應該還是會有應用會剛好用到。

不過還是期待前陣子出來的 c5,對於寫出很驚人的 SQL query,在 MySQL 內跑大量運算的應用會有幫助,就繼續等吧... :o

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

MicrosoftGitHub 合作將本來只有在 Windows 上可以用的 GVFS 移植到 LinuxMac 上:「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 需求...

EC2 的 X1e 推出更小台的機種

本來 EC2x1e 家族只有 x1e.32xlarge,現在拆小拿出來租了:「Amazon EC2 Update – X1e Instances in Five More Sizes and a Stronger SLA」。

這次算是補足中間的缺口,因為先前的洞有點大:r4.16xlarge 是 488GB RAM,而往上就變成 x1e.32xlarge 的 3904GB,中間都沒有其他選擇可以用。這次 x1e.8xlarge (976GB) 與 x1e.16xlarge (1952GB) 算是補上了這邊的缺口,拿來跑需要大量記憶體,但還不需要到 4TB RAM 等級的程式...

Amazon Aurora (MySQL) 推出的 Asynchronous Key Prefetch

Amazon Aurora (MySQL) 推出新的效能改善,可以改善 JOIN 時的效能:「Amazon Aurora (MySQL) Speeds Join Queries by More than 10x with Asynchronous Key Prefetch」。

看起來像是某個情況的 optimization,將可能的 random access 換成 sequential access 而得到大量的效能:

This feature applies to queries that require use of the Batched Key Access (BKA) join algorithm and Multi-Range Read (MRR) optimization, and improves performance when the underlying data set is not in the main memory buffer pool or query cache.

其實記憶體還是最好用的加速器,能加大硬拼就先硬拼... XD

Apache 的 Optionsbleed

Apache 也出了類似 Heartbleed 的包:「Apache bug leaks contents of server memory for all to see—Patch now」,原文出自「Optionsbleed - HTTP OPTIONS method can leak Apache's server memory」。

這掛上 CVE-2017-9798 了,影響版本包括了:

This affects the Apache HTTP Server through 2.2.34 and 2.4.x through 2.4.27.

發生在對 OPTIONS 處理出問題:

Optionsbleed is a use after free error in Apache HTTP that causes a corrupted Allow header to be constructed in response to HTTP OPTIONS requests. This can leak pieces of arbitrary memory from the server process that may contain secrets. The memory pieces change after multiple requests, so for a vulnerable host an arbitrary number of memory chunks can be leaked.

就... 更新吧 @_@

Amazon EC2 推出 4TB 的機器

之前 Amazon EC2 記憶體最大的機器是 x1.32xlarge 的 2TB RAM (更精確是 1952GB),現在推出了 4TB RAM 的 x1e.32xlarge (3904GB):「Now Available – EC2 Instances with 4 TB of Memory」。

現在這個時間點在 us-east-1 的價錢是 USD$26.688/hour (一個月 USD$19215.36),用的到的人應該付得起?

另外值得注意的是,x1e.32xlarge 雖然比 x1.32xlarge 多了一倍的記憶體,但 vCPU 不變 (都是 128),而且 ECU 下降了 (從 349 降到 340)。

這個機器目前在 us-east-1us-west-2eu-west-1ap-northeast-1 四區提供服務:

The x1e.32xlarge instances can be launched in On-Demand and Reserved Instance form via the AWS Management Console, AWS Command Line Interface (CLI), AWS SDKs, and AWS Marketplace in the US East (Northern Virginia), US West (Oregon), EU (Ireland), and Asia Pacific (Tokyo) Regions.

InnoDB 與 MyRocks 之間的取捨

MyRocks 的主要作者 Mark Callaghan 整理了一篇關於大台機器下,資料可以放到記憶體內的效能比較:「In-memory sysbench, a larger server and contention - part 1」。

這其實才是一般會遇到的情況:當事業夠大時,直接花錢買 1TB RAM + 數片 PCI-E SSD 的機器用錢換效能... (主要應該會在記憶體花不少錢,剛剛查了一下,現在白牌的 server 一台大約七十萬就可以擺平?兩台做 HA 也才一百四十萬,對有這個規模的單位來說通常不是大問題...)

而三種不同的 case 裡面,最後這個應該是最接近真實情況的:

可以看到 InnoDB 在幾乎所有項目都還是超越 MyRocks (只有 random-points 與 insert-only 輸)。

不知道後續的開發能量還會有多少... (因為 Facebook 的用法跟一般情況不一樣)

Reddit 在處理 Page View 的方式

Reddit 說明了他們如何處理 pageview:「View Counting at Reddit」。

以 Reddit 的規模有提到兩個重點,第一個在善用 RedisHyperLogLog 這個資料結構,當量大的時候其實可以允許有微小的誤差:

The amount of memory varies per implementation, but in the case of this implementation, we could count over 1 million IDs using just 12 kilobytes of space, which would be 0.15% of the original space usage!

維基百科上有說明當資料量在 109 這個等級時,用 1.5KB 的記憶體只有 2% 的誤差值:

The HyperLogLog algorithm is able to estimate cardinalities of > 109 with a typical error rate of 2%, using 1.5 kB of memory.

第二個則是寫入允許短時間的誤差 (pageview 不會即時反應),透過批次處理降低對 Cassandra cluster 的負荷:

Writes to Cassandra are batched in 10-second groups per post in order to avoid overloading the cluster.

可以注意到把 Redis 當作 cache 層而非 storage 層。

主要原因應該跟 Redis 定位是 data structure server 而非 data structure storage 有關 (可以從對 Durability 的作法看出來),而使用 Cassandra 存 key-value 非常容易 scale,但讀取很慢。剛好兩個相輔相成。