Tag Archives: memory

Nokia 釋出的 Memory Profiler

Rust 開發的 memory profiler,可以抓 memory leaking 與 memory fragmentation,然後宣稱效能影響也比較低:「A memory profiler for Linux」,有提供網頁界面,還蠻美觀的:

給的範例有兩行,一行是跑 profiler:

LD_PRELOAD=./libmemory_profiler.so ./your_application

另外一行是讀資料給 HTTP server:

./memory-profiler-cli server memory-profiling_*.dat

之後有機會抓漏時可以拿來用看看...

增加工作效率:關閉 Mac 上切換視窗時的動畫效果

把各種動畫效果時間減少主要是因為要降低對「短期記憶」的影響,尤其年紀大了以後特別有感覺:

短期記憶(英語:Short-term memory,也稱為primary memory或者active memory)是記憶的一種類型,它可以在頭腦中讓少量資訊保持啟用狀態,在短時間內可以使用。短期記憶的持續時間(在沒有複述或者啟用的情況下)以秒計算。與長期記憶相比,短期記憶對資訊的儲存時間較短,資訊儲存的容量也很有限。關於短期記憶的容量,一個常常參照的數字是7 ± 2 個元素。

在這個基礎下,半秒鐘到一秒鐘的動畫效果對於短期記憶的影響其實非常大,所以花了些時間找看看怎麼關掉...

後來在「How can I disable animation when switching desktops in Lion?」這篇翻到,裡面主要有兩個方法,一個是用 command line 的方法,但我測了不會動 (在 10.14.3 上),另外一個方法是已經被整合進系統了:

改了以後快不少,但要習慣一下...

Percona 對於 PostgreSQL 使用 HugePages 的評論

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

Hi,

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 的人要記得更新...