換成 t4g.small 後的一些整理

昨天在這邊提到因為 Amazon EC2t4g.small 提供了 free tier 方案 (到今年年底),blog 主機剛好從 t4g.micro 改成用 t4g.small,到年底前可以看看有沒有 t5g 或是類似的主機出來:「往上升級或是用 Unlimited mode 撐」。

除了換完後 CPU credit 給的量上升減緩了情況以外,我在檢查時才發現 PHPopcache 的 cache 使用量也超過預設值 128MB 了,改成 192MB 後看起來 CPU usage 也有下降一些:

這點算是先前沒注意到的,上面 PHP 跑兩個 WordPress 以及一個 MediaWiki (都掛了各式各樣的 plugin & extension),還有一個自己寫的小東西,這樣會超過 opcache 的 cache 大小...

現在換到 t4g.small 後總算又開始養的起 CPU credit 了:

另外也補上幾個 CloudWatch Alarms (看起來 free tier 是十個) 監控主機的 CPUCreditBalance,然後透過 AWS Chatbot 接到自己的 Slack 上,至少之後有狀況的時候會主動通知。

往上升級或是用 Unlimited mode 撐

這個 blog 跑在 Amazon EC2t4g.micro 上面,以往跑起來 baseline 是 10% CPU credit 也還算夠用,但最近的 loading 特別的大,發現是有 bot 在砍站砍的比較兇 (參考「t4g 的 CPU credit 被吃完了」這邊),雖然擋掉後有降不少,但看起來還是比之前高不少:(這邊是一天的平均,拉三個月資料來看)

以往這種一陣一陣的可以靠 CPU credit 頂過去,但因為先前 CPU credit 被 bot 砍完後沒了,就常常撞到底,只好先開 Unlimited mode 擋著了。

另外一方面,當初買的三年 RI 時間也快到了 (居然),這幾天差不多要處理了:

Start
February 9, 2021, 17:43 (UTC+8:00)

Expires
February 9, 2024, 17:43 (UTC+8:00)

升級到 t4g.small 剛好會符合 AWS 的免費方案,看起來可以先掙扎一陣子:

Until December 31, 2024, all AWS customers will be enrolled automatically in the T4g free trial as detailed in the AWS Free Tier. During the free-trial period, customers who run a t4g.small instance will automatically get 750 free hours per month deducted from their bill during each month.

我記得我算過但沒找到文章,所以這邊還是算一下... 如果 t4g.small 要錢的話,與 Unlimited mode 的消費差異大概是多少。

us-east-1t4g.small 是 $0.0168/hr,用 720 小時換算是 $12.096/mo。

假設 CPU 使用率平均在 15%,那用 t4g.micro 的 $0.0084/hr 會是 $6.408/mo,另外加上 5% * 2vCPU = 10% 的 Unlimited mode 費用 ($0.04/hr/vCPU),會是 $2.88/mo。

假設 CPU 使用率平均在 20% (剛好跟 t4g.small 的 baseline 相同的話),會是 $5.76/mo,所以如果用不到對應的記憶體的話,跑 Unlimited mode 會比較划算。

先開一張票。年底的時候再來看看當時的機種與優惠方案...

Jetpack 的備份功能失效

發現 1/13 後 Jetpack 就會一直發信通知備份功能失效,像是這樣:

連到 WordPress.com 上把語系改成英文,抓了一下問題發現錯誤訊息是:

We could not back up your site because it appears to be offline
Backup failed

用這個當關鍵字去找可以找到這篇:「13.0 and backups?」,照著裡面的方法把 Jetpack 降版到 12.9.3 後,隔天再看備份就正常了...

先把版本卡在 12.9.3,之後有新版再測試新版...

t4g 的 CPU credit 被吃完了

這個站 blog.gslin.org 掛了三個多小時:

先連機器 SSH 看起來是正常的,但習慣性的 w 看一下情況發現 CPU load 有 6.x,用 top 看一下就看到幾隻 php82-fpm 跑滿 CPU,心裡大概有底是被砍站了...

