2010-05-02 44 views
3

我已經寫了一個PHP腳本,通過SSH和nohup運行,意在處理來自數據庫的記錄,並與他們做東西(例如,處理一些圖像,更新一些行)。php cli腳本掛起沒有消息

它適用於小負載,高達10k條記錄。我有一些處理大約40k個記錄的較大數據集(我不瞭解,但是當每個記錄需要下載和處理多達50個圖像時,這會增加很多工作量)。

較大的數據集可能需要數天處理。有時我會在調試日誌中看到內存錯誤,這些錯誤足夠清楚 - 但有時腳本看起來像是「死亡」或者對我來說是殭屍。我的調試日誌尾部停止,沒有錯誤消息,nohup日誌的尾部沒有錯誤,並且過程仍然顯示在ps列表中,看起來像這樣 -
26075 pts/0 S 745: 01/usr/bin/php ./import.php
但是沒有工作完成。

任何人都可以給我一些想法,爲什麼一個過程會剛剛退出?就我所知,顯而易見的事情(如php腳本超時和內存問題)並不是一個因素。

感謝您的任何提示

PS--這是託管在GoDaddy的VDS(不是我的選擇)。我有點懷疑,儘管覆蓋了我的代碼(例如set_time_limit(0);),但是godaddy具有某種限制,可能會觸發我。

+0

(1)你不能把處理分成更小的塊嗎? (2)你爲什麼用nohup而不是screen? – 2010-05-02 20:08:47

+0

好吧,它一次運行500批次的記錄。我相信還有其他策略可以分擔負擔,但看起來這是合理的,這只是耗時。初次導入後,記錄更新要小得多,而且非常易於管理。 我已閱讀關於屏幕,但我沒有經歷過它 - 屏幕的優勢是什麼? 謝謝 – julio 2010-05-02 20:17:54

回答

2

很可能是OOM killer。如果你真的,真的真的想留出其覆蓋面,爲,有你的過程寫-17/proc/self/oom_adj注意:內核通常會更好。逃避OOM殺手可能實際上削弱了您試圖查詢的相同RDBMS。這將是一個惡性循環:)

你可能(相反)想要根據你從/proc/loadavg/proc/meminfo讀取的內容來錯開查詢。如果增加負載或按指數級數交換,則需要退後,尤其是作爲後臺進程:)

此外,在運行時監視器IOWAIT。與系統啓動時相比,這可以從/proc/stat中取平均值。當你開始和你進步的時候記下它。

不幸的是,被稱爲OOM殺手的連環殺手並沒有維護一個除解析內核消息之外可訪問的主體數量。

或者,您的cron作業會一直保持其已分配堆的數量爲ulimit。無論哪種方式,您的工作需要在適當的時候退出,或者在做任何工作之前防止其自身消亡(如上所述)。

作爲一個方面說明,你可能不應該做你正在做的共享主機。如果它那麼大,那麼它是時候獲得一個VPS(至少),在哪裏你可以控制哪個流程可以做什麼。

+0

還有'strace'來查看它是掛在系統調用還是內部的php – 2010-05-02 22:13:13

+0

@Marc - 可能,但不太可能。 '內部到PHP'會導致磁盤睡眠或傳遞錯誤的一些小孩。要麼是顯而易見的。 – 2010-05-02 22:27:12

+0

@Marc - 或者只是一個殭屍程序 – 2010-05-02 22:37:40