關於 linux group user ，我們在網路上蒐集到這些相關的討論、資訊與評價

本文延續前篇效能校正的經驗談，上篇文章探討了關於應用程式本身可以最佳化的部分，包含了應用程式以及框架兩個部分。本篇文章將繼續剩下最佳化步驟的探討。

Speculative Execution Mitigations
接下來探討這個最佳化步驟對於效能有顯著的提升，但是本身卻是一個非常具有爭議性的步驟，因為其涉及到整個系統的安全性問題。
如果大家對前幾年非常著名的安全性漏洞 Spectre/Meltdown 還有印象的話，本次這個最佳化要做的就是關閉這類型安全性漏洞的處理方法。
標題的名稱 Speculative Execution Migitations 主要跟這漏洞的執行概念與 Pipeline 有關，有興趣理解這兩種漏洞的可以自行研究。

作者提到，大部分情況下這類型的防護能力都應該打開，不應該關閉。不過作者認為開關與否應該是一個可以討論的空間，特別是如果已經確認某些特別情境下，關閉防護能力帶來的效能如果更好，其實也是一個可以考慮的方向。

舉例來說，假設今天你運行了基於 Linux 使用者權限控管與 namespaces 等機制來建立安全防護的多使用者系統，那這類型的防護能力就不能關閉，必須要打開來防護確保整體的 Security Boundary 是完整的。 但是如果今天透過 AWS EC2 運行一個單純的 API Server，假設整個機器不會運行任何不被信任的程式碼，同時使用 AWS Nitro Enclaves 來保護任何的機密資訊，那這種情況下是否有機會可以關閉這類型的檢查?

作者根據 AWS 對於安全性的一系列說明認為 AWS 本身針對記憶體的部分有很強烈的保護，包含使用者之間沒有辦法存取 Hyperviosr 或是彼此 instance 的 Memory。
總之針對這個議題，有很多的空間去討論是否要關閉，以下就單純針對關閉防護能力帶來的效能提升。

作者總共關閉針對四種攻擊相關的處理能力，分別是

Spectre V1 + SWAPGS
Spectre V2
Spectre V3/Meltdown
MDS/Zombieload, TSX Anynchronous Abort
與此同時也保留剩下四個，如 iTLB multihit, SRBDS 等
這種設定下，整體的運作效能再次提升了 28% 左右，從 347k req/s 提升到 446k req/s。

註: 任何安全性的問題都不要盲從亂遵循，都一定要評估判斷過

Syscall Auditing/Blocking
大部分的情況下，Linux/Docker 處理關於系統呼叫 Auditing/Blocking 兩方面所帶來的效能影響幾乎微乎其微，不過當系統每秒執行數百萬個系統呼叫時，這些額外的效能負擔則不能忽視，如果仔細觀看前述的火焰圖的話就會發線 audit/seccomp 等數量也不少。

Linux Kernel Audit 子系統提供了一個機制來收集與紀錄任何跟安全性有關的事件，譬如存取敏感的機密檔案或是呼叫系統呼叫。透過這些內容可以幫助使用者去除錯任何不被預期的行為。
Audit 子系統於 Amazon Linux2 的環境下預設是開啟，但是本身並沒有被設定會去紀錄系統呼叫的資訊。

即使 Audit 子系統沒有真的去紀錄系統呼叫的資訊，該子系統還是會對每次的系統呼叫產生一點點的額外處理，所以作者透過 auditctl -a never,task 這個方式來將整體關閉。

註: 根據 Redhat bugzilla issue #1117953, Fedora 預設是關閉這個行為的

Docker/Container 透過一連串 Linux Kernel 的機制來隔離與控管 Container 的執行權限，譬如 namespace, Linux capabilities., cgroups 以及 seccomp。
Seccomp 則是用來限制這些 Container 能夠執行的系統呼叫類型

大部分的容器化應用程式即使沒有開啟 Seccomp 都能夠順利的執行，執行 docker 的時候可以透過 --security-opt seccomp=unconfined 這些參數告訴系統運行 Container 的時候不要套用任何 seccomp 的 profile.

