2009-11-28 106 views
13

基本上,我有一個30,000個URL的列表。 該腳本通過URL並下載它們(兩者之間有3秒的延遲)。 然後它將HTML存儲在數據庫中。爲什麼我的python腳本會被隨機殺死?

它循環和循環...

爲什麼它會隨機獲得「Killed」?我什麼也沒碰。

編輯:這發生在我的3臺Linux機器上。 機器位於具有256 MB內存的Rackspace雲上。沒有別的東西在運行。

+0

這很可能是有幫助的,以提供有關該腳本運行的環境信息。例如,你是在自己的服務器上還是共享主機上運行它?還有其他什麼東西在運行?等等...... – Amber 2009-11-28 00:50:00

+6

錯誤回溯會有幫助。否則,我們只是猜測。我猜這是51區的殭屍。 – 2009-11-28 01:02:56

+0

沒有錯誤。它只是說「被殺害」。 – TIMEX 2009-11-28 01:06:02

回答

18

看起來您可能內存不足 - 如果您有「泄漏」(例如,由於積累了循環引用),可能很容易發生在長時間運行的程序中。 Rackspace是否提供任何易於使用的工具來跟蹤進程的內存,因此您可以確認是否屬於這種情況?否則,這種事情並不難於用流程外的普通Linux工具進行監控。一旦確定「內存不足」可能導致死亡,Python專用工具(如pympler)可以幫助您準確跟蹤問題的來源(從而確定如何避免這些引用 - 通過更改他們弱參考,或其他更簡單的方法 - 否則刪除泄漏)。

+0

我認爲它內存不足,對吧? Mem:總計26​​2364k,使用258264k,使用4100k,使用884k緩衝區 更換:總共524280k,使用285204k,使用239076k,使用14568k緩存 – TIMEX 2009-11-28 01:02:50

+1

SWAP持續上漲。 – TIMEX 2009-11-28 01:05:14

+0

@alex,所以絕對看起來像一個「泄漏」。除了我已經建議的pympler,請嘗試古比 - http://guppy-pe.sourceforge.net/ - 他們可以幫助您確定**所有內存的位置(查看您的代碼,另一個問題,不知道你正在使用的所有第三方庫,沒有任何幫助!)。 – 2009-11-28 05:15:10

1

是否有可能觸及未捕獲的異常?你是從shell運行它,還是從cron或其他自動化方式運行?如果它是自動的,輸出可能不會顯示在任何地方。

14

在這種情況下,您應該檢查日誌文件。

我用Debian和Ubuntu,所以我的主要日誌文件是:/var/log/syslog

如果您使用紅帽,我認爲日誌:/var/log/messages

三長兩短是因爲作爲特殊內核查殺你的進程,作爲解釋它的日誌事件。

我懷疑你被Out Of Memory Killer擊中。

1

您是否在使用某種隊列管理器或某種類型的進程管理器? 當我使用的批處理隊列管理器在時間到時發送SIGUSR2時,我明顯遇到了隨機殺死的消息。

否則我強烈支持內存不足選項。

0

對於那些誰來到這裏與mysql,我發現這個答案可以通過有益的:通過this

conn = MySQLdb.connect(host=DB_HOST, user=DB_USER, db=DB_NAME, 
         passwd=DB_PASSWORD, charset="utf8", 
         cursorclass=MySQLdb.cursors.SSCursor) 

爲suggented

使用SSCursor和遍歷光標通過this

cursor = conn.cursor() 
cursor.execute("select * from very_big_table;")  
for row in cur: 
    # do what you want here 
    pass 
的建議

注意什麼docYou MUST retrieve the entire result set and close() the cursor before additional queries can be peformed on the connection.,所以如果你想要寫和的同時,你應該使用其他連接,或者你會得到

`_mysql_exceptions.ProgrammingError: (2014, "Commands out of sync; you can't run this command now")`