先把 nginx 停下來,瞄了一下 /var/log/nginx 下面的 log 就知道是 ClaudeBot 造成的,看起來都是從 AWSus-east-1 機器打過來的。

然後翻一下 log 看看什麼時候開始打的,先看 log 已經被 gzip 起來的這些:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log.{?,??}.gz | xargs -n1 | xargs -n1 -I% sh -c "echo %; zgrep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log.2.gz
  13031  169403 1986719
/var/log/nginx/blog.gslin.org_ssl-access.log.3.gz
    459    5967   85350
/var/log/nginx/blog.gslin.org_ssl-access.log.4.gz
  14533  188929 2219819
/var/log/nginx/blog.gslin.org_ssl-access.log.5.gz
   6502   84526 1026178
/var/log/nginx/blog.gslin.org_ssl-access.log.6.gz
  32483  422279 4905919
/var/log/nginx/blog.gslin.org_ssl-access.log.7.gz
  21304  276952 3221877
/var/log/nginx/blog.gslin.org_ssl-access.log.8.gz
   7921  102973 1199356
/var/log/nginx/blog.gslin.org_ssl-access.log.9.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.10.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.11.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.12.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.13.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.14.gz
      0       0       0

看起來是從 blog.gslin.org_ssl-access.log.8.gz 這邊開始的,大概是 1/25 開始 (機器上面是 UTC 時間):

-rw-r----- 1 www-data adm   1894325 Jan 26 00:00 /var/log/nginx/blog.gslin.org_ssl-access.log.8.gz

然後再來看一下最近的 log,看起來是這兩天打的特別重,到五萬多:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log{,.?} | xargs -n1 | xargs -n1 -I% sh -c "echo %; grep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log
  29436  382668 4387703
/var/log/nginx/blog.gslin.org_ssl-access.log.1
  51712  672256 7852345

拉了 AWS 的圖來看跟預期的差不多:

機器是 t4g.micro 而且沒開 burstable,先前差不多都是略低於 10% 的線在跑,剛好利用 CPU credit 的概念,這幾天看起來就是被打而跑上去。

好像該補一下 alarm,丟到我自己的 Slack 以及 Pushover...

拿許久沒用的 abpe.org 出來架 Mastodon

前幾天 Twitter 在搞事情,把未登入的存取方式都擋住了,所以本來透過 RSS-Bridge 的方式也被擋掉了,只好趕快研究 Mastodon 要怎麼架。

https://abpe.org/@gslin 這邊。

要先注意硬體需求,好像沒有文章特別獎,但實際測試後發現 2GB RAM 的 VPS 只是超級低標,光是跑起來就把 2GB 吃乾了,我測試的時候開 VPS (2GB RAM + 512MB swap) 才勉強撐住,swap 都已經吃到 400MB 左右。一開始開 1GB RAM 的時候直接 OOM 給你看...

現在是跑在家裡的機器上,8GB RAM 的機器上面跑個 Sentry + Mastodon 就差不多了。

文件的部分因為想要用 Docker Compose 跑,是參考「How to take advantage of Docker to install Mastodon」這篇跑起來的,把裡面 docker-compose.yml 使用的版本換新再跑,基本上沒有問題。

接下來就是找有誰已經在 Mastodon 上,要花時間訂起來...

WordPress 誕生 20 年

Matt Mullenweg 寫了一篇文章簡單提到 WordPress 誕生 20 年:「WP20 & Audrey Scholars」。

雖然 Matt Mullenweg 在文章裡都沒提到,但 WordPress 的興起其實跟當年 2004 年最大的 blog 軟體 Movable Type 自己出的包有很大的關係:

With the release of version 3.0 in 2004, there were marked changes in Movable Type's licensing, most notably placing greater restrictions on its use without paying a licensing fee. This sparked criticism from some users of the software, with some moving to the then-new open-source blogging tool WordPress. With the release of Movable Type 3.2, the ability to create an unlimited number of weblogs at all licensing levels was restored. In Movable Type 3.3, the product once again became completely free for personal users.

