題目1 很簡單，某mysql數據庫服務器A，出現mysql鏈接過多，導致前端web服務器無法打開數據庫連接，現在，由你來解決這個問題。 題目1之問題1：你會以怎樣的步驟來處理這個事情。請注意，步驟 題目1之問題2：如何分析這一問題，共有幾種可能性，每種可能性的分析方式，判別標準是什么。 題目1之問題3：針對不同可能性，給出盡可能完整的解決途徑。 不要告訴我您會修改mysql鏈接參數，如果您只想到這一條，不要來信了。 題目2： 某linux服務器平時負載很輕，cpu在10%-20%之間，但是每周都會有幾天在不定時間突然躍升到100%，然后導致該服務器拒絕一切響應（包括ssh鏈接在內），無奈之下只能電話通過機房重啟。 現在，負載飆升時無法連接ssh，暫時無法確認負載飆升原因，請給出你想到的處理步驟和解決思路。 不要告訴我您會設置一個24小時短信提醒，那是最基本基本的了。 題目3：某linux 服務器一直負載很輕，但是會突然拒絕正常的服務，此時仍然可以登錄，仍然看到在線很輕的負載，請告訴我你分析排查的思路。
參考答案： 1:數據鏈接過多，這是最常見的問題，但是其實也是這里最重點的問題 子問題1，為什么提到步驟，很少有人告訴我，第一步是盡快臨時恢復線上應用，這就是意識！ 恢復線上應用有幾種場景，最簡單的是show processlist 然后kill掉阻塞的processlist，其次是重啟數據庫，如果數據庫重啟后又會快速堵塞，那么要盡快從前端代碼中找到阻塞點，臨時屏蔽掉某些導致 阻塞的功能，以及增加同時鏈接參數，為了保證在你徹底解決這個問題的這段時間里，你的前面網頁是可以順利打開的。 這里存在一個小問題，如果是面試我會單獨提出來，你怎么保證連接過多的情況下，后面還能看到show processlist，這里的竅門是，前段務必不要使用root連接數據庫，這樣mysql后端root仍然會多出一個進程來滿足查詢要求。 之前我跟工程師說這個問題，他們果然換了一個賬號，一個不叫root但是權限是root的賬號在前端連接數據庫，害的我郁悶了n多天找不到阻塞點。 第二步是確認阻塞點和阻塞方向，為什么說阻塞方向，因為數據庫的阻塞，并不一定都是數據庫造成的，連帶影響非常多，通過show processlist ，如果看到大量的Lock，那么其一是代碼優化，其二是改造數據引擎，如果Lock不多，而執行中查詢很多，其一是索引優化，其二是數據庫參數優化，有人 說會看慢查詢，慢查詢很重要，但是不夠的，對于高并發來說，一個常見SQL執行0.1秒都是不可容忍的，通常這是索引不徹底造成的，比如簡單來說 ，如果有個同城速配的常見SQL select * from users where sex='女' and area='廈門' order by lastlogin desc ，這么一個查詢，你會怎么建立索引？我告訴你，三鍵復合索引！少一個效率都不行. 而且順序還必須保證！ 之前非常多發現因為復合索引不到位，導致數據查詢執行0.05 -0.1秒的準慢查詢，通過set profiling是可以分析的，優化后效率提升10-100倍。 此外，連帶影響也是一個大問題，比如說，有時候你會看到大量SLEEP鏈接，那多半是前段執行完SQL沒有及時關閉，之前我的博客如果有認真閱讀的，會看 到因為echo影響，因為memcache鏈接阻塞影響都會存在，當然還有一種，網絡帶寬阻塞影響，Waiting for net狀態阻塞， 這里確認阻塞點和阻塞方向，最關鍵的是思路要足夠發散，不要只看數據庫配置，或者數據索引；前端程序，網絡環境（曾經因為別人的外掛程序，以及代碼 不嚴謹，導致內網網卡阻塞，數據庫連接過多）都需要考慮周全，所以有些答案caoz回復說思路不開闊，就是這個原因。這里具體分支場景很多，caoz也只 是列舉一二，僅僅配置優化，就有無數參數可以提出。 第三步是解決，這里通常要多向考慮，什么叫多向考慮，分析問題如果夠全面，就會發現問題往往是伴生出現，比如出現阻塞，也許你優化后臺參數的確可以 解決，但是如果前端調用腳本也優化一下，可能就會得到更好的效果，那么這里要強調的是，解決問題必須給出明確的數字支持，比如升級后，性能提升多少，負載 支撐提升多少，可支持多少并發，支持多少同時連接，由于經驗問題，很多人估算不準，這不是問題，幾次訓練下來就準了，但是如果不去估算，那么永遠都沒有經 驗，永遠估不準，這其實也是意識。 但是到了這里，事情還不算完，還有一步！ 第四步是什么呢？無人值守腳本 千算萬算，不能不算，無人值守情況下，數據鏈接過多怎么辦，有幾種解決方案，重啟數據庫未必明智，一個很簡單的原因，如果是myisam，重啟可能 導致數據索引出錯，如果是innodb，可能重啟需要很長時間，最有效的，還是直接kill掉阻塞的查詢進程。然后記錄日志以備后續分析。 而且，按照caoz的經驗，不要等鏈接阻塞再去kill掉查詢進程，應該在鏈接數超過報警閾值的時候直接kill掉執行時間過長的SQL查詢進程，有人會問，哪里有這樣的系統？自己寫一個cron腳本，花不了一個小時的。 第二個問題，在上頭啰啰嗦嗦有羅列 第三個問題，場景很多，簡單列如下 1：數據庫讀寫鎖，換成innodb引擎是最快的方法，那么讀寫分離做主從也是一種方案，不過要考慮成本還是蠻高的。此外就是讀取數據多用緩存，寫入過多怎么辦？也用緩存！緩存回寫，同主鍵寫入合并，具體策略不多說了，這是caoz看家的本事。 2： sleep鏈接太多，前端代碼檢查，找到關聯影響點，盡快釋放mysql鏈接 3： 慢查詢和準慢查詢太多，索引優化，以及數據庫拆分優化（忙閑拆分，主鍵hash拆分，還有其他拆分模式），索引碎片整理（數據索引優化或重建，半夜偷偷干吧） 4： 網絡阻塞，減少控制數據庫操作的數據流量，改代碼去吧 5：i/o壓力過大，有些參數可以設置的，比如innodb的數據提交不一定每次操作都提交的。 總之，優化方案之多，難以全面羅列，可以整理如下 優化分為架構優化，比如引入緩存層，引入主從架構，引入中間件，分庫分表，都屬于架構優化。 代碼優化，減少重復和不必要的查詢，合并重復查詢，良好的代碼習慣 DBA優化，索引優化，存儲引擎優化，mysql參數優化，數據庫版本優化 操作系統優化，文件系統優化，linux內核優化， 對系統架構的理解，有助于從不同層面分析問題，思路要發散，不要只看數據庫 對數據查詢的理解，多使用set profiling，對每一個停留狀態，每一個耗時和資源分配，索引的每一次查詢方式要心理有數。 對數據庫參數的理解，要知道每個參數對i/o的影響，對查詢執行的影響，對每個SQL進程執行步驟（set profiling可以分析SQL執行步驟）的影響是什么， 對程序的理解，要知道程序為什么請求數據，請求數據的目標和方法是否合理，是否有重復和無效的請求占用資源。請求數據后是否長期閑置鏈接，是否存在不合理的關聯影響。 對系統的理解，是否存在系統配置短板，導致數據庫性能無法發揮。 第二題 簡單說，關鍵是無人值守腳本，無人值守腳本要 1：記錄負載提升時的系統狀態和進程列表，進程資源占用數據。 2：自動對突然增加負載的用戶或系統進程進行處理， 3：記錄處理結果和處理后的狀態。 無人值守記錄是系統維護的關鍵點，有很多人用第三方工具，當然很好，但是必要的時候必須親自做一些監控腳本，這東西用什么寫都可以，php,perl，ruby都無所謂，能記錄，能執行關閉進程和啟動進程的操作就可以。 第三，這種問題當然有很多種可能，分析日志也好，分析系統狀態也好，不過根據caoz經驗，出這種問題，80%以上是系統某參數越界，這種越界還蠻 多的，比如最多文件打開數，系統最大連接數，syn_backlog，甚至最多文件節點數（看硬盤空間還有，其實inode沒有了，大量瑣碎小文件就會出 這個問題！）還有，ip_contrack什么參數，可能導致網絡丟包嚴重， 所以這個問題的關鍵是，對linux各項內核參數必須有深入了解，有時候你看服務器跑不動了，可能改一下參數馬上就好了，但是改哪個參數，怎么改，這就只 能是經驗和搜索技巧了。 其實caoz想到的也不完整，后來有人給caoz很多提醒，比如前端mysql,memcache鏈接應該設置超時參數云云。不過總體來說 意識到位（先臨時處理立即恢復線上應用，再徹底處理，處理要評估并且做出預判，優化與故障自動處理要并行，不能100%依賴優化結果） 思路開闊（dba的問題別死盯著dba，謝謝） 經驗豐富，上述列到的，您列出了幾個？ 答案就此公開，謝謝各位的來信。真有不少人才，讓caoz興奮！ 來自：http://hi.baidu.com/caoz/blog/item/6020720e81ec12c67bcbe14b.html

轉載于:https://blog.51cto.com/dadloveu/541505

總結

以上是生活随笔為你收集整理的linux 系统工程师 面试 开放式问答的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。