【導讀】的調查，世界上百分之五十以上的Web服務器都在使用Apache。Apache服務器一個主要的特點是完全免費，并且完全公開其源代碼，由此用戶。可根據(jù)自身的需要去進行相關模塊的開發(fā)。臺性，它可以在UNIX、Windows、Linux等多種操作系統(tǒng)上運行。天有數(shù)百萬人訪問的Web服務器，Apache可能是最佳選擇。另外Apache支持許多特性，大部分通過編譯的模塊實現(xiàn)。MPM)，使用此模塊會在服務器會在服務器處理多個請求時，控制Apache的運行方式。

　　

【正文】 明珠 《 基于 Linux 的 Apache 服務器的構建 》 第 21 頁 共 27 頁 圖 啟動 HTTP服務器 啟動服務器之后打開瀏覽器，在地址欄里輸入 回車，就可以訪問 office 頁面，如圖 所示。 圖 office主頁 啟動服務器之后打開瀏覽器，在地址欄里輸入 回車，就可以訪問 puter 頁面，如圖 所示。 李明珠 《 基于 Linux 的 Apache 服務器的構建 》 第 22 頁 共 27 頁 圖 puter 主頁 啟動服務器之后打開瀏覽器，在地址欄里輸入 回車，就可以訪問 student 頁面，如圖 所示。 圖 student主頁 李明珠 《 基于 Linux 的 Apache 服務器的構建 》 第 23 頁 共 27 頁 5 異常處理 其中有一次不能訪問 apache 的頁面，檢查得知， apache 在瘋狂寫日志，而且大部分是一句話 ： “ winnt_accept: Asynchronous AcceptEx failed” ， 最多的時候寫到了 100M以上。經各方探索，最終在 apache 的手冊上找到了一個解決方法： 在 配置中設置 Win32DisableAcceptEx 參數(shù)。這樣做的原因是， apache 在某些 Windows 版本上可能兼容性不足 ，在調用 AcceptEx 接收請求時可能有問題，使用上面的參數(shù)禁用后， apache 會使用另一套方案替代（ BSD），這種方案效率稍微低些。 當時修改完該設置后，重啟 apache，測試了一段時間，感覺原來的問題確實消除了，不過當時感覺內存占用量非常明顯，但測試一段時間沒有問題就放過去了，直到前幾天 又不能訪問頁面了，然后檢查 apache 發(fā)現(xiàn)它已經 crash 了。然后打開日志發(fā)現(xiàn)最后一句： “ Out of memory！ ” —— 內存不足了。 然后對內存進行測試，發(fā)現(xiàn)一直按住 F5 鍵不停， apache 的內存就不停上漲，似乎有 一直吃光內存的意思，停止刷新后只能下降到 500M 左右了（剛啟動時是 20M）。如果不使用 Win32DisableAcceptEx 參數(shù)則明顯沒有這個問題，停止刷新后能回落到 20M?？磥硎沁@個參數(shù)的原因。 于是從 google 上尋找答案，但可惜的是沒有太多有價值的東西。只能看到 apache的官方網站已經把這個問題列為了一個 bug，甚至有些人又退回到不使用那個參數(shù)（忍受 AcceptEx failed 的風險？）。最后看到了一個說法，將 ThreadsPerChild 設為 170 以下就可以，可為什么是 170 以下呢？作者沒有 很多描述。 如果將 Threadsperchild 設為 50，無論怎么刷新內存最多到 150M 左右，但不會再長了。停止刷新后，會降到 55M 左右；如果將 ThreadsPerChild 設為 100， 內存峰值：282M，能降到 92M 左右；如果將 ThreadsPerChild 設為 550，內存峰值 2G，停止后到500M 左右。 按照上述規(guī)律，基本上找到了問題的原因，因為我的配置中原來使用的是ThreadsPerChild 550，這樣也就是內存很可能會長到 2G 以上（復雜頁面比簡單頁面耗用量大），而機器的內存設置不能支持這 么大，因此應該就是這個問題了。 所 以 最 終 的 解 決 方 法 就 是 保 留 Win32DisableAcceptEx 的 同 時 修 改 了ThreadsPerChild 150。解決完成后我推測內存瘋狂增長的原因： 首先， ThreadsPerChild 的意思是系統(tǒng)啟動時默認啟動的等待線程數(shù)，用來等待處理客戶的請求。在使用 AcceptEx 時內存增長不明顯并且可以降回 20M 左右，可能是因為 李明珠 《 基于 Linux 的 Apache 服務器的構建 》 第 24 頁 共 27 頁 用戶來了請求線程分配了一些資源，此時內存增長，但用戶訪問完成后，這些資源都釋放了（這些資源很可能都和用戶相關，沒法留著下個用戶使用，所以都釋放了）。但禁用了 AcceptEx 后，由于 apache 每個線程需要處理網絡事件，因此每個線程的資源需要就多了，并且處理完一個用戶的請求后，有些資源不想釋放，是可以對下個用戶重用的，這樣就留在了里面。由于我的線程數(shù)設了 550（估計網上很多人遇到這個類似于 “memory leak”問題的可能也都設的比較大或者機器虛擬內存較?。?，這樣當線程較多時就會出現(xiàn)達到最大內存的情況，而且這種現(xiàn)象給人的感覺就是有內存泄漏，因為初始時是 20M，來一個請求后線程分配一些資源（暫時不釋放的），這樣可能就變成了 21M，如果同時有 10 個人訪問，可能 等他們訪問完后就變成了 50M，感覺是有內存泄漏。 這樣也就解釋了為什么有人說設到 170 以下就不再出現(xiàn)內存不足了，可能因為他的機器這個配置比較合適。不過知道了上述的規(guī)律和一些推測，這個結論應該是根據(jù)自己機器的情況合理調配。 我很少接觸 apache 等 linux 上的東西，所知較少，只是遇到了問題才開始了解的上述信息，可能有很多的理解錯誤。如果能給別人一些幫助我會比較欣慰，如果誤導甚至幫了倒忙，也希望能夠理解！ 如果在 Win 下使用 Apache,而你又必須要開防火墻之類的軟件 ,那么如果你的Apache 運行有問題 ,比如 文件下載不完全或者損壞、未知錯誤信息、防火墻沖突等等 ,請參考如下 :打開你的 配置文件 ,看是否如下修改可以解決問題 : EnableSendfile Off EnableMMAP Off Win32DisableAcceptEx 李明珠 《 基于 Linux 的 Apache 服務器的構建 》 第 25 頁 共 27 頁 6 結束語 通過本次課程設計對 Linux Apache 服務器的配置和應用 ，確實積累和總結了不少的經驗，鍛煉了我的獨立工作和實際動手能力，加深了對 Linux 操作系統(tǒng) 工作原理的認識，提高了對 服務器配置，尤其是 Apache 服務器配置的了解以及其工作 原理的認識。提供了 分析問題、解決問題、概括總結的實際工作能力，對 涉及 Linux 操作系統(tǒng)以及服務器的配置方面 有 了 初步認識。 經過近了兩周的設計和開發(fā)， 基于 Linux 操作系統(tǒng)下的 Apache 服務器的 設計 基本完畢。其功能基本符合用戶需求，能夠完成 對數(shù)量不大的客戶的訪問 。但是由于課程設計時間較短，還有許多不盡如人意的地方， 其中最大的缺憾就是在基于 IP 虛擬主機的配置完成后，出現(xiàn)了不少的錯誤，后來還是在網上找到了相關的解決辦法才得以順利完成。此次課程設計中的 Apache 服務器只停留在配置成功的層面上，還不能進行真的服務 器的應用，所以 還有待于進一步完善其功能。但我從中學到了不少的道理，真正的理解到，理論與實踐之間還是有很大的距離，這必將有利于我們以后的學習。使我明白，在以后的學習中，要不斷的完善自己的知識體系結構，注意理論與實踐的結合，學知識關鍵是要學活，而不能死記死搬書本上的知識，關鍵是要會靈活應用，這樣所學到的東西才真正的學以致用，才達到了學習的真正目的！ 在本次課題程序設計中，我學到了很多東西，通過本次課題程序設計，無論在理論上還是在實踐中，我的計算機應用水平得到了很大的提升， 尤其是對 Linux 操作系統(tǒng)有 了更深一層 的了解， 這對于今后的工作和學習都是一種巨大的財富。 李明珠 《 基于 Linux 的 Apache 服務器的構建 》 第 26 頁 共 27 頁 致 謝 在這次 計算機網絡 的課程設計中，曾遇到很多的問題，單靠我個人的努力，很難按時完成該課程設計，在此，我衷心感謝我的指導老師 ——侯 利 娟 。 侯 利 娟 老師認真負責的工作態(tài)度，嚴謹?shù)闹螌W精神和深厚的理論水平都使我獲益非淺。另外，還要感謝學校領導、班主任、各位同學對我們的關懷、幫助，為我們提供了良好的設計環(huán)境以及各方面的支持。 另再次感謝 侯 利 娟 老師， 侯 老師在我做課程設計期間給我很多無私的幫助，讓我更清楚的理解了 Linux 操作系統(tǒng)的 原理和應用。 李明珠 《 基于 Linux 的 Apache 服務器的構建 》 第 27 頁 共 27 頁 參考文獻 [1]劉兵，吳煜煌 . Linux 實用教程 [M]. 北京： 中國水利水電出版社， 2020 [2]梁如軍，叢日權 . Red Hat Linux 9 網絡服務 [M]. 北京： 機械工業(yè)出版社 ， 2020 [3]傅宇旭， Apache 服務器配置和管理 [M]. 北京：清華大學出版社 ， 2020 [4]肖薇，裴植 . Linux 實用組網技術 [M]. 北京： 清華大學出版社， 2020 [5]andy，異常處理 [J]