Tại sao thả cache trong Linux?

Trong các máy chủ của chúng tôi, chúng tôi có thói quen thả bộ nhớ cache vào nửa đêm.

sync; echo 3 > /proc/sys/vm/drop_caches

Khi tôi chạy mã, nó dường như giải phóng rất nhiều RAM, nhưng tôi có thực sự cần phải làm điều đó không. Không phải RAM miễn phí là một sự lãng phí?

Bạn đúng 100%. Nó không phải là một thực hành tốt để giải phóng RAM. Đây có thể là một ví dụ về quản trị hệ thống sùng bái hàng hóa.

Có, xóa bộ nhớ cache sẽ giải phóng RAM, nhưng nó khiến kernel tìm kiếm các tệp trên đĩa thay vì trong bộ đệm có thể gây ra các vấn đề về hiệu năng.

Thông thường, kernel sẽ xóa bộ nhớ cache khi hết RAM. Nó thường ghi nội dung bẩn vào đĩa bằng pdflush.

Lý do để giảm bộ nhớ cache như thế này là để đánh giá hiệu năng đĩa và là lý do duy nhất nó tồn tại.

Khi chạy điểm chuẩn chuyên sâu I / O, bạn muốn chắc chắn rằng các cài đặt khác nhau mà bạn thử đều thực sự làm I / O trên đĩa, vì vậy Linux cho phép bạn bỏ bộ nhớ cache thay vì khởi động lại đầy đủ.

Để trích dẫn từ các tài liệu :

Tệp này không phải là phương tiện để kiểm soát sự phát triển của các bộ đệm hạt nhân khác nhau (inodes, dentries, pagecache, v.v.) Những đối tượng này được kernel tự động lấy lại khi cần bộ nhớ ở nơi khác trên hệ thống.

Sử dụng tập tin này có thể gây ra vấn đề hiệu suất. Vì nó loại bỏ các đối tượng được lưu trong bộ nhớ cache, nên có thể tốn một lượng đáng kể I / O và CPU để tạo lại các đối tượng bị rơi, đặc biệt nếu chúng đang được sử dụng nhiều. Do đó, không nên sử dụng ngoài môi trường kiểm tra hoặc gỡ lỗi.

Ý tưởng cơ bản ở đây có lẽ không tệ (chỉ rất ngây thơ và sai lệch): Có thể có các tệp được lưu trong bộ nhớ cache, rất khó có thể được truy cập trong tương lai gần, ví dụ như logfiles. Những ram "ăn hết" này, sau này sẽ phải được giải phóng khi cần thiết bởi HĐH bằng cách này hay cách khác.

Tùy thuộc vào cài đặt của bạn về swappiness, mẫu truy cập tệp, mẫu cấp phát bộ nhớ và nhiều thứ không thể đoán trước hơn, có thể xảy ra rằng khi bạn không giải phóng các bộ đệm này, chúng sẽ bị buộc phải sử dụng lại, mất nhiều thời gian hơn một chút cấp phát bộ nhớ từ nhóm bộ nhớ không sử dụng. Trong trường hợp xấu nhất, các cài đặt swappiness của linux sẽ khiến bộ nhớ chương trình bị tráo đổi, bởi vì linux nghĩ rằng các tệp đó có thể sẽ được sử dụng trong tương lai gần hơn bộ nhớ chương trình.

Trong môi trường của tôi, linux đoán khá thường xuyên sai và khi bắt đầu hầu hết các sàn giao dịch chứng khoán châu Âu (khoảng 0900 giờ địa phương), các máy chủ sẽ bắt đầu làm những việc mà họ chỉ làm một lần mỗi ngày, cần trao đổi trong bộ nhớ đã bị tráo đổi vì viết logfiles, nén chúng, sao chép chúng, v.v. đang lấp đầy bộ đệm đến mức mọi thứ phải được hoán đổi.

Nhưng liệu thả bộ đệm là giải pháp cho vấn đề này? chắc chắn không. Điều gì sẽ là giải pháp ở đây là nói với linux những gì nó không biết: những tệp này có thể sẽ không được sử dụng nữa. Điều này có thể được thực hiện bởi ứng dụng viết bằng cách sử dụng những thứ như posix_fadvise()hoặc sử dụng công cụ dòng cmd như vmtouch(cũng có thể được sử dụng để xem xét mọi thứ cũng như các tệp bộ đệm).