將這兩個機制關閉後，系統帶來的效能提升了 11%，從 446k req/s 提升到 495k req/s。

從火焰圖來看，關閉這兩個設定後，syscall_trace_enter 以及 syscall_slow_exit_work 這兩個系統呼叫也從火焰圖中消失，此外作者發現 Amazon Linux2 預設似乎沒有啟動 Apparmor 的防護，因為不論有沒有關閉效能都沒有特別影響。

Disabling iptables/netfilter
再來的最佳化則是跟網路有關，大名鼎鼎的 netfilter 子系統，其中非常著名的應用 iptables 可以提供如防火牆與 NAT 相關功能。根據前述的火焰圖可以觀察到，netfilter 的進入 function nf_hook_slow 佔據了大概 18% 的時間。

將 iptables 關閉相較於安全性來說比較沒有爭議，反而是功能面會不會有應用程式因為 iptables 關閉而不能使用。預設情況下 docker 會透過 iptables 來執行 SNAT與 DNAT(有-p的話)。
作者認為現在環境大部分都將 Firewall 的功能移到外部 Cloud 來處理，譬如 AWS Security Group 了，所以 Firewall 的需求已經減少，至於 SNAT/DNAT 這類型的處理可以讓容器與節點共享網路來處理，也就是運行的時候給予 “–network=host” 的模式來避免需要 SNAT/DNAT 的情境。

作者透過修改腳本讓開機不會去預設載入相關的 Kernel Module 來達到移除的效果，測試起來整體的效能提升了 22%，從 495k req/s 提升到 603k req/s

註: 這個議題需要想清楚是否真的不需要，否則可能很多應用都會壞掉

作者還特別測試了一下如果使用 iptables 的下一代框架 nftables 的效能，發現 nftables 的效能好非常多。載入 nftables 的kernel module 並且沒有規則的情況下，效能幾乎不被影響(iptables 則相反，沒有規則也是會影響速度)。作者認為採用 nftables 似乎是個更好的選擇，能夠有效能的提升同時也保有能力的處理。

不過 nftables 的支援相較於 iptables 來說還是比較差，不論是從 OS 本身的支援到相關第三方工具的支援都還沒有這麼完善。就作者目前的認知， Debian 10, Fedora 32 以及 RHEL 8 都已經轉換到使用 nftables 做為預設的處理機制，同時使用 iptables-nft 這一個中介層的轉換者，讓所有 user-space 的規則都會偷偷的轉換為底層的 nftables。
Ubuntu 似乎要到 20.04/20.10 的正式版本才有嘗試轉移到的動作，而 Amazon Linux 2 依然使用 iptables 來處理封包。

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

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

由 Cloud Native Taiwan User Group 所持續推動的每月線下活動又來囉，本次內容包含了近幾年與底層非常熱門的 eBPF 以及透過講者所開發的開源專案，KubeFire, 其透過 Firecracker 這個方式來創建並管理一個 Kubernetes 叢集

該次議程地點為台北天瓏書局，同時當天也會開放線上直播，讓不克前來的社群朋友一起參與，會後也會有相關錄影。

請點選下方連結來瞭解更多
https://www.meetup.com/CloudNative-Taiwan/events/273340386/

