linux查看apache進程，以及類unix上開啓，關閉，重啓

linux查看apache進程，以及類unix上開啓，關閉，重啓

（文檔暫存）
在linux下如何查看apache的請求進程數:
要想在 Linux系統下查看 Apache的負載狀況，最簡單有效的方法就是查看Apache Server Status，在沒有開啓Apache Server Status的狀況下，或安裝的是其餘的Web Server，好比Nginx的時候，可使用下面的命令查看。
#ps -ef|grep httpd|wc -l
1388
統計httpd進程數，這個請求會啓動一個進程，使用於Apache服務器。
表示Apache可以處理1388個併發請求，這個值Apache可根據負載狀況 自動調整
#netstat -nat|grep -i "80"|wc -l
4342
netstat -an會打印系統當前網絡連接狀態，而grep -i 「80″是用來提取與80端口有關的鏈接的, wc -l進行鏈接數統計。
最終返回的數字就是當前全部80端口的請求總數。#netstat -na|grep ESTABLISHED|wc -l
376
netstat -an會打印系統當前網絡連接狀態，而grep ESTABLISHED 提取出已創建鏈接的信息。 而後wc -l統計。
最終返回的數字就是當前全部80端口的已創建鏈接的總數。
#netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
FIN_WAIT_1 286
FIN_WAIT_2 960
SYN_SENT 3
LAST_ACK 32
CLOSING 1
CLOSED 36
SYN_RCVD 144
TIME_WAIT 2520
ESTABLISHED 352
返回參數的說明以下：
SYN_RECV表示正在等待處理的請求數；
ESTABLISHED表示正常數據傳輸狀態；
TIME_WAIT表示處理完畢，等待超時結束的請求數。

在類Unix系統上如何中止和重啓Apache 。
Windows NT/2000/XP/2003的用戶請參見以服務方式運行Apache ，Windows 9x/ME用戶則參見在控制檯中運行Apache 。

簡介
爲了中止或者從新啓動Apache ，你必須向正在運行的httpd進程發送信號。有兩種發送信號的方法。第一種方法是直接使用UNIX的kill命令向運行中的進程發送信號。你也許你會 注意到 你的系統裏運行着不少httpd進程。但你不該該直接對它們中的任何一個發送信號，而只要對已經在PidFile中記載下了自身PID的父進程發送信號。 也就是說，你沒必要對父進程之外的任何進程發送信號。你能夠向父進程發送三種信號：TERM、HUP、USR1 ，咱們過一下子再進行詳細的說明。

你能夠用下面這樣的命令來向父進程發送信號：

kill -TERM `cat /usr/local/apache2/logs/httpd.pid`

第二種方法是使用下面將要描述的httpd二進制可執行文件的 -k 命令行選項：stop、restart、graceful、graceful-stop 。不過咱們推薦你使用apachectl控制腳原本向httpd二進制可執行文件傳遞這些選項。

當你向httpd發送信號後，你能夠這樣來讀取它的進行過程：

tail -f /usr/local/apache2/logs/error_log

你能夠修改這些示例以適應你的ServerRoot和PidFile 設置。
當即中止
信號：TERM
apachectl -k stop
發送TERM或stop信號到父進程可使它馬上殺死全部子進程。這將花費一些時間來殺死全部子進程。而後父進程本身也退出。全部進行中的請求將被強行停止，並且再也不接受其它請求。
優雅重啓
信號：USR1
apachectl -k graceful
USR1或graceful信號使得父進程建議子進程在完成它們如今的請求後退出(若是他們沒有進行服務，將會馬上退出)。父進程從新讀入配置文件並從新打開日誌文件。每當一個子進程死掉，父進程馬上用新的配置文件產生一個新的子進程並馬上開始伺服新的請求。

重啓代碼的設計可以確保MPM進程控制指令的正常運做，也就是在重啓過程當中確保有適當數量的進程和線程以響應客戶端的請求。它是這樣 StartServers的：若是在一秒鐘之後尚未新建立StartServers個子進程，則建立出足夠完成如今任務的子進程個數。所以，代碼除了保 有可以維持服務器的現有負載數量的子進程外，也確保StartServers按你的意願運做。

