Linux không giải phóng bộ nhớ cache đĩa lớn khi nhu cầu bộ nhớ tăng


24

Chạy Ubuntu trên kernel 2.6.31-302 x86-64. Vấn đề chung là tôi có bộ nhớ trong danh mục 'được lưu trong bộ nhớ cache' liên tục tăng và sẽ không được giải phóng hoặc sử dụng ngay cả khi ứng dụng của chúng tôi cần.

Vì vậy, đây là những gì tôi nhận được từ lệnh 'miễn phí'. Không ai trong số này nhìn ra ngoài bình thường thoạt nhìn.

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5750320    1608172          0       7848    1443820
-/+ buffers/cache:    4298652    3059840
Swap:            0          0          0

Điều đầu tiên ai đó sẽ nói là "Đừng lo lắng, linux sẽ tự động quản lý bộ nhớ đó." Vâng, tôi biết làm thế nào trình quản lý bộ nhớ được cho là làm việc; Vấn đề là nó không làm đúng. 1,4 GB "được lưu trong bộ nhớ cache" ở đây dường như được bảo lưu và không sử dụng được.

Kiến thức về Linux của tôi cho tôi biết rằng 3 GB là "miễn phí"; nhưng hành vi của hệ thống nói khác. Khi bộ nhớ trống thực tế 1.6 GB được sử dụng hết trong thời gian sử dụng tối đa, ngay khi có nhiều bộ nhớ hơn (và 'miễn phí' trong cột đầu tiên tiếp cận 0), kẻ giết người OOM được gọi, các quy trình bị giết và các vấn đề bắt đầu nảy sinh ngay cả khi 'miễn phí' trong hàng - / + bộ đệm / bộ đệm vẫn có khoảng 1,4 GB 'miễn phí'.

Tôi đã điều chỉnh các giá trị oom_adj trên các quy trình chính để nó không khiến hệ thống phải quỳ xuống, nhưng ngay cả khi đó các quy trình quan trọng sẽ bị giết và chúng tôi không bao giờ muốn đạt đến điểm đó. Đặc biệt là về mặt lý thuyết, 1,4 GB vẫn là "miễn phí" nếu nó chỉ xóa bộ nhớ cache của đĩa.

Có ai có bất cứ ý tưởng những gì đang xảy ra ở đây? Internet tràn ngập những câu hỏi ngớ ngẩn về lệnh 'miễn phí' của Linux và "tại sao tôi không có bộ nhớ trống" và tôi không thể tìm thấy bất cứ điều gì về vấn đề này vì điều đó.

Điều đầu tiên xuất hiện trong đầu tôi là hoán đổi bị tắt. Chúng tôi có một sysadmin kiên quyết về nó; Tôi sẵn sàng giải thích nếu chúng được sao lưu. Điều này có thể gây ra vấn đề?

Đây là miễn phí sau khi chạy echo 3 > /proc/sys/vm/drop_caches:

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5731688    1626804          0        524    1406000
-/+ buffers/cache:    4325164    3033328
Swap:            0          0          0

Như bạn có thể thấy, một số lượng bộ nhớ cache rất nhỏ thực sự được giải phóng, nhưng khoảng 1,4 GB dường như bị "kẹt". Vấn đề khác là giá trị này dường như tăng theo thời gian. Trên một máy chủ khác, 2.0 GB bị kẹt.

Tôi thực sự muốn bộ nhớ này trở lại ... bất kỳ trợ giúp sẽ được đánh giá cao nhất.

Đây là cat /proc/meminfonếu nó có giá trị bất cứ điều gì:

# cat /proc/meminfo 
MemTotal:        7358492 kB
MemFree:         1472180 kB
Buffers:            5328 kB
Cached:          1435456 kB
SwapCached:            0 kB
Active:          5524644 kB
Inactive:          41380 kB
Active(anon):    5492108 kB
Inactive(anon):        0 kB
Active(file):      32536 kB
Inactive(file):    41380 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:               320 kB
Writeback:             0 kB
AnonPages:       4125252 kB
Mapped:            42536 kB
Slab:              29432 kB
SReclaimable:      13872 kB
SUnreclaim:        15560 kB
PageTables:            0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3679244 kB
Committed_AS:    7223012 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        7696 kB
VmallocChunk:   34359729675 kB
DirectMap4k:     7340032 kB
DirectMap2M:           0 kB

