Tại sao bảng trang của tôi chiếm quá nhiều bộ nhớ?


10

Máy tính Windows 7 64 bit của tôi rất chậm chạp. Tôi nhận thấy trong Trình quản lý tác vụ rằng mức sử dụng bộ nhớ của tôi gần 100% - tuy nhiên mức sử dụng được báo cáo cho mỗi quá trình không tăng thêm tổng cộng 6GB (Firefox hiển thị khoảng 500 MB, phần còn lại ít hơn nhiều). Tôi đã tải xuống RAMMap và thấy rằng Bảng trang đang chiếm một lượng bộ nhớ đáng kể (2,5 GB).

Ảnh chụp màn hình RAMMap

Tôi đã googled điều này và không có nơi nào - rõ ràng bảng trang có thể bị phân mảnh. Rõ ràng tôi sẽ khởi động lại máy và xem nếu nó giúp. Nhưng có cách nào tốt hơn để sửa nó không?

EDIT: được khởi động lại và bảng trang giảm xuống còn 30 MB.

EDIT 2: Sau một vài ngày thời gian hoạt động, việc sử dụng bảng trang lại tăng lên. Tôi đã làm theo hướng dẫn của @ magicandre1981 trong câu trả lời này để tìm nguồn gốc của việc sử dụng bảng trang. Thật không may, tôi đã vẽ một khoảng trống - bảng trang được sử dụng bởi "Unknown"!

Ảnh chụp màn hình WPA

Bất cứ ai có bất kỳ ý tưởng sáng sủa?


Bạn phải xác định những gì đang sử dụng tệp trang của bạn để hiểu lý do sử dụng tệp trang của bạn (tức là bộ nhớ ảo) cao.
Ramhound

1
Không, tôi nghĩ rằng đây là bộ nhớ vật lý đang sử dụng, không phải ảo. Tôi nghĩ bảng trang là một loại tài liệu tham khảo cho trình quản lý bộ nhớ?
benshepherd

2
Như tôi đã nói trong câu hỏi, không có bất kỳ quá trình nào đang sử dụng bộ nhớ. Tôi có ấn tượng rằng bảng trang là một thứ khác với tệp trang .
benshepherd


1
Bảng trang là một thứ rất khác với tệp trang. Xem câu trả lời của tôi dưới đây. Ngoài ra, trong khi tệp trang có thể bị phân mảnh, bảng trang ... tốt, chúng luôn bị phân mảnh (như nằm rải rác trong RAM) và điều đó không quan trọng trong một chút.
Jamie Hanrahan

Câu trả lời:


5

Tôi cần bình luận cho các bình luận cho câu hỏi, đặc biệt là sự nhầm lẫn giữa "bảng trang" và "tệp trang". Đây không phải là một câu trả lời nhưng nó sẽ không phù hợp với không gian được phép cho ý kiến.

"Bảng trang" thực sự là một điều rất khác với tệp trang. Có n MB RAM được sử dụng cho các bảng trang không có nghĩa là bạn đang sử dụng n MB dung lượng trang. Và mặc dù một số mục trong bảng trang (PTEs, đó là những gì bảng trang bao gồm) tham chiếu đến nội dung của trang, nhưng không phải tất cả đều làm.

Các bảng trang là các cấu trúc trong bộ nhớ được MMU của CPU sử dụng để thực hiện dịch địa chỉ từ địa chỉ ảo (một lần nữa, không phải tệp trang) sang địa chỉ vật lý và bởi HĐH để theo dõi không gian địa chỉ ảo và giúp khắc phục lỗi trang. Bảng trang bao gồm các mục trong bảng trang (PTEs). Mỗi PTE chiếm 8 byte và xác định 4K byte không gian địa chỉ ảo - tức là một trang ảo. Đại khái, có một PTE cho mỗi trang không gian địa chỉ ảo.

Nhân tiện, mặc dù pagefile có thể gặp cả sự phân mảnh bên ngoài và bên trong (cái trước thường không có vấn đề gì; cái sau có thể được cải thiện bằng cách làm cho nó lớn gấp bốn lần), nhưng bảng trang không thể. Chúng luôn luôn bị phân mảnh và điều đó không quan trọng trong một chút.

Mỗi PTE có một bit "hợp lệ". Đối với các trang "hợp lệ", còn gọi là "thường trú", PTE chứa số trang vật lý tương ứng với số trang ảo được liên kết với PTE; cái này được MMU sử dụng trực tiếp.

Đối với các trang "không hợp lệ", MMU gây ra lỗi trang và PTE sau đó có nhiều định dạng và giải thích có thể có.

Lưu ý: Tất cả những điều trên áp dụng cho mọi hệ điều hành cho phép phân trang trên x86 / x64. Dưới đây là phần lớn dành riêng cho Windows, nhưng nhiều khái niệm áp dụng cho các HĐH khác, với sự khác biệt về chi tiết triển khai.

Đối với một trang trong bộ đệm trang, PTE vẫn chứa số trang vật lý. Đối với các trang bị mất từ ​​RAM và được ghi vào tệp trang, PTE không chứa số trang và phần bù trong tệp trang nơi nội dung trang được viết. Các nội dung PTE khác có thể là các tham chiếu đến các mô tả địa chỉ ảo , các tham chiếu đến " PTE nguyên mẫu", các tham chiếu đến các trang không có nhu cầu , v.v., mà tôi sẽ không tham gia. Chỉ cần nói rằng chỉ một số PTE đề cập đến các vị trí trong tệp trang.

