Về cơ bản, tôi có danh sách 30.000 URL. Tập lệnh đi qua các URL và tải chúng xuống (với độ trễ 3 giây ở giữa). Và sau đó nó lưu trữ HTML trong cơ sở dữ liệu.Tại sao kịch bản python của tôi bị giết một cách ngẫu nhiên?
Và vòng lặp và vòng lặp ...
Tại sao ngẫu nhiên nhận được "Bị giết"? Tôi không chạm vào bất cứ thứ gì.
Chỉnh sửa: điều này xảy ra trên 3 máy linux của tôi. Các máy trên một đám mây Rackspace với bộ nhớ 256 MB. Không có gì khác đang chạy.
Có vẻ như bạn sắp hết bộ nhớ - có thể dễ dàng xảy ra trên một chương trình chạy dài nếu bạn bị "rò rỉ" (ví dụ: do tích luỹ tham chiếu vòng tròn). Rackspace có cung cấp bất kỳ công cụ dễ sử dụng nào để theo dõi bộ nhớ của một quá trình, vì vậy bạn có thể xác nhận xem đây có phải là trường hợp không? Nếu không, loại điều này là không khó để theo dõi với các công cụ Linux bình thường từ bên ngoài quá trình. Một khi bạn đã xác định rằng "hết bộ nhớ" là nguyên nhân gây tử vong, các công cụ cụ thể của Python như pympler có thể giúp bạn theo dõi chính xác vị trí của vấn đề (và do đó xác định cách tránh những tham chiếu đó) chúng tham chiếu yếu hoặc các cách tiếp cận đơn giản khác - hoặc loại bỏ các rò rỉ).
Tôi nghĩ rằng nó đang hết bộ nhớ, phải không? Mem: 262364k tổng số, 258264k sử dụng, 4100k miễn phí, 884k bộ đệm Hoán đổi: 524280k tổng số, 285204k sử dụng, 239076k miễn phí, 14568k lưu trữ – TIMEX
SWAP tiếp tục tăng lên. – TIMEX
@alex, vì vậy chắc chắn nó trông giống như một "rò rỉ". Bên cạnh pympler, mà tôi đã gợi ý, hãy thử guppy - http://guppy-pe.sourceforge.net/ - chúng có thể giúp bạn xác định ** nơi ** tất cả bộ nhớ đó đang đi (xem mã của bạn, mà bạn đã đăng một câu hỏi khác, mà không biết về tất cả các thư viện của bên thứ ba mà bạn đang sử dụng, không có ích gì cả!). –
Có thể nó đã đạt được một ngoại lệ không bị bắt? Bạn đang chạy này từ một vỏ, hoặc là nó đang được chạy từ cron hoặc trong một số cách tự động khác? Nếu nó tự động, đầu ra có thể không được hiển thị ở bất cứ đâu.
Trong trường hợp như thế này, bạn nên kiểm tra tệp nhật ký.
tôi sử dụng Debian và Ubuntu, vì vậy các tập tin đăng nhập chính đối với tôi là: /var/log/syslog
Nếu bạn sử dụng Red Hat, tôi nghĩ rằng bản ghi là: /var/log/messages
Nếu có gì xảy ra đó là như vượt trội như hạt nhân giết chết quá trình của bạn, có sẽ là sự kiện nhật ký giải thích sự kiện đó.
Tôi nghi ngờ bạn đang bị ảnh hưởng bởi số Out Of Memory Killer.
Bạn đang sử dụng một số loại trình quản lý hàng đợi hoặc trình quản lý quy trình của một số loại? Tôi nhận được thông báo rõ ràng là ngẫu nhiên khi trình quản lý hàng đợi mà tôi đang sử dụng đang gửi SIGUSR2 khi hết thời gian.
Nếu không, tôi đặc biệt ưu tiên tùy chọn hết bộ nhớ.
Đối với những người đến đây với mysql, tôi thấy câu trả lời này có thể bằng cách hữu ích:
sử dụng SSCursor như suggented bởi this
conn = MySQLdb.connect(host=DB_HOST, user=DB_USER, db=DB_NAME,
passwd=DB_PASSWORD, charset="utf8",
cursorclass=MySQLdb.cursors.SSCursor)
vấn và duyệt qua con trỏ theo đề nghị của this
cursor = conn.cursor()
cursor.execute("select * from very_big_table;")
for row in cur:
# do what you want here
pass
Hãy chú ý đến những gì doc nói You MUST retrieve the entire result set and close() the cursor before additional queries can be peformed on the connection., vì vậy nếu bạn muốn viết và đồng thời, bạn nên sử dụng kết nối khác hoặc bạn sẽ nhận được
`_mysql_exceptions.ProgrammingError: (2014, "Commands out of sync; you can't run this command now")`
Có thể sẽ hữu ích khi cung cấp thông tin về môi trường mà tập lệnh của bạn đang chạy. Ví dụ, bạn đang chạy nó trên máy chủ của riêng bạn, hoặc một máy chủ chia sẻ? Những thứ khác đang chạy? Vv ... – Amber
Traceback lỗi sẽ hữu ích. Nếu không, chúng tôi chỉ đoán thôi. Tôi đoán đó là Zombies từ Khu vực 51. –
Không có lỗi. Nó chỉ nói "bị giết". – TIMEX