您在這裡

watchdog的資料爆多

tky's 的頭像
tky 在 2008-01-14 (週一) 14:03 發表

最近要備份一個站的資料庫時,發現sql檔案的體積達到1.7G,嚇得tky趕忙去查看哪裡有問題。
一看之下發現watchdog的資料爆多,光它就佔了1.6G的資料,實在太誇張。

到日誌系統去查看,發現每跑一個頁面出來,救出現一大堆php錯誤的訊息,大多像這樣:
在 ./includes/database.mysql.inc 的第 172 行: Table 'stm.cache_views' ....

把日誌系統的紀錄功能停用也沒有用。
清空watchdog之後,24小時不到,又上升到350mb去了。這樣下去,資料量真的蠻驚人的。

這個站最近才從4.7.x升級到5.6來,問題似乎是因為升級產生的。
到網路上去搜尋,好像是一個常見的問題;麻煩的地方是:沒有常見的解決方案!

大家有碰過的話,麻煩回應一下tky,指點一下,謝謝。

可能因為找不到頁面的request太多
另外,可以設定watchdog只保存1個小時,用cron固定清空
--
from open mind to open source~

--
from open mind to open source~

這個嘛,tky看過,似乎不是找不到頁面的問題,而純粹就是php錯誤。
同一秒產生出來的php錯誤訊息高達好幾頁,而tky設定poormanscron是每12個小時跑一次,這樣量還是很驚人。

這個「第 172 行」的錯誤可以說出現在所有的頁面中,有人點一次它就來一次,這樣的資料量實在太大了。
問題是,又不知道這個錯誤是來自於那裡。真的蠻令人苦惱的。

停用watchdog這個模組的話,就不能知道每一頁的瀏覽次數了,真麻煩啊。

tky

tky

啊?難道這是一個孤兒問題嗎?為什麼tky老是會碰到這樣的狀況咧?
12個小時清空一次watchdog的結果,就是watchdog總是保持在3萬多筆資料,容量1G左右....。

老天那!

又看了一次錯誤碼,發現大多都是這樣:
在 /home/includes/database.mysql.inc 的第 172 行: Table 'stm.cache_views' doesn't exist query: UPDATE cache_views SET data = 'a:11:{s:8:\"bulletin\";s:8:\"bulletin\";s:5:\"event\";s:8:\"activity\";s:5:\"about\";s:5:\"about\";s:7:\"archive\";s:7:\"archive\";s:10:\"biblioview\";s:10:\"biblioview\";s:9:\"frontpage\";s:9:\"frontpage\";s:13:\"image_gallery\";N;s:12:\"image_latest\";s:12:\"image/recent\";s:14:\"panels_by_term\";s:14:\"panels_by_term\";s:18:\"taxonomy_directory\";s:9:\"directory\";s:7:\"tracker\";s:7:\"tracker\";}', created = 1200413814, expire = 0, headers = '' WHERE cid = 'views_urls' 。

很奇怪的是,tky發現資料庫中根本沒有cache_views這個資料表。
有cache_content、cache_filter、cache_menu、cache_page;但是就是沒有cache_views。
顯然裝某個模組的時候漏掉了這個資料表吧?
有沒有人知道要怎麼把這個資料表弄回來?

tky

tky

見鬼了,才剛發現問題出在那,就解決了。
剛剛上網搜了一下cache_views,找到這篇文

照著重建一次cache_views這個資料表就好了。
看來這是一個常見的升級問題,主要在於從4.7升級到5.x的版本時,系統不會自動建立這個資料表;或者是本來就有這個資料表,卻不會更新。

於是你就看到一整車的php錯誤碼出現。果然不能輕忽錯誤碼啊!

送給有類似問題的朋友們,希望你們能早日搜到這一篇

tky

tky

若有安裝memcache模組,就mysql資料庫還需執行下列指令:

ALTER TABLE {cache_views} ADD serialized int(1) NOT NULL default '0';

請見memcache模組內的memcache.install。

--
denqyj

--
denqyj