các chủ đề lôgic hiện tại tăng/ngăn xếp luồng bị rò rỉ

Question

Giám sát ứng dụng .NET của tôi trong Màn hình Hiệu suất Tôi có thể xem .NET CLR LocksAndThreads/# của Chủ đề hợp lý hiện tại đang tăng đều đặn (hiện tại là 293) theo thời gian cho biết ngăn xếp chủ đề bị rò rỉ.

Tôi có thể tìm thấy nhiều bài báo cho tôi biết đây là vấn đề nhưng không có gì cho tôi biết cách tìm nguyên nhân - vậy tôi bắt đầu từ đâu? Windbg có thể cho tôi biết vấn đề nằm ở đâu không?

Đây là màn biểu diễn của tôi trên 3hrs nói đề logic hiện tại của tôi là 150:

Và đây là sản phẩm của cửa sổ đề, mà không cho tôi biết nhiều vì tôi không thể truy cập ngăn xếp cuộc gọi của họ - chúng hầu như được đánh dấu là [không khả dụng] hoặc [Khi đang ngủ, hãy đợi hoặc tham gia] | [External Code]:

Unflagged  141024 124 Worker Thread <No Name>  Normal 
Unflagged > 0 0 Unknown Thread [Thread Destroyed]  
Unflagged  136272 2 Worker Thread <No Name>  Highest 
Unflagged  133060 7 Worker Thread vshost.RunParkingWindow [Managed to Native Transition] Normal 
Unflagged  136952 10 Main Thread Main Thread [edited].Program.Main Normal 
Unflagged  134544 9 Worker Thread .NET SystemEvents [Managed to Native Transition] Normal 
Unflagged  136556 11 Worker Thread Worker Thread [edited].MessageService.ProcessJobs.AnonymousMethod__0 Normal 
Unflagged  141364 113 Worker Thread <No Name> [In a sleep, wait, or join] Normal 
Unflagged  140896 0 Worker Thread [Thread Destroyed]  Normal 
Unflagged  136776 19 Worker Thread <No Name> [In a sleep, wait, or join] Normal 
Unflagged  135704 20 Worker Thread <No Name> [In a sleep, wait, or join] Normal 
Unflagged  136712 21 Worker Thread <No Name> [In a sleep, wait, or join] Normal 
Unflagged  134984 22 Worker Thread <No Name> [In a sleep, wait, or join] Normal 
Unflagged  134660 23 Worker Thread Worker Thread [edited].BroadcastService.ProcessJobs.AnonymousMethod__1d Normal 
Unflagged  140224 152 Worker Thread <No Name>  Normal 
Unflagged  140792 157 Worker Thread <No Name>  Normal 
Unflagged  137116 0 Worker Thread <No Name>  Normal 
Unflagged  140776 111 Worker Thread <No Name>  Normal 
Unflagged  140784 0 Worker Thread [Thread Destroyed]  Normal 
Unflagged  140068 145 Worker Thread <No Name>  Normal 
Unflagged  139000 150 Worker Thread <No Name>  Normal 
Unflagged  140828 52 Worker Thread <No Name>  Normal 
Unflagged  137752 146 Worker Thread <No Name>  Normal 
Unflagged  140868 151 Worker Thread <No Name>  Normal 
Unflagged  141324 139 Worker Thread <No Name>  Normal 
Unflagged  140168 154 Worker Thread <No Name>  Normal 
Unflagged  141848 0 Worker Thread [Thread Destroyed]  Normal 
Unflagged  135544 153 Worker Thread <No Name>  Normal 
Unflagged  142260 140 Worker Thread <No Name>  Normal 
Unflagged  141528 142 Worker Thread <No Name> [In a sleep, wait, or join] Normal 
Unflagged  141344 0 Worker Thread [Thread Destroyed]  Normal 
Unflagged  140096 136 Worker Thread <No Name>  Normal 
Unflagged  141712 134 Worker Thread <No Name>  Normal 
Unflagged  141688 147 Worker Thread <No Name>  Normal 

