章來源：GMK NucBox–掌上迷你Windows10電腦評測 - CNX Software中文站
GMK不久前發布了一款名為NucBox的迷你電腦，但他們最近又更新了BOM，增加了新的風扇和WiFi模塊，并將其LOGO從GMK改為GMK TEC。GMK送來了新的NucBox進行評測，各種測試的結果詳見下文。
NucBox外殼由一個62 x 62 x 42 mm（2.44 x 2.44 x 1.65英寸）的長方形金屬外殼以及一個塑料頂板和一個塑料底板組成。作為一款主動冷卻的迷你PC，它搭載了英特爾14 nm的J4125 Gemini Lake Refresh處理器，這是一款四核、四線程2GHz處理器，可通過英特爾的UHD Graphics 600提升至2.7 GHz。
NucBox外殼前面只有電源按鈕，而后面包括兩個USB 3.0端口，一個HDMI端口和一個用于供電的Type-C USB端口。左側有一個微型SD卡插槽和一個耳機插孔，右邊則什么都沒有。
供評測樣機還包括在雙通道下運行的8GB DDR4 2133MHz的焊接內存：
評測樣機內存
以及一個128GB M.2 2242 SATA驅動器，可通過卸下底部的底板進行訪問：
GMK TEC底部
此外，還有一個焊裝的英特爾Wireless-AC 9461 WiFi 5（或802.11ac）模塊，此設備的內部由兩塊堆疊的主板組成。
GMK TEC設備內部兩塊主板
最上面放的是風扇。
用戶手冊規格說明：
然而，WiFi模塊實際上只有1×1，而不是英特爾Wireless-AC 7265模塊本應提供的2×2。據GMK稱，這是由于WiFi模塊的全球性短缺導致的不同生產批次之間規格變化，這一點無法反映在用戶手冊中。此外，由于沒有以太網端口，需要一個USB-以太網適配器（“加密狗”）來“支持外部以太網”。
在包裝盒中，你會得到一個電源適配器和電線，一個適合你所在國家的獨立插頭適配器，以及一份用戶手冊。
NucBox包裝
在評測迷你電腦時，我通常會查看它們在Windows和Linux（Ubuntu）操作系統下的性能，并將它們與一些最近發布的迷你電腦進行對比。自2021年開始，我一直使用Windows 10 20H2版本和Ubuntu 20.04 LTS進行評測，但是由于Windows的更新和NucBox上Ubuntu的問題，這次我同時使用Windows 10 21H1版本和Ubuntu 20.04 LTS & 21.04進行評測。我選擇了一些常用的Windows基準測試和/或與之對應的Linux測試，以及Thomas Kaiser的“sbc-bench”，一組不同的CPU性能測試，并專注于在Ubuntu上運行時的服務器性能。我還在Windows和 Ubuntu上使用了“Phoronix 測試套件”和基準測試，以進行比較。在Ubuntu上，我還使用默認配置編譯了v5.4linux內核，作為使用真實場景的性能測試。
在進行基準測試之前，為運行兩個操作系統的最新版本，我進行了所有必要的安裝和更新。我還捕捉了每個操作系統的設備的一些基本細節。
安裝并啟動Ubuntu 20.04.2后，“dmesg”顯示“snd_hda_intel 0000:00:0e.0: No response from codec, reset bus:”錯誤，這導致了系統死機：
編碼無響應
當和揚聲器系統有響應時，HDMI音頻都沒有辦法進行運行工作：
HDMI 和揚聲器音頻不起作用
因此，我使用“snd_hda_intel.enable=0”的內核參數完全禁用音頻以避免卡頓問題，并重新啟動系統：
這導致了一個虛擬輸出。
HDMI音頻虛擬輸出
經過一些故障排除，我嘗試安裝Ubuntu 21.04，HDMI音頻問題得到了解決。
HDMI音頻問題
然而，仍然無法從3.5毫米的耳機插孔產生音頻，因為在連接耳機時，沒有檢測到任何東西，也沒有相應的改變，包括在連接/斷開耳機或列出ALSA音頻設備時，“dmesg”中沒有任何東西。
更重要的是，在Ubuntu系統，NucBox的風扇未能被正確檢測到。如果開機時CPU的溫度低于55℃，風扇就不會開啟，否則，風扇就會持續運行。在沒有風扇的情況下運行的問題是，作為過熱降頻保護功能的一部分，“PL1”和“Tau”的值被降低，一旦CPU冷卻下來，它們就不會被重置。這將導致降頻保護是永久性的，直到重啟。例如，在Ubuntu上運行Passmark，在風扇運轉的情況下，可以得到3107.82分，但如果CPU被降頻保護了，則只能得到467.34分。GMK為Ubuntu提供的解決方案是“禁用”BIOS中的“智能風扇功能”，使風扇永久運行。
最后，我個人不喜歡的一個問題是必須使用插頭適配器。正如下面這張照片。
插頭適配器
電源適配器必須插入插頭適配器，然后再插入插頭插座。雖然電源適配器很小，但它有一定的重量，而且插頭適配器有一定的“間隙”，這會使整個適配器“塔”略微晃動。
最初，NucBox安裝的是Windows 10 家庭版2004 build 19041.685的授權拷貝。在升級到21H1 build 19043.1023版本后（因為20H2版本不提供升級選項），快速查看硬件信息將會顯示：
21H1 build 19043.1023版本硬件信息
簡要檢查顯示了音頻、微型SD、Wi-Fi和藍牙都能正常工作。用一個USB連接到以太網的加密狗進行測試，確認以太網也能工作。
然后我將電源模式設置為“高性能（High performance）”并運行我的(2021)標準基準測試工具包來查看Windows系統下的性能：
對于我的一組特定的Phoronix測試套件測試，結果如下：
Phoronix測試套件測試結果
可以將所有這些結果與其他最近發布的迷你PC進行比較：
多款迷你PC性能對比
結果顯示，與使用相同J4125 CPU的其他迷你PC一致。
在將Windows分區縮小一半并創建一個新的分區后，我安裝了Ubuntu，使其成為雙系統啟動。最初，我安裝了Ubuntu 20.04.2用于性能測試，使用GRUB禁用音頻，并通過BIOS將風扇設置為常開狀態（見上面的安裝問題）
在安裝和更新之后，簡要的檢查顯示，當使用USB-Ethernet加密狗時，microSD、Wi-Fi、藍牙和以太網都能工作。然而，如上所述，音頻并不工作。
Ubuntu 20.04.2系統下主要關鍵硬件信息如下：
前往“CNX Software中文站”官網，查看完整信息
然后，我將CPU Scaling Governor設置為“performance”，并運行我的Linux基準測試，其中大部分測試結果是基于文本的，但也包括如下圖形的結果。
我還運行了Passmark PerformanceTest Linux（測試工具包）：
可以直接與在Windows中運行CPU測試的結果進行比較：
對于同一組 Phoronix Test Suite的測試，結果為：
Phoronix Test Suite測試結果
完整結果及同其他最新款的迷你PC比較：
最新迷你PC性能對比
并再次顯示與使用相同J4125 CPU的其他迷你PC保持一致的結果。
Ubuntu 21.04 ISO提供了HDMI音頻，然后我使用它覆蓋了已安裝系統，并在風扇一直運轉的情況下測試了圖形性能。
對于實際測試，我在Windows上的Edge、Chrome和Kodi 以及Ubuntu上的 Firefox、Chrome和Kodi中播放了一些視頻。下表總結了每個測試和結果：
Windows上及Ubuntu上播放視頻的測試結構
從上面的Unigine Heaven得分可以看出，NucBox只能提供有限的游戲性能體驗。
雖然兩個操作系統之間的詳細比較超出了本評測的范圍，但值得注意的是我觀察到了一些關鍵的信息。看一下兩個操作系統之間共同的性能工具，就會發現它們是相當的匹配。
然而，由于在Ubuntu系統上沒有檢測到風扇，并且在Windows上的視頻播放比在Ubuntu上運行得更好，考慮到價格包括了Windows 10 Home許可證，將該設備用作Linux HTPC可能沒有太大意義。
NucBox使用主動冷卻，在Windows下可以正常工作：
NucBox主動冷卻在Windows下正常工作
它有一個相當安靜的風扇，當運行時，我在設備旁邊的聲級計上測量到數值約為41dBA。
然而，正如在Ubuntu系統上已經提到的，風扇沒有被正確檢測到，如果在CPU低于55°C時啟動，它要么保持關閉，要么永久保持開啟狀態。如果沒有風扇，過熱降頻保護功能會降低“PL1”和“Tau”的值，一旦CPU得到冷卻，它們就不會再重新設置。這可以通過在“壓力測試”期間和之后監控到的數值來證明。關閉風扇，測試運行五分鐘：
關閉風扇進行測試
“PL1”和“Tau”的過熱降頻保護功能僅在三分鐘后產生，而在風扇運轉的20分鐘測試期間內，它們保持不變：
過熱降頻保護功能
有趣的是，過熱降頻保護功能對在Kodi下播放視頻未產生任何影響：
過熱降頻保護功能未對視頻播放造成影響
然而，它顯然影響了CPU性能：
過熱降頻保護功能影響了CPU性能
其中采用了降頻保護性能的Passmark結果為467.34，與之相比風扇運行時結果 為3107.82（見上文）。
在Ubuntu上使用“iperf”測量了連網時的網速。
很差的性能顯示出使用1×1 WiFi模塊的影響。
在Windows系統中，BIOS風扇默認設置下測量了功耗，在Ubuntu系統中，將風扇設置為關閉和運轉時測量了功耗，如下所示：
*BIOS（見下文）
**功率數字會波動，因此該值是中值高功率讀數和中值低功率讀數的平均值。
我們可以看出，在Ubuntu中使用風扇時，會在CPU待機時增加大約0.4瓦的功耗。
在GMK網站上，有一個Windows驅動的下載鏈接，以及一個包含了驅動的修改后的Windows ISO，但這些都沒有作為本評測的一部分。
NucBox開機后，點擊F7鍵會出現一個啟動菜單，其中包括訪問BIOS的權限。BIOS是不受限制的。
相關視頻：點擊可查看
總的來說，這是一臺可愛的迷你PC。然而，它也不是沒有限制的。由于體積太小，它只有兩個USB端口，理想情況下，第三個端口會很有用，可以避免在使用有線鍵盤和有線鼠標時需要一個USB集線器。選擇“替代”WiFi模塊有點令人失望，因為單天線會導致網絡性能不佳。最后，在Ubuntu中不能正確識別風扇，在使用最新的LTS版本時出現HDMI問題，這可能意味著這臺迷你電腦只適合運行Windows系統。
亮點 | 限制 |
尺寸小 | WiFi 被限制為1x1 |
Ubuntu 支持問題 |
我要感謝GMK提供的NucBox評測套件。它目前在Amazon、Banggood或GMKTec 商店的配置測試版零售價低于200美元，您可以使用促銷代碼“KB1”將價格降低 40美元，并可獲得一個USB 集線器作為禮物，其中還包括一個快速 (100Mbps) 以太網端口和三個 USB 2.0 端口。
更多干貨，請點擊：CNX SOFTWARE中文站 — 嵌入式開發者的新聞知識庫！
作者 | 饒全成
來源 | 碼農桃花源（ID：CoderPark）
最近遇到了一起依賴升級 + 異常數據引發的線上事故，教訓慘痛，本文對此進行回故和總結。
起因是我們使用的服務框架版本比較老，GC 次數的 metrics 打點一直為 0，咨詢了相關同學后，決定升級框架。升級的過程中，出現了 useofinternalpackagexxxnotallowed 的報錯，又咨詢了一下相關同學后，嘗試使用 go mod 解決。
從 go vendor 到 go mod 的升級的過程也不太順利，這里按下不表，最終是升級成功了。一同升級的還有 Go 版本，從 1.11 升級到 1.13。
周四上完線后，一切都看似很不錯：內存占用、GC 消耗的 CPU 有了優化，GC 次數的監控也有了。因為涉及到公司內部數據，圖我就不放了。
周五、周六都平安度過，周日出問題了，小組的同學從下午 12 點左右一直忙到凌晨 12 點，才松了一口氣。可憐我們來之不易的一個周日！
周日 11 點 45 左右，端口的調用失敗率報警，同時有業務方反饋調用接口報錯。
同志們，關鍵時刻，完善的報警能給事故的處理和恢復贏得時間啊！
By case 排查，發現服務 shard3 集群的機器報 i/o timeout 錯誤。服務共有 4 個分片集群（根據 ID hash 到對應分片），其他 3 個集群完全正常。接著發現 shard3 集群的機器內存正常、端口還在，但 in/out 流量全部掉到幾十 KB/s，看日志也沒有發現任何異常。
重啟 shard3 集群的服務，重啟后的服務恢復正常，訪問 debug 端口，也是正常的。然而，十幾分鐘后，恢復的服務再次出現異常：in/out 流量再次掉到幾十 KB/s，訪問 debug 端口也沒有任何響應，開始慌了。
上線出問題，第一時間回滾！
穩定性里面很重要的一條就是：有問題，先回滾。先止損，將事故影響降到最低，事后再來追查根因，總結復盤。
于是開始操作回滾， reset 到周四上線之前的一個 commit，重新打包，上線 shard3 集群。之后，對外接口完全恢復，操作回滾其他集群。
服務啟動之前，需要先加載幾十個 G 左右的數據，啟動過程長達 10+ min。我申請了一臺線上問題機器的 root 權限，執行了 strace-p 命令：
發現服務卡在 futex 系統調用上，這很明顯是一個 timer，但是 timer 為何會卡住？正常情況下，會有各種像 write，read 的系統調用，至少打日志、上報 mertrics 打點數據都會有 write 系統調用吧，哈？再執行 perf top 命令：
相關的只有 codec 函數，再看服務進程：
看 perf 輸出的結果，全部聚焦到 codec 這個第三方庫上，主要的兩個函數竟然是 codec.quoteStr 和 utf8.DecodeRuneInString。而我們用 codec 的地方是在程序啟動時加載數據文件以及定時的 dump 文件到本地。現在程序已經啟動了，只可能是 dump 文件出問題了。查看相關日志，果然有開始 dump 文件的日志記錄，卻一直沒有 dump 成功的記錄。
事后追查階段嘗試在 test 集群上重現故障，因為只有單個分片出問題，說明此故障和特定數據有關，是 hash 到分片 3 的數據引起的問題。
又因為 test 集群并沒有分片，所以強行（改代碼 && 改環境變量）將其偽裝成 shard3 集群，然則并沒有復現，猜測可能是計劃下線了。
周二的時候，終于在 test 集群上模擬分片 1 時重現了線上故障。
對比 codec 的版本問題，果然有問題：周四上線前， vendor.json 里的版本是 v1.1.7，上線后，升級到了 v1.1.8，看來找到問題了！修改 codec 的版本，重新編譯、部署，問題依然存在！
這時，組里其他同學反饋 2018 年的時候也出過 codec 的問題，當時也是出現了異常數據導致重啟時加載文件不成功。于是我直接將周四上線前 vendor 文件夾里 codec.quoteStr 函數的代碼和 codec 的 v1.1.7 代碼進行對比，并不相同！vendor.json 里的版本并沒有正確反應 vendor 里實際的 codec 版本！！！
進一步查看提交記錄，發現在 2017 年 11 月份的時候有一次提交，修改了 vendor 文件夾里的代碼，但這時 vendor.json 并沒有 codec 記錄。而在 2019 年 11 月的一次提交，則只在 vendor.json 里增加了一條 codec 記錄，vendor 文件夾里的代碼并沒有更改：
{
"checksumSHA1": "wfboMqCTVImg0gW31jvyvCymJPE=",
"path": "github.com/ugorji/go/codec",
"revision": "e118e2d506a6b252f6b85f2e2f2ac1bfed82f1b8",
"revisionTime": "2019-07-23T09:17:30Z",
"tree": true
}仔細比對代碼，主要差異在這：
從現象及源碼看，大概率是在 codec.quoteStr 里死循環了！由于 Go 1.14 前都無法搶占正在執行無限循環且沒有任何函數調用的 goroutine，因此一旦出現死循環，將要進行 GC 的時候，其他所有 goroutine 都會停止，并且都在等著無限循環的 goroutine 停下來，遺憾的是，由于 for{} 循環里沒有進行函數調用，無法插入搶占標記并進行搶占。于是，就出現了這樣一幕：
只有 dump 數據文件這一個 goroutine 在干活，而且做的又是無限循環，服務整體對外表現就像是“死機”了一樣。并且這個 goroutine 由一個 timer 觸發工作，所以一開始我們看到的卡在一個 futex 調用上就可以解釋得通。因為 runtime 都停止工作了，timer 自然就沒法“到期”了。
接著，使用 Go 1.14 去編譯有問題的代碼版本，上到 test 集群，果然問題“消失”。服務狀態完全恢復正常，唯一不正常的是數據文件無法 dump 下來了，因為即使是 Go 1.14，也依然在執行無限循環，不干“正事”。
接下來的問題就是找到異常的數據了。使用上線前的版本（使用 go vendor），將 codec 替換為最新的 v1.1.8 版本，并且在 quoteStr 函數里打上了幾行日志：
部署到 test 集群，問題復現：
異常數據就是：“孫雷”：
為什么會引發死循環，在調用 utf8.DecodeRuneInString 函數后：
c == utf8.RuneError
size == 3
再看 RuneError 的定義：
const RuneError = '\uFFFD'
看一下兩個版本的代碼不同之處：
老版本的代碼，不會進入 if 分支，而新版本的代碼，由于 c==utf8.RuneError，所以先進入 if 分支，之后， size==3，不滿足里層分支，直接 continue 了，因此 i 值并沒有發生變化，死循環就這么發生了。
最后就是找到異常數據到底屬于哪個計劃。我嘗試去每個集群的機器上，從數據文件里尋找“孫雷”。但文件太大了，幾十個 G， grep 搞不定，沒關系，使用 dd 工具：
dd if=model_20200423155728 bs=1024 skip=3600000 count=1200 | grep '孫雷'
使用二分法找到了“孫雷”！關于 dd+grep 的用法，總結了幾點：
每次從文件開頭先跳過 skip*bs 大小的內容，復制 count*bs 大小的內容過來用 grep 查詢。
如果不設置 count，就會查找整個文件，如果查到，則會有輸出；否則無。
對于特別大的文件，可以先把 count 設為跳過一半文件大小的值，采用二分法查找。如果找到，則限定在了前半范圍，否則在后半部分。使用類似的方法繼續查找……
如果找到，最后會輸出 count*bs 大小的內容。
服務重大版本更新，至少在線下跑一周。
有問題，第一時間回滾。
對于工具的使用要規范。如不要隨意更改 vendor 文件夾的內容而不同步更新 vendor.json 文件，反之亦然。
因為 go mod 的版本選擇以及不遵守開源規范的第三方庫作者會讓使用者不知不覺、被動地引入一些難以發現的問題。可以使用 go mod vendor 代替，如果要鎖死版本的話，使用 replace。
【stw 如何停止 goroutine】https://medium.com/a-journey-with-go/go-how-does-go-stop-the-world-1ffab8bc8846
【煎魚 Go Modules 終極入門】https://eddycjy.com/posts/go/go-moduels/2020-02-28-go-modules/
今日福利
遇見大咖
由 CSDN 全新專為技術人打造的高端對話欄目《大咖來了》來啦！
CSDN 創始人&董事長、極客幫創投創始合伙人蔣濤攜手京東集團技術副總裁、IEEE Fellow、京東人工智能研究院常務副院長、深度學習及語音和語言實驗室負責人何曉冬，來也科技 CTO 胡一川，共話中國 AI 應用元年來了，開發者及企業的路徑及發展方向！