ref: https://cmdchallenge.com/#/hello_world
今天分享的是一個有趣的 Command Line Interface(CLI) 挑戰,該挑戰主要是基於 Linux bash 的環境有一系列的指令挑戰
挑戰內容基本上都不會太困難,一開始都是非常基礎的 Linux 指令操作,後面會需要使用 grep, sed, awk, find 等不同指令的組合來完成任務。
大部分的題目都會基於一些情境,譬如想要針對 httpd server 底下的 log 進行過濾,計算符合某些內容的行數等等
每道題目除了自行挑戰外也可以看一下別人的解決方案,不過解決方案中有一些是作弊的內容,譬如直接針對題目用 echo 輸出之類的,就滿搞笑的。
我認為這類型的挑戰有兩個值得去玩看看的理由
1. 測試自已是否能夠解決每一個問題,順便看一下自己的解決方式跟別人的比起來如何,有時候會有一些意想不到的指令與用法可以讓整個寫法更為簡潔
2. 如果有面試需求的時候,可以考慮從這邊找一些相關題目,看看面試者對於 shell script 的熟悉度,同時互相討論每個解法的好壞處。
歡迎愛寫 shell script 的人都寫一遍看看
linux基本指令 在 矽谷牛的耕田筆記 Facebook 的精選貼文
本文延續前篇效能校正的經驗談,上篇文章探討了關於Locality與中斷中可以最佳化的部分,。本篇文章將繼續剩下最佳化步驟的探討。
The Case of the Nosy Neighbor
從前述最後的火焰圖中,作者觀察到幾個跟網路有關的 kernel call,譬如 dev_queue_xmit_nit 以及 __netif_receive_skb_core 等有可能有成長的空間,於是輾轉前往這邊去研究。
作者觀察到 packet_rev 這個函式有不少的比例,而該函式的意思是有人嘗試透過使用 AF_PACKET 等方式開啟了 RAW socket 來處理封包。透過 ss 這個指令,作者觀察到系統中有其他的應用程式透過 AF_PACKET/SOCKET_RAW 也在處理封包,最後輾轉發現原來是系統上的 dhclient。
DHCP Client 必須要在系統有 IP 以前就有收送封包的能力,所以使用 AF_PACKET 也滿合理的。作者思考是否有辦法可以讓 DHCP Client 拿到 IP 之後就關閉 AF_PACKET,改使用純 UDP 的方式來進行後續的 DHCP Renewal 功能,可惜這個方向沒有辦法達成。
根據 AWS 的官方文件,當一個 IP 被分配到一個機器後,這個 IP 會跟該機器同生死,因此這種情況下 其實不需要透過 DHCP Renewal 來反覆取得 IP,只要取得一次 IP 即可。
作者變修改相關腳本,當 DHCP 取得 IP 後關閉 dhclient,此外還必須要記得去修改網卡層級關於該 IP 的記憶,預設期間是一小時,作者將其修改為永遠。
透過這樣簡單的設定,整體的效能又再度提升了 6%,從 1.06M req/s 提升到 1.12M req/s
The Battle Against the Spin Lock
作者陳述自己花了非常多時間與 Spin Lock(作者心魔的大白鯨) 奮戰,幾乎是茶不思飯不想的滿腦都在思考如何加速,然後再經歷過反反覆覆的失敗後,作者最後決定還是要寫出一些關於 Spin Lock 的嘗試與研究心得,算是一個很精彩的踩雷心得。
這部分的篇幅很長,而且內容也滿深的,最後的解決方式也只有提升 2%左右的效能,所以對這部分有興趣的讀者再自行閱讀囉
This Goes to Twelve
終於來到最後的最佳化步驟了,這個步驟中的範疇都只能勉強壓榨出些許的效能,包含了關閉 GRO, TCP壅塞控制以及靜態中斷處理。
(Generic Receive Offload)GRO 是一個網路相關的功能,目的是用來將 Kernel 層級的封包給聚合起來變成一個大封包,而 Kernel 收到這個封包後會把該大封包重新組合變成本來的小封包,對於使用者的應用程式來說不會有任何感覺,但是對於整體的封包傳輸來說能夠節省花費的並提升效能。大部分情況下這個功能都是開啟的,Amazon Linux 2 預設也是打開這個選項。
然而針對作者的測試情境,由於所有的封包基本上都是同一條連線且資料量也不大,因此 GRO 雖然可以帶來聚合的效果,但是也會拖延封包進入到 Linux Kernel Network Stack 的時間點,因此開啟 GRO 帶來的好處沒有很大。
TCP 壅塞控制有不同的演算法,Amazon Linux2 內建兩種演算法 Cubic 以及 Reno,除此這兩個之外常見的還有 Google 多年前貢獻的 BBR。根據作者測試,其實驗環境中有比較好效能的則是 Reno
註: 不同算法針對不同應用場景,所以要切換演算法前要先釐清自己的應用情境以及用哪種演算法比較合適。
全部零零總總的修改後提升了 4%,整體的效能服務來到了 1.2M reqs/s
這篇文章真的很長,有些最佳化的方式是針對該應用場景而特別去使用的,這也意味者並非所有的修正方式都可以套用到各位的應用程式。
本篇文章還是很值得一讀,整個分析的思路與想法都非常有趣,雖然不一定用得到但是也許未來有一天會有機會使用。
https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/
linux基本指令 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
本篇文章是一個技術探討文,探討 Docker 是如何使用硬碟空間以及當維運人員發現空間不足時應該要如何清理系統上的空間。
Docker 的便利使用方式使得開發人員可以非常簡的透過的 Container 的概念來運行各式各樣的應用程式,這中間牽扯包含 Image 的建置,抓取以及透過其產生出一個運行的 Container。
隨者時間愈用愈久,系統內可用的空間也會愈來愈少,這時候可以透過 docker system df 來觀看一下目前系統上的空間資訊,主要包含下列四種類型,而每個類型也會包含目前使用量以及可以回收的量有多少
1. Images
2. Containers
3. Local Volumes
4. Build Cache(只有 docker 18.09 後使用 buildkit 才會有)
當 Contaienr 被創建時, /var/lib/docker 底下會有很多檔案以及資料夾都被創建出來,譬如
- /var/lib/docker/containers/ID (資料夾):如果 container 使用的是預設的 logging driver,則 log 檔案都會以 JSON 的格式存放於這個資料夾底下。
所以要注意,當 contaienr 有太多 log 時,其會透過這個方式影響節點檔案系統的容量
- /var/lid/docker/overlay2 (資料夾): 這邊包含了 containers 本身的 read-write layer 的檔案,大部分 Linux 發行版預設都會使用 overlay2 來管理。此外 contaienr 內如果有存放任何額外檔案於系統中,實際上都會放這節點上的這個資料夾內。
接下來作者透過一個實際的範例,讓一個全新的 contaienr 內透過 dd 指令來產生一些檔案,並且觀察上述資料夾的變化以及 docker system df 的結果,最後介紹 docker prune 以及 docker rm 針對 contaienr 的處理。
關於 image 的部分,除了常規使用的 Image 外,還有
1. Dangling images: 不再被參考使用的 image,譬如 ID/Tag 都是 None 的
這邊可以透過 docker image ls -f dangling=true 的指令
文章後半部分還有介紹 docker volume 以及 build cache 的部分,這篇文章非常推薦大家閱讀,除了基本使用外還會介紹底層 docker 實際上用到的資料夾,有了這些概念未來對於如何清除 docker 環境就會更有概念,知道要刪除哪些資料夾以及為什麼要刪除。
https://betterprogramming.pub/docker-tips-clean-up-your-local-machine-35f370a01a78
linux基本指令 在 linux基本指令-在PTT/IG/網紅社群上服務品牌流行穿搭 的推薦與評價
找linux基本指令在Dcard與PTT討論/評價與推薦,提供linux基本指令,linux常用指令pdf,Linux 指令集相關資訊,找linux基本指令就在網路品牌潮流服飾穿搭. ... <看更多>
linux基本指令 在 More content - Facebook 的推薦與評價
【基礎課程】 Linux 基礎社課(二) 不懂Linux 的指令嗎? ... 【課程介紹】 ✓ Linux 基本指令✓ 檔案路徑觀念✓ Linux 掛載裝置【課程資訊】 日期:3/1 (二) ... ... <看更多>
linux基本指令 在 Linux 基本認識與常用指令整理 - Dylan's Blog 的推薦與評價
透過這個指令可以利用sudo 不需要輸入密碼的特性,開啟一個root 的shell 環境,很常在Ubuntu Linux 中使用。 1, sudo su -. 補充:. sudo 可以不 ... ... <看更多>
相關內容