Giới hạn thực tế về số lượng các phiên bản FileSystemWatcher mà máy chủ có thể xử lý là gì?

Question

Tôi có dịch vụ cửa sổ hiện đang instantiating khoảng một chục FileSystemWatcher trường hợp để giám sát các thư mục được chia sẻ trên mạng công ty để xử lý tệp.

Tôi đang tìm kiếm thêm nhiều phiên bản khác vì vậy tôi tự hỏi liệu có ai ở đây có kinh nghiệm (với hệ thống sản xuất) hay không giới hạn thực tế về số lượng FileSystemWatcher trường hợp hệ thống sản xuất có thể xử lý một cách đáng tin cậy?

Chỉnh sửa: Trong trường hợp của tôi, thuộc tính InternalBufferSize không được sửa đổi để InternalBufferSize là mặc định 8 KB ... Tôi giả định tăng InternalBufferSize sẽ ảnh hưởng đến số lượng FileSystemWatcher trường hợp hệ thống có thể chạy đồng thời do đó cũng là một phần của equasion ...

Chỉnh sửa: Nếu bạn cho rằng đây chỉ là vấn đề tài nguyên và nó chỉ phụ thuộc vào lượng bộ nhớ có sẵn hoặc một số khía cạnh phần cứng khác của hệ thống, vui lòng chia sẻ kinh nghiệm hoặc liên kết của bạn với tài liệu hoặc các bài viết chứng thực ý kiến ​​của bạn ... Tôi thực sự muốn nghe từ một người đạt đến giới hạn sản xuất bất kể thông số kỹ thuật phần cứng của họ vì vậy trước khi bỏ phiếu, hãy xem xét rằng 7 người khác trong vòng chưa đầy 20 phút đã thể hiện sự quan tâm đến việc nghe từ một người đã đẩy giới hạn này lên ...

Answer 1

FileSystemWatcher dưới bìa sử dụng ReadDirectoryChangesWhttp://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx. Đây là một hoạt động hợp lý không tốn kém mà chỉ là một đọc từ thư mục mà hoàn thành trên một sự thay đổi.

Kết quả được lưu trữ trong bộ đệm hạt nhân trước khi chúng được sao chép vào bộ đệm bộ nhớ của riêng bạn FileSystemWatcher.

Đó là hai nguồn hệ điều hành để đi vào xem xét, Handle tạo ra bởi các cuộc gọi đến CreateFile bởi FileSystemWatcher, và kích thước 8KB (mặc định) đệm trong hạt nhân cho từng đối tượng FileSystemWatcher mà mất đi từ Kernel Paged và Không của hệ thống của bạn Bể bơi -Paged.

Số FileSystemWatcher của bạn chủ yếu cạnh tranh cho ba tài nguyên này.

1. CPU thời gian để xử lý những thay đổi
2. Xử lý trên hệ thống
3. Trang Pool

Bạn sẽ không gặp phải một vấn đề với (2). Có khả năng xảy ra sự cố với (3) trên hệ thống điện (tải của CPU) đang chạy x86. Nếu không (1) sẽ là giới hạn của bạn.

Xử lý

Handles đang bị cạn kiệt (đặc biệt trên x86), hơn về vấn đề này ở đây, http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx

Nhưng tại 16million xử lý + (ngay cả trên x86) trước khi bạn chạy ra ngoài, cho intententions của bạn, tôi d nghĩ về nó như một nguồn tài nguyên vô hạn. Bạn sẽ làm cạn kiệt các thay đổi xử lý CPU tốt trước khi bạn nhấn bất kỳ giới hạn hệ điều hành nào.

Trang/Pools Non-Paged

trang/Pools Non-Paged có thể được nhìn thấy trong công việc quản lý. Trên x86, chúng là rất hữu hạn. đây hơn, http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits

CPU

Bạn sẽ thấy vô số bằng chứng rằng khi điều này được cạn kiệt, FileSystemWatcher loại dừng làm việc. Một số thay đổi thư mục được báo cáo, một số không và không thể tránh khỏi khi triển khai lớn FileSystemWatcher bạn sẽ phải phát hiện những dịp này và tự mình liệt kê danh sách hoặc thực hiện trên cơ sở bỏ phiếu.

Ghi chú

Nếu bạn đang thực hiện một tải của FileSystemWatcher s coi chừng;

1. Bộ đệm trên chạy
2. Kích thước bộ đệm lớn hơn 64KB trên đường dẫn mạng.

Thông tin thêm về thực hành mã hóa tốt cho đối tượng này ở đây, http://bytes.com/topic/visual-basic-net/answers/536125-filesystemwatcher-across-network#post2092018