本文延續前篇效能校正的經驗談，上篇文章探討了關於系統呼叫, iptables 可以最佳化的部分，。本篇文章將繼續剩下最佳化步驟的探討。

Perfect Locality
預設情況下， Linux Kernel 會盡量平均地將請求給分配到所有的處理佇列，譬如 network queues, processes, CPUS. 大部分情況下這種機制運作良好不會有太多問題，不過如果今天要追求的不單單只是好的效能，而是極致的效能，則 locality 這個概念就要特別的去注意。

這篇文章中提到很多不同的方式，包含了 CPU Pinning, Receive Side Scaling(RSS), Transmit Packet Sterring(XPS)等，其實用比較簡單的介紹方式就是，希望可以使用固定的 CPU 來處理一條連線上的所有封包(進出)，這樣帶來的好處有
1. CPU Cache 可以盡可能的去使用，減少各種 miss 產生的成本
2. 減少 context switch 帶來的成本
3. 減少跨 CPU 之間交換資料帶來的成本
4. 減少 lock 之間帶來的成本
除了 CPU Pin, RSS, XPS 外，還有 irqbalance, smp_affinity_list 等相關的概念需要一併學習，對於這個概念有興趣的讀者非常歡迎去找尋這類型的資料

接者是 SO_REUSEPORT 這個參數，創建 Socket 時使用這個參數能夠使得多個 Process 共用一個連接埠，底層 Kernel 會針對 src/dst{ip/port} 來產生對應的 Hash，並且決定當前封包要送給哪一個 Process。
這個方式搭配前述各種 CPU Pin, 中斷的最佳化則會遇到問題，因為可能底層將該封包送到 CPU2 結果這個函式又把封包重新分配到 CPU0, 這樣就導致該連線要跨 CPU 處理了。
為了解決這個問題， Linux Kernel 4.6 後有新的參數 SO_ATTACH_REUSEPORT_CBPF，使用者可以自行撰寫 BPF 的程式來決定如何分配封包。作者根據這過想法撰寫了一個 BPF 的程式，來確保這個機制可以與前述的最佳化穩定運作。

這次的最佳化帶來的 38% 的成長，這時候的封包處理能力從 603k req/s 提升到 834k req/s
原文中關於這次的最佳化還有一些後續探討，有興趣的可以閱讀

Interrupt Optimizations

當封包透過網路送到網卡後，網卡必須要通知 OS 讓它知道有封包來了，要記得處理。一切處理完畢後網卡就可以繼續等待新的封包過來並且再次發送中斷給 OS 處理封包。這個流程大部分情況也是運作良好，不過當有大量的封包不停傳送來時，頻繁的中斷其實也是會造成不小的額外成本。

為了解決這個問題，目前比較嶄新的網卡都有支援中斷聚合等功能，透過這個功能可以延後中斷一個小週期，而該週期內收到的所有封包只需要透過一次的中斷就可以來處理，藉此降低中斷的次數。更為進階的網卡甚至支援動態自行調整該週期的時間，譬如當網路空閒時，減少週期使得每個封包能夠盡快的發送中斷被處理，而當網路流量很大時則會加大該該週期時間來更有效地處理封包。

註: AWS ENA 有支持這種動態調整的機制

作者基於 AWS 開啟動態調整收端中斷時間的功能，整個效能提升了 14%，從 834k req/s 提升到 955k req/s。作者說這次的調整可以說是整篇文章中幾個非常強的改動，改動的地方少，效能提升明顯，同時背後的隱憂與限制也少。

除了上述中斷的方式外，另外一種則是透過 Busy Polling 這種針對低延遲性的方式。預設情況下其允訓設定為 blocked 的 socket 能夠消耗額外的 CPU Cycle 來讀取接下來的封包，可以將其想成一成一種混合體，當底層網卡告訴我有資料要讀取時，我預期接下來還會有更多的資料，因此我就透過輪詢的方式去多問幾個封包。

由於作者的應用程式是使用 non-blocking 的方式去讀寫封包，所以預設的方式是沒有辦法使用的。而該應用程式又是使用 epoll 來進行底層封包的讀寫。 epoll 於 kenel 4.12 後正式支援 busy polling 的方式，所以這部分就沒有太大的問題。文章中有滿多關於 busy_poll 的一些參數調整。

將這兩個機制給整合後，整體的效能提升達到 28%，從 834k req/s 到達 1060k req/s，同時 99%的 latency 也從 361μs 下降到 292μs.

同時這兩個機制導入後，整個系統每秒產生的硬體中斷數量也從 183k 降到 16k。 Context switches 的數字也從 6k 下降到 1k 左右。

下篇文章會繼續從剩下的三個最佳化策略繼續介紹

https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/

最近跟大家分享一個 2020 年初左右的問題，這個問題的徵狀使用者透過 service 去存取相關服務時，會一直遲遲連接不上，直到 63 秒後服務才會通。
這個問題有兩種類型，一個是 63 秒後服務會通，一個則是 1 秒後會通，兩個背後的原因都一樣，這邊就來稍微簡介一下這個問題