Cập nhật: Tôi đã kể từ khi được theo dõi thủ phạm xuống một System.Timers.Timer. Ngay cả khi bộ đếm thời gian này được gọi là một phương thức trống trên mỗi sự kiện đã trôi qua, nó vẫn tăng số lượng chuỗi logic vô thời hạn. Chỉ cần thay đổi bộ đếm thời gian sang DispatcherTimer đã khắc phục được sự cố.

Tôi bắt đầu xem xét tất cả các bộ hẹn giờ trong ứng dụng của mình sau khi nhìn thấy số lớn khi chạy !dumpheap -type TimerCallback trong Windbg như đã đề cập trong this question.

Tôi vẫn muốn biết làm thế nào tôi có thể đã phát hiện điều này thông qua gỡ lỗi Windbg thay vì tắt tính năng/kiểm tra hiệu suất/phương pháp lặp lại dẫn tôi đến sửa chữa. I E. bất cứ điều gì mà có thể đã nói với tôi mà bộ đếm thời gian đã được tạo ra vấn đề.

Answer 1

Điều này thường xảy ra do việc tạo chuỗi chủ đề của nhóm bị kẹt và không hoàn thành. Mỗi nửa giây, trình quản lý threadpool cho phép một luồng khác bắt đầu cố gắng làm việc với việc tồn đọng. Điều này tiếp tục cho đến khi nó đạt đến số lượng chủ đề tối đa được thiết lập bởi ThreadPool.SetMaxThreads(). Theo mặc định một số lượng lớn, 1000 trên một máy tính 4 lõi.

Sử dụng Debug + Windows + Chủ đề để xem các chuỗi đang chạy. Ngăn xếp cuộc gọi của họ nên làm cho nó rõ ràng lý do tại sao họ đang chặn.

Answer 2

Hãy thử tất cả các hoạt động chạy dài của bạn (100+ ms Cuộc gọi cơ sở dữ liệu, đĩa hoặc truy cập mạng) để chạy không đồng bộ.

Sử dụng async/await hướng dẫn nguyên thủy trong .NET 4.5.

Nhóm chủ đề sẽ tăng số lượng chuỗi nếu không có chuỗi nào có sẵn khi nhiệm vụ được xếp hàng được truy xuất từ ​​hàng đợi của luồng chủ đề. Nếu xu hướng tiếp tục theo cách này trong máy chủ, bạn có thể sẽ kết thúc với một hồ bơi Starter đói. Với hàng đợi của luồng chứa đầy đủ các tác vụ .net sẽ từ chối nhiều yêu cầu hơn, do đó bạn sẽ có giới hạn về khả năng mở rộng của ứng dụng của mình.

hướng dẫn đang chờ sẽ tạo ra quy trình làm việc trong ứng dụng của bạn, giải phóng chuỗi chính. Sau khi hoạt động chạy dài được thực hiện, một nhiệm vụ mới được xếp hàng đợi trong nhóm luồng tự động cho phép bạn tiếp tục ứng dụng. Chủ đề giải phóng và tái chế theo cách này sẽ giữ cho # luồng logic hợp lý hiện tại ở mức tối thiểu, ngăn chặn sự đói và nhiều chuyển đổi ngữ cảnh giữa các luồng.

Cũng trong .NET 4.5 thuật toán mới kiểm soát chi phí/lợi ích của việc tạo luồng mới bên trong nhóm luồng, giữ mối quan hệ hợp lý giữa tăng hiệu suất và chuyển đổi ngữ cảnh khi xu hướng tăng. Đây là một lợi ích bổ sung mà bạn nhận được nếu bạn chuyển sang 4.5 nếu bạn đã không làm như vậy.

Vì vậy, bước đầu tiên là xác định các hoạt động chạy dài của bạn và sau đó làm cho chúng không đồng bộ.

Bạn có thể xác minh điều này bằng cách tương quan # chuỗi logic hợp lý hiện tại với các bộ đếm khác (kết nối máy khách cơ sở dữ liệu, đĩa IO đọc, v.v.). Nếu lần đầu tiên tăng khi những người khác tăng bạn có thể chắc chắn đây là vấn đề. Đồng thời kiểm tra xem các hoạt động mất bao lâu. 100 ms là một biện pháp tốt để nói rằng hoạt động của bạn dài chạy theo nghĩa chung.

Hy vọng trợ giúp này.