Làm cách nào để xác định ứng dụng nào bị rò rỉ bộ nhớ nonpaged?

Gần đây chúng tôi đã gặp sự cố trên máy chủ trực tiếp khiến Ứng dụng web của chúng tôi ngừng phản hồi. Tất cả những gì chúng tôi nhận được là 503 lỗi cho đến khi chúng tôi khởi động lại máy chủ thì mọi chuyện vẫn ổn. Cuối cùng, tôi đã lần theo dấu vết của nó trở lại omeprr.log và tìm thấy rất nhiều lỗi 1_Connections_Refuse.

Điều tra sâu hơn dường như chỉ ra rằng chúng tôi đã đạt đến giới hạn nhóm không được phân loại. Kể từ đó, chúng tôi đã theo dõi bộ nhớ pool không được phân vùng bằng Poolmon.exe và chúng tôi tin rằng chúng tôi đã xác định được thẻ gây ra sự cố.

Tag   Type    Allocs       Frees       Diff       Bytes      Per Alloc
Even  Nonp  51,231,806   50,633,533   684,922   32,878,688      48

Nếu chúng tôi sử dụng poolmon.exe / g, nó sẽ hiển thị Trình điều khiển được ánh xạ dưới dạng [<unknown> đối tượng sự kiện].

Điều này là khá nhiều không có sự giúp đỡ nào cả. Nhóm của tôi đã dành thời gian đáng kể để nghiên cứu vấn đề này và không thể tìm thấy một quy trình để thu hẹp vấn đề này xuống một ứng dụng hoặc dịch vụ cụ thể. Tôi có cảm giác rằng hầu hết mọi người dường như giải quyết vấn đề bằng cách giết các tiến trình trên máy cho đến khi họ thấy thiết lập lại bộ nhớ không bị chặn. Đây không phải là chính xác những gì bạn muốn thấy khi làm việc trên một máy sản xuất.

Nếu tôi mở Trình quản lý tác vụ và xem danh sách quy trình. Tôi thấy MailService.exe có giá trị NP Pool là 105K, cao hơn 36K so với giá trị của quy trình được liệt kê thứ hai. Vì chúng tôi đã có một số vấn đề với Máy chủ Thư của chúng tôi trong quá khứ (có thể có hoặc không liên quan đến vấn đề này) cảm giác ruột của tôi là điều này gây ra sự cố.

Tuy nhiên, trước khi chúng tôi ngừng khởi động lại các dịch vụ, tôi muốn có một chút chắc chắn hơn là chỉ là "cảm giác ruột".

Tôi cũng đã thử sử dụng poolmon.exe / c nhưng điều này luôn trả về lỗi:

unable to load msvcr70.dll/msvcp70.dll

và nó không tạo localtag.txt. Đồng nghiệp của tôi đã phải tải xuống pooltag.txt từ internet vì chúng tôi không thể tìm ra vị trí của nó. Chúng tôi không có trình gỡ lỗi win hoặc cài đặt DDK win (mà tôi có thể thấy). Có thể lỗi ở trên được đưa ra bởi vì chúng tôi không cài đặt một trong hai lỗi này - nhưng tôi không biết.

Cuối cùng tôi đã thử:

C:\windows\system32\driver\findstr /m /l Even *.sys

Điều này trả về một danh sách khá lớn các tệp .sys và một lần nữa hoàn toàn không hữu ích với vấn đề trong tay.

Vì vậy, câu hỏi của tôi là: Có cách nào khác để thu hẹp nguyên nhân rò rỉ bộ nhớ này không?

CẬP NHẬT:

Như được đề xuất bên dưới, tôi đã đăng nhập Pool Nonpaged Byte cho ngày cuối cùng hoặc lâu hơn để xem liệu có quá trình nào đang có xu hướng hay không. Đối với hầu hết các phần, tất cả các quy trình dường như khá tĩnh trong việc sử dụng chúng. Hai trong số họ trông có vẻ nhột lên. Tôi sẽ tiếp tục theo dõi điều này trong vài ngày tới.

Tôi cũng quên đề cập trước đó rằng không có quá trình nào có vẻ như đang sử dụng quá nhiều số lần xử lý.

CẬP NHẬT 2:

Tôi đã theo dõi điều này trong vài tuần qua. Cả nhóm byte không được phân vùng cho các quy trình riêng lẻ và tổng số nhóm byte không được phân vùng vẫn tương đối ổn định trong thời gian đó. Trong thời gian này, Windows đã được cập nhật và máy chủ khởi động lại nên tôi tự hỏi liệu điều đó có giải quyết được vấn đề không. Tôi chắc chắn không thấy sự tăng trưởng nhất quán trong Nhóm Byte Nonpaged bây giờ mà tôi đã ở trước đó.