# 發生條件
1. 使用 VXLAN 作為底層 Overlay Network，最常見的就是 Flannel 這套 CNI
2. Kubernetes 的版本不能太舊，至少要 1.16 以後，不過目前這個問題已經修復，所以現在要撞到除非特別指定版本
3. 使用的 Linux Kernel 版本也不能太新，目前該問題已經修復於大部分的 upstream

# 發生原因
1. VXLAN 本身是一個基於 UDP 的封裝協議，有一個已知的 bug 會使得其 checksum 發生錯誤，導致封包不會被遠端接收方給接收
2. kube-proxy 內關於 iptables 的設定沒有妥善，導致 VXLAN 封包會進行二次 SNAT
3. 第二次的 SNAT 就會觸發(1) 的 bug(當然還有其他條件，但是那些條件也剛好符合)
，最後導致封包的 checksum 不同，因此送到遠方就被拒絕
4. 底層的 TCP 建立連線時，會不停地嘗試，每次失敗都會等待更多時間，分別是1,2,4,8,16,32秒
5. 五次都失敗後， TCP 就會觸發重傳機制，下一次的重傳就不會進入到第二次的 SNAT，因此封包就不會踩到問題，因此通過

# 解決方法
1. 基本上這個問題要踩到要各方一起努力才會踩到，也因此修復方式也是多元化
2. Kernel 本身修復了關於 UDP 封裝的 Checksum 計算
3. Kubernetes 這邊則是針對 kube-proxy 進行強化，其使用的 iptables 規則會避免二次 SNAT 的情況

# 其他問題
1. 為什麼 TCP 重送後就不會踩到二次 SNAT? 這部分我看了相關的 issue 以及諸多文章都沒有看到解釋，都在探討 SNAT 後產生的 checksum，至於為什麼 TCP 重送後就通則是一個謎底
2. 為了解決這個謎體，我特別指定 kubernetes 版本並且重新編譯 Ubuntu 的 Linux Kernel 版本，盼望從 Kernel 中來觀察並且理解這個問題，目前已經有一些初步的進度。之後完成後會在撰寫文章跟大家分享這個問題

這個問題我認為非常有趣，也許自己的環境剛好沒有踩到，但是可以透過觀察不同的 issue 來研究各式各樣問題，也藉由這些過程來學習

相關 PR: https://github.com/kubernetes/kubernetes/pull/92035

創鈺「UWB室內定位解決方案」 啟動工業4.0的第一步

Sponsored Content 2018.01.05
數位時代

效率、品質、成本，是製造業最關注的三大重點，近年來興起的工業4.0趨勢，其核心精神也是環繞這三個營運重點，透過自動化與智慧化的方式，提高生產效率和品質、並降低成本，然而工廠智慧化的方式有很多種，從人、生產設備、物料管理到環境監控…等，每一個都是可以切入的面向，只可惜台灣目前在討論工業4.0時，太過強調生產設備智慧化，忽略「人」才是智慧化的基礎。 「我認為工業4.0的第一步，應該先從人的管理開始做起，」創鈺國際科技總經理賴鴻銓語氣肯定地說。

台灣製造業所使用的生產設備，大多數為單機作業環境，要經過很多道程序才能轉型智慧化，例如：佈建網路、裝感測器、開發數據分析軟體…等，這當中所需投入的成本和時間，容易讓企業卻步不前，但是「人」的管理相對容易許多，只要透過室內定位技術及圖形化的後台介面，就能幫助製造業實現從人員、機器設備、原物料、作業方式到環境的管理智慧化。

以人的管理為基礎 啟動工業4.0轉型藍圖

然而，目前常見的室內定位技術如RFID、藍牙、WiFi、ZigBee等，因為穿透性佳，反而不適合應用在牆壁隔間多的製造工廠，當訊號穿透牆壁時，容易與其他空間的訊號相互干擾、影響定位準確度。

因此創鈺國際以UWB（Ultra Wide Band；超寬頻通訊技術）為基礎推出「製造業微定位解決方案」，應用創新的演算法設計，實現工廠管理智慧化的目標，台灣某知名電子製造大廠便是應用創鈺國際科技「製造業微定位解決方案」管理位在大陸的上千人工廠，大幅改善人員作業效率與管理透明度。

創鈺國際科技副總經理賴宗鼎指出，該製造業在導入「製造業微定位解決方案」後，進入廠內的所有人員都需配戴UWB手環，做為人員進出工廠的門禁管制，當其在廠內移動時，圖台會清楚標示出目前所在位置，如此一來，管理者便能確保工廠內所有人員，包含作業人員、訪客與外包廠商的生命安全。

倘若人員遇到緊急狀況，只要按下UWB手環上的求救鈕，管理者便能從圖台介面得知求救者的位置，並通知距離最近的救護人員前往協助，又或者當人員在禁區或高危險區域長達一段時間沒有移動，管理者也能即時派人前往查看，降低工安意外的發生機率。

