我還有哪些其他選項可以簡化WordPress內存使用？

Question

所以我跑進了一堵牆試圖破解爲什麼這個WordPress安裝瞭如此多的內存。我在MediaTemple DV 4.0帳戶上將我的服務器從512升級到1 GB RAM，並且此單一安裝平均使用率爲60％，如果有人擺弄儀表板，則跳至118％。前端用戶不會遇到任何性能問題，並且該站點沒有崩潰，但由於消耗的內存太多，我經常必須重新啓動服務器，只是通過FTP或SSH進入。現在，通常每個頁面儀表盤將會持續一兩分鐘。這種情況會間歇性地發生，但一旦啓動，儀表板中的每個頁面都會一直掛起，並且重新啓動服務器不會糾正它（它只是神祕地回到正常狀態）。另外，我還在服務器上安裝了其他WP，但他們都沒有在儀表板內部或外部遇到任何問題。他們也使用CloudFlare和AmazonS3，如下所述。我知道有這個沒有直接的答案，但我很好奇，如果任何人有任何意見，提供試用下一步是什麼，因爲我已經嘗試過：

這裏的裝機什麼：

1. W3的總緩存+ PHP APC（該網站正在使用數據庫緩存，頁面緩存和APC對象緩存）。
2. 圖像資產通過W3 Total Cache在Amazon S3/Cloudfront上託管。我在S3上存儲了大約50,000個圖像，儘管只有一小部分（大約1-2k）在站點中使用。
3. 該網站背後的CloudFlare和使用CloudFlare的插件，修正的IP徵求意見。
4. 我沒有做任何特別壯觀的主題（http://www.rokkyuu.com）。該網站唯一特別高級的功能是，對於來自WP的某些圖像，如果媒體庫中不存在圖像的大小調整版本，則WP會動態調整圖像大小，然後將該圖像推送到Amazon S3，以便在W3 Total Cache替換路徑，前端最終使用S3資產。這是爲了避免WP爲每個上傳的圖像裁剪8個自定義大小。但是，這不會在儀表板中發生。
5. 這些都是我所安裝的插件：
   • 的Akismet
   • BWP谷歌XML網站地圖
   • 的CloudFlare
   • 共同作者加
   • 的Facebook頁面發表
   • 的LiveJournal Crossposter
   • 重定向
   • SABRE
   個
   • 簡單的本地化身
   • 主題我的登錄
   • Twitter的工具
   • 分享Tweet攪拌機
   • 用戶切換
   • W3的總緩存
   • WordPress的搜索引擎
   • WordPress的防火牆2
   • WP-DB經理
   • WP自定義管理欄
   • WP隱藏儀表板
   • WPTouch臨

我已經嘗試做調試：

1. 我安裝了APC的緩存（但話又說回來，W3的總緩存沒有按」 t緩存儀表板）

2. 我改變了我的MySQL配置以匹配Matt Mullenweg的mysql建議。 http://www.codinghorror.com/blog/files/matt-mullenweg-wordpress-mysql-recommendations.txt

3. 我安裝了xdebug和webgrind並分析了cachegrind輸出，但我不太確定什麼算作紅旗。我寫的很少的PHP函數甚至被列入要求總包容成本高的項目以及總包含成本最高的項目（php :: call_user_func_array），通過call_user_func_array調用的函數均勻分佈在覈心函數中，而我的擁有。我抽取的主頁的示例cachegrind爲15 MB。另一方面，Dashboard中的Post Edit屏幕的cachegrind爲186 MB，並且最高級的違規者似乎是自定義的manage_posts_columns。但是，我刪除了所有manage_post_columns自定義項，並且Dashboard仍然掛起，經常無法使用。

我甚至可以在哪裏開始排除故障？

Answer 1

我想我找到了罪魁禍首：

的CloudFlare的WP插件和儀表板=核危機。

我不確定爲什麼，但是在檢查webgrind中Dashboard頁面的內存配置文件後，我發現CloudFlare API的curl請求在內存中引起了巨大的高峯。一旦我從MediaTemple DNS中禁用了CloudFlare並禁用了插件，儀表板開始正常運行。

不知道但如果它的好啓用CloudFlare的W/O的WP插件，但我的目的，我寧願有一個正常運作的儀表盤......

Answer 2

從一個乾淨，新鮮的WP安裝開始，然後慢慢地加入你正在做的各種事情。如果您在添加內容時觀察內存使用情況，則會發現導致問題的部分。