2016/02/04

xargs -P 在 stdout 可能會遇到 race condition

爬 log 發現 log 格式不正確,而且還是經常發生,而手動追蹤時又找不到錯誤在哪裡:
find . -name '*2016-01*.log.gz' | xargs -I'{}' -P 4 zgrep keyword {} | awk ...

做了測試以後才發現 xargs -P 時,各個 process 只要有 stdout 就會和其他 process 打架,造成資料還沒寫完就被其他 process 插單,導致最後出來的資料不正確。



先建立二個檔案,儲存不同的二個資料。

0.test.log (每行 50 字):
.................................................
.................................................
.................................................
....

1.test.log (每行 50 字):
1111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111
...


接下來使用 xargs 來 echo 這二個檔案內容:
find . -name '*test.log' | xargs -I'{}' -P 2 cat {} > output.xargs.log

接下來寫個 script 來檢查 output.xargs.log 的內容是否都正確:
for LINE in `cat output.xargs.log `; do
    if [ 50 -lt ${#LINE} ]; then
        echo $LINE
    fi
done

結果會發現 output 有一行超過 50 個自得情況發生:
111111111111111111111111111111111111.................................................

而相同的情況下,parallel 就不會有相同的情況發生:
find . -name '*test.log' | parallel -j 2 cat {} > output.xargs.log

原因是 parallel 會將 jobs (process) 的 output 先 buffer 起來,等到整個 job 都結束以後在一起送到 stdout。若使用上述的範例改用 parallel 的操作來測試的話,可以發現不同 job 的 output 有被完全區隔開來,沒有混在一起:

...
.................................................
.................................................
.................................................
1111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111
...


總之,以後用到 xargs -P 時,要小心 race condition ... (暈)

2015/11/10

特定情況下 PHP 可以比 awk 還要快

因為工作上的需要,會需要將 HTTP log 抓出來做統計,所以會遇到類似下方的 RESTful path:
GET /user/123/bio HTTP/1.1 ...
GET /user/456/bio HTTP/1.1 ...

如果取完整的 path 則無法辨別後端到底是使用哪一個 API,所以使用 awk 的 regex 辨識後 mapping 到 API 名稱上。寫完以後的 awk script 大約有 300 行左右,一份 log 大概要花 2 分鐘左右。

後來經高人指點,PHP 的 native library 好歹也是 C++ 寫的,理論上不會太慢,於是用 PHP 的 preg_match() 將相同的邏輯寫了一次。同一份 log 使用 PHP 來 parse 大約只需要 1 分 32秒。

另外 PHP 預設會載入已安裝的 extensions (mysql, mcrypt ...),既然只用到 native library 的話,其實這些也可以去掉不要用。改為「php -n」不載入任何 extension 再執行時,速度又快了一些,只要約 1 分鐘。

PHP 其實還有一些可以繼續調整的東西,像是把資料放在陣列裡面做搜尋時,如果把資料存成 array index 並使用 array_key_exists() 方式去判斷,會比 in_array() 還要更快 [Ref]

2015/11/09

同時追蹤多個 log 檔

通常我們會用「tail -f FILE」來將檔案新增加的內容顯示在螢幕上,不過要同時顯示多個檔案的新資料就有點麻煩了,會需要改成以下寫法:
tail -f FILE_1 -f FILE_2 ....

所以有人寫了個歡樂的工具叫做「multitail」可以一次監視多個檔案,甚至還會自動幫你切割視窗來顯示不同檔案的內容。

要做到同上的功能,只要這樣寫:
multitail FILE_1 FILE_2

若要觀察的檔案太多,多到分割視窗根本看不到東西時,也可以讓 multitail 不要做切割,全部顯示在一起就好:
 multitail --mergeall FILE_1 FILE_2

2015/09/16

寫 shell script 的一些平行處理工具

最近在處理數十 TB 的 HTTP server log 有感,記錄一些可以拿來做分散式運算的工具以及語法 (參數)。



gzip 一直是你的好工具,特別是儲存空間放在網路上時,可以大幅的減少讀取、寫入資料時所需要的 throughput。不過 gzip 一次只會用到一個 CPU core 壓縮資料,所以有人寫了 pigz ,在壓縮時建立多個 thread 同時運算。

還有不少針對 gz 的工具可以使用,像是:zcat、zgrep 和 zless (這超神奇,其實打 less 好像就會自動偵測是不是 gz 了  XD)


parallel


之前的筆記參考一下即可。


sort


排序大量資料也是會耗掉相當多的時間,幸好 sort 內建平行運算功能,只要加個參數即可。

$ sort --parallel=8 -S 4G unsort.list > sorted.list

「--parallel」可以指定要同時多少資源做排序,而「-S」則是設定要使用多大的記憶體來做排序。



xargs


感謝 Joe Horn 和 Wen-Shih Chao 提供指點,xargs 也有 parallel 的功能。使用「-P」參數就可以讓 xargs 自動做平行處理。

ls *.log | xargs -P 8 grep PATTERN




目前最常用的是這幾個,其他的就待以後用到慢慢補上。若有更好的做法也歡迎分享~

2015/08/24

語音通訊服務之差異與比較

最近常常開會,使用了各種不同的語音通訊服務,各有其優缺點和限制。做個筆記,以後可以依照不同的需求使用特定的特定的服務。


Hangouts:

  • 語音通訊同時通訊人數為 10 人
  • 有螢幕分享、白板、文件協作等功能
  • 音訊品質較差,容易有回音或是有雜訊

Skype:
  • 語音通訊人數好像沒上限 (目前沒遇到)
  • 有螢幕分享功能,但是超過 10  人就無法使用
  • 音訊較好,較少有雜音或回音 (大推)

LINE:
  • 音訊不差,但是時間延遲有時候會超過 3 秒鐘 (無法對話)
  • 請專心作貼圖服務

Steam:
  • 不是開玩笑的,Steam 的為了遊戲中的溝通,語音通訊不算差
  • 大家都需要有 Steam 帳號,小麻煩
  • 沒有螢幕畫面分享 (?)
  • 同時通訊的人數似乎不多 (不確定上限多少人)


不曉得還有沒有其他可以作為線上音訊討論的工具?真的有大量需求的話,其實花錢買解決方案應該也是可以的