前言bash
此文不涉及到因網絡、防火牆設備而致使的SSH不能訪問。運維常見問題,這裏不作過多的講解,主要講講出了你們所知道的,還有其餘什麼緣由會致使SSH沒法訪問呢?好了,那麼,若是想知道的話,那就繼續往下看。服務器
故障說明網絡
從監控看,咱們這兩臺服務器只是SSH端口不能訪問。經過查看監控以及簡單的網絡監測,發現系統是正常運行的,而且裏面的服務也是可以訪問到,包括zabbix-agent都正常。這個問題簡直奇葩,簡直莫名其妙。因爲進不去系統,只能重啓機器。經過日誌,咱們看到以下的信息:運維
what fuck ? 沒有分配內存給他。。。。spa
嚇的我趕忙 Google 一下!然而並無谷歌出來啥呢......尷尬,不過,老夫仍是發現了一些東西。線程
故障猜想日誌
根據百度、谷歌出來的文檔,能夠得出以下猜想:blog
1. 可能真的存在內存不足;隊列
2. 因爲某些資源限制,致使的系統資源不能分配給SSH,好比 limit 限制和 pid_max 限制;進程
故障分析
1. 排除內存不足
排除方法,經過查看 dmesg/messages 日誌並無出現 "Out of memory"。
2. 某些資源限制
經過命令 " sysctl kernel.pid_max " 得出 " kernel.pid_max = 32768 ",居然是默認大小;可是,怎麼會把 pid 用到了 32768 的呢?這個問題我尚未搞明白,主要是當時也沒法登錄系統,沒法查看當時的系統狀況。遇到這種狀況,我都是直接修改參數再說,將 "echo "kernel.pid_max=99999" >> /etc/sysctl.conf " ,而後執行 "sysctl -p"便可。等待觀察便可....這裏還有一個地方,也須要做爲查看目標,那就是 "/etc/security/limits.conf"。至於怎麼改,本身百度便可。
其餘說明
相關命令總結:
cat /proc/loadavg 0.04 0.04 0.05 1/2078 23615
lavg_1 (0.04) 1-分鐘平均負載。
lavg_5 (0.04) 5-分鐘平均負載。
lavg_15(0.05) 15-分鐘平均負載。
nr_running (1) 在採樣時刻,運行隊列的任務的數目,與/proc/stat的procs_running表示相贊成思。
nr_threads (2078) 在採樣時刻,系統中活躍的任務的個數(不包括運行已經結束的任務)。
last_pid(23615) 最大的pid值,包括輕量級進程,即線程。
cat /proc/sys/kernel/pid_max && cat /proc/sys/kernel/threads-max
查看系統最大pid 以及最大線程數。