使用mod_status的用戶會注意到在USR1信號發出後，服務器的統計信息沒有被清零。代碼被寫成既能將你服務器沒法伺服新請求的時間降至最少(這些請求將被操做系統放到隊列裏，使得它們不會丟失)，又能聽從你的參數 優化。爲了作到這一點，它將在從新生成子進程的過程當中，在scoreboard上保存全部子進程的狀態。 mod_status還會將那些在優雅重啓前就已經開始而沒有結束伺服請求的子進程用一個"G"來標誌。 目前，日誌滾動腳本還沒法使用USR1來肯定全部寫入預重啓日誌的子進程都已結束。咱們建議你在發出了USR1信號後等待一個適當的時間，而後再對舊的日 志作處理。好比說若是對於一個窄帶用戶來講，大部分的點擊處理將在10分鐘以內完成，那麼你應該在處理舊的日誌前等待15分鐘。 如 果Apache重啓時發現配置文件有誤，那麼父進程將不會重啓，而是報錯並退出。在優雅重啓的狀況下，它將在處理中的子進程存在的狀況下維持它的存在(就 是那些被要求在處理完它們的請求後"優雅退出"的子進程)。若是你要重啓服務器，這將致使一些問題：它將不能綁定到它的監聽端口。在執行重啓以前，你能夠 用 -t 命令行參數來檢查配置文件語法的正確性(參見httpd)。但這仍然不能保證服務器必定能夠正確的重啓。爲了從語法和語義兩方面檢查配置文件，你能夠用一 個非root用戶來啓動httpd。若是沒有錯誤，它將嘗試去打開套接字和日誌文件，繼而因沒有root權限而失敗(或是由於如今運行的httpd已經綁 定了這些端口)。若是是由於其餘緣由那麼就多是一個配置文件產生的錯誤，你就應當在進行優雅重啓以前改正這個錯誤。當即重啓 信號：HUP apachectl -k restart 向父進程發送HUP或restart信號會使它象收到TERM信號同樣殺掉全部的子進程，不一樣之處在於父進程自己並不退出。它從新讀入配置文件、從新打開日誌文件。而後產生一系列新的子進程來繼續服務。 使用mod_status的用戶會注意到在HUP信號發出後，服務器統計信息會被清零。 若是你重啓時配置文件有誤，那麼父進程將不會重啓，而是報錯並退出。參見上文中避免的方法。優雅中止 信號：WINCH apachectl -k graceful-stop WINCH或graceful-stop信號使得父進程建議子進程在完成它們如今的請求後退出(若是他們沒有進行服務，將會馬上退出)。而後父進程刪除 PidFile並中止在全部端口上的監聽。父進程仍然繼續運行並監視正在處理請求的子進程，一旦全部子進程完成任務並退出或者超過由 GracefulShutdownTimeout指令規定的時間，父進程將會退出。在超時的狀況下，全部子進程都將接收到TERM信號並被強制退出。 在"優雅"狀態下，TERM信號將會當即停止父進程和全部子進程。因爲PidFile已經被刪除，你將沒法使用apachectl或httpd發送該信號。 graceful-stop容許你同時運行多個相同配置的httpd實例。這在對Apache進行平滑升級的時候是一個很是有用的特性。不過它在某些配置的狀況下一樣可能會致使死鎖和競爭條件。 必須注意確保諸如Lockfile和ScriptSock之類的磁盤文件包含服務器的PID ，而且可以安全的共存。然而若是一個配置指令、第三方模塊或持久CGI使用任何磁盤鎖或狀態文件，必須注意確保多個httpd運行實例之間不會爭搶文件。 你還必須防止潛在的競爭條件，好比使用rotatelogs風格的管道日誌。運行中的多個rotatelogs實例企圖同時滾動同一個日誌文件可能會致使互相破壞對方的日誌文件。 附錄：信號和競爭條件 在Apache 1.2b9 以前，有不少關於重啓和死亡信號的競爭條件。關 於競爭條件的一個簡單描述是：一個時間敏感的問題，若是一些事情在不適當的時間或以不恰當的順序發生，它將做出你不指望的反應；若是一樣的事情在恰當的時 間發生，則不會出現異常。憑藉那些擁有"正確"特性設置的體系結構，咱們儘可能避免了它們的出現。但值得注意的是，仍然有一些競爭條件存在於這樣的體系結構 中。 使用物理磁盤的ScoreBoardFile就有損壞ScoreBoard的潛在危險。這將發生在"bind: Address already in use"(HUP以後)或"long lost child came home!"(USR1以後)時。前者是一個致命錯誤，然後者則會使服務器丟失ScoreBoard的一個記錄。因此咱們建議多使用優雅重啓，偶爾使用硬 重啓。這些問題很難解決，但幸運的是大多數結構並不須要ScoreBoard文件。而若是你須要這樣的結構，你能夠參考ScoreBoardFile文 檔。 當 每一個子進程在一個HTTP的持續鏈接(KeepAlive)中涉及到第二個併發的請求時，全部的結構都會或多或少存在競爭狀態的問題。它將在讀取了請求而 沒有讀取任何請求頭以後馬上退出。這個修復對於1.2來講來得太晚了。但由於持續鏈接的客戶端已經考慮到網絡延時和服務器超時會形成相似的狀況，因此理論 上說，這不是一個太大的問題。而實際上彷佛也沒有任何影響：在一個測試案例中服務器在一秒以內被重啓了20次，而客戶端卻成功的瀏覽了網站，並且沒有任何 破損的圖片或空文檔。