《新日微信》20160918開放世代的開放難題
開放創新（Open Innovation）自2003年被提出以來，從觀念到實現之路途遙遠，而且年輕世代對開放的接受度已逐漸撼動既有的慣性，因此，對經營者而言，To open or not to open, that is a question.而這個決策所面對的優劣分析，已經複雜到難以理性判斷的地步，擁抱風險者自然大步邁向這些創新的選項，遭遇困境時再見招拆招；而規避風險者則自然地推論其中的窒礙難行，會不會淹沒在新興的浪潮中，仍是保守主義者心中的陰霾。
　
對於開放創新的倡議，十多年來的確有一些成功的實踐案例，例如，P&G的C&D（Connect & Development），寶僑以其產業中的廣泛觸角，往外伸向各種利害關係人，並吸取其智慧與資源，在新產品發展方面成為典範。一方面可以由外部資源提供更深刻的市場洞見（Insight），另一方面又可以大幅縮短開發的時程，就方法論而言，頗具設計思考的架構，因為內部的設計師或產品開發工程師使盡洪荒之力去探究同理心，不如讓身為當事人的消費者自己敘事，將內心的悸動與苦楚表達出來。多數消費者可能不擅表達深層的想望與渴望，此時具備人類學家功力的引導人員，適時出招發揮汲引的效用，應可竟其功。若再輔以逐漸熱門的大數據決策分析，廠商在創新之際的工具堪稱不斷推陳出新。
　
跳tone介紹最近一檔熱映的電影「薩利機長」，在劇終前讓我們見識到大數據的威力。在釐清薩利機長究竟「是英雄或是莽夫」這道難解的爭議時，讓一般觀眾一窺在航空界沿用多年的模擬飛行。塔台所建議的兩座返航機場與被鳥擊後的全美航空1549航班之間，所有決策只有208秒。為確認是否有人為疏失，聽證會上導入模擬機與真人模擬的飛航，但二者均不等同於208秒的危機處理，最精彩的證詞是「模擬的情境並未納入人因」（The simulated scenarios didn't account for the "human factor".）薩利據此以關鍵的「人性」扣除35秒，證明自己當時的決策無誤。我們（連薩利本人）都難以還原那個決策中寂靜的幾十秒，喜劇收場雖沖淡了深度學習的機會，相信那三、四十秒將會成爲EMBA領導力課程中的最佳案例探討。
　
回到開放創新的兩難，一般論及開放式創新的方法不外乎五類：共創工作坊（Co-creation workshop，召聚先驅使用者Lead User進行焦點團體活動Focus Group）、群眾外包（Crowdsourcing）、開源軟體（Open Source）、大量客製（Mass Customization）、與使用者原創內容（User Generated Content），多數屬於單純線上（On-line）或線上對線下（Ｏ2O）的新興現象。技術的可行性難以證明整體營運模式無誤，商業競爭的錙銖必較，仍令人不禁對開放者的無私抱持著疑懼的態度，這也是開放創新發展迄今十餘年，仍有許多窒礙難行的領域難以跨越。倡議與推動開放創新者也必須瞭解其限制條件，才能受惠開放這項具有前瞻未來的選項。
　
諸多限制條件中，智慧財產權是一個關鍵因素。iThome新聞引述Linux之父Linus Torvalds 最近呼應Linux Kernel開發人員Greg Kroah-Hartman的看法，認為把違反通用公共授權（GPL）的Linux案件搬上法院不會帶來任何的友誼，而是讓興訟者淪為惡霸，這些訴訟案破壞了社群、瓦解了信任，也將摧毀Linux社群數十年來所建立的善意。另一個年輕人的開放生活經驗是最近剛慶祝二十歲生日的PTT，這個菁英與民粹雜燴的台灣民主聖地，有自己的法律、法院和貨幣，有如文化創意BoBo族（布爾喬爾Bourgeoisie與波希米亞Bohemia）在傳統與創新間的糾結，數位世界的未來想像與實體世界的傳統包袱在PTT上的衝突，不僅打造了媒體傳播的新世界，也處處陷O2O新模式於探索的蹣跚。信任處於不斷地被破壞、重組、再破壞、再重組的循環中，但「信任」超越「法律」與體制不知凡幾，被破壞的人因與人性，是否能以體制重組與重建，值得每一個開放創新的謹慎以對。
　
財產權，自然是所有體制與人性的攻防關鍵。體制創新容許人類的創意以無體財產的型態顛覆產品的創新、廠商的競爭與產業的規律，回過頭來，又不斷以新興的法規協調改變社會的風貌（Social Landscape），但那只是維繫社會發展的必要條件，耳畔不禁又響起Michelle Obama那句震古鑠今的When they go low, we go high!在面對開放創新的兩難時，所有的情境模擬，最後還是不脫薩利機長所說的人因與人性。排除了人因與人性，「向上走」恐怕就已被排除在選項之外了。