Byte riêng, byte ảo, tập làm việc là gì?

Tôi đang cố gắng sử dụng tiện ích perfmon windows để gỡ lỗi rò rỉ bộ nhớ trong một tiến trình.

Đây là cách perfmon giải thích các điều khoản:

Bộ làm việc là kích thước hiện tại, tính bằng byte, của Bộ làm việc của quy trình này. Bộ làm việc là tập hợp các trang bộ nhớ được chạm vào gần đây bởi các luồng trong quy trình. Nếu bộ nhớ trống trong máy tính vượt quá ngưỡng, các trang sẽ được để lại trong Bộ làm việc của một quy trình ngay cả khi chúng không được sử dụng. Khi bộ nhớ trống giảm xuống dưới ngưỡng, các trang sẽ được cắt bớt khỏi Bộ làm việc. Nếu cần, sau đó chúng sẽ bị lỗi mềm trở lại Bộ làm việc trước khi rời bộ nhớ chính.

Byte ảo là kích thước hiện tại, tính bằng byte, của không gian địa chỉ ảo mà quá trình đang sử dụng. Việc sử dụng không gian địa chỉ ảo không nhất thiết ngụ ý việc sử dụng tương ứng của các trang đĩa hoặc bộ nhớ chính. Không gian ảo là hữu hạn và quá trình có thể giới hạn khả năng tải các thư viện.

Byte riêng là kích thước hiện tại, tính bằng byte, của bộ nhớ mà quá trình này đã phân bổ không thể chia sẻ với các quy trình khác.

Đây là những câu hỏi tôi có:

Đây có phải là byte riêng mà tôi nên đo để chắc chắn liệu quy trình có bị rò rỉ hay không vì nó không liên quan đến bất kỳ thư viện dùng chung nào và bất kỳ rò rỉ nào, nếu xảy ra, sẽ đến từ chính quá trình đó?

Tổng bộ nhớ tiêu thụ của quá trình là gì? Đây có phải là byte ảo hay là tổng của byte ảo và bộ làm việc?

Có bất kỳ mối quan hệ nào giữa các byte riêng, bộ làm việc và byte ảo không?

Có công cụ nào khác cho ý tưởng tốt hơn về việc sử dụng bộ nhớ không?

Câu trả lời ngắn gọn cho câu hỏi này là không có giá trị nào trong số này là một chỉ số đáng tin cậy về việc bộ nhớ thực sự sử dụng được bao nhiêu bộ nhớ và không có giá trị nào thực sự thích hợp để gỡ lỗi rò rỉ bộ nhớ.

Byte riêng đề cập đến dung lượng bộ nhớ mà quá trình thực thi đã yêu cầu - không nhất thiết là số lượng mà nó thực sự đang sử dụng . Chúng là "riêng tư" vì chúng (thường) loại trừ các tệp ánh xạ bộ nhớ (tức là các DLL được chia sẻ). Nhưng - đây là cách bắt - họ không nhất thiết loại trừ bộ nhớ được cấp phát bởi các tệp đó . Không có cách nào để biết liệu một sự thay đổi trong các byte riêng là do chính nó có thể thực thi được hay do một thư viện được liên kết. Các byte riêng tư cũng không chỉ là bộ nhớ vật lý; chúng có thể được phân trang vào đĩa hoặc trong danh sách trang chờ (nghĩa là không còn được sử dụng, nhưng chưa được phân trang).

Bộ công việc đề cập đến tổng bộ nhớ vật lý (RAM) được sử dụng bởi quy trình. Tuy nhiên, không giống như các byte riêng tư, điều này cũng bao gồm các tệp được ánh xạ bộ nhớ và các tài nguyên khác, do đó, nó là một phép đo thậm chí còn kém chính xác hơn các byte riêng tư. Đây là cùng một giá trị được báo cáo trong "Sử dụng Mem" của Trình quản lý tác vụ và là nguồn gốc của vô số sự nhầm lẫn trong những năm gần đây. Bộ nhớ trong Bộ làm việc là "vật lý" theo nghĩa là nó có thể được xử lý mà không có lỗi trang; Tuy nhiên, danh sách trang standby là cũng vẫn thể chất trong bộ nhớ nhưng không được báo cáo trong Set Working, và đây là lý do tại sao bạn có thể thấy "Mem Usage" đột nhiên thả khi bạn hạn chế tối đa một ứng dụng.

Byte ảo là tổng không gian địa chỉ ảo bị chiếm bởi toàn bộ quá trình. Điều này giống như tập làm việc, theo nghĩa là nó bao gồm các tệp ánh xạ bộ nhớ (DLL chung), nhưng nó cũng bao gồm dữ liệu trong danh sách chờ và dữ liệu đã được phân trang và đang nằm trong một trang trên đĩa ở đâu đó. Tổng số byte ảo được sử dụng bởi mọi quy trình trên một hệ thống chịu tải nặng sẽ tăng thêm bộ nhớ đáng kể so với máy thực sự có.

Vì vậy, các mối quan hệ là:

• Byte riêng là những gì ứng dụng của bạn đã thực sự phân bổ, nhưng bao gồm việc sử dụng pagefile;
• Bộ công việc là các byte riêng không phân trang cộng với các tệp ánh xạ bộ nhớ;
• Byte ảo là Bộ làm việc cộng với byte riêng được phân trang và danh sách chờ.

Có một vấn đề khác ở đây; cũng giống như các thư viện dùng chung có thể phân bổ bộ nhớ trong mô-đun ứng dụng của bạn, dẫn đến các lỗi tích cực tiềm ẩn được báo cáo trong Private Byte của ứng dụng, ứng dụng của bạn cũng có thể phân bổ bộ nhớ trong các mô-đun được chia sẻ , dẫn đến phủ định sai . Điều đó có nghĩa là ứng dụng của bạn thực sự có thể bị rò rỉ bộ nhớ mà không bao giờ xuất hiện trong byte riêng tư. Không thể, nhưng có thể.

Byte riêng là một xấp xỉ hợp lý của lượng bộ nhớ mà bạn có thể sử dụng và có thể được sử dụng để thu hẹp danh sách các ứng cử viên tiềm năng bị rò rỉ bộ nhớ; nếu bạn thấy con số tăng lên và tăng trưởng liên tục và vô tận, bạn sẽ muốn kiểm tra xem có bị rò rỉ không. Tuy nhiên, điều này không thể chứng minh rằng có hoặc không có rò rỉ.

Một trong những công cụ hiệu quả nhất để phát hiện / sửa lỗi rò rỉ bộ nhớ trong Windows thực sự là Visual Studio (liên kết đến trang sử dụng VS để rò rỉ bộ nhớ, không phải trang sản phẩm). Rational Purify là một khả năng khác. Microsoft cũng có một tài liệu thực hành tốt nhất chung hơn về chủ đề này. Có nhiều công cụ được liệt kê trong câu hỏi trước đây .

Tôi hy vọng điều này sẽ làm sáng tỏ một vài điều! Theo dõi rò rỉ bộ nhớ là một trong những điều khó thực hiện nhất trong việc gỡ lỗi. Chúc may mắn.

Bạn không nên cố gắng sử dụng perfmon, trình quản lý tác vụ hoặc bất kỳ công cụ nào như thế để xác định rò rỉ bộ nhớ. Chúng tốt cho việc xác định xu hướng, nhưng không nhiều. Các số họ báo cáo theo thuật ngữ tuyệt đối quá mơ hồ và được tổng hợp để hữu ích cho một tác vụ cụ thể như phát hiện rò rỉ bộ nhớ.

Một câu trả lời trước cho câu hỏi này đã đưa ra một lời giải thích tuyệt vời về các loại khác nhau là gì.

Bạn hỏi về một đề xuất công cụ: Tôi khuyên bạn nên Trình xác thực bộ nhớ. Có khả năng giám sát các ứng dụng tạo ra hàng tỷ phân bổ bộ nhớ.

http://www.softwareverify.com/cpp/memory/index.html

Tuyên bố miễn trừ trách nhiệm: Tôi đã thiết kế Trình xác thực bộ nhớ.

Định nghĩa của bộ đếm perfmon đã bị phá vỡ ngay từ đầu và vì một lý do nào đó dường như quá khó để sửa.

Tổng quan tốt về quản lý bộ nhớ Windows có sẵn trong video " Bí ẩn về quản lý bộ nhớ được tiết lộ " trên MSDN: Nó bao gồm nhiều chủ đề hơn mức cần thiết để theo dõi rò rỉ bộ nhớ (ví dụ: quản lý bộ làm việc) nhưng cung cấp đủ chi tiết trong các chủ đề có liên quan.

Để cung cấp cho bạn một gợi ý về vấn đề với các mô tả bộ đếm perfmon, đây là câu chuyện bên trong về các byte riêng tư từ " Bộ đếm hiệu suất byte riêng tư - Hãy coi chừng! " Trên MSDN:

Q: Khi nào thì Byte riêng không phải là Byte riêng?

A: Khi nó không cư trú.

Bộ đếm Byte riêng báo cáo phí cam kết của quy trình. Điều đó có nghĩa là, dung lượng đã được phân bổ trong tệp hoán đổi để giữ nội dung của bộ nhớ riêng trong trường hợp nó bị tráo đổi. Lưu ý: Tôi đang tránh từ "dành riêng" vì có thể nhầm lẫn với bộ nhớ ảo ở trạng thái dành riêng không được cam kết.

Từ " Lập kế hoạch hiệu suất " trên MSDN:

3.3 byte riêng

3.3.1 Mô tả

Bộ nhớ riêng, được định nghĩa là bộ nhớ được phân bổ cho một quy trình không thể chia sẻ bởi các quy trình khác. Bộ nhớ này đắt hơn bộ nhớ dùng chung khi nhiều quá trình như vậy thực thi trên một máy. Bộ nhớ riêng trong các dll không được quản lý (truyền thống) thường tạo thành các thống kê C ++ và chiếm 5% tổng số tập làm việc của dll.

Có một cuộc thảo luận thú vị ở đây: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/307d658a-f677-40f2-bdef-e6352b0bfe9e/ Sự hiểu biết của tôi về chủ đề này là giải phóng phân bổ nhỏ không được phản ánh trong Private Byte hoặc Work Set.

Mẩu chuyện dài:

nếu tôi gọi

p=malloc(1000);
free(p);

sau đó các byte riêng chỉ phản ánh sự phân bổ, không phải là sự phân bổ.

nếu tôi gọi

p=malloc(>512k);
free(p);

sau đó các byte riêng phản ánh chính xác sự phân bổ và sự phân bổ.