連結: https://coolshell.cn/articles/21672.html 本篇文章是作者工作 20 年來的經驗分享文，內容非常好，提出了很多不同的觀點，由於是篇中文文章，所以就不幫忙節錄重點，直接列 文章中的十一個原則標題。 每個原則都非常精彩，文章底下的討論也滿有趣的。 原则一：关注于真正的收益而不是技术本身 原则二：以应用服务和 API 为视角，而不是以资源和技术为视角 原则三：选择最主流和成熟的技术 原则四：完备性会比性能更重要 原则五：制定并遵循服从标准、规范和最佳实践 原则六：重视架构扩展性和可运维性 原则七：对控制逻辑进行全面收口 原则八：不要迁就老旧系统的技术债务 原则九：不要依赖自己的经验，要依赖于数据和学习 原则十：千万要小心 X – Y 问题，要追问原始需求 原则十一：激进胜于保守，创新与实用并不冲突
連結: https://emmer.dev/blog/docker-shell-vs.-exec-form/
Docker 基本介紹文，不知道常寫 Dockerfile 的讀者能不能分清楚 Dockerfile 內 Shell 與 Exec 兩種格式的差異 RUN, CMD, ENTRYPOINT 等指令都同時支援這兩種格式 Shell 格式就是 RUN command arg1 arg2 arg3 這種直接描述的格式，而 Exec 則是用 [] 包起來，每個參數單獨敘述，譬如 RUN ["command", "arg1", "arg2", "arg3"] 等。 本篇文章推薦 RUN 指令採取 Shell 格式而 CMD/ENTRYPOINT 都應該採用 EXEC 格式。 如果自己不清楚差異以及沒有想法為什麼平常自己這麽寫的話可以參考全文
連結: https://linuxconfig.org/how-to-propagate-a-signal-to-child-processes-from-a-bash-script
基本 Bash 介紹文，探討 trap 的用法，如何於不同的情況下正確攔截 SIGNAL，同時如果 script 中運行的程式有無背景執行 會有什麼差異，推薦給對 Bash 不熟的讀者閱讀重新複習
連結: https://matduggan.com/mistakes/
本文是作者踩過的各種 Infrastructure 雷，希望讀者能夠避免這些雷。
總共有幾大類，分別
其中第六點簡短扼要，大概就是「沒有人知道如何正確地去安裝與打包你的 python apps, 你真的要寫一個內部的 python 工具就給我讓他完全跨平台不然就給我改用 go/rust, 不要浪費生命去思考到底該如何安裝那些東西」
這讓我想到你的 Python 跟我的 Python 每次都不一樣，有已經不支援的 python 2.x, 還有各種可能會互相衝突的 python 3.x....
連結: https://www.weave.works/blog/racy-conntrack-and-dns-lookup-timeouts
今天跟大家分享一個 UDP 於 Linux Kernel 內的 Race Condition 問題。這問題我以前於 Linux Kernel 3.14 也有採過一樣的雷，但是到今日都還沒有一個很漂亮的解決方案，這邊就快速的跟大家介紹一下這個問題> 是什麼，以及跟 k8s 有什麼關係
相同的 Client 短時間內透過 UDP (也許是不同 thread) 送出兩個 UDP 封包到外面，對於 Linux Kernel 來說，會希望透過 conntrack 來追蹤每一條連線，但是底層建立的時候會有一些會有一些機制，因此當兩個封 包同時進入的時候，有可能就會因為先後順序導致第二個封包被丟棄
DNS 的請求封包預設情況下會同時透過 UDP 送出 A & AAAA 兩個封包，而這兩個封包如果很巧的採到這個情況，然後你的 A 封包就沒有辦法順利解出 DNS，最後就要等五秒的 timeout 來重新發送 下偏這篇文章就是 weave works 遇到 DNS 5秒 timeout 的問題，然後仔細的將我上面所寫的總結給解釋清楚，每一個步驟發生什麼事情，什麼是 conntrack 以及暫時的 workaround 是什麼 之後會在跟大家分享目前一些解決方法怎麼做
連結: https://lwn.net/Articles/835962/
LWN.net 這幾天有一個文章是關於基於安全性考量下，改用其他工具取代 scp, 譬如使用 sftp 以及 rsync. 有常常使用 scp 這個工具的人可以看一下這篇文章討論的原因，以及如果要改成使用 rsync, 可以有什麼樣的參數使用
連結: https://erickhun.com/posts/kubernetes-faster-services-no-cpu-limits/
想必大家一定都有使用過 CPU Limit 的經驗，透過這個機制能夠確保每個 Container 使用的 CPU 資源量，也可以保證每個節點上面會有足夠 CPU 供 Kubernetes 原生服務 (kubelet) 使用。 然而本篇文章就要來跟大家分享一個設定 CPU Limit 反而造成效能更差的故事，故事中當 CPU 設定為 800ms 的時候，卻發現實際運行的 Container 最高大概就只有 200ms 左右，這一切的一切都是因為 Liniux Kernel 的臭蟲導致! 一個直接的做法就是針對那些本來就沒有過高 CPU 使用量服務取消其 CPU Limit，作者於文章中也探討了一些機制要如何保護與應對這些被移除 CPU 限制的服務。 這個臭蟲於 Linux Kernel 4.19 後已經修復，但是要注意你使用的發行版本是否有有包含這個修復，作者列出一些已知的發行版本修復狀況 Debian: The latest version buster has the fix, it looks quite recent (august 2020). Some previous version might have get patched. Ubuntu: The latest version Ubuntu Focal Fosa 20.04 has the fix. EKS has the fix since December 2019, Upgrade your AMI if necessary. kops: Since June 2020, kops 1.18+ will start using Ubuntu 20.04 as the default host image. GKE: THe kernel fix was merged in January 2020. But it does looks like throttling are still happening.
blktrace is a block layer IO tracing mechanism which provide detailed information about request queue operations up to user space.
blkparse will combine streams of events for various devices on various CPUs, and produce a formatted output the the event information. It take the output of above tool blktrace and convert those information into fency readable form.
In the following, We will use those tools blktrace and blkparse to help us to observe sector numbers which has been written by fio requests. We will use the fil to generate two diffenrt IO pattern requests, sequence write and random write.
OS: Ubuntu 14.04 Storage: NVME FIO: fio-2.19-12-gb94d blktrace: 2.0.0 blkparse: 1.1.0
you can use following commands to install blktrace and blkparse
apt-get install -y blktrace
In order to make the output of blkparse more easily to read, we set the numjobs to 1. Following is my fio config
[global]
iodepth=256
numjobs=1
direct=1
time_based
runtime=120
group_reporting
size=5G
ioengine=libaio
filename=/dev/nvme1n1
[rw]
bs=4k
rw=randwrite
[sw]
bs=64k
rw=write
After we setup the fio config, use the fio to generate the IO request. In this example, we ask the fio to generate the IO via sequence write pattern.
fio ${path_of_config} section=sw
During the experiment, you can use the tool iostat to monitor the I/O information about the device we want to observe.
Open other terminal and use blktrace to collection the data, there are two parameter we need to use,
First one is -d, which indicate what target device blktrace will monitor to.
Second, is -w, we use it to limit the time (seconds) how long blktrace will run.
So, our final command looks like below.
blktrace -d /dev/nvme1n1 -w 60
In the end of blktrace, you can discover some new files has created by blktrace and its prefix name is nvme1n1.blktrac.xx The number of files is depends how may CPUs in your system.
-rw-r--r-- 1 root root 821152 Jun 2 10:39 nvme1n1.blktrace.0
-rw-r--r-- 1 root root 21044368 Jun 2 10:39 nvme1n1.blktrace.1
-rw-r--r-- 1 root root 462864 Jun 2 10:39 nvme1n1.blktrace.10
-rw-r--r-- 1 root root 737960 Jun 2 10:39 nvme1n1.blktrace.11
-rw-r--r-- 1 root root 865872 Jun 2 10:39 nvme1n1.blktrace.12
-rw-r--r-- 1 root root 755248 Jun 2 10:39 nvme1n1.blktrace.13
-rw-r--r-- 1 root root 4675176 Jun 2 10:39 nvme1n1.blktrace.14
-rw-r--r-- 1 root root 4471480 Jun 2 10:39 nvme1n1.blktrace.15
-rw-r--r-- 1 root root 5070264 Jun 2 10:39 nvme1n1.blktrace.16
-rw-r--r-- 1 root root 5075040 Jun 2 10:39 nvme1n1.blktrace.17
-rw-r--r-- 1 root root 5062104 Jun 2 10:39 nvme1n1.blktrace.18
-rw-r--r-- 1 root root 5586936 Jun 2 10:39 nvme1n1.blktrace.19
-rw-r--r-- 1 root root 3718848 Jun 2 10:39 nvme1n1.blktrace.2
Now, we can use the blkparse to regenerate human-readable output form the output we get via blktrace before.
We need to indicate source files, you can just use the device name without .blktrace.xx, for example, nvmen1, it will search all files which match the pattern nvmen1.blktrace.xx and put together to analyze. Then, the -f option used to foramt the output data, you can find more about it via man blkparse
OUTPUT DESCRIPTION AND FORMATTING
The output from blkparse can be tailored for specific use -- in particular, to ease parsing of output, and/or limit output fields to those the user wants to see. The data for fields which can be output include:
a Action, a (small) string (1 or 2 characters) -- see table below for more details
c CPU id
C Command
d RWBS field, a (small) string (1-3 characters) -- see section below for more details
D 7-character string containing the major and minor numbers of the event's device (separated by a comma).
e Error value
m Minor number of event's device.
M Major number of event's device.
n Number of blocks
N Number of bytes
p Process ID
P Display packet data -- series of hexadecimal values
s Sequence numbers
S Sector number
t Time stamp (nanoseconds)
T Time stamp (seconds)
u Elapsed value in microseconds (-t command line option)
U Payload unsigned integer
For our observation, we use %5T.%9t, %p, %C, %a, %S\n to format our result containing timestamp, command, process ID, action and sequence number.
Since the data I/O contains many action, such as complete, queued, inserted..ect. we can use option -a to filter actions, you can find more info via man blktrace. In this case, we use the write to filter the actions.
In the end, use the -o options to indicate the output file name.
barrier: barrier attribute
complete: completed by driver
fs: requests
issue: issued to driver
pc: packet command events
queue: queue operations
read: read traces
requeue: requeue operations
sync: synchronous attribute
write: write traces
notify: trace messages
drv_data: additional driver specific trace
The command will look like below and it will output the result to file output.txt.
blkparse nvme1n1 -f "%5T.%9t, %p, %C, %a, %S\n" -a write -o output.txt
open the file, the result looks like
0.000000000, 22890, fio, Q, 1720960
0.000001857, 22890, fio, G, 1720960
0.000005803, 22890, fio, I, 1720960
0.000009234, 22890, fio, D, 1720960
0.000036821, 0, swapper/0, C, 1996928
0.000067519, 22890, fio, Q, 1721088
0.000068538, 22890, fio, G, 1721088
0.000071531, 22890, fio, I, 1721088
0.000073102, 22890, fio, D, 1721088
0.000093464, 0, swapper/0, C, 1994624
0.000123806, 0, swapper/0, C, 1785472
0.000147436, 22892, fio, C, 1784576
0.000159977, 22891, fio, C, 1997312
0.000166653, 22891, fio, Q, 2006912
0.000167632, 22891, fio, G, 2006912
0.000169422, 22891, fio, I, 2006912
0.000171178, 22891, fio, D, 2006912
0.000188830, 22892, fio, Q, 1817728
0.000189783, 22892, fio, G, 1817728
0.000191405, 22892, fio, I, 1817728
0.000192830, 22892, fio, D, 1817728
0.000202367, 22891, fio, Q, 2007040
0.000203160, 22891, fio, G, 2007040
0.000205969, 22891, fio, I, 2007040
0.000207524, 22891, fio, D, 2007040
0.000227655, 22892, fio, Q, 1817856
0.000228457, 22892, fio, G, 1817856
0.000231936, 22892, fio, I, 1817856
....
Since the fio will fork to two process to handle the process, we use the grep to focus on one specific process (pid=22892).
grep "22892, fio" output.txt | more
Now, the result seems good, we can discover the sequence number (fifth column) is increasing. One thing we need to care about is the row which action is "C", which means the completed, since we don't know how NVME handle those request and reply to upper layer. we only need to focus on other action. such as "Q (queued This notes intent to queue i/o at the given location. No real requests exists yet.)" or "I (inserted A request is being sent to the i/o scheduler for addition to the internal queue and later service by the driver. The request is fully formed at this time)".
0.000147436, 22892, fio, C, 1784576
0.000188830, 22892, fio, Q, 1817728
0.000189783, 22892, fio, G, 1817728
0.000191405, 22892, fio, I, 1817728
0.000192830, 22892, fio, D, 1817728
0.000227655, 22892, fio, Q, 1817856
0.000228457, 22892, fio, G, 1817856
0.000231936, 22892, fio, I, 1817856
0.000233530, 22892, fio, D, 1817856
0.000360361, 22892, fio, Q, 1817984
0.000361310, 22892, fio, G, 1817984
0.000364163, 22892, fio, I, 1817984
0.000366696, 22892, fio, D, 1817984
0.000536731, 22892, fio, Q, 1818112
0.000537758, 22892, fio, G, 1818112
0.000539371, 22892, fio, I, 1818112
0.000541407, 22892, fio, D, 1818112
0.000670209, 22892, fio, Q, 1818240
0.000671345, 22892, fio, G, 1818240
0.000673383, 22892, fio, I, 1818240
0.000676260, 22892, fio, D, 1818240
0.001885543, 22892, fio, Q, 1818368
0.001887444, 22892, fio, G, 1818368
0.001891353, 22892, fio, I, 1818368
0.001895917, 22892, fio, D, 1818368
0.001934546, 22892, fio, Q, 1818496
0.001935468, 22892, fio, G, 1818496
0.001936891, 22892, fio, I, 1818496
0.001938742, 22892, fio, D, 1818496
0.001965818, 22892, fio, Q, 1818624
Now, we can do all above command again and change the section to rw for fio using the randon write pattern. The blkparse result will show the random sequence number.
In this article, we try to use tools blktrace and blkparse to analysiz the block level I/O for fio request. We observe the filed sequence number to make sure thhat the fio can generate the sequence or random according to its config.
本文主要嘗試分析 drbd(9.0) 於 kernel運行時的效能分析，希望藉由 perf 這個 tool 來分析整個程式運行的狀況，藉此觀察其運行時各 function 的比例。
為了進行效能上的分析，首要條件就是先將 DRBD 給衝到效能瓶頸才有機會去觀察，所以本文採用下列的環境與工具來進行這項作業
CPU: Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz Storage: Non-Volatile memory controller(NVME) Tool: fio OS: Ubuntu 16.04 with linux 4.4.0-78-generic
為了更方便觀察 drbd 的運行，我們將 drbd 創造的 kernel thread 都分別綁在不同的 cpu 上，這樣可以讓每隻 kernel thread 盡可能去使用cpu。
ps or htop 取得 kernel thread 的 pid,這邊可以關注的有taskset 這個指令將上述程式分別綁到不同的 cpu 上taskset -p 0x100 18888
...
本文使用 fio 來進行資料的讀取，下方提供一個簡易的 fio 設定檔，可依照自行的環境變換修改。
[global]
iodepth=512
numjobs=3
direct=1
time_based
runtime=30
group_reporting
size=5G
ioengine=libaio
filename=/mnt/beegfs/fio1.test
[rrw]
bs=4k
rw=randrw
rwmixread=75
[rr]
bs=4k
rw=randread
[rw]
bs=4k
rw=randwrite
[sr]
bs=64k
rw=read
[sw]
bs=64k
rw=write
我們 fio 採用 client/server 的架構，要是可支援多台 client 同時一起進行資料讀取，提供更高的壓力測試。
假設該設定檔名稱為 fio.cfg，並且放置於 /tmp/fio.cfg 則首先在 node-1 上面執行下列指令以再背景跑一個 fio server
fio -S &
接下來要運行的時候，執行下列指令來運行 fio，其中若想要改變測試的類型，可透過 --secion進行切換。
/fio --client=node-1 /tmp/fio.cfg --section=rw
這時候可以透過 htop 以及 iostat 的資訊去觀察，如下圖
當前透過 iostat 觀察到的確對 drbd0 有大量的讀寫動作
同時由 htop (記得開啟 kernel thread觀察功能)，可以看到 drbd_s_r0 以及 drbd_a_r0 都各自吃掉一個 cpu，大概都快接近 100% 的使用率。
有了上述的環境後，我們就可以準備來分析 drbd 程式碼運行狀況。
這邊使用 perf 這套程式來分析，基本上 kernel 新一點的版本都已經內建此功能了，比較舊的 kernel 則需要自己重新開啟該 kernel config然後重新 build kernel，所以這邊使用 Ubuntu 16.04 with linux 4.4.0-78-generic 相對起來非常簡單。
直接執行 perf 這個指令，若系統上有缺少 linux-tools-4.4.0-78 相關 tool 的話會有文字提示你，如下所示，按照提示使用 apt-get 將相關的套件安裝完畢後，就可以使用 perf 了。
WARNING: perf not found for kernel 4.4.0.78
You may need to install the following packages for this specific kernel:
linux-tools-4.4.0-78-4.4.0-78
linux-cloud-tools-4.4.0-78-4.4.0-78
perf 的功能非常強大，可以參考 wiki, 這邊我們使用 perf top 的方式來觀察結果。
為了可以順便觀看 call graph 的過程，再執行perf的時候要多下-g這個參數
指令為 perf top -g -p $PID，如 perf top -g -p 18888。
在這邊我嘗試觀察 drbd_a 這隻，結果如下列
這邊可以觀察到三隻吃比較兇的 function 都吃很兇,分別是 native_queue_spin_lock_slowpath 、 tr_release 以及 idr_get_next。
這邊比較麻煩的是你看這個只能知道就是卡在 spin_locK，系統上是不是 multithread，然後有太多的資料要搬移導致 spin_lock ? 這些搬移的資料是誰放進去的?，這些資料是什麼?
以及更多的問題都必須要看程式碼去理解其整體設計架構，才有辦法講出一套完整的流程說明這個結果。
這部份等之後能夠完整理解整個 drbd 的 write-path 或是 read-path 時再重新來看一次這張圖，到時候應該會有完全不一樣的思維。
有時候根據應用需求，會需要針對去檢查目前系統上有哪些port正在被使用
#[FreeBSD]
可以使用 sockstat 這個command 來檢查系統上port的使用。
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root cron 93468 4 udp4 :638 :*
在預設的情況下，會輸出
使用者名稱，執行的程序，該程序的pid，在該程序中使用該port的file descriptor是多少 使用何種協定，以及address
如果使用 sockstat -4lP tcp 就可以找出 使用tcp & ipv4 ，並且正在listen的port
這對於要尋找是否有人在寫Socket programming來說是很方便的。
詳細的可以man sockstat
#[Linux] 可以使用 netstat 這個工具來檢視，搭配一些參數還可以看到該 port 被那些 process 使用
netstat -anptn
tcp 1 0 127.0.0.1:40147 127.0.0.1:36524 CLOSE_WAIT 7147/vim
tcp 1 0 127.0.0.1:58289 127.0.0.1:52849 CLOSE_WAIT 19421/vi
...
#[Windows]
可以使用netstat來檢視，netstat能夠顯示的資訊非常的多，為了精簡我們的需求，必須去過濾這些資訊
在windows上使用find這個指令，類似於UNIX中grep的功能
舉例來說，netstat -an |find /i “listening" 這個指令
netstat -an 會顯示所有連線以及正在監聽的port，並且以數字的形式來顯示IP以及PORT
find /i “listening" 則會以不區分的方式去搜尋每一行，若包含listening則將該行印出
EX:
TCP 192.168.1.116:139 0.0.0.0:0 LISTENING
TCP 192.168.1.116:49156 216.52.233.65:12975 ESTABLISHED