Tôi có một dịch vụ web điều khiển PostgreSQL trên hai máy chủ Debian, một máy chủ vhost chạy Linux kernel 3.2.0-2 với RAM 2GB và máy chủ chuyên dụng khác chạy Linux kernel 2.6.26-1 với RAM 6 GB. Mặc dù ứng dụng có dung lượng bộ nhớ rất nhỏ, nhưng theo thời gian, bộ đệm sẽ lấp đầy đến một mức nhất định mà các quá trình bị tráo đổi làm tăng tải của hệ thống, cuối cùng hết bộ nhớ và cuối cùng bị sập kernel (chỉ hoạt động tương tự trên cả hai hệ thống khoảng thời gian khác nhau). Trước khi gặp sự cố, free -mbáo cáo một cái gì đó tương tự với:
$ free -m
total used free shared buffers cached
Mem: 1978 1583 394 0 147 1208
-/+ buffers/cache: 227 1751
Nếu tôi khởi động lại hệ thống, nó sẽ chạy trơn tru trong một thời gian (thường là vài tuần hoặc vài tháng, nhưng đôi khi chỉ vài ngày) cho đến khi bộ nhớ cache được lấp đầy trở lại. Sau khi khởi động lại, free -mbáo cáo:
$ free -m
total used free shared buffers cached
Mem: 1978 452 1526 0 6 302
-/+ buffers/cache: 143 1835
Tôi có thể chấp nhận được nếu máy chủ chậm một phần do I / O của đĩa nếu có các đỉnh do sử dụng quá mức, nhưng không thể chấp nhận được rằng hệ thống gặp sự cố sau đó và khi bộ nhớ cache của đĩa không được phục hồi để xử lý nếu chúng tạm thời cần thêm bộ nhớ.
Vì vậy, trên một máy chủ, tôi đã vô hiệu hóa việc hoán đổi (vì với việc hoán đổi tải lên tới 300 - 400 (theo kiểu phản ứng dây chuyền nếu các tiến trình bị giết) khiến hệ thống không thể sử dụng được ngay cả khi đăng nhập từ xa để bắt đầu khởi động lại. Tôi đã thiết lập tham số điều chỉnh kernel vm.swappiness=0và vm.overcommit_memory=2như được khuyến nghị trong hướng dẫn Điều chỉnh hiệu suất cao PostgreSQL để buộc kernel lấy lại bộ nhớ từ bộ đệm và tránh quá mức cam kết.
Nhưng điều này dường như không có hiệu ứng mong muốn - đầu ra ở trên freekhông hiển thị bộ đệm bị thu hẹp trong khi các chương trình lại bắt đầu gặp sự cố với no memory availablethông báo lỗi (đầu ra ở trên freeđược tạo ra chỉ vài giây sau khi các no memory availablethông báo đầu tiên xuất hiện trong syslog sau khoảng Hai tháng hoạt động trơn tru).
Có bất kỳ cơ hội nào để tránh bộ nhớ đệm quá mức này để có thể sử dụng bộ nhớ cho các ứng dụng thay vì cho I / O đĩa không?
Việc tăng bộ nhớ vật lý không giúp ích gì vì trên hệ thống được trang bị 6GB, tôi sớm nhận được kết quả tương tự khi có nhiều khách hàng kết nối với dịch vụ (đó là máy chủ xác thực hotspot để sử dụng công cộng miễn phí với số lượng người dùng không xác định và tôi cần phải sử dụng với hai máy chủ một thời gian vì nhiều lý do). Trên vhost, lần đầu tiên tôi sử dụng 1GB, bây giờ là 2GB - là giới hạn cho vhost của tôi - và tất cả những gì tôi nhận được cho đến nay là tăng dung lượng bộ nhớ cache, nhưng không phải trong bộ nhớ cho các quy trình. Đây có phải là cách nó được cho là hoạt động trên Linux? Chỉ cần 12% bộ nhớ cho các quy trình? Hoặc những gợi ý trên từ sách HPT không chính xác?
Cảm ơn trước cho bất kỳ gợi ý!
Xin chào Michael, vâng, có vẻ như vậy. Tôi cũng nghĩ rằng bộ nhớ cache kernel nên được giải phóng nếu các ứng dụng userland cần thêm bộ nhớ. Nhưng nhìn vào kết quả này từ free(1)tôi đã lưu ý khi hệ thống trở nên không phản hồi trở lại, đó là một dấu hiệu cho thấy tình huống dẫn đến kẻ giết người OOM bị đá sớm hay muộn:
total used free shared buffers cached
Mem: 1978 981 997 0 142 638
-/+ buffers/cache: 200 1777
Swap: 0 0 0
Tôi có thể thấy việc free Memgiảm xuống 0 trong khi -/+ buffers/cachevẫn hiển thị một số giá trị cao trước khi các hệ thống cuối cùng gặp sự cố. Tôi ngay lập tức xóa bộ nhớ cache bằng cách syncing và viết 3 để /proc/sys/vm/drop_cacheskết quả là giải phóng bộ nhớ kernel:
total used free shared buffers cached
Mem: 1978 481 1496 0 1 283
-/+ buffers/cache: 196 1782
Swap: 0 0 0
Vì vậy, như một công việc xung quanh tôi thỉnh thoảng xóa bộ nhớ cache. Thật không may, tôi không thể chỉ cập nhật HĐH trên hệ thống sản xuất mà phải thay đổi hệ thống trước khi cập nhật để đảm bảo 99% khả dụng. Kiểm tra hạt nhân trên hệ thống dàn của chúng tôi là có thể, nhưng vô ích vì tình huống được mô tả sẽ chỉ xuất hiện sau một thời gian nhất định trên hệ thống sản xuất của chúng tôi phục vụ hàng chục ngàn yêu cầu đăng nhập mỗi ngày.
BTW, đây là đầu ra của free -mngày hôm nay:
total used free shared buffers cached
Mem: 1978 1107 871 0 146 753
-/+ buffers/cache: 207 1771
Swap: 0 0 0
Nếu tôi hiểu chính xác, các ứng dụng và kernel sử dụng khoảng 190 đến 227 MB, trong khi bộ đệm và bộ đệm sẽ tiêu thụ phần còn lại của bộ nhớ. Tôi chắc chắn rằng vấn đề không liên quan đến một số ứng dụng vì không có gì thay đổi nếu tôi khởi động lại ứng dụng, nhưng nó giúp xóa bộ nhớ cache theo cách thủ công.