Bằng cách đó, bạn có thể xóa dữ liệu không cần thiết nữa khỏi bộ đệm và giữ những thứ cần lưu trong bộ nhớ cache, bởi vì khi bạn bỏ tất cả bộ nhớ cache, rất nhiều thứ phải đọc lại từ đĩa. Và rằng tại thời điểm tồi tệ nhất có thể: khi cần thiết; gây ra sự chậm trễ trong ứng dụng của bạn đáng chú ý và thường không được chấp nhận.

Những gì bạn nên có là một hệ thống theo dõi các kiểu sử dụng bộ nhớ của bạn (ví dụ nếu có thứ gì đó đang tráo đổi) và sau đó phân tích tương ứng và hành động tương ứng. Giải pháp có thể là đuổi một số tệp lớn vào cuối ngày bằng vtouch; nó cũng có thể là để thêm nhiều ram hơn bởi vì việc sử dụng máy chủ tối đa hàng ngày chỉ là như vậy.

Tôi đã thấy drop cache rất hữu ích khi khởi động một loạt các máy ảo. Hoặc bất cứ điều gì khác sử dụng Trang lớn như một số máy chủ cơ sở dữ liệu.

Các trang lớn trong Linux thường cần phân mảnh RAM để tìm 2 MB RAM vật lý liền kề để đưa vào một trang. Giải phóng tất cả các bộ đệm tập tin làm cho quá trình này rất dễ dàng.

Nhưng tôi đồng ý với hầu hết các câu trả lời khác ở chỗ không có lý do chính đáng để bỏ bộ đệm ẩn tệp mỗi đêm.

Có thể đây được coi là một cách để ổn định hệ thống khi không có ai có kỹ năng hoặc kinh nghiệm để thực sự tìm ra vấn đề.

Giải phóng tài nguyên

Việc xóa bộ nhớ cache về cơ bản sẽ giải phóng một số tài nguyên, nhưng điều này có tác dụng phụ là làm cho hệ thống thực sự làm việc chăm chỉ hơn để làm những gì nó đang cố gắng làm. Nếu hệ thống bị tráo đổi (cố gắng đọc và ghi từ phân vùng trao đổi đĩa nhanh hơn khả năng thực sự) thì việc thả bộ nhớ cache định kỳ có thể làm giảm triệu chứng , nhưng không có gì để chữa nguyên nhân .

Ăn gì lên bộ nhớ?

Bạn nên xác định những gì gây ra nhiều tiêu thụ bộ nhớ khiến cho việc lưu trữ bộ đệm dường như hoạt động. Điều này có thể được gây ra bởi bất kỳ số lượng quá trình máy chủ được cấu hình kém hoặc chỉ sử dụng sai quy trình. Chẳng hạn, trên một máy chủ, tôi đã chứng kiến ​​việc sử dụng bộ nhớ tối đa khi một trang web Magento đạt được số lượng khách truy cập nhất định trong khoảng thời gian 15 phút. Điều này cuối cùng được gây ra bởi Apache được cấu hình để cho phép quá nhiều quá trình chạy cùng một lúc. Quá nhiều quá trình, sử dụng nhiều bộ nhớ (đôi khi Magento là một con thú) = hoán đổi.

Dòng dưới cùng

Đừng chỉ cho rằng đó là điều cần thiết. Hãy chủ động tìm hiểu lý do tại sao nó ở đó, có can đảm để vô hiệu hóa nó nếu người khác cho rằng nó sai và quan sát hệ thống - tìm hiểu vấn đề thực sự là gì và khắc phục nó.

Linux / m68k thực sự có lỗi kernel khiến kswapd phát điên và ăn hết 100% CPU (50% nếu có một số tác vụ gắn với CPU khác, như gói tự động gói nhị phân Debian - Vulgo buildd - đã chạy), có thể (hầu hết về thời gian; không phải lúc nào cũng được giảm nhẹ bằng cách chạy lệnh đặc biệt này cứ sau vài giờ.

Điều đó có nghĩa là máy chủ của bạn rất có thể không phải là hệ thống m68k (Atari, Amiga, Classic Macintosh, VME, Q40 / Q60, Sun3) ;-)

Trong trường hợp này, người đặt các dòng theo một số câu hỏi nghi vấn hoặc, tốt nhất, đã hết lời, hoặc có ý tưởng về cách sử dụng RAM sai (suy nghĩ hiện đại thực sự nói rằng RAM miễn phí RAM bị lãng phí RAM và gợi ý bộ nhớ đệm) , hoặc đã phát hiện ra rằng, điều này đã khắc phục lỗi này [sic!] một vấn đề khác ở nơi khác (và quá lười biếng để tìm kiếm một bản sửa lỗi thích hợp).

