Tìm plugin cpu-hogging trong python đa luồng

Question

Tôi có một hệ thống được viết bằng python xử lý lượng lớn dữ liệu bằng cách sử dụng các trình cắm được viết bởi một số nhà phát triển với các mức trải nghiệm khác nhau.

Về cơ bản, ứng dụng bắt đầu một số chuỗi công việc, sau đó cấp dữ liệu cho chúng. Mỗi chuỗi xác định plugin để sử dụng cho một mục và yêu cầu nó xử lý mục. Một plug-in chỉ là một mô-đun python với một hàm cụ thể được định nghĩa. Quá trình xử lý thường liên quan đến các cụm từ thông dụng và không nên mất nhiều hơn một giây.

Thỉnh thoảng, một trong các plugin sẽ mất phút để hoàn thành, chốt CPU trên 100% trong toàn bộ thời gian. Điều này thường được gây ra bởi một biểu thức chính quy phụ tối ưu kết hợp với một mục dữ liệu cho thấy sự kém hiệu quả đó.

Đây là nơi mọi thứ trở nên phức tạp. Nếu tôi nghi ngờ thủ phạm là ai, tôi có thể kiểm tra mã của nó và tìm ra vấn đề. Tuy nhiên, đôi khi tôi không may mắn như vậy.

• Tôi không thể đi đơn luồng. Có thể mất tuần để tái tạo sự cố nếu tôi làm.
• Việc đặt bộ hẹn giờ trên plugin không hiệu quả, bởi vì khi nó bị đóng băng, sẽ mất GIL với nó và tất cả các plugin khác cũng mất vài phút để hoàn thành.
• (Trong trường hợp bạn đang tự hỏi, SRE engine doesn't release the GIL).
• Theo như tôi có thể nói profiling là khá vô ích khi đa luồng.

Viết lại toàn bộ kiến ​​trúc thành đa xử lý, bất kỳ cách nào tôi có thể tìm ra ai đang ăn tất cả CPU của tôi?

THÊM: Trong câu trả lời cho một số ý kiến:

1. profiling mã đa luồng trong python không hữu ích vì các hồ sơ đo tổng thời gian chức năng và không phải là lần cpu hoạt động. Hãy thử cProfile.run ('time.sleep (3)') để xem ý tôi là gì. (ghi có vào rog [nhận xét cuối]].

2. Lý do đi đơn luồng là khó khăn là vì chỉ có 1 mục trong 20.000 gây ra sự cố và tôi không biết đó là vấn đề gì. Chạy đa luồng cho phép tôi trải qua 20.000 mục trong khoảng một giờ, trong khi luồng đơn có thể mất nhiều thời gian hơn (có rất nhiều thời gian chờ của mạng). Có một số biến chứng mà tôi không muốn đi vào ngay bây giờ.

Điều đó nói rằng, không nên cố gắng tuần tự hóa mã cụ thể gọi các plugin để thời gian của một người sẽ không ảnh hưởng đến thời gian của những người khác. Tôi sẽ thử và báo cáo lại.

Answer 1

Như bạn đã nói, vì GIL không thể thực hiện được trong cùng một quá trình.

Tôi khuyên bạn nên bắt đầu quá trình theo dõi thứ hai, điều này lắng nghe nhịp đập cuộc sống từ một chuỗi khác trong ứng dụng gốc của bạn. Khi nhịp thời gian đó bị thiếu trong một khoảng thời gian nhất định, màn hình có thể giết ứng dụng của bạn và khởi động lại ứng dụng.

Answer 2

Nếu có thể đề xuất bạn có quyền kiểm soát khung làm việc vô hiệu hóa tất cả trừ một plugin và xem. Về cơ bản nếu bạn có P1, P2 ... Các plugin Pn chạy quy trình N và vô hiệu hóa P1 trong lần đầu tiên, P2 theo thứ hai và như vậy trên

nó sẽ nhanh hơn nhiều so với chạy đa luồng của bạn. bạn sẽ biết sớm hơn plugin nào là thủ phạm.

Answer 3

Bạn rõ ràng không cần phải xử lý đa luồng, chỉ đồng thời bởi vì chủ đề của bạn không chia sẻ bất cứ tiểu bang:

Hãy thử đa xử thay vì đa luồng

Độc chủ đề/N subprocesses. Ở đó bạn có thể yêu cầu mỗi lần, vì không có GIL nào được giữ.

Khả năng khác là để thoát khỏi nhiều luồng thực hiện và sử dụng sự kiện dựa trên lập trình mạng (tức là sử dụng xoắn)

Answer 4

tôi vẫn muốn nhìn vào gợi ý nosklo của. Bạn có thể hồ sơ trên một chủ đề duy nhất để tìm mục, và nhận được các bãi chứa tại rất dài của bạn chạy một có thể nhìn thấy thủ phạm. Vâng, tôi biết đó là 20.000 mặt hàng và sẽ mất một thời gian dài, nhưng đôi khi bạn chỉ cần hút nó lên và tìm thấy điều darn để thuyết phục bản thân vấn đề được bắt và chăm sóc. Chạy kịch bản, và làm việc trên một cái gì đó khác xây dựng. Quay lại và phân tích kết quả. Đó là những gì ngăn cách những người đàn ông từ các chàng trai đôi khi ;-)

Hoặc /, thêm thông tin ghi nhật ký theo dõi thời gian thực thi từng mục khi nó được xử lý từ mỗi plugin. Nhìn vào dữ liệu nhật ký ở cuối chương trình của bạn đang chạy, và xem cái nào mất một thời gian dài khủng khiếp để chạy so với các chương trình khác.