除了降低工安意外，掌握作業人員位置還有一個好處，就是搭配管理政策來提高生產效率、降低員工「假性出席(Presenteeism)」的機率。

美國學術期刊《Journal of Occupational Health Psychology》曾經刊出一篇文章指出，上班族普遍有「假性出席」的現象，也就是雖然出勤卻因故無法發揮全效狀態，可能因為精神不佳無法投入工作，或假藉各種名義離開工作崗位、直到接近下班時間再回來，這種假性出席的工資成本占整體薪資比例將近4成。

透過UWB手環的配置，系統可以計算人員在線時間，並列出報表，針對沒有達到標準值的員工，再由主管介入主動關懷，久而久之自然能減少作業人員刻意偷懶的行為、提高生產效率。「一座5千人的工廠，每年人資成本至少20億元，只要提高5%的作業效率，就能節省至少1億元的成本，」賴宗鼎強調。

室內定位圖台升級戰情中心 工廠管理資訊一手掌握

由於室內定位的圖台介面可以整合很多訊息，因此該製造業者也善用此特性，從最初的人員管理，到之後陸續整合其他資訊系統，將圖台轉變成工廠戰情中心，集中管理廠內的人員、機器、原物料、作業方式與環境安全。

舉例來說，在機器設備管理上，整合了設備數據自動化蒐集系統，在圖台上標示出產線主要機器設備的位置，當機器故障或需要更換零件時，圖台介面就會亮起警示燈號，提醒管理者通知相關人員，以便產線能夠快速復原，將效能維持在一定水準。「雖然設備數據自動化蒐集系統，也會預知機器維修時間，但是沒有圖形化介面去提醒管理者，相關訊息很容易就會被忽略，之前就曾經聽過某大型工廠的機器壞了3年都沒有被發現，」賴宗鼎解釋。

至於原物料管理上，則是在物料自走搬運車安裝UWB手環，當自走車發生碰撞、脫離軌道等異常現象而靜止不動時，圖台介面同樣會亮起警示燈號，中控室就會告知相關人員自走車停在哪個位置必須處理。另外，圖台介面也整合了生產資訊管理系統，當產品良率低於正常標準時，管理者只要點選圖台上的攝影機圖示，螢幕就會立即秀出即時監控影像，確認是否產線員工的操作方式有誤而影響良率。

雲端提供充分運算資源 確保室內定位精準度

由於室內定位所需的運算資源非常大，創鈺國際將相關的演算法和運算引擎放上微軟Azure雲端平台，因為Azure提供完整的開發套件如：MSDN、.NET等，所以開發速度很快，另一方面對使用者來說，雲端也是比較具有成本效益的選擇。

賴宗鼎進一步解釋，隨著使用規模擴大，室內定位所需求的運算資源也會跟著增加，例如：一座5千人的製造工廠，假設每隔5秒鐘就發出一次訊息，等於同時有2萬5千個訊息發送給伺服器，這對系統來說是很沉重的負擔，很容易造成當機或塞車的情形，而伺服器運算速度只要延遲個2秒，最終運算出來的結果與實際位置可能會誤差到15公尺之多，大幅影響定位精確度。

室內定位技術一開始應用於大型公共空間的導覽服務，例如：展覽會場、博物館、美術館、機場…等，隨著技術演變而成為工廠智慧管理的推進器，協助製造業順利踏上工業4.0之路。

醫療智慧化 提昇品質和效率

除了製造業以外，醫療業也很適合應用UWB室內定位技術提升服務品質或管理效率。賴宗鼎指出，醫療業的室內定位應用分成兩種，一個是傳統常見的導覽應用，以藍牙技術為基礎、手機App為介面，為到院就診的病患或家屬提供路線導航服務，避免民眾在醫院迷失方向，並降低在醫院停留的時間。

另一種則是應用於醫療管理，此時就適合採用UWB技術，讓醫護人員可以即時找到想要找的人或儀器設備。舉例來說，健檢中心的客戶在等待檢查過程中，可能會四處走動打發時間，護理師只要在健檢者手上配戴UWB手環，就能透過圖台看到健檢者目前所在位置、提前通知客戶回到健檢室進行檢查；又如急診室空間有限，病床不得不置放在週遭的走廊上，導致急診室醫師無法在第一時間找到病患，若在病床上安裝UWB手環就能解決此困擾。

創鈺國際科技成功背後的 Azure 關鍵服務 : Azure Virtual Machines

創鈺國際客戶群涵蓋政府單位與公民營大型企業，由於每個客戶對於公有雲接受度不一，採用 Azure Virtual Machines 帶給創鈺最大的業務彈性，Azure Virtual Machines 採用 Windows Server Hyper-V 相同之虛擬化技術，可以直接使用 Hyper-V 虛擬硬碟檔案格式 (VHD) 上傳至雲端使用。也可以透過 Azure 入口管理管帳自由選用 Windows 或 Linux作業系統之映像檔直接在雲端建立虛擬機器，用戶隨時都可以將整個虛擬硬碟檔案虛擬硬碟檔案 (VHD) 匯出或下載，不會受制於單一雲端業者服務。