3
Tôi không có bất kỳ lời giải thích nào cho bộ nhớ cache của bạn (mặc dù tôi nghi ngờ rằng các tệp của mmap có thể có trong đó), nhưng vì lợi ích của nhân loại, hãy dùng xẻng và một số vôi sống và loại bỏ "bạn không cần trao đổi nếu bạn có nhiều RAM! " tăng cường. Họ miễn nhiễm với các cuộc thảo luận hợp lý, và họ đã sai một cách nguy hiểm. Việc kẻ giết người OOM đang rình rập bạn chỉ là một triệu chứng của việc này.
womble

Suy nghĩ của tôi chính xác. Cảm ơn vì lời khuyên. Bạn có biết bất kỳ bài viết hay lập luận tốt nào khác về lý do tại sao trao đổi là cần thiết?
trisweb

6
Bởi vì nếu bạn không có trao đổi, những thứ như thế này sẽ xảy ra. Nhưng đừng bận tâm đến việc tranh luận với người từ chối trao đổi của bạn; hoặc thoát ra khỏi vôi sống hoặc nói "nếu bạn không muốn trao đổi ở đây, bạn sẽ sửa chữa mớ hỗn độn này mà bạn khăng khăng tạo ra". Cuối cùng họ sẽ tự thay đổi suy nghĩ hoặc họ sẽ chết vì cố gắng. Vấn đề được giải quyết một trong hai cách.
womble

Tuyệt vời, cảm ơn vì lời khuyên. Nhân tiện, bạn đã đúng về các tập tin mmap'd - một lsof nhanh chóng cho thấy các tập tin nhật ký chiếm bộ nhớ. Xóa chúng ra đã giải quyết vấn đề.
trisweb

Vấn đề là không có trao đổi, kết quả quá mức trong trình diệt OOM đang chạy và không kết quả quá mức trong một hệ thống không thể khởi chạy các quy trình. Bạn cần trao đổi để sử dụng RAM hiệu quả.
David Schwartz

Câu trả lời:


8

Tôi đã phát hiện ra câu trả lời cho câu hỏi của riêng tôi - nhờ sự giúp đỡ của womble (gửi câu trả lời nếu bạn muốn).

lsof -s hiển thị các thẻ xử lý tệp đang sử dụng và hóa ra có một vài gigabyte tệp nhật ký mmap chiếm bộ nhớ cache.

Việc thực hiện một logrotate sẽ giải quyết hoàn toàn vấn đề và cho phép tôi tận dụng nhiều bộ nhớ hơn.

Tôi cũng sẽ kích hoạt lại trao đổi để chúng tôi không gặp vấn đề gì với kẻ giết người OOM trong tương lai. Cảm ơn.


2
Các trang của mmap'd bị loại bỏ do đó không nên khiến bộ đệm được ghim. Bạn đang sử dụng một ramfs?
psusi

Xin chào, xin lỗi vì đã đào một chủ đề cũ, nhưng hiện tại tôi đang đối mặt với cùng một vấn đề và lsof -skhông hiển thị bất kỳ cách sử dụng bất thường nào. Tuy nhiên, tôi đang sử dụng một ramfs như bạn đã nói [và kernel 2.6.10, không có tính năng drop_caches]. Bạn nghĩ gì là nghi phạm có khả năng?
Ram

1
Cảm ơn vì tiền hỗ trợ! Tôi đang thêm lsof -s | sort -rnk 7 | lessvào hộp công cụ của tôi bây giờ. Một lưu ý cho những độc giả khác: đây có thể là những mục lớn như thế /proc/net/rpc/nfs4.nametoid/channel, nhưng họ không trở thành thủ phạm trong trường hợp của tôi.
Nickolay

đảm bảo các tệp hoặc chương trình lớn của bạn không sử dụng mlock. trong /proc/meminfocái nhìn tại trang "Unevictable".
Michael Martinez

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.