當年 hlb 在社團主機上用 Movable Type 架了服務讓大家寫,結果後來發生了 license 問題,大家就都順勢跑到 WordPress 上了;而等到 Movable Type 再次想放寬 license 的時候已經來不及了,大家都已經搬完了。

翻了一下最舊的文章 (在另外一個 WordPress 上) 是在 2004 年十月的時候寫的,就有提到當時從 Movable Type 換到 WordPress 的考量:「開場:為什麼用 WordPress」。

備份 Xuite Blog 的公開文章

中華的 Xuite 前陣子宣佈了服務中止的公告:「Xuite隨意窩平台服務終止公告」(這邊就先拉 Internet Archive 的連結了,看起來之後會消失...)。

Blog 的部份,除了作者本身可以拉資料下來放到其他平台以外,外人也可以把這些歷史遺跡保留下來,像是丟到 Internet Archive 的 Wayback Machine 上面。

所以用 Perl 寫了一隻 script,把 url 掃出來後,後續就可以用其他工具 submit 到 Wayback Machine 上面:「xuite-urldump」。

當年有不少 ACG 相關的 blog 在上面,先來備份起來...

WordPress 打算要支援 SQLite 作為後端資料庫

目前 WordPress 只有支援 MySQL,而昨天在 Hacker News 上看到 WordPress 有打算要支援 SQLite 作為後端資料庫的消息:「WordPress testing official SQLite Support (github.com/wordpress)」,原文在 GitHub 上:「Implement new experimental SQLite integration module」。

理論上對使用者會更方便,但對 extension 開發者會麻煩一些 (或是直接標不支援?),尤其是用到 MySQL 特有的語法就要注意了。

實質上 PHP + MySQL hosting 其實蠻常見的,這個作法有多少幫助就不知道了。

但突然想到,如果做一個 read-only 版本的 WordPress 站台,然後把 SQLite 的讀取部份改用 sql.js 之類的計畫,再把一堆 server side rendering 的部份變成 client side rendering,好像有機會可以整包直接上 GitHub Pages 之類的服務?雖然這樣有點拖褲子放屁...

又有 Blog Search Engine 了:Blog Surf

在「Show HN: Search Engine for Blogs (blogsurf.io)」這邊看到又有 blog search engine 了,叫做 Blog Surf

比較有趣的應該是留言裡面看到這個,已經掛掉的先人出來說,以前這個使用族群都是在打手槍的族群 XDDD

mgarfias 12 hours ago

We, sphere.com, did this starting in 2006. After a year or so, we realized the only people using the service were looking to stroke their egos.

Ice rocket, and something else (I can’t remember the name) tried it at the same time and failed.

We pivoted, which ended up leading to some unspeakable horrors.

At any rate, good luck, hope it works better for you.

回到 Blog Surf 來看,在 About 頁上提到了 MarketRank,基本上就是服務作者提出來的演算法:

Points are calculated using Market Rank. They are a measure of the popularity of a post across online communities. Blog points are simply the sum of a blog’s post points.

不是太看好但就觀察看看...

把 Blog 丟到 CloudFront 上

先前在「AWS 流量相關的 Free Tier 增加不少...」這邊有提到一般性的流量從 1GB/month per region 升到 100GB/month,另外 CloudFront 則是大幅增加,從 50GB/month (只有註冊完的前 12 個月) 提升到 1TB/month (不限制 12 個月),另外 CloudFront 到 EC2 中間的流量是不計費的。

剛剛花了點功夫把 blog 從 Cloudflare 搬到 CloudFront 上,另外先對預設的 /* 調整成 no cache,然後針對 /wp-content/* 另外加上 cache 處理,跑一陣子看看有沒有問題再說...

目前比較明顯的改善就是 latency,從 HiNet 連到免費版的 Cloudflare 會導去美國,用 CloudFront 的話就會是台灣了:

另外一方面,這樣國際頻寬的部份就會走進 AWS 的骨幹,比起透過 HiNet 自己連到美國的 PoP 上,理論上應該是會快一些...