Monthly Archives: February 2019

Python 上觀察 Memory Leak

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

首先是先看正常與疑似異常的分析:

然後可以拉出資料型態資訊:

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

Cloudflare 發表 Logpush,把 log 傳出來

Cloudflare 推出了 Logpush,可以把 log 傳到 Amazon S3 或是 Google Cloud Storage 上 (目前就支援這兩個):「Logpush: the Easy Way to Get Your Logs to Your Cloud Storage」,目前是 enterprise 方案可以用:

Today, we’re excited to announce a new way to get your logs: Logpush, a tool for uploading your logs to your cloud storage provider, such as Amazon S3 or Google Cloud Storage. It’s now available in Early Access for Enterprise domains.

Logpush currently works with Amazon S3 and Google Cloud Storage, two of the most popular cloud storage providers.

以往是自己拉,需要考慮 HA 問題 (兩台小機器就可以了,機器成本是還好,但維護成本頗高),現在則是可以讓 Cloudflare 主動推上來...

我大多數的建議是 log 儘量留 (包括各種系統的 log 與 http access log)。主要是因為儲存成本一直下降 (S3 的 1TB 才 USD$23/month,如果使用 Glacier 會低到 USD$4/month),而且 log 在壓縮後會變小很多 (經常會有重複的字)。

最傳統的 AWStats 就可以看到不少資訊,如果是透過 IP address 與 User-agent,交叉配合其他 event data 就可以讓很多 machine learning 演算法取得的資訊更豐富。

Hacker News 官方提供的回朔功能

如果要找 Hacker News 的歷史記錄,通常會去 Hacker News Daily 上翻,這邊可以翻到每天 top 10 的記錄,對於比較基本的情境下應該是夠用,但對於想要更多資料的人可能不太夠。

剛剛看到官方直接提供了對應的功能,在「https://news.ycombinator.com/front」這邊算是入口,選個連結後會變成「https://news.ycombinator.com/front?day=2019-02-23」這樣的 url,然後舉一反三可以直接改參數設定對應的日期,這樣就可以以日為單位看到當天的頁面。

算是補個歷史記錄的功能...

開源的語音助理 Leon

目前的語音助理都會把資訊傳回到中央伺服器,而 leon-ai/leon 則是希望在本地端解決:

Leon is an open-source personal assistant who can live on your server.

He does stuff when you ask him for.

You can talk to him and he can talk to you. You can also text him and he can also text you. If you want to, Leon can communicate with you by being offline to protect your privacy.

作者錄了一段目前版本的功能,可以看到語音輸入與分析運作的還不錯:

看到 1.0.0 beta,最近應該會釋出正式版,接下來就是看可以掛什麼 plugin 進去讓他更好用?

開始把一堆網域轉到 Cloudflare 上...

看到「Cloudflare Registrar at three months」這篇文章,然後前幾天剛好也有其他人提到轉到 Cloudflare 的事情,就把手上的網域也轉一轉...

轉過來最主要的原因還是價錢,另外也是因為都掛進 Cloudflare 了,直接把註冊商掛在 Cloudflare 上有很多設定會比較簡單。

批次轉移界面做的還不錯,系統會先把帳號內的網域都列出來,然後依照註冊商歸類後給你填 auth code,之後開始轉就會收到確認信,確認後就都過去了。不過還是有些沒收到確認信,不知道是不是等五天...

另外一個是信用卡的部份,元大的 JCB 刷不過 (不過元大的系統擋很凶似乎是用這張的人都知道了...),改用富邦的 VISA 一刷下去就過了,但是轉 n 個網域就產生了 n 筆交易,然後就接到銀行的關切電話了...

雖然支援了 246 個 tld,但目前 *.tw 還不能轉,先把其他的轉過來了...

PostgreSQL 對 fsync() 的修正

上次寫了「PostgreSQL 對 fsync() 的行為傷腦筋...」提到 fsync() 有些地方是與開發者預期不同的問題,但後面忘記跟進度...

剛剛看到 Percona 的人寫了「PostgreSQL fsync Failure Fixed – Minor Versions Released Feb 14, 2019」這篇才發現在 2/14 就出了對應的更新,從 release notes 也可以看到:

By default, panic instead of retrying after fsync() failure, to avoid possible data corruption (Craig Ringer, Thomas Munro)

Some popular operating systems discard kernel data buffers when unable to write them out, reporting this as fsync() failure. If we reissue the fsync() request it will succeed, but in fact the data has been lost, so continuing risks database corruption. By raising a panic condition instead, we can replay from WAL, which may contain the only remaining copy of the data in such a situation. While this is surely ugly and inefficient, there are few alternatives, and fortunately the case happens very rarely.

A new server parameter data_sync_retry has been added to control this; if you are certain that your kernel does not discard dirty data buffers in such scenarios, you can set data_sync_retry to on to restore the old behavior.

現在的 workaround 是遇到 fsync() 失敗時為了避免 data corruption,會直接 panic 讓整個 PostgreSQL 從 WAL replay 記錄,也代表 HA 機制 (如果有設計的話) 有機會因為這個原因被觸發...

不過也另外設計了 data_sync_retry,讓 PostgreSQL 的管理者可以硬把這個 panic 行為關掉,改讓 PostgreSQL 重新試著 fsync(),這應該是在之後 kernel 有修改時會用到...

「歡樂」的 USB cable...

在這邊看到的,把整個惡意晶片藏在 USB cable 裡面,讓攻擊者可以透過 Wi-Fi 控制主機的 O.MG Cable:「WiFi Hides Inside a USB Cable」。

是個大家都有想過的情境,不算是特別的技術,困難點在於空間有限 (要藏在接頭裡面),現在有人做出 prototype 了... 在 demo 影片內可以看到可以透過 Wi-Fi 開啟主機本身的 browser 並且連線,不知道是模擬鍵盤還是其他方式做的?

Internet 上的 3rd party js 的情況

Twitter 上看到這則:

裡面提到了「patrickhulce/third-party-web」的分析 (作者是從 HTTP Archive 的資料分析),裡面依照不同種類的 3rd party js (像是 ad,或是 social element,或是分析工具) 需要執行的時間,以及使用的站台數量。

Social 那邊意外看到 PIXNET 有上去,然後速度只比 Disqus 快一些,應該是沒有 optimize 的關係。

如果整體一起看的話 (總和花費時間),可以看到 Google 各項產品都在最前面,畢竟裡面每個項目都是被廣泛使用的。

WireGuard 上 macOS 了...

在「WireGuard for macOS」這邊看到 WireGuard 進到 Apple 家的 Mac App Store 了。

除了是透過 app store 下載外,另外的重點在於整合了 NetworkExtension API

This is built from the same code base as our existing iOS app and makes use of Apple's Network Extension API to provide native integration into the operating system's networking stack.

這樣可以確保相容性,而且可以用內建的 VPN 機制管理。另外也給了一些 screenshot 可以看,可以看出來就是走 Mac 上的管理方式: