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 的人都寫一遍看看

時間管理方法是科學方法，很多時候真正的問題可能和我們的感覺不一樣，需要一些實際的計算，才能找出解決真正問題的計畫。

但要如何相對準確的計算自己到底把時間花在哪些事情上呢？這時候一款「自動追蹤軟體使用時間」、「可手動追蹤任務執行時間」的軟體就會有幫助，今天要分享的「 Tockler 」，就是一款這樣的電腦端免費軟體，支援 Windows、 Mac、 Linux。

如果你比較常使用電腦處理任務，或是生產力工具以電腦軟體為核心，那麼這款免費、可離線、簡單易用的軟體確實有幫助。並且「 Tockler 」除了免費、可離線外，也不需帳號登入，因為所有資料都儲存在自己的單機電腦中。

- 如果想要簡單追蹤電腦工作與軟體使用時間，那麼「 Tockler 」甚至完全不需要設定就可以使用。
- 如果要計算處理真正任務的總執行時間，「 Tockler 」也能滿足簡單需求。

有需要的朋友，歡迎參考我的測試與使用教學：

本文是一篇 2017 年的文章，雖然已經四年之久，但是我認為本篇文章值得一讀。
作者團隊於 2017 年時正在經歷如何將 VM 上的各種 Java 應用程式轉移到 Kubernetes 內的 Container，而本篇文章則是探討到底 Container 是如何透過 Linux Control Group 以及 namespace 實作的，透過對這些底層實作的瞭解，才有辦法針對 Container 效能部分去除錯與提升。

這種文章探討的都是很底層的概念，建議所有人都閱讀一遍，好好複習關於 cgroups/namespace 的概念，透過對這些概念的理解與掌握，能夠更有系統的去解釋何謂Docker Container，何謂輕量級虛擬化。

以下幫大家節錄一些重點，還是推薦自行閱讀全文

1. cgroup 用來隔離與限制 CPU,Memory,Disk,Network Bandwidth 等資源的用量
2. namespace 則是用來限制 ipc, pid, mount ,network, utc 等資訊的可視性，不同 namespace 內看到的資訊是獨立的，但是最終彼此還是屬於同一個 Kernel。
3. 任何沒有被 cgroup 規範的應用程式都會被自動包含到 root cgroup 的規範，不同發行版其位置不同，譬如 /sys/fs/cgropu.

假設今天透過 docker run 去運行一個 java 應用程式
a. Docker 會創建一個 pid namespace，接者運行 Java 前先把該應用程式給掛到新的 pid namespace 上並且賦予該 java 應用程式 PID 1
註: Host 上還是可以觀察到該 Java 應用程式，因為除了 Host 本身外，每個 pid namespace 都有自己的老爸，而老爸是可以看到小孩資訊的，這意味 docker dameon 雖然創建新的 pid namespace，但是host的pid namespace 實際是新 namespace 的老爸
b. 從老爸的視角來看，可以看到該 Java 應用程式也會有一個不同的 PID，而這個 PID 也會於 cgroup 系統中有自己的設定

4. CPU Cgroup 則是會用 share 為單位來定義每個 task 可以獲得多少相對的 CPU 時間，相對的算法是去計算 task 擁有的 share 數量佔了整個 cgroup 階層元件中的多少百分比。
舉例: 捨去其他服務單純考慮運行三個 Container 且有 4 Core CPU 的環境，三個 Container Task 分別給予 2048,1024,1024 share 的話，第一個 Container 大致是會被分配到兩個 CPU Time

5. CPU shares 沒有辦法去保證每個 task 最小用量是多少，所以需要透過 CPU Quotas 的概念來設定 CPU.cfs_quota_us(假設使用 CFS 這個排成演算法)以及 CPU.cfs_period_us(預設100ms)。
概念大概就是 cfs_period_us 定義的時間內，你最小可以使用多少時間，所以假如設定 cfs_quota_us 為 100ms，則預設情況下該 process 可以使用的量就是 100ms/100ms = 1 ~= 1 Core CPU

k8s 與上述的相關bug 可參考下列 issue
https://github.com/kubernetes/kubernetes/issues/67577

6. JVM 看到的是系統上全部的 CPU 資源，但是 Contaienr 本身當被限制 CPU 用量時，會有資訊落差，造成 GC 運行的效果不如預期，因為其認為系統有超多 CPU，而不知道自己其實被限制的CPU很少。

原文滿精彩的，推薦閱讀
https://engineering.squarespace.com/blog/2017/understanding-linux-container-scheduling

硬核的知識也許不是每個工程師都能夠在職涯發展中完全運用到，但無論是本科系、轉職、自學成為工程師的朋友，都應該要知道，這些紮實的背景知識提早學習起來，在未來的日子裡，只有好沒有壞。

就透過本影片我的真實經驗分享，告訴你這些我在大學時期看似枯燥乏味的理論，其實就是程式設計內功，而日後沉睡已久的內功卻又恰巧的在職涯旅途中碰上用處。

章節:
00:00 學這些有用嗎
00:52 我與速成班的距離
04:45 業務增長後的影響
06:36 基本功知識科普

喜歡影片的話！可以幫忙點個喜歡以及分享、訂閱唷！😘
━━━━━━━━━━━━━━━━
⭐ 蝦皮賣場: https://shopee.tw/bboyceo
⭐ instagram (生活日常): https://www.instagram.com/niclin_tw/
⭐ Facebook (資訊分享): https://www.facebook.com/niclin.dev
⭐ Blog (技術筆記): https://blog.niclin.tw
⭐ Linkedin (個人履歷): https://www.linkedin.com/in/nic-lin
⭐ Github: https://github.com/niclin
⭐ Podcast: https://anchor.fm/niclin
━━━━━━━━━━━━━━━━
🌟 任何問題或合作邀約信箱: niclin0226@gmail.com

#資料結構 #演算法 #計算機概論 #前端 #後端 #工程師