在運行dedecms是有些朋友會發現有些頁面會提示Fatal error: Allowed memory size of 134217728 bytes exhauste錯誤了，下面我們一起來看看解決此問題辦法。
報錯提示：Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 38218371 bytes) in .....
解決方法：
1.取消PHP的內存限制。
在php程序中添加 ini_set("memory_limit","-1");
2.根據自己的需要及參考本機的內存大小修改php內存限制，如改為1024M。
在php程序中添加 ini_set("memory_limit","1024M"); 或者將php.ini中相應位置改為memory_limit = 1024M;
內存限制的意義
php中的相關文檔解釋 memory_limit 如下:
memory_limit： integer
該指令設定了一個腳本 所能夠申請到的最大內存字節數。這有助於防止寫得不好的腳本消耗光服務器上的可用內存。要使用此指令必須在編譯的時候激活。因此 configure 一行中應該包括：--enable-memory-limit。如果不需要任何內存上的限制，必須將其設為 -1。 從 php 4.3.2 起，當激活了 memory_limit，PHP 函數 memory_get_usage() 便可以使用了。也就是說，php在一個 page 中的處理內存限制，默認的(/etc/php.ini)定義為 128M (我的系統默認安裝後)，後來開發組的應用寫的越來越復雜，但是在結構上可能還有些欠缺，頻繁的對象請求，居然造成了內存不足。
應用層面測試與解決方法
最好的方式應該在應用層面解決，而不是不斷的增加內存設置。以下為代碼測試：
代碼如下 復制代碼<?
printf(" total run: %.2f s<br>".
"memory usage: %.2f M<br> ",
microtime(true)-$HeaderTime,
memory_get_usage() / 1024 / 1024 );
?>
運行結果顯示如下：
total runtime: 1.47 s
memory usage: 77.09 M
一個頁面居然會有77M的請求。究其原因，是程序員在編碼時，僅僅對變量賦值，卻從來沒有 unset ($var) 過。試想，如果一個頁面請求要處理20個sql查詢，每個sql查詢返回10個sql結果，而程序員從來都不關心是返回一個row的所有column還是僅僅返回需要的column(實際上當我們采用更common的中間層時，往往會返回全部的column而不是特定的某幾個字段，就像在 ORM 中如NHibernate, JBOSS中的那樣)如果一條row有10K, 那麼這個頁面到處理結束時就要增加到 10K*10*20=2M的數組分配，這還不算有時候我們需要最數組進行復制。
所以在php中，合理的方法是變量使用後就 unset($var)，最大限度節省內存資源。
經驗之談
本人有一台服務器使用的是apaceh2.3與php5.2.6上面的方法無效，經官方確認是php版本bug了，我們可以換個高版本手php版本即可解決。
