太多的連接數據庫錯誤在緩存更新

[krisp]

另一個晚上，我正好是清醒一點後，在4日上午，在論壇上突然下跌對於像20分：


在百度推廣數據庫錯誤：

mysqli_real_connect（）[<a href='function.mysqli-real-connect'> function.mysqli實時連接 </ A>]：（08004/1040）：太多的連接
/ VAR / WWW /虛擬主機 / ... ... /上傳至httpdocs /包括/ class_core.php上線 1138

MySQL的錯誤：
錯誤號：
申請日期：星期二，2009年12月15日@上午4時 28分00秒
錯誤日期：星期二，2009年12月15日@上午四時 28分00秒
腳本：http://.../
介紹人：
IP地址：
用戶名：
類名：vB_Database_MySQLi
MySQL的版本：
-->

現在，我從來沒有經歷過這之前，我想知道，如果這是一個巧合，這是圍繞 VB緩存更新計劃任務。

今天早上我檢查一切正常，所以今天沒有重複。

服務器似乎不被強調，因為我還有另外一個論壇上相同的服務器，而不會 vbet，那是在運行良好的停機時間，我vbet論壇。

縱觀 serverlog，有沒有顯得有些機器人活動，但沒有太多的用戶活動。該機器人似乎得到OK 200 - 但普通用戶得到dberror。另外奇怪的記錄在服務器日誌文件似乎不是按時間順序進行排序...

A位的puzzele ...也許你能告訴我，如果包含/ class_core.php上線 1138參與更新緩存？或許有些你有一個想法如何解決呢？

[vBET]

vBET不會創建新的連接 - 它可以重新建立連接，但如果這是只一個是實際損失（在情況下，如果翻譯來得太遲從谷歌）。而這方面是由$百度推廣 - > DB ->連接，以便作出一切必要的清理百度推廣在最後。

所以在這個時刻，我們認為，這個問題是在其他地方。

class_core.php不是我們的文件，它並不直接使用vBET緩存 - 但是，如果這個文件是負責執行預定的任務，那麼它也將執行緩存清除。

[vBET]

還有一點。如果你正在寫關於 vBET緩存清除，然後請赫克你有多少數據在緩存中。如果真的是很大的數目，那麼請改變你的緩存清除策略。
vBET不會產生額外的連接，但如果結算時間過長，那麼其他客戶都在等待新的連接，並用VB創建新的客戶，這病等。這就是為什麼我們添加多個結算策略。對於真正的大數據量，請使用上的策略。

請注意，這個問題將在3.3.0最小化，因為我們會分裂緩存表為每種語言，所以你的索引將是52倍小，結算將會更快 - 刪除數據的速度很快，但沒有必要更新大 型索引。因此，在這一刻，請考慮使用其他結算策略，更好地為大指標：）

[krisp]

Happend再從 04-05 - 所有域下有太多的聯繫。我認為你是對的。論壇是忙碌清除緩存和搜索機器人的篡改一個請求每秒。我可以看到serverload極高。現在是非常低了。 vbet DB約 1.1 GB

我切換到“刪除所有緩存的數據高速緩存 TTL一次間隔”。

聽起來確實很好330解決這個問題！