Hiểu cách sử dụng bộ nhớ ảo> trao đổi + vật lý trên Linux

Tôi có một quy trình được báo cáo trong 'top' rằng nó có 6GB bộ nhớ lưu trú và 70GB bộ nhớ ảo được phân bổ. Điều kỳ lạ là máy chủ đặc biệt này chỉ có 8GB vật lý và 35GB dung lượng trao đổi có sẵn.

Từ hướng dẫn 'hàng đầu':

   o: VIRT  --  Virtual Image (kb)
      The total amount of virtual memory used by the  task.   It  includes
      all  code,  data  and  shared  libraries  plus  pages that have been
      swapped out. (Note: you can define the STATSIZE=1 environment  vari-
      able  and  the VIRT will be calculated from the /proc/#/state VmSize
      field.)

      VIRT = SWAP + RES.

Đưa ra lời giải thích này, tôi sẽ mong đợi việc cấp phát bộ nhớ virut cho một quá trình được giới hạn trong trao đổi + bộ nhớ vật lý có sẵn của tôi.

Theo 'pmap', mã, thư viện dùng chung và các phần bộ nhớ dùng chung của quy trình này đều tối thiểu - không quá 300M hoặc hơn.

Rõ ràng, máy và quy trình vẫn hoạt động chính xác (mặc dù chậm), vậy tôi còn thiếu gì ở đây?

Nó có thể là bộ nhớ không yêu cầu không có trong ram vật lý hoặc trong tệp trang.

Một số tài nguyên bạn có thể muốn xem xét:

• http://www.gitam.edu/eresource/comp/gvr(os)/13.6.htm
• http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2006-11/msg00176.html

Ứng dụng của bạn có tạo ra nhiều trang bộ nhớ trống không? Nếu vậy, ứng dụng của bạn có thể được hưởng lợi rất nhiều từ:

• http://code.google.com.vn/p/compcache/ ( TRẢI NGHIỆM )

Nó cho phép bạn nén và giải nén trong các trang bộ nhớ thời gian thực. Đổi lại, bạn có thể giữ mọi thứ trong RAM thay vì trao đổi vào đĩa ( rất chậm ).

Đây là một cuộc thảo luận về đức so với bộ nhớ cư dân:

/programming/561245/virtual-memory-usage-from-java-under-linux-too-much-memory- used

Cuộc thảo luận đề cập đến các quy trình Java, nhưng có thể áp dụng cho mọi thứ chạy trên Linux. Điểm chính liên quan đến đức là tổng số bao gồm cả một loạt các công cụ có thể không bao giờ được sử dụng. Virt là một cái gì đó để xem xét cho các HĐH 32 bit (vì các quy trình sẽ đạt giới hạn về không gian địa chỉ), nhưng phần lớn không hữu ích nếu không. Như đã lưu ý, điều cần chú ý là bộ nhớ lưu trú, sẽ bị giới hạn ở RAM vật lý có sẵn và trao đổi của bạn.

Điều này có thể là do không gian địa chỉ của quy trình có kích thước như bạn đã nêu, nhưng nó không thực sự được phân bổ bởi HĐH.

Từ: http://lwn.net/Articles/428100/

Trong quá trình cố gắng đạt được mục tiêu "đủ chi phí thấp và không có độ trễ đáng kể", các nhà phát triển Go đã đưa ra một số giả định đơn giản hóa, một trong số đó là bộ nhớ được quản lý cho một ứng dụng đang chạy đến từ một địa điểm gần như duy nhất phạm vi địa chỉ. Các giả định như vậy có thể gặp phải cùng một vấn đề mà trình soạn thảo của bạn gặp phải với vi - mã khác có thể phân bổ các phần ở giữa phạm vi - vì vậy các nhà phát triển Go đã áp dụng cùng một giải pháp: họ chỉ phân bổ tất cả bộ nhớ mà họ nghĩ họ cần (họ đã tìm ra, một cách hợp lý, 16GB đó sẽ đủ cho hệ thống 64 bit) khi khởi động.

Vì vậy, đôi khi đó là cách quản lý bộ nhớ không được thực hiện - có một không gian địa chỉ liên tục đơn giản hóa việc giải phóng các mem không sử dụng.

Câu trả lời có lẽ là MMAP - dữ liệu nằm trên đĩa, nhưng nó nằm ngoài "trao đổi" và không thể nhìn thấy bằng lệnh "miễn phí" hoặc "trên cùng".

Nếu quy trình java không quá phức tạp, bạn có thể thử chơi với "lsof" để tìm vị trí tệp MMAP. Tuy nhiên nếu quá trình java này phức tạp, sẽ khó có thể nhìn thấy.

Tôi cũng ngạc nhiên khi Linux cho phép bạn phân bổ bộ nhớ ảo nhiều hơn bộ nhớ vật lý + không gian hoán đổi, nhưng rõ ràng nó giúp hiệu năng trong các tình huống điển hình.

May mắn thay, có một tham số điều chỉnh kernel có thể được sử dụng để chuyển đổi chế độ kế toán bộ nhớ. Tham số này là vm.overcommit_memory và nó cho biết thuật toán nào được sử dụng để theo dõi bộ nhớ khả dụng. Mặc định (0), sử dụng phương pháp heuristic và vượt quá hệ thống bộ nhớ ảo. Nếu bạn muốn các chương trình của mình nhận được các lỗi hết bộ nhớ phù hợp khi phân bổ thay vì khiến các quá trình của bạn bị giết ngẫu nhiên, bạn nên đặt tham số này thành 2.

http://www.linuxjournal.com/article/10678