[以管窺天] AWS RDS Query Thruoughput 太高.

公司的網站在改版後, 雖然使用同樣的database (Aurora RDS), 但一直有個奇怪的現象.
每秒的select 數一直偏高. 工程師猜測應該只是RDS 統計介面的一個Bug...

Well, 在Google 的幫忙下, 我們找到了一個Script(run in python)可以做這統計.
https://www.centos.bz/2015/02/analysis-mysql-general-log/



After the new version of web site launched, we found that the number of select/sec goes high all the time. The db is running on AWS Aurora service with MySQL compatible. Engineer of my department says that is an bug of RDS, while I dont think so. After the great 'Google', we found a tool that could help us what are the often-run statements.



預設這個script 會將所有的資料印出在螢幕上, 為了使用方便, 建議轉向寫入檔案來觀看,
下圖是我們主機執行的結果 (query 內文先馬賽克起來 *笑*)
嗯, 前幾名加起來跑了超過100萬次. (一小時內). 後面看來有不小的調整要進行啊.


By default the script directly shows the result on STDOUT, and we suggest you may using I/O redirection to check it.
The following screenshot(with mozaic mask, lol), tell us that the top queries run more than 1,000,000 times in an hour. well, we have lot's of things to do...

[以管窺天] AWS S3 Bucket 定期清除舊檔案

不少人都有使用S3 的經驗, 但無論個人或者企業, 除非不用考慮$$ 的問題, 否則盡可能把錢花在必要之處是一定會需要注意的項目.

有時候我們會把EBS內的某些資料(or 臨時開立的EC2 主機中臨時產生卻需要留下的資料)留在S3 中, 或甚至把CDN Log 也放在裡面, 確保資料可用.


但, 留在S3中的資料, 有時我們不想保留那麼久....
如果是在UNIX 環境, 許多老一點的人大概都用過類似的command.

ex: find /var/log/nginx -mtime +30 -exec rm -f {};

為了刪除s3的檔案, 理論上我們也可以用類似的做法, 只要
a. 以s3fs 之類的程式掛載s3 到主機上
b. 以crontab 執行類似的command
c. 等, 然後期望在下次crontab起來前能跑完, 不要出包

溫馨提示: s3 的速度一般來說不怎麼快, 傳輸不快是一回事, 小檔案的操作更是不快.


上述方法理論可行, 實際上建議別這麼幹, 真心不騙.

這邊分享另一個作法.
簡單的步驟是:
1. 找到該s3 bucket
2. 設定 'expiration' 的天數
3. 收工(驚)

就跟菲姐做菜一樣, 就是這麼簡單.

其中步驟2.
選到對應的bucket 後, 點選 [management] 這個tab.
[選擇] lifecycle.
[選擇] add new rule
[填寫] 你想要設定的rule name
[填寫] 檔案的到期日(檔案create 後幾天會刪除
[填寫] 上傳檔案如果不完整, 幾天後要刪除
到下一頁再看一眼, 存檔, 建立規則.

簡單吧?



後記: 2017.12.20 凌晨00:38 分, 我也開始進行實驗. 第一次增加了rule.
為了測試效果, 我先將expiration period 改為 1day, 後續再來update 實際測試結果.

2017.12.21 紀錄:

2017.12.26 update.
忙了好幾天沒時間看S3, 今天一看, 檔案怎麼都還在, 照參考文件[3] 的修改方法又調整了一次, 讓我們來試試看吧.

2017.12.28 update.
搞了半天是prefix 輸入錯了, 然後, 當啷~ 成功了 :D


參考文章:
1. http://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html
2. http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
3. https://aws.amazon.com/tw/blogs/aws/amazon-s3-object-expiration/

[以管窺天] AWS EC2 主機的硬碟I/O 速度. EC2 i系列主機的高 I/O 速度實際測試.

提供虛擬主機(EC2) 給廠商時,  廠商回覆需要EC2 主機有高的硬碟I/O 速度,
我們以AS SSD Benchmark 測試實際速度時, 卻發現EC2主機(m4.2xlarge) I/O 速度很不理想.
和預想的情況有相當大落差

經過了一些交叉測試以及討論後. 得知:

1. EBS 的速度, 除了Provisioned IOPS(目前Max IOPS 32,000)外, 也受到主機網路速度的影響. m4.2xlarge 主機基本上是1Gb Network, 所以基於網路提供服務的EBS 磁碟效能也受到主機端網路頻寬限制. 白話文, IOPS 開再高, 實際虛擬機對外頻寬不足也只是空花錢..


2. 如果要快, 可改以本機硬碟(ex: i系列主機),  效能就噴發.
   溫馨提示1: i系列的SSD 預設沒有掛載, 需要在作業系統中自己掛載、分割、格式化.
   溫馨提示2: i系列一樣有一個EBS磁碟, 請把工作區擺在快的硬碟, 不然也只是白花錢....

在i3.2xlarge 提供的SSD 上跑出的賽豬公分數

同一台i3主機 但使用預設的EBS 時賽豬公

最後提醒.  若僅是DB 需要I/O 快, 或許RDS 是比較合適的作法.
1. 價格可能較為划算(算上了單機服務要設定redundancy 的effort 時)
2. 如果有輪子沒必要自己刻..


參考資料:
EBS 規格