嵌入式Web訪問時的內存丟失問題

由于嵌入式技術的發展，嵌入式Web服務器軟件越來越大，對硬件的要求也相應地提高，但在工業現場的底層控制中，一般嵌入式系統的硬件配置都不是很高，導致了軟件和硬件的沖突。本文就是對實際應用過程中，偶爾出現的Web頁面訪問出錯問題進行深入的研究。

1 嵌入式Web在系統中的應用
??? 多支點觸發系統包括以下幾個模塊：控制臺模塊、網絡觸發源模塊、被觸發設備模塊。其中，網絡觸發源和被觸發設備都是掛載在總線上的，通過現場總線可以將系統各個節點相互連接起來以方便管理。嵌入式web就是應用于網絡觸發源模塊中，它負責控制臺和被觸發設備之間的通信。控制臺通過瀏覽器訪問網絡觸發源，在Web頁面上完成相應控制操作后，由網絡觸發源把操作命令發送到總線上，被觸發設備從總線上接收到命令后，完成相應操作。在網絡觸發源模塊中，Web服務器采用的是Boa，嵌入式操作系統采用的是uClinux，處理器采用的是Sam-sung公司的S3C44BO。多支點觸發系統結構如圖1所示。

2 Boa的運行流程及出現的問題
??? Boa是單任務的http服務器，源碼開放，性能高。與傳統的Web服務器不同，它并不對每個進入服務器的連接開辟新的進程，所有活動的http連接都在內部進行處理，而只為每個CGI連接啟動新進程。在已進行的測試中，Boa服務器比其他的Web服務器要快，所以它應用在嵌入式系統中是具有良好前景的。圖2是Boa基本的運行流程。

?在Boa運行過程中，用戶請求初始Lo-gin頁面時，系統能正常響應操作。當用戶輸入正確的Login信息，要實現頁面跳轉時，PC機上的瀏覽器里面不能正確瀏覽，提示錯誤：“502 bad gate-way The CGI was notCGI／1．1 compliant”。由于運行的是CGI程序，通過調試和查看錯誤日志，發現系統停留在步驟⑤～⑦間。在排除CGI程序錯誤后，通過串口調試終端打印出的錯誤信息發現：在執行CGI程序時，內核申請內存時出錯，提示申請的內存塊不能得到，即內存丟失。

3 系統內存丟失分析
3．1 uClinux的內存管理
??? uClinux不能使用處理器的虛擬內存管理技術，它仍然采用存儲器的分頁管理。系統啟動時對存儲器分頁，加載應用程序對程序分頁加載。由于沒有MMU管理，所以uClinux采用實存儲器管理。uClinux系統對內存的訪問是直接的(它對地址的訪問不經MMU，而是直接送到地址線上輸出)，所有程序訪問的地址是物理地址。那些比物理內存還大的程序將無法執行。

uClinux將整個物理內存劃分成為4 KB的頁面。由數據結構page管理，有多少頁面就有多少page結構，它們又作為元素組成數組men_map[]。物理頁面可作為進程代碼、數據和堆棧的一部分，還可存儲裝入的文件，也可作緩沖區。
??? uClinux用標準Linux內核變型BuddySystem機制管理空閑物理頁面。
3．2 內存丟失原因
??? 由于uClinux提供了跟普通Linux一樣的內存分配器，普通Linux中缺省的內存分配器是使用“2的冪”的分配方法，這樣可以快速找到符合要求的內存區域。在系統開發過程初期，采用的就是“2的冪”的分配方法。如果一個應用程序要求(X)KB內存空間進行裝載，則實際使用占用的內存空間大小為Y=2m(Y≥X)。試想一個65 KB應用程序，如果按照“2的冪”的分配方法，就必須分配128 KB(2的7次方)的內存空間，這樣就有63 KB的內存空間不能被利用上。這對于小內存的嵌入式系統來說是相當大的浪費。
??? 多支點觸發系統運行時，嵌入式操作系統uClinux使用“2的冪”的內存分配方法，大多數情況下都能正常工作。但在不斷反復測試中，偶爾會出現上述頁面出錯問題。錯誤的原因是不能獲得足夠的內存加載程序。通過調試終端，用free命令查看系統內存分配情況如表1所列。

??? 由表1可以看出，空閑的內存空間還有1560 KB，而應用程序所需的內存空間為400多KB，但是內核認為并沒有足夠的內存空間用來加載程序。例如一個系統內存大小為1 MB，有400KB的空閑內存，為了裝載一個應用程序需要分配100 KB的空間。大家可能覺得這個需要肯定能得到滿足，然而，由于uClinux必須給應用程序分配連續內存空間的特性，所以必須有100KB連續的內存空間才能滿足這個需要。而當系統內存分配如圖3所示時，最大的連續內存塊的大小只有80 KB，這樣是沒有辦法分配給這個應用程序的。這就是系統中頁面訪問出錯的問題所在，雖然有足夠的空閑內存空間，但是沒有應用程序所需的連續內存空間。

??? 這就是內存丟失問題。雖然系統會顯示大量的可用內存，但是應用程序卻不能得到。

4 內存丟失問題的解決
??? 由于系統的內存管理默認采用“2的冪”的分配方法，這就造成了內存空間的巨大浪費，當某些應用程序要申請較大的連續空間時，卻不能滿足。為了解決這個問題，專門為uClinux內核設計了可選的內存分配器。不同的內核版本，這個可選的內存分配器不同，一般是page_alloc2和kmalloc2。
??? page_alloc2能解決缺省的分配方法造成的浪費問題。雖然它也是使用“2的冪”的分配方法，但它是按頁(每頁4 096B，即4 KB)分配的，分配的內存大小如果已經滿足了要求，則只是將當前的一頁分配出去，其他的就不再分配。還是一個65 KB的應用程序，如果使用這種方法，就只是分配68 KB(≥65 KB，且為整頁)即可，這樣就能節省60 KB的空間。
??? page_alloc2還采取了一些避免內存碎片的方法。它將所有的兩頁(8 KB)或更少的內存需求從空閑內存開始部分向上分配，所有大的內存需求從剩余內存的末尾部分開始向下分配。這樣防止了網絡緩存等的臨時分配，避免了內存碎片的出現。同時，它支持一次申請超過1 MB的內存空間，這對一些大的應用程序是很好的支持。采用此方法后，在系統運行過程中，并未出現過頁面訪問出錯問題。通過free命令查看內存分配如表2所列。

結 語
??? 在嵌入式系統應用日益廣泛的情況下，本文結合嵌入式Web在多支點觸發系統中的應用，介紹了Web訪問出現的問題以及它的解決方法。在實際應用中，新的內存分配方法能讓系統穩定地工作，但是從表2可以發現：采用“page_alloc2'’的內存分配方法時，系統的Cache較小，這就造成了頁面訪問有一定的延時。而“2的冪”的分配方法，系統的Cache較大，訪問速度較快。從這個對比得知，在反應時間要求不是很高的情況下，“page_alloc2”的內存分配方法更適合小內存的嵌入式系統；而“2的冪”的分配方法更合適那些內存足夠大的嵌入式系統。系統開發者可以根據實際情況采用不同的方案。