LAMP max_connections，睡眠進程，鎖定進程，等待超時，內存不足

Question

我會盡量簡短並且仍然完整。 Thx提前爲那些花費寶貴的時間指出我一個可能的解決方案。

---

在Ubuntu環境下的PHP/Mysql應用程序。

原始發行日期：

Keep getting error 'to_many_connections'. 

當我檢查：

show processlist; 

有很多睡眠過程。所以我想這些是to_many_connections錯誤的原因，因爲他們阻止任何新的傳入連接。

改變MySQL的設置：

Raise max_connections from 250 to 400; 
lower wait_timeout from 60 to 15; 

連接似乎工作，但現在我的Apache是​​內存霸佔。 只需更改這2個設置即可從11G變爲25G以上。 我無法想象150個額外的mysql_connections佔用14G的額外內存？ 我也不希望wait_timeout設置較低，以增加apache的內存使用量。它應該在內存中使用較少的內存少連接？我期望過程使用量上升，但不是記憶。當然不是那麼多。

試圖realtering MySQL的設置：

keep max_connections at 400 
raise wait_timeout to 30 sec 

內存使用率下降，約5分鐘，但之後再次上升。

其他說明：

我注意到有很多鎖定過程一定 表。 （mysql：show processlist;） 更新：表是MyISSAM表。

我也改變了一些數據庫實現，這並不理想，有些頁面使用2個連接到數據庫，因爲我們正在經歷一個代碼重構階段。 從功能的mysql_query切換到PDO功能

更新：

新PDO功能已專門設置爲false（即使它默認爲false） 舊版本的MySQL功能不使用持久連接持久連接無論是。

public function __construct($dbname, $username, $password) { 
     parent::__construct('mysql:hostname=localhost;dbname=' . $dbname . ';', $username, $password, array(
      PDO::ATTR_PERSISTENT => false, 
      PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, 
      PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, 
      PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8;" 
     )); 
    } 

我很清楚地知道，使該數據庫中的幾個連接遠非最佳實踐，但我們目前的應用程序丟失的設計模式了很多，一切仍是程序性的，沒有MVC，沒有OOP 。 我有責任做這些實踐，因爲我的僱主想要結果，並且此時並沒有打算對我們的應用程序進行完全重寫，以使用應該早已實施LOONG的設計/編碼標準。 無論如何我會很驚訝，如果這個代碼將是真正的原因，因爲它已經運行完美了一個多星期，並且由於討價還價的期限（在1個月的巨大的一個月的巨大訪問量在我們的商店討價還價/優惠）。

任何有關此事的見解將不勝感激。至於這一點，我不知道下一步可能會解決這個問題。

update2 已關閉，因爲已發現該問題，但與原始帖子無關。

Answer 1

我爲你感到這些大問題！我將芯片與幾件事情，看看你是否已經嘗試

• 重：Apache的記憶 - 我的Apache測試我最近在做，實際上指向降低MaxClients的數目，下一個AB或攻城測試我實際上在測試環境中獲得了更好的性能，使用~12而不是256.雖然這是非常多的開發環境，而不是生產到目前爲止

• 關於鎖定的mysql進程，您使用的是哪種表類型？我相信MyIsam比InnoDB更容易發生鎖定問題。 MyISAM數據表是鎖定，其中InnoDB的是排IIRC

• 我注意到你寫

  新PDO功能已設置爲false

持久連接正在使用的持久連接舊代碼？我從來沒有多少運氣或爲他們使用

• 你有多少緩存？你有mysql查詢緩存啓用，如何在webserver和mysql之間使用memcache或nosql系統？

我知道很多人會說memcache等不是緩慢/崩潰的應用程序的解決方案，但如果它給你更多的呼吸空間，爲什麼不呢？當緩存不是緩存時，還有一些理念：例如，我使用redis.io，它可以存儲在內存中，但也可以保存到光盤上，無論何時管理系統更新mysql，它也更新這個「緩存」，它在數據存活的時間內保持不變 - 最小化熱點問題 - 並且始終到目前爲止沒有滯後。從理論上講，它可以感覺有點像一個警察迴避這樣的東西，但redis比我們設法得到mysql在我們的環境中執行相同任務的速度快6倍（開箱即用）...

更新 我看你使用的是myisam，所以任何鎖定問題都可以歸結爲，iirc更新會鎖定整個表的持續時間，這可能會導致查詢堆積起來，雪球和每一個回落

re：緩存層 緩存可以迴避/推遲問題，因爲您將連接到數據庫更少，我有一些頁面根本不連接！我可以從字面上做一個mysqld停止，他們仍然工作，即使他們在技術上的動態

相關提示你連接到數據庫經常在頁面的頂部或僅在需要時？

更新 額外的評論讓我想起了一個類似的問題，我有一個時間，其中一個XML飼料（即在頁面請求跑 - 無法預緩存由於政治！）從第三方供應商將運行緩慢就像網站的其他部分會變得忙碌起來一樣，慢速的XML提要會導致瓶頸與Apache進程綁定並使服務器變慢，這意味着有些人不會等待他們的頁面完成，但數據庫仍然會嘗試提供的信息中斷請求以及新的，所以它首先看起來像一個數據庫問題