Tôi đã theo dõi điều này khoảng 6-7 tuần nay và cuối cùng có thể đưa ra câu trả lời dứt khoát cho vấn đề này.

Đầu tiên, các byte không được xử lý cho các quy trình riêng lẻ thực sự không cho tôi biết bất cứ điều gì hữu ích vì tất cả chúng đều có vẻ khá tĩnh trong cách sử dụng. Có những đột biến nhưng việc sử dụng luôn trở lại đường cơ sở sau đó.

Tổng bộ nhớ Byp Nonpaged cũng tĩnh trong một lúc nhưng sau đó bắt đầu tăng dần và sau đó tăng vọt. Sau khi tăng khoảng một nửa bộ nhớ đã được giải phóng và sau đó nó vẫn tĩnh trở lại (ở mức cao hơn) trong một thời gian cho đến khi mô hình lặp lại. Nhìn vào biểu đồ tôi nhận thấy rằng các gai này dường như khá đều đặn và hóa ra chúng xảy ra cách nhau 2 tuần và luôn luôn vào Chủ nhật.

Vì vậy, câu hỏi tiếp theo là: Cái gì đang chạy vào hai tuần một lần vào Chủ nhật? Tôi đã có một cái nhìn trong Event Viewer và mỗi khi có sự tăng đột biến thì McAfee đang chạy . Tôi cũng nghĩ rằng bằng cách đăng nhập vào máy chủ thường xuyên để theo dõi vấn đề, chúng tôi đã vô tình làm cho vấn đề trở nên tồi tệ hơn vì McAfee có một máy quét thời gian thực và tôi tin rằng điều này đã gây ra sự gia tăng nhỏ hơn mà chúng ta đang thấy.

Tôi nghĩ rằng việc quét đang được lên lịch tác vụ cũng giải thích lý do tại sao chúng tôi thấy Bộ nhớ NP tăng gắn liền với thẻ Đối tượng sự kiện trong PoolMon thay vì thẻ cụ thể của McAfee. Đây là điều chính thực sự dẫn chúng tôi xuống con đường vườn.

Bây giờ chúng tôi cuối cùng đã biết những gì gây ra rò rỉ, chúng tôi có thể làm gì đó về nó. Mặc dù vậy, thật khó tin khi phải mất nhiều thời gian để theo dõi nó.

CẬP NHẬT : Chỉ là một lưu ý cuối cùng. McAfee's đã được cập nhật vào cuối tuần và điều này đã giải quyết hoàn toàn vấn đề Bộ nhớ không phân trang của chúng tôi.

CẬP NHẬT 2 : Vì tôi vừa nhận được một phiếu bầu cho điều này, tôi sẽ thêm một bản cập nhật tiếp theo cho điều này. Ban đầu, bản cập nhật cho McAfee đã xuất hiện để khắc phục sự cố của chúng tôi, tức là chúng tôi không còn thấy các đột biến lớn trong Bộ nhớ NP theo định kỳ. Tôi cũng nhận thấy rằng kể từ khi cập nhật, có vẻ như McAfee không còn ghi nhật ký vào Trình xem sự kiện theo mặc định, nó ẩn khi nó đang tích cực quét.

Nhưng chúng ta vẫn đang thấy sự gia tăng dần dần trong việc sử dụng bộ nhớ NP. Đã đến lúc chúng ta cần khởi động lại máy chủ của mình sau mỗi 2 tuần hoặc lâu hơn. Thật tệ khi gần đây chúng tôi đã mua một máy chủ mới với hy vọng rằng phần cứng và phần mềm được cập nhật sẽ khiến vấn đề này biến mất NHƯNG máy chủ hoàn toàn mới của chúng tôi chỉ với Windows Server 2008, SQL Server 2008 R2 và McAfee được cài đặt VẪN hiển thị rò rỉ Bộ nhớ NP . Chỉ sau khi tôi gỡ bỏ hoàn toàn McAfee thì sự rò rỉ mới dừng lại và nó vẫn ở trạng thái tĩnh ngay cả sau khi chúng tôi thiết lập máy chủ với tất cả phần mềm của chúng tôi để chuẩn bị chuyển sang nó.

Tôi đã đọc và tôi không biết điều này có đúng không, rằng vấn đề không nằm ở McAfee, nhưng với một số thói quen Windows mà McAfee sử dụng khiến NP Memory bị rò rỉ. Rõ ràng, hoạt động mạng là nguyên nhân của sự rò rỉ tức là hoạt động mạng nhiều hơn => rò rỉ lớn hơn. Điều này dường như không phù hợp với kinh nghiệm của chúng tôi, trong đó rò rỉ đã trở nên tồi tệ hơn khi máy chủ của chúng tôi trở nên bận rộn hơn.