Một lý do có thể là trang web đang chạy một số loại giám sát, đó là kiểm tra lượng ram miễn phí và gửi cảnh báo cho quản trị viên khi ram miễn phí giảm xuống dưới một tỷ lệ nhất định. Nếu công cụ giám sát đó đủ ngu ngốc để không bao gồm bộ đệm trong tính toán ram miễn phí, nó có thể gửi cảnh báo sai; thường xuyên làm trống bộ nhớ cache có thể ngăn chặn các cảnh báo này trong khi vẫn cho phép công cụ nhận thấy khi ram "thực" xuống thấp.

Tất nhiên, trong tình huống này, giải pháp thực sự là sửa đổi công cụ giám sát để đưa bộ đệm vào tính toán ram miễn phí; làm sạch bộ đệm chỉ là một cách giải quyết và cũng là một điều xấu, bởi vì bộ đệm sẽ nhanh chóng nạp lại khi các tiến trình truy cập vào đĩa.

Vì vậy, ngay cả khi giả định của tôi là đúng, việc dọn dẹp bộ đệm không phải là điều có ý nghĩa, đó là cách giải quyết của một người không đủ năng lực để khắc phục vấn đề chính.

Tôi có thể nghĩ ra một lý do chính đáng để làm việc này trong một công việc định kỳ hàng đêm.

Trên một hệ thống lớn, có thể hữu ích khi định kỳ thả bộ đệm để bạn có thể loại bỏ phân mảnh bộ nhớ.

Hỗ trợ hugepage trong suốt kernel thực hiện quét bộ nhớ định kỳ để kết hợp các trang nhỏ thành các trang web. Trong điều kiện suy biến, điều này có thể dẫn đến tạm dừng hệ thống trong một hoặc hai phút (trải nghiệm của tôi với điều này là ở RHEL6; hy vọng nó được cải thiện). Việc lưu trữ bộ đệm có thể cho phép trình quét hugepage có chỗ để làm việc.

Bạn có thể lập luận rằng đây là một lý do chính đáng để vô hiệu hóa các vòng đệm trong suốt; OTOH bạn có thể tin rằng cải thiện hiệu suất tổng thể từ các vòng đệm trong suốt là đáng để có và đáng để trả giá khi mất bộ nhớ cache mỗi ngày một lần.

Tôi đã nghĩ đến một lý do khác mà bạn muốn làm điều đó, mặc dù không phải trong một công việc định kỳ. Ngay trước khi một hệ thống ảo hóa chuyển VM sang phần cứng mới sẽ là thời điểm rất tốt cho việc này. Nội dung bộ nhớ ít hơn để sao chép vào máy chủ mới. Cuối cùng, bạn sẽ phải đọc từ bộ lưu trữ, thay vào đó, tất nhiên, nhưng tôi có thể lấy sự đánh đổi đó.

Tôi không biết nếu có bất kỳ phần mềm virt nào thực sự làm điều này.

Chỉ cần thêm hai xu của tôi: Hệ thống biết rất rõ rằng các trang bộ nhớ này là bộ nhớ cache và sẽ giảm nhiều nhất có thể khi một ứng dụng yêu cầu bộ nhớ.

Một cài đặt có liên quan là /proc/sys/vm/swappiness, thông báo cho hạt nhân trong quá trình cấp phát bộ nhớ mới để giảm bộ nhớ đệm hoặc hoán đổi các trang bộ nhớ được phân bổ "nhàn rỗi".

Câu hỏi là từ năm 2014, nhưng vì vấn đề tồn tại cho đến ngày nay trên một số phụ kiện ẩn 6,8 centos, nó vẫn có thể hữu ích cho ai đó.

https://github.com/zfsonlinux/zfs/issues/1548 mô tả sự cố với zfs. Ở đó, không gian đĩa không được giải phóng cho các tệp đã bị xóa bởi vì nếu nfs được sử dụng trên đầu zfs thì các nút của tệp không bị rơi khỏi bộ đệm inode của kernel.

Để trích dẫn từ chủ đề lỗi, Behlendorf, ngày 6 tháng 1 năm 2015 đã viết:

Suy đoán hiện tại là vì một số lý do, máy chủ NFS đang giữ một phiên bản lưu trữ của bộ xử lý tệp. Cho đến khi máy chủ NFS loại bỏ tệp này, ZFS không thể hủy liên kết tệp này. Một số thử nghiệm ánh sáng đã chỉ ra rằng việc thả bộ nhớ cache trên máy chủ sẽ khiến tham chiếu này bị hủy (như xử lý tệp NFS) tại đó không gian được giải phóng chính xác. Áp lực bộ nhớ cũng có thể làm cho nó bị giảm.

tức là tiếng vang hàng đêm 3> / Proc / sys / vm / drop_caches là cách khắc phục dễ dàng nhất cho lỗi đó nếu bạn không muốn có thời gian chết để tái cấu trúc zfs của mình.

Vì vậy, có thể không quản trị sùng bái hàng hóa, nhưng một số gỡ lỗi khá tốt là lý do.

Điều này có thể có ý nghĩa trên các hệ thống NUMA (truy cập bộ nhớ không đồng nhất), trong đó, thông thường, mỗi CPU (ổ cắm) có thể truy cập tất cả bộ nhớ trong suốt nhưng bộ nhớ của chính nó có thể được truy cập nhanh hơn bộ nhớ của ổ cắm khác, kết hợp với các ứng dụng HPC song song.

Nhiều ứng dụng song song đơn giản có xu hướng thực hiện I / O tệp từ một quy trình duy nhất, do đó thoát khỏi một phần lớn bộ nhớ trên một nút NUMA duy nhất được phân bổ cho bộ đệm đĩa, trong khi trên nút NUMA khác, bộ nhớ có thể hầu hết là miễn phí. Trong các tình huống này, do quá trình lấy lại bộ đệm trong nhân Linux, theo như tôi biết, vẫn không nhận biết được NUMA, các quy trình chạy trên nút NUMA có bộ nhớ được cấp phát cho bộ nhớ cache buộc phải phân bổ bộ nhớ trên nút NUMA khác, miễn là có RAM miễn phí trên nút khác, do đó giết chết các màn trình diễn.

Tuy nhiên, trong một hệ thống HPC, sẽ tốt hơn nếu làm sạch bộ đệm trước khi bắt đầu một công việc người dùng mới, không phải vào một thời điểm cụ thể với cron.

Đối với các ứng dụng không song song, vấn đề này khó có thể phát sinh.

Khi bộ đệm trang của bạn khá lớn (lớn hơn rất nhiều so với mức sử dụng trao đổi hiện tại của bạn) và việc hoán đổi và trao đổi xảy ra lần lượt, đây là lúc bạn cần bỏ bộ đệm. Tôi đã thấy các trường hợp sử dụng bộ nhớ tăng lên ở một trong các máy chủ cơ sở dữ liệu MariaDB của tôi chạy Ubuntu 16.04LTS và Linux chỉ chọn tăng sử dụng trao đổi thay vì xóa bộ đệm trang không sử dụng. Những cái ôm trong suốt đã bị vô hiệu hóa trong hệ thống của tôi vì TokuDB yêu cầu nó phải bị vô hiệu hóa. Dù sao, có thể đó không phải là một lỗi, nhưng linux vẫn thực hiện hành vi này khá khó hiểu với tôi. Nhiều nguồn khác nhau tuyên bố rằng Linux sẽ xóa bộ đệm trang khi ứng dụng yêu cầu:

• https://www.linuxHRyram.com/
• https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics

Nhưng thực tế không đơn giản. Cách giải quyết là:

1. Thực hiện thả bộ nhớ cache định kỳ
2. Thực thi thả bộ đệm khi cần thiết (màn hình sử dụng vmstat 1 để hoán đổi các hoạt động)
3. Khuyên linux nên xóa một số tệp khỏi bộ đệm (như tệp nhật ký apache) bằng tiện ích như dd hoặc python-fadvise. Xem https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache

Ví dụ dd chạy:

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

Ví dụ python-fadvise:

pyadvise -d /var/log/apache2/access_log.1

Tôi có một máy tính để bàn với 16GB RAM chạy trên kernel PAE. Sau một hoặc hai giờ, hiệu suất đĩa giảm đáng kể cho đến khi tôi bỏ bộ đệm, vì vậy tôi chỉ cần đặt nó vào cron. Tôi không biết liệu đây có phải là sự cố với hạt nhân PAE hay việc triển khai bộ đệm quá chậm nếu có nhiều bộ nhớ.