阿里雲新服務器遇到的問題之--完結

寫在前面

由於原來的描述錯誤，內容作了更正。對於涉及T系列服務器的評論，請忽略。咱們提供的是C系列計算型。由於着急，提供的錯誤信息請諒解。

前言

公司一直用的阿里雲服務器，系統是windows server 2008。由於作技術，瞭解作一個雲服務有多難。阿里起家早，當時的種種壯舉也早已耳熟能詳。本着技術人的同情與傾佩，一直很相信阿里雲。結果這兩天碰到了一個bug，阿里雲對這個事情的處理態度讓人心寒。回想去年嘲笑騰訊雲由於人爲失誤致使用戶數據丟失，結果僅僅賠付購買服務器的錢，如今覺着好打臉。是天下烏鴉通常黑呢？仍是尾大不掉呢？

原由

客戶反應，他遊戲的階段不對了，每一個階段很是長。我上服務器查看，錯誤日誌沒有，數據庫異常語句沒有，cpu正常，內存正常，磁盤正常，惟一發現內存有硬錯誤，而且有點多。上網查了一下，沒有什麼介紹爲何內存硬錯誤，有一點介紹是硬件讀寫超時致使的。找不出什麼緣由，就是感受系統有點卡，看了一下配置，與咱們正常的服務器沒什麼區別，惟一的區別是系統cpu不同。

調查

那隻能調試了。從新編譯了版本，上傳上去，開啓遠程調試，發現GetTickCount64調用異常。

這個函數參考 https://docs.microsoft.com/zh-cn/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount64

Retrieves the number of milliseconds that have elapsed since the system was started.

按照微軟的說法，就是返回系統啓動到如今經歷的毫秒數。而且咱們使用了這麼久，沒出過問題，也很是精確。

可是調試發現，GetTickCount64兩次獲取差值是10000，表示正好是10秒鐘，結果服務器上通過了40多秒才返回。也就是10000個系統時鐘的差值是40多秒，不是10秒。

好奇怪，第一次遇到這個問題。詳細查了一下新系統的cpu，發現與咱們原來使用的都不同，是新一代升級過的。

 

原來咱們之前的服務器是Intel Xeon CPU 8163 如圖

 

新的服務器是 Intel 8269cy，如圖

好吧，新產品上線，不免有問題。只好給阿里雲提工單。

不爽的經歷

咱們不是第一次給阿里雲提供工單了，公司大，須要流程，OK能夠理解，可是此次沒了互聯網公司敏捷的感受，多了臃腫的政治化寡頭的味道。

第一天提，把問題描述清楚，說咱們什麼語言，調用了什麼api，如今是什麼現象，理論上是什麼現象。

下午有人問了一遍大致問題。而後就是請等待，正在找技術調查。

次日第二我的上線問，結果仍是個客服。說是技術，隨便說兩句話就露餡了。讓咱們提供測試結果和代碼。這……好我忍，寫了測試代碼。

int main() { long long stick = GetTickCount64(); long long etick = GetTickCount64(); cout << "start tick " << stick << endl; time_t stime = time(NULL); cout << "start time " << stime << endl; while (etick - stick < 10000) { etick = GetTickCount64(); } cout << "end tick " << etick << endl; time_t etime = time(NULL); cout << "end time " << stime << endl; cout << "end tick - start tick = " << etick - stick << endl; cout << "end time - start time = " << etime - stime << endl; char inchar; cin >> inchar; }

而後在正常的服務器上跑一遍，OK，結果都是對的，時間也是10秒。

在異常的服務器上跑一遍，嗯？？？奇異的現象發生了，結果也是對的。

下面是結果

 

 

 這這這，徹底出乎個人意料了。原本覺得，GetTickCount64調用有問題，也就是每次加1，並非1毫秒了，而是幾毫秒，或是幾十毫秒。可是time是正常的，那麼結果就是GetTickCount64返回值10000的差值應該是time返回值差值的40多。如今都是同樣。我慢慢的點開系統右下角的時間，靈異的事情發生了。以下視頻

 

系統時間都變慢了！！！

這足夠能夠說明問題了吧，咱們把視頻發給阿里雲。結果他們說他們測試下來正常的。給咱們了他們的視頻，以下

可是從阿里雲本身提供的視頻上面能夠看出。不論是桌面仍是系統時間（由於他們是在線，要求咱們調查，過了幾分鐘立馬回的），都不是咱們有問題的系統。也就是他們隨便找了一臺正常的服務器，錄了一個視頻給我，而後告訴咱們沒問題。

退款

咱們要求退款，而後買一個新的，阿里雲不一樣意。

沒辦法我打杭州12315消費者協會電話，被告知，阿里雲屬於商業產品，他們不受理，就算是我的買來使用也不行，只能走法律途徑。回到工位給同事說，感受就是，十幾千米上班的路程，覺着太遠，問一下有沒有公交，被告知，只有飛機，愛坐不坐，否則就走着過來。

強行扯皮

沒辦法，只能死磕了，由於服務器是客戶帳戶買的，不能說上一個不能使用就讓客戶直接買新的。扯皮了很久，終於贊成退款。可是要500多天，錢才能夠到帳。能夠的，這很霸道。

新服務器上線

晚上買了新服務器，查看系統時間，正常。配置好，啓動。打開遊戲，驚呆了！！！遊戲階段變快了。也就是原來10秒鐘的時鐘，如今也就二、3秒。這……

正在準備調試的時候，好了？！戰戰兢兢等了幾十分鐘，沒有異常。OK，回家。

問題重現

早上來到，就被告知，階段變慢的問題又出現了。黑線~~

猜想

昨天我就猜想是否是由於咱們C6的系統，用的是C5的鏡像致使的。可是當時由於客戶着急，先應付一下，不用鏡像，配置太麻煩了。因此第二個新系統仍是用的鏡像。如今咱們重裝系統，不用鏡像，再次測試，由於問題復現須要次日……

無解

剛剛把經過鏡像建立的服務器重裝系統，啓動，我還沒配置好，又出現時間走的慢的問題了。求救哪位老哥知道解決方法

回覆

不少同窗建議換一個實例，實際上咱們第二個新的實例，就換了一種，不過仍是有問題。關鍵是這個問題，阿里雲沒有給明確的說明，他那麼多實例，從幾百到幾千一個月，不可能做爲用戶幫他們一個個測試到底哪一個是好用的。就他這個退款速度，實在是也不敢試啊。

對於有的同窗說的，使用突發性能實例的問題。是我描述信息錯誤，咱們購買的是計算型實例。以下圖，通常都是4核8G的。根據後續要求，再提高。

 

後續

阿里雲終於解決了，說是換了一個物理機，而且電話回訪，作了解釋。算是挽回一分。等待週六週日看看狀況吧。

問題復現

還沒等到週一，剛剛過了一會，問題復現。如今已經呆住……

最新進展

能夠打臉某些人了。首先感謝樓下的阿里雲產品經理。提醒我是C6的服務器，不是T6的實例，他們也在跟蹤解決，而且有回電詢問問題詳細狀況。等待中……

完結

週五晚上，與阿里雲那邊協做了好晚，感謝阿里雲提供的支持。目前兩個實例都是正常的。

原文出處：https://www.cnblogs.com/studywithallofyou/p/11556152.html