Servers 服務器

  • 用 Windows Remote Desktop Connect 連 xrdp 閃跳

    TL;DR 在 Ubuntu Desktop 開啟 xrdp。第一次遠端進入沒問題。但要遠端登入就會閃跳。原來是先前的工作階段鎖住了。新連線無法恢復原來的工作階段會出現閃跳。 問題 首先先查看有幾個現有的連線工作階段 來看看c1這個連線工作階段是不是有畫面的工作階段。 🧨Bingo! X11 GNOME 就是之前連線還沒有中斷的工作階段。用以下的指令砍了c1 再來確認現在現有的工作階段是什麼。 如果沒再看到了。最後就重新啟動遠端桌面服務 xrdp 就好了. 問題: 👉1. 為什麼不能像 Windows 一樣回後原來的連線工作階段呢? XRDP 不能重新再連上己經在跑的本地 GNOME X11 session (Display=:10).新的連線會變成:11 👉2. 為什麼會出現這現象? 其實內建的設定因為安全原因,會在5分鐘自動把桌面鎖上。只要去設定裡把自動鎖上的解除就好了。我的 Server 平時是不插銀幕的。只有遠端連線,所以解除沒有安全上的顧慮。像圖下的選項。自動把自動銀幕鎖解除後,我之後的連線就是原來的工作階段了。

  • 別用平均值(Average)或中間值(Median)來評價服務器反應效能,應該用百分位數(Percentile)

    在打合約或工作聲明中。對於伺服器或雲端服務的反應時間 (response time) 和延遲 (latency),以前都會用平均值 (average) 或中間數 (median) 來評量。但是只用平均值或中間數來看,會無法完整的看出整理的延遲反應。 就拿以下的圖表為例,當一個專業的網管,單純的看延遲反應,在下午一點五十一分左右,系統出現了不穩定。延遲衝到了800毫秒。一連持續到約二點零七分左右。直覺可能是其中一個服務器掛掉了。但又自我修復好了。 所幸暴衝不是一直持續,所以可能不以為意。 毫秒 圖一:系統3小時的反應時間 如果是早期的服務水平,這時候會調出平均服務圖表來確認整體的服務是不是有被影響到。一般的服務水平都會訂在 99% 的情況下,服務水平會在 200 或 250 毫秒以下。以平均表來看,在反應最慢的時候也都還在 160 毫秒內。所以看起來也是沒什麼異狀。  圖二:系統3小時的平均反應時間 但是如果是使用 90 百分位數的圖表來看,那可就不同了。90 百分等級是一種描述統計指標。意思是指,在百分之九十位數 (90th percentile) 的正常狀況之下,服務狀況還是可以持續在 200 毫秒內嗎?  圖三:系統3小時的90百分等級時間 圖三指出在十二點三十三分時,百分之九十的正常服務就己經飇高了。一直攀昇到一點五十一分到最高峯約 500 毫秒,之後才開始穩定下來直到約二點零三才恢復過來。那其實不穩定的時間比相象中更久,快要 90 分鐘系統的穩定性一直都是在服務平均水平之外的。 所以結論就是在管理系統時,不能只單看平均服務的數據來確定服務水平是否有達標。利用百分位數的圖表可以更了解系統淺在表現狀況。主統雲端服務都有提供百分位數的監控(如 AWS),請大家多加利用。 參考文獻: 1. https://www.elastic.co/blog/averages-can-dangerous-use-percentile 2. https://azure.microsoft.com/zh-tw/support/legal/sla/cloud-services/v1_5/ 3. https://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Percentiles

  • chaoman.com 現在用 HTTPS 啦!!

    有鑑於現在主流的瀏覽器會把一般的 HTTP 劃分成不安全未加密的網站,炒麵決定購入 HTTPS 認證讓本站也加入綠色認證的行列。雖然本站無廣告,無個資的疑慮,但就為在技術上不能落後,現在一 都連線都會通過 HTTPS 加密。還有,網站全面改版。新的板模是用Gantry5 的架構,更彈性更流暢。2019 一開始就來個新氣象。 開心啦!