Tôi đề cập đến tất cả những điều này chủ yếu để chỉ ra rằng pagefile và các bảng trang, trong khi có liên quan, chắc chắn không giống nhau.

Bảng trang được tổ chức thành một cấu trúc cây. Có một cây khác nhau, hoặc tập hợp các bảng trang, cho mỗi quy trình - đây là thứ cho phép mỗi quy trình xác định thể hiện không gian địa chỉ ảo của riêng nó. Bảng trang ở gốc của cây phải luôn ở trong RAM. Những người khác là phân trang; chúng thậm chí không tồn tại ở nơi chúng sẽ tương ứng với các vùng lớn (tối thiểu 2 MB) không gian địa chỉ ảo không xác định hoặc miễn phí.

Các mục trong bảng trang trong các bảng ở "lá" của cây tương ứng với các trang của không gian địa chỉ ảo. Các PTE trong các bảng cấp cao hơn - các bảng gần với gốc hơn (và chính gốc) - cho biết các bảng cấp thấp tiếp theo nằm ở đâu (nếu chúng tồn tại).

Số được hiển thị bởi RAMmap là bộ nhớ vật lý (RAM) được chiếm bởi tất cả các bảng trang thường trú (trong RAM) cho tất cả các quy trình cộng với HĐH.

Điều quan trọng ở đây là hệ thống trong OQ có 2,5 GB RAM được gắn với các bảng trang. Điều đó có nghĩa là, tối thiểu, có 2,5 GB bảng trang được xác định. Vì các bảng trang có thể phân trang được, kích thước ảo có thể lớn hơn nhiều so với kích thước vật lý, đó là tất cả RAMmap có thể hiển thị cho chúng tôi. Nhưng giả sử nó "chỉ" 2,5 GB. Với tám byte cho mỗi PTE, tức là khoảng 320 triệu PTE. Vì mỗi PTE định nghĩa một trang - 4K byte - không gian địa chỉ ảo, điều đó có nghĩa là hơn 1,2 terabyte không gian địa chỉ ảo được xác định bởi các bảng trang trong bộ nhớ .

Điều đó không phải là không thể nhưng nó khá là nhiều.

Để tham khảo, trên hệ thống của tôi, tôi có khoảng 125 MB RAM trong các bảng trang. Điều này sẽ chỉ cho thấy khoảng 65 GB không gian địa chỉ ảo. Mức sử dụng ảo thực tế của tôi cao hơn nhiều (125 TB chỉ dành cho các quy trình) nhưng đó là do hầu hết các bảng trang không có RAM. "Các trang lớn", một điều khác tôi không nên vào đây, cũng có thể giúp tính các tỷ lệ khác nhau giữa kích thước của bảng trang so với kích thước của không gian địa chỉ ảo đang sử dụng.

Vì vậy: Để tìm ra thủ phạm, trước tiên tôi sẽ tìm kiếm trong Trình theo dõi hiệu suất trong danh mục Quy trình cho các quy trình có giá trị truy cập "Virtual Byte" cao.


4

Lenovo "RapidBoot Shield" là thủ phạm đối với tôi.

Sau một tuần không khởi động lại, "Bảng trang" của tôi đã sử dụng 4GB +. Hóa ra, mọi quy trình bị chấm dứt đều bị kẹt khi sử dụng RAM 20K (riêng tư 4K, Bảng trang 16K) như được hiển thị trong tab "Quy trình" của RamMap và có khoảng 200.000 trong số chúng!

Khởi động lại giảm danh sách nhưng nó bắt đầu phát triển trở lại. Nó có thể được sao chép bằng cách mở notepad, giết nó và quan sát rằng nó vẫn nằm trong danh sách các quy trình RamMap.

Dựa trên các đề xuất về luồng kỹ thuật này, tôi đã gỡ cài đặt "RapidBoot Sheild", khởi động lại máy và sau đó các quy trình không còn tồn tại khi bị giết. Vấn đề được giải quyết!


3

Trong trường hợp của tôi, đây là trình điều khiển bộ lọc Aksdf.sys và Hardlock.sys từ trình điều khiển Aladdin Knowledge Systems Aladdin . Tôi cũng đã tìm được câu trả lời bằng RAMMap. Nó hiển thị bộ nhớ, tiêu thụ bởi quá trình kết thúc. Các quy trình đã bị xóa khỏi danh sách quy trình Windows vẫn tồn tại trong bản đồ bộ nhớ. Các trình điều khiển dường như ngăn chặn hoàn toàn các quá trình.


1

Tôi đã hỏi bộ phận CNTT của tôi về điều này, và họ cũng tương tự như vậy. Tôi đã kết thúc bằng Driver Easy để cập nhật trình điều khiển của mình. Những người dường như tạo ra sự khác biệt, đủ kỳ lạ, là các trình điều khiển màn hình. Trước đây tôi đã có trình điều khiển Windows "Generic PnP Monitor" tiêu chuẩn. Nhưng khi tôi cập nhật chúng cho đúng kiểu dáng và mẫu màn hình của mình, vấn đề dường như biến mất.


1

Mở tab "Quy trình" trong RamMap và sắp xếp theo tên. Tìm kiếm một số lượng cao đáng ngờ của cùng một quá trình. Trên máy của tôi, "SynTPEnh.exe" là thủ phạm (một phần của trình điều khiển touchpad). Sau một tuần hoạt động, nó đã tích lũy được hàng chục ngàn mục trong bảng trang, mỗi kích thước 32kb.

Kích thước bảng trang của tôi là 1 GB, sau khi khởi động lại, nó chỉ còn 50 MB.

nhập mô tả hình ảnh ở đây

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.