dma free:71672kb min:616kb low:768kb high:924kb active_anon:0kb inactive_anon:0kb active_file:0kb inactive_file:0kb unevictable:0kb isolateds
lowmem_reserve: 0 1244 1593 1593
normal free:1249804kb min:4212kb low:5264kb high:6316kb active_anon:0kb inactive_anon:0kb active_file:0kb inactive_file:0kb unevictable:0kb o
lowmem_reserve: 0 0 2794 2794
highmem free:223000kb min:348kb low:640kb high:936kb active_anon:39248kb inactive_anon:140kb active_file:61020kb inactive_file:34108kb unevio
lowmem_reserve: 0 0 0 0
dma: 22*4kb 90*8kb 21*16kb 82*32kb 7*64kb 137*128kb 69*256kb 3*512kb 8*1024kb 5*2048kb 3*4096kb 0*8192kb 0*16384kb 0*32768kb = 71672kb
normal: 1*4kb 53*8kb 16*16kb 6*32kb 6*64kb 4*128kb 1*256kb 1*512kb 2*1024kb 2*2048kb 3*4096kb 2*8192kb 4*16384kb 35*32768kb = 1249772kb
highmem: 14*4kb 10*8kb 437*16kb 386*32kb 374*64kb 27*128kb 10*256kb 7*512kb 8*1024kb 7*2048kb 4*4096kb 2*8192kb 1*16384kb 3*32768kb = 223000b
23829 total pagecache pages
0 pages in swap cache
swap cache stats: add 0, delete 0, find 0/0
free swap = 0kb
total swap = 0kb
524288 pages of ram
387015 free pages
73287 reserved pages
1169 slab pages
8545 pages shared
0 pages swap cached
physical memory allocation error!
physical memory allocation error!
通過log，定位到輸出的位置是解碼驅動中，驅動在dma請求失敗後，輸出以上資訊。針對這個現象，按以下幾個思路進行的調查：
1. 記憶體洩露
2. 記憶體碎片
echo 3 > /proc/sys/vm/drop_caches
試驗之後，果然有效，測試了手中的測試用例幾千次後，發了測試軟體，結果悲劇，開發部的測試用例幾次就測出同樣的問題，該方案水土不服。
3. 調查linux記憶體使用
從記憶體碎片這個思路出發，分析什麼導致了驅動的dma空間碎片化。查了一些資料發現，linux的記憶體劃分分成3塊：dma，low memory和high memory。一般32位pc的配置是dma zone位於0x00010000-0x00ffffff，大約16mb，low memory是0x01000000-0x37bfdfff，約800多mb，再往上的空間給high memory，這部分的訪問要通過跳轉，效能不如dma zone和low memory zone快。而記憶體分配的策略是從上往下分配，一旦高位的記憶體空間不足，則向低位址的空間請求記憶體。在我們的產品上，總的記憶體大小是512mb，某些驅動預留128mb，dma zone的配置是184mb，那麼實際剩下的low memory zone只有200mb，而這200mb要執行ui，**管理，互聯等等一系列程序。一旦low memory zone的記憶體不夠用，系統會向dma zone請求記憶體，從而導致的dma空間的記憶體碎片化！而這時，通過free命令是看不到正確的記憶體資訊的，因為看到的空間還有，但一是被cache占用，二是計算的是總數，而不是真正的連續記憶體，這時檢視記憶體應該使用系統提供的buddy info來看真正剩餘的記憶體塊：
$cat /proc/buddyinfo
node 0, zone dma 3 1 3 4 1 2 2 0 1 2 0 3 2 2
node 0, zone normal 74 36 29 8 6 4 3 2 1 2 3 2 0 2
輸出的資料從左側開始是4k記憶體塊的個數，依次乘2到最右側的32m；在出問題時，系統基本上只有小塊的記憶體，而問題的原因就是一些檔案訪問的操作導致dma zone的空間被cache使用了。
4. 控制記憶體分配演算法
5. 最終方案
由於產品的總記憶體太小，而預留的dma zone太大，所以需要調整dma zone預留的空間，但lowmem_reserve_ratio已無調整空間，所以考慮從調整kernel上下手。最後，將kernel中的dma zone總大小由184mb調整為原來的3/4，即138mb，得到乙個近似合理的配置，保證的dma和low memory都可以申請到足夠的空間，長時間測試後，未再現相關問題。
Linux 如何調整虛擬記憶體大小
我用的centos，直接貼操作步驟，供參考 root 1pad free m total used free shared buffers cached mem 3702 722 2979 0 149 230 buffers cache 342 3359 swap 3839 0 3839 root ...
調整虛擬記憶體
調整虛擬記憶體 虛擬記憶體一般由程序 檔案系統快取以及核心消耗。虛擬記憶體的使用由很多因素決定，受以下引數影響 引數值可為 0 100，控制系統 swap 的程式。高數值可優先系統效能，在程序不活躍時主動將其轉換出物理記憶體。低數值可優先互動性並盡量避免將程序轉換處物理記憶體，並降低反應延遲。預設值...
Oracle記憶體調整辦法
手動修改引數 設定前 設定過程 1.cmd sqlplus system賬戶登入 2.show parameter sga 顯示記憶體分配情況 3.alter system set memory target 1200m scope spfile 4.alter system set sga max...