2017年6月20日更新：今天我們最終發現，CPU 100%問題是博客后台程序所引用的開源組件 HtmlSanitizer 在處理特定html字符串時引起的，升級至最新版3.4.156可解決這個問題。 非常抱歉，今天下午14:20-14:55期間，由於同一個負載均衡中的2台服務器都出現CPU ...

非常抱歉，昨天的服務器CPU 100%問題是達到 memcached 的連接數限制引起的，不是阿里雲服務器的問題。 之前我們用的是阿里雲“雲數據庫 memcached 版”，上個周末我們換成了自己搭建——基於阿里雲“內存網絡增強型”服務器用 docker 跑 memcached ...

今天下午訪問高峰的時候，主站的Web服務器出現奇怪的問題，開始是2台8核8G的雲服務器（ECS），后來又加了1台8核8G的雲服務器，問題依舊。 而且3台服務器特地使用了不同的配置：1台是禁用了虛擬內存的臨時磁盤雲服務器，1台是啟用了虛擬內存的臨時磁盤雲服務器，1台是禁用了虛擬內存的雲盤雲服務器 ...

這篇博文記錄一下6月1日在阿里雲上遇到的奇怪的CPU 100%問題，希望多年以后能真相大白。 那天負載均衡（SLB）中只放了1台雲服務器（平時都放2台），由於是節假日，雖然只放了一台，但這台服務器的負載也沒有平時高。但在上午的時候突然出現了CPU 100%問題，然后切換到另外一台雲服務器恢復正常 ...

首先向大家致歉，這次雲服務器故障發現於17:30左右，18:30左右恢復正常，給大家帶來了麻煩，請大家諒解！ 故障的原因是雲服務器所在的集群負載過高，磁盤寫入性能急劇下降，造成很多數據庫寫入操作超時。后來恢復正常的解決方法是將雲服務器遷移至另一個集群。 下面是故障發生的主要經過： 今天上午 ...

雲計算之路系列博文分享的是我們將網站從IDC機房遷移至雲計算平台的實際經歷，目前已遷入阿里雲，這次分享的是我們對之前的博文“解決images.cnblogs.com響應速度慢的詭異問題”中遇到的雲服務器並發連接問題的猜想。不妥之處，歡迎批評指正。 這里再簡單描述一下這個問題：我們的圖片站點（靜態 ...

最近我們在服務器部署上使用了一些阿里雲競價服務器，比如在負載均衡中使用包年包月服務器與競價服務器相結合，服務器部署調整時先用競價服務器臨時頂替一下。使用競價服務器最大的風險是隨時可能會被釋放，今天之前我們只遇到過1次競價服務器被釋放的情況，那次被釋放了2台，也是在周五，看來周五是一個競價的高峰 ...

虛擬內存的，但昨天由於虛擬內存不夠用，造成了服務器自動重啟（詳見雲計算之路-阿里雲上：禁用Window ...