Có cách nào để phát hiện sự phân mảnh bộ nhớ trên linux không? Điều này là do trên một số máy chủ chạy lâu tôi đã nhận thấy sự suy giảm hiệu suất và chỉ sau khi tôi khởi động lại quá trình, tôi mới thấy hiệu suất tốt hơn. Tôi nhận thấy nó nhiều hơn khi sử dụng hỗ trợ trang lớn linux - các trang lớn trong linux có dễ bị phân mảnh hơn không?

Tôi đã xem xét / Proc / Buddyinfo nói riêng. Tôi muốn biết liệu có cách nào tốt hơn (không chỉ các lệnh CLI mỗi se, bất kỳ chương trình hoặc nền tảng lý thuyết nào sẽ làm) để xem xét nó.

Tôi đang trả lời cho thẻ linux . Câu trả lời của tôi chỉ dành riêng cho Linux .

Có, các trang lớn dễ bị phân mảnh hơn. Có hai khung nhìn của bộ nhớ, một khung nhìn mà quá trình của bạn nhận được (ảo) và một khung nhìn mà kernel quản lý (thực). Bất kỳ trang nào càng lớn, sẽ càng khó nhóm (và giữ nó với) hàng xóm của nó, đặc biệt là khi dịch vụ của bạn đang chạy trên một hệ thống cũng phải hỗ trợ những người khác mặc định phân bổ và ghi vào bộ nhớ nhiều hơn họ thực sự cuối cùng sử dụng.

Ánh xạ của các địa chỉ được cấp (thực) của kernel là riêng tư. Có một lý do rất chính đáng tại sao không gian người dùng xem chúng là kernel trình bày chúng, bởi vì kernel cần có khả năng vượt mức mà không gây nhầm lẫn cho không gian người dùng. Quá trình của bạn có được một không gian địa chỉ "Disneyfied" đẹp, liền kề để làm việc, không biết gì về nhân thực sự đang làm với bộ nhớ đó đằng sau hậu trường.

Lý do bạn thấy hiệu suất bị suy giảm trên các máy chủ chạy dài rất có thể là do các khối được phân bổ chưa bị khóa rõ ràng (ví dụ mlock()/ mlockall()hoặc posix_madvise()) và không được sửa đổi trong một thời gian đã bị loại bỏ , điều đó có nghĩa là dịch vụ của bạn trượt vào đĩa khi nó phải đọc họ Sửa đổi hành vi này làm cho quy trình của bạn trở thành hàng xóm tồi , đó là lý do tại sao nhiều người đưa RDBMS của họ lên một máy chủ hoàn toàn khác so với web / php / python / ruby ​​/ bất cứ điều gì. Cách duy nhất để khắc phục điều đó, hoàn toàn, là giảm sự cạnh tranh cho các khối liền kề.

Sự phân mảnh chỉ thực sự đáng chú ý (trong hầu hết các trường hợp) khi trang A nằm trong bộ nhớ và trang B đã chuyển sang hoán đổi. Đương nhiên, việc bắt đầu lại dịch vụ của bạn dường như sẽ 'chữa trị' điều này, nhưng chỉ vì hạt nhân chưa có cơ hội để đưa ra quy trình '(bây giờ) các khối mới được phân bổ trong giới hạn của tỷ lệ thừa.

Trên thực tế, việc bắt đầu lại (giả sử) 'apache' dưới tải trọng cao có khả năng sẽ gửi các khối thuộc sở hữu của các dịch vụ khác vào thẳng đĩa. Vì vậy, vâng, 'apache' sẽ cải thiện trong một thời gian ngắn, nhưng 'mysql' có thể bị ảnh hưởng .. ít nhất là cho đến khi hạt nhân khiến chúng đau khổ như nhau khi đơn giản là thiếu bộ nhớ vật lý dồi dào.

Thêm bộ nhớ, hoặc chia tách những malloc()người tiêu dùng khó tính :) Nó không chỉ là sự phân mảnh mà bạn cần phải xem xét.

Cố gắng vmstatcó được một cái nhìn tổng quan về những gì thực sự được lưu trữ ở đâu.

Hạt nhân

Để có được chỉ số phân mảnh hiện tại, sử dụng:

sudo cat /sys/kernel/debug/extfrag/extfrag_index

Để chống phân mảnh bộ nhớ kernel, hãy thử thực thi:

sysctl vm.compact_memory=1  

Ngoài ra, bạn hãy thử tắt các trang lớn trong suốt (còn gọi là THP) và / hoặc vô hiệu hóa trao đổi (hoặc giảm swappiness).

Không gian người dùng

Để giảm sự phân mảnh không gian người dùng, bạn có thể muốn thử phân bổ khác nhau, ví dụ jemalloc(nó có khả năng hướng nội tuyệt vời , điều này sẽ cung cấp cho bạn một phân đoạn bên trong của phân bổ).

Bạn có thể chuyển sang malloc tùy chỉnh bằng cách biên dịch lại chương trình của bạn với nó hoặc chỉ bằng cách chạy chương trình của bạn với LD_PRELOAD: LD_PRELOAD=${JEMALLOC_PATH}/lib/libjemalloc.so.1 app (hãy cẩn thận với các tương tác giữa THP và bộ cấp phát bộ nhớ )

Mặc dù, hơi không liên quan đến phân mảnh bộ nhớ (nhưng được kết nối với quá trình nén / di chuyển bộ nhớ), bạn có thể muốn chạy nhiều phiên bản dịch vụ của mình, một phiên bản cho mỗi nút NUMA và liên kết chúng bằng cách sử dụng numactl.

Sử dụng các trang lớn sẽ không gây ra sự phân mảnh bộ nhớ thêm trên Linux; Hỗ trợ Linux cho các trang lớn chỉ dành cho bộ nhớ dùng chung (thông qua shmget hoặc mmap) và bất kỳ trang lớn nào được sử dụng phải được yêu cầu cụ thể và được cấp phép bởi quản trị viên hệ thống. Khi đã ở trong bộ nhớ, chúng được ghim ở đó và không bị tráo đổi. Thách thức của việc hoán đổi trong các trang lớn khi phân mảnh bộ nhớ chính xác là lý do tại sao chúng vẫn bị ghim trong bộ nhớ (khi phân bổ một trang lớn 2 MB, hạt nhân phải tìm 512 trang 4KB miễn phí liền kề, thậm chí có thể không tồn tại).

Tài liệu Linux trên các trang lớn: http://lwn.net/Articles/375098/

Có một trường hợp phân mảnh bộ nhớ có thể khiến việc phân bổ trang lớn bị chậm (nhưng không phải là nơi các trang lớn gây ra phân mảnh bộ nhớ) và đó là nếu hệ thống của bạn được định cấu hình để phát triển nhóm trang lớn nếu được ứng dụng yêu cầu. Nếu / Proc / sys / vm / nr_overcommit_hugepages lớn hơn / Proc / sys / vm / nr_hugepages, điều này có thể xảy ra.

Có /proc/buddyinforất hữu ích. Nó hữu ích hơn với định dạng đầu ra đẹp, như kịch bản Python này có thể làm:

https://gist.github.com/labeneator/9574294

Đối với các trang lớn, bạn muốn có một số mảnh miễn phí ở kích thước 2097152 (2MiB) hoặc lớn hơn. Đối với các trang lớn trong suốt, nó sẽ tự động nén khi kernel được yêu cầu một số, nhưng nếu bạn muốn xem bạn có thể nhận được bao nhiêu, thì khi chạy root:

echo 1 | sudo tee /proc/sys/vm/compact_memory

Cũng có, các trang lớn gây ra vấn đề lớn cho phân mảnh. Hoặc bạn không thể có được bất kỳ trang lớn nào, hoặc sự hiện diện của chúng khiến kernel mất nhiều thời gian hơn để cố gắng lấy một số trang.

Tôi có một giải pháp phù hợp với tôi. Tôi sử dụng nó trên một vài máy chủ và máy tính xách tay của tôi. Nó hoạt động tuyệt vời cho các máy ảo.

Thêm kernelcore=4Gtùy chọn vào dòng lệnh Linux kernel của bạn. Trên máy chủ của tôi, tôi sử dụng 8G. Hãy cẩn thận với số này, vì nó sẽ ngăn hạt nhân của bạn phân bổ bất cứ thứ gì bên ngoài bộ nhớ đó. Các máy chủ cần nhiều bộ đệm ổ cắm hoặc ổ đĩa đó ghi vào hàng trăm ổ đĩa sẽ không thích bị giới hạn như thế này. Bất kỳ phân bổ bộ nhớ nào phải được "ghim" cho bản mỏng hoặc DMA đều thuộc loại này.

Tất cả bộ nhớ khác của bạn sau đó trở thành "có thể di chuyển", điều đó có nghĩa là nó có thể được nén lại thành các đoạn đẹp để phân bổ trang lớn. Bây giờ các trang lớn trong suốt có thể thực sự cất cánh và hoạt động như mong muốn. Bất cứ khi nào kernel cần nhiều hơn 2 triệu trang, nó có thể chỉ cần ánh xạ lại các trang 4K sang một nơi khác.

Và, tôi không hoàn toàn chắc chắn làm thế nào điều này tương tác với IO trực tiếp không sao chép. Bộ nhớ trong "vùng di động" không được cho là được ghim, nhưng một yêu cầu IO trực tiếp sẽ thực hiện chính xác điều đó cho DMA. Nó có thể sao chép nó. Nó có thể ghim nó trong vùng di động nào. Trong cả hai trường hợp, nó có thể không chính xác những gì bạn muốn.