軟體主廚的程式料理廚房

前些日子開了一台新的 SQL Server，最近從監控當中發現凌晨 02:10 ~ 02:30 之間 CPU 被拉高，日復一日都是相同的時間點。

看起來吃了不少 CPU 資源，由於這段時間嚴格來講並不算是服務的離峰時間，還是希望將珍貴的 CPU 資源留給服務，所以必須查出來到底是誰吃掉了 CPU 的資源？

手上或所處的資訊環境如果有一些舊硬碟，在還堪用的情況之下，應該會希望能持續發揮它的價值直到它生命的最終點，微軟從 Windows 7、Windows Server 2012 R2 開始就內建軟體式的 RAID 功能，有 JBOD、RAID-0、RAID-1、RAID-5 可以選擇使用，已經能滿足大部分的需求了。

Topshelf 這個套件在網路上隨便搜尋，不管國內外都有很多文章在介紹它，我是直到最近才開始跟它有更親密的接觸，利用它我們可以很容易地將 Console 程式 Host 成 Windows 服務，變成 Windows 服務之後我們的應用程式就擁有了透明且可控的生命周期。

在 twMVC#34 聽到一位朋友說他遇到 ASP.NET SignalR 有連線數 11 的限制，由於這位朋友沒有現身，不知道更詳細的情況，我就我之前遇到的情況跟各位朋友分享，ASP.NET SignalR 是會有連線數限制的情形，但這不是 ASP.NET SignalR 的問題。

一直以來，都以為 Windows 工作排程器（Task Scheduler）的重複工作間隔時間最小只能設到分鐘，無意中查到這篇文章，原來不是不行，是我不會。

這個雷我踩了不下三次，寫下來記錄一下，C# 程式要取得當前目錄的方法我們下關鍵字搜尋可以搜出一堆解決方案，沒意外的話第一個搜尋結果通常是 Directory.GetCurrentDirectory 方法(System.IO) - MSDN - Microsoft，但是這個方法在程式是由 Windows 工作排程器（Task Scheduler）啟動的狀況下就不 Work 了。

某個週末公司某個裝在 Windows Server 上的 Redis 服務掛點，從 Server Log 看到下面這段錯誤：

# Write error saving DB on disk: Invalid argument
# rdbSave failed in qfork: Invalid argument
# fork operation complete
# Background saving error

是在 Redis 做 Snapshot 的時候沒有成功，進而影響到服務的運作，Snapshot 會失敗大概會有幾個原因：

1. 記憶體不足
2. 磁碟空間不足
3. 權限不足

現在我們就來看看是哪一個原因？

有一些專案的建置作業中，某些步驟是需要對 Git Repository 做操作的，比如說在一切測試都通過之後，發行一個可執行的版本並 commit，然後 push 到待上線的 Git Repository，這時候賦予給 CI 的 Git 帳號就至少要有 Write 的權限，並且執行需要授權的操作時，自動帶上認證。

會有這個結論的起因是 Jenkins 有一個 Ruby Runtime Plugin，有很多 Plugin 會相依於它，雖然它最近一次更新的日期是在 2013 年 6 月 5 日，但依舊每個月都會有一萬多個安裝，而且跑在新版本的 Jenkins 也沒什麼問題（目前最新版本是 2.60.3），但是在 Windows 環境底下要安裝它就會有可怕的事情發生。

偶爾我們會打開效能計數器，加入幾個 Counter 像是 Processor Information - % Processor Time、ASP.NET v4.0.30319 - Requests Current、ASP.NET v4.0.30319 - Requests Queued，來觀察系統目前的狀況。

不過我們很辛苦地萬中選一挑出我們想要的 Counter 之後，想要儲存起來重複使用卻沒辦法，下面就針對將效能計數器的設定儲存起來重複使用的方法做個記錄。