硬件資源應做到心中有數
場景
因爲考試人員增多以及一些未能預知的問題需要擴內存或者硬盤,因爲資源有限,服務器的內存如果少於85%又不是很穩定,這個時候因爲不清楚自己的資源有多少就會很尷尬
建議
服務器以及虛擬機安裝完畢之後,由服務器總負責人出一份服務器明細,包括:
1) 是不是做的集羣
2) 每臺物理服務器的總的ip,cpu核數,內存,磁盤空間以及上面的虛擬機有哪些
3) 每臺物理服務器已用和所剩的內存,磁盤空間還剩多少,並給出預警值
4) 每臺虛擬機分配的cpu核數,內存以及磁盤空間數
參考:
運維人員和操作文檔不可缺
場景
某臺虛擬機的內存不夠用了,或者磁盤要擴盤,這個時候就要涉及到擴充,而vsphereclient一般只有運維人員比較熟悉,運維人員不在就略顯尷尬
建議
1) 提前令運維相關這方面的負責人把擴內存和磁盤以及如何操作vsphereclient的文檔準備好
2) 找至少兩個人對這塊熟悉輪崗,以備不時之需
服務器監測有學問
場景1
臨時徵用電腦顯尷尬,比如在用某某的電腦監測呢,可能因爲他的電腦上有代碼,這時候就尷尬,然後監測着突然發現230飈的很高,230是什麼來着什麼來着,這就是監測虛擬機是的命名問題了
建議
提前確定好是用自己的電腦還是學校的電腦,然後確定好就不要動了,就固定下來,然後建議每臺最多監測6臺虛擬機,命名以ip+虛擬機的服務命名
場景2
有人來看服務器的情況詢問監看服務器的人一些界面的基本東西,如咱們都需要看些什麼啊,這個cpu%都飆到100多了怎麼還沒有崩啊,結果被問的一臉懵,也很沒有存在感
建議
1) 由運維人員或專人負責出一個介紹top命令的文檔,對界面上的東西進行一個簡介,給出一些建議警戒值
2) 負責看服務器的人弄清這些常見的屬性,並在中場結束後給出一些簡單的分析,如內存數,cpu的一個跳動幅度,什麼服務的壓力是突然增加的交給負責人(如這次的李總),這樣既可以熟悉有什麼服務,也可以收穫一些linux方面的知識
場景3
單核cpu一般飆到75%-80%達到一個滿負荷,下面的cpu%一般是360%達到滿負荷,正常情況下低於這些值很多是很正常的,但是在19號上午第二場考試的時候因爲調查問卷的原因數據庫崩掉了一次,已經很脆弱了,原因也沒有完全排查出來,結果突然從40飆到了100多,平常情況這都不叫事但這種情況下就要立即上報,果然因爲點擊了設計表而導致了鎖表,這個時候服務器監測就起到了作用
建議
1) 作爲服務器監測人員更應該關注着出現的問題,來及時調整監測的重心,既能收穫開發或線上的知識,也能及時防止因爲服務器導致項目不能鄭航使用
2) 學會具體問題具體分析
所有服務都要設置自啓
場景
因爲學校斷電,導致所有服務器都關機了,導致zabbix服務關閉,米老師想去看的時候,沒有及時把服務啓動
建議
在正式應用之前都要做關機重啓實驗,保證能正確運行後,向總負責人驗收確認
附錄
查看內存
free –m
查看存盤
df –h
清理緩存
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches
防火牆
最好是開着防火牆,把每個服務的端口號開着