Percona 對於 PostgreSQL 使用 HugePages 的評論

開頭我先說一下我的想法,我對於 Percona 的 Ibrar Ahmed 的文章保持著懷疑的態度,因為他先前在「Benchmark PostgreSQL With Linux HugePages」這篇做的 benchmark 就有奇怪的結果,但卻給不出合理的原因,甚至連 Percona 自家的 CEO 公開在 comment 問之後也沒有看到文章提出合理的解釋:


A lot of interesting results here…

1) PgBench access distribution is very interesting. With database size growing by 20% from 80G to 96G we see performance drop of Several times which is very counter-intuitive

2) There is no difference between 2MB and 4K but huge difference between 1G and 2M even though I would expect at least some TLB miss reduction in the first transitioning. I would understand it in case transparent huge pages are Enabled… but not disabled

3) For 96GB why would throughput grow with number of clients for 1G but fall for 2M and 4KB.

這次看到「Settling the Myth of Transparent HugePages for Databases」這篇,也是在討論 Linux 的 HugePages 對 PostgreSQL 帶來的影響,同樣馬上又看到奇怪的東西...


Figure 1.1 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload(48GB) < shared_buffer (64GB)

Figure 1.2 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload (48GB) > shared_buffer (64GB)

不過這邊可以推測 Figure 1.2 應該是 112GB (因為對應的圖片上面標的是 112GB),當做是標錯就好。

但這樣又跑出一個奇怪的結果,48GB 的資料量比較小,TPS 大約是 35K/33K/41K,但 112GB 資料量比較大,卻可以達到 39K/43K/41K~42K,反而比較快?我暫時想不到什麼理由...

整體的測試有 pgbench 與 sysbench (這邊也打錯成 sysbecnch,先不管),其中 pgbench 跑了 10 mins 與 60 mins 的版本,但是 sysbench 只跑了 10 mins 的版本?這是什麼原因...

另外還是有些情況是打開 HugePages 比較快的 (sysbench 的 64 clients),如果以直覺來說的話,我反而還是會打開 HugePages (yeah 純粹是直覺),我現在比較想知道他會在 Percona 裡面待多久...

Python 上觀察 Memory Leak

Zendesk 的「Hunting for Memory Leaks in Python applications」這篇介紹了 memory_profiler 這個工具,可以比較長期的觀察記憶體使用量的問題。



這些資訊要找 memory leak 還是蠻粗糙的,但算是給了個方向,而且用起來算是簡單...

AWS 宣佈 Fargate 大幅降價

AWS Fargate 大幅降價:「Announcing AWS Fargate Price Reduction By Up To 50%」、「AWS Fargate Price Reduction – Up to 50%」。

先前 Fargate 的定價超級高,基本上是不會有正常應用會丟上去的情境... 如果可以接受 Fargate 的價錢,平常就用 ECS 或是 EKS 開三到五倍的機器在旁邊待機就好了,container scale 的速度還比 Fargate 快。

這次降價幅度很大,vCPU 降 20% 其實不算小,但相較於 Memory 降的 65% 就感覺好像沒降很多 (...):

Effective Jan 07, 2019, we are reducing the price for AWS Fargate by 20% for vCPU and 65% for memory across all regions where Fargate is currently available.

us-east-1m5.24xlarge 的價錢來看是 USD$4.608/hr。以他的 96 vCPU + 384 GiB RAM 對應到 Fargate 來算是 USD$5.59296/hr,大約多 21% 的價錢。


用 ESP8266 模擬 PC-XT...

看到拿 ESP8266 模擬 PC-XT,是個懷古時間:「IBM PC-XT Emulator on an ESP8266」。

現在小板子的 CPU 跟記憶體都比三十年前的桌機還要大了,直接在上面跑模擬器就算慢一點也已經不是問題了... 直接上麵包板接起來跑:

然後也可以跑 Windows 3.0:

純粹 hacking 的專案 XD

AWS 提供 6TB/9TB/12TB RAM 的機器...

AWS 推出了超大記憶體的機器,代碼 u-{6,9,12}tb1.metal,分別對應 6TB/9TB/12TB 的 RAM:「Now Available – Amazon EC2 High Memory Instances with 6, 9, and 12 TB of Memory, Perfect for SAP HANA」。

這記憶體比我桌機的硬碟還大... 然後還打算出更大台的機器 XDDD:

We’re not stopping at 12 TiB, and are planning to launch instances with 18 TiB and 24 TiB of memory in 2019.

不過目前從 web console 上沒看到可以選擇,似乎沒有開放零租 (i.e. 以分計費,或是以小時計費),在價錢頁「Amazon EC2 Pricing」這邊沒看到,在 Reserved Instance (RI) 的頁面「Amazon EC2 Reserved Instances Pricing」這邊也沒看到。

從文章裡的描述知道目前在 us-east-1 & ap-northeast-1 有提供,但從後台情況以及文章語氣推測,似乎要另外開 support ticket 才能選用:

These instances are now available in the US East (N. Virginia) and Asia Pacific (Tokyo) Regions as Dedicated Hosts with a 3-year term, and will be available soon in the US West (Oregon), Europe (Ireland), and AWS GovCloud (US) Regions. If you are ready to get started, contact your AWS account team or use the Contact Us page to make a request.


Python 3 內建的 lru_cache...

Twitter 上看到 Python 3 內建的 lru_cache()

從文件上可以看到預設值是 128 個:

@functools.lru_cache(maxsize=128, typed=False)

tweet 裡面有討論到 memory leak 的問題可以看一下,不過如果是拿來寫工具的話,應該不會有什麼問題...

EC2 推出了 R5、R5d、z1d 三種機器...

上個禮拜 Amazon EC2 就放話預定要推出 r5r5dz1d 三種機器,但當時沒公佈價錢,只公佈了規格,這樣就沒辦法比較成本。尤其 R 系列的機器主要就是看記憶體的單位成本...

今天總算是正式推出公開價錢了:「Now Available: R5, R5d, and z1d Instances」。

r{4,5}.large 比較,都是 2 vCPU,但 r5 的 ECU 快了一些,記憶體多了一些,價錢少了一些:

vCPUECUMemory (GiB)Instance Storage (GB)Linux/UNIX Usage
r5.large2816 GiBEBS Only$0.126 per Hour
r4.large2715.25 GiBEBS Only$0.133 per Hour

完全是個「麵多一點、湯多一點,但錢少一點」的概念 XD

另外這次推出的 z1d 系列主打高時脈:

The high frequency z1d instances use custom Intel® Xeon® Scalable Processors running at up to 4.0 GHz, powered by sustained all-core Turbo Boost, perfect for Electronic Design Automation (EDA), financial simulation, relational database, and gaming workloads that can benefit from extremely high per-core performance.

vCPUECUMemory (GiB)Instance Storage (GB)Linux/UNIX Usage
z1d.large21116 GiB1 x 75 NVMe SSD$0.186 per Hour

對於沒有辦法利用平行化加速的工作會有幫助,不過在目前 EC2 的價位表上面大概是因為比 r4 的記憶體還多,所以放在「Memory Optimized - Current Generation」而不是 Compute Optimized,不知道實際上用的時候會偏向哪塊...

7-Zip 的 RCE 安全性問題

7-Zip 被發現安全性問題 (CVE-2018-10115):「7-Zip: From Uninitialized Memory to Remote Code Execution」。而在 2018/04/30 推出的 18.05 修正了這個問題:「7-Zip 18.05」。

The vulnerability in RAR unpacking code was fixed (CVE-2018-10115).

除了修正以外,另外也開了 ASLR,對安全性會多一些防禦:

2018-03-06 - Discovery
2018-03-06 - Report
2018-04-14 - MITRE assigned CVE-2018-10115
2018-04-30 - 7-Zip 18.05 released, fixing CVE-2018-10115 and enabling ASLR on the executables.

手上有裝 7-Zip 的人要記得更新...

MySQL 8.0 的 innodb_dedicated_server

Percona 介紹了 MySQL 8.0 將會推出的 innodb_dedicated_server 參數:「New MySQL 8.0 innodb_dedicated_server Variable Optimizes InnoDB from the Get-Go」,Oracle 官方的文件在「15.6.13 Enabling Automatic Configuration for a Dedicated MySQL Server」這邊可以翻到。

這是針對整台機器完全給 MySQL 用的情況所設計的參數。在這種情況下,可以透過 RAM 的大小以及一些簡單的公式,得到還算堪用的系統參數...

依照說明,可以看到系統會依照記憶體的大小自動計算出 innodb_buffer_pool_sizeinnodb_log_file_size 這兩個參數,並且把 innodb_flush_method 設為 O_DIRECT_NO_FSYNC (如果所在平台有支援這個值)。

不過看了一下公式,依照經驗可以設的更積極一點... 像是 Percona 文章裡提到的,當記憶體夠大時,其實可以考慮從 80% 開始調整大小 (innodb_buffer_pool_size):

For InnoDB buffer pool size (based on this article), consider allocating 80% of physical RAM for starters. You can increase it to as large as needed and possible, as long as the system doesn’t swap on the production workload.

innodb_log_file_size 則應該要分析寫入的 pattern 而不是直接看 RAM 大小。有些機器雖然很大台但幾乎沒有寫入的量,照著公式的值就偏大很多:

For InnoDB log file size, it should be able to handle one hour of writes to allow InnoDB to optimize writing the redo log to disk. You can calculate an estimate by following the steps here, which samples one minute worth of writes to the redo log. You could also get a better estimate from hourly log file usage with Percona Monitoring and Management (PMM) graphs.

不過基本上 tune 出來的值還算堪用,對於剛入手的人頗有幫助。

Working Set Size (WSS) 的想法

NetflixBrendan Gregg (他比較知名的發明是 Flame Graph) 寫了一篇「How To Measure the Working Set Size on Linux」,他想要量測單位時間內會用到的記憶體區塊大小:

The Working Set Size (WSS) is how much memory an application needs to keep working. Your app may have populated 100 Gbytes of main memory, but only uses 50 Mbytes each second to do its job. That's the working set size. It is used for capacity planning and scalability analysis.

這可以拿來分析這些應用程式是否能夠利用 L1/L2/L3 cache 大幅增加執行速度,於是就可以做成圖,像是這樣:

在 Netflix 這樣人數的公司,需要設計一些有用的指標,另外發展出對應的工具,讓其他人更容易迅速掌握狀況,畢竟不是每個人都有上天下海的能力,遇到狀況可以馬上有頭緒進行 trouble shooting...