Tại sao kswapd0 chạy trên máy tính không có trao đổi?

Tôi có một máy chủ đám mây với ~ 14G RAM và không trao đổi. Tuy nhiên, tôi thỉnh thoảng thấy kswapd0 chiếm một số CPU khi tôi chạy top. Tại sao kswapd0 sẽ chạy hoàn toàn nếu không có không gian hoán đổi cho nó để quản lý?

Nó vẫn có một quy trình để kiểm tra nếu có bất kỳ trao đổi. Để giảm nó, bạn sẽ cần phải thiết lập của bạn swappiness -

chỉnh sửa "/etc/sysctl.conf" làm gốc, sau đó thay đổi (hoặc thêm)

vm.swappiness = 0

Không gian hoán đổi chỉ được sử dụng cho dữ liệu không được hỗ trợ bởi bất kỳ tệp nào khác. Dữ liệu được ánh xạ từ các tệp khác trên đĩa (như chương trình thực thi) vẫn được hoán đổi thành các tệp tương ứng ngay cả khi bạn không có thiết bị trao đổi.

Một vấn đề nổi tiếng là khi Linux hết bộ nhớ, nó có thể vào các vòng trao đổi thay vì làm những gì cần làm, giết chết các tiến trình để giải phóng ram. Có một kẻ giết người OOM (Hết bộ nhớ) thực hiện việc này nhưng chỉ khi Hoán đổi và RAM đầy.

Tuy nhiên điều này không thực sự là một vấn đề. Nếu có một loạt các quy trình vi phạm, ví dụ như Firefox và Chrome, mỗi quy trình đều có các tab vừa sử dụng và lấy bộ nhớ, thì các quy trình này sẽ khiến trao đổi đọc lại. Linux sau đó đi vào một vòng lặp trong đó cùng một bộ nhớ đang được di chuyển qua lại giữa bộ nhớ và ổ cứng. Điều này lần lượt gây ra sự đảo ngược ưu tiên trong đó hoán đổi một vài quá trình qua lại làm cho hệ thống không phản hồi.

Nếu bạn vô hiệu hóa trao đổi, bạn sẽ làm cho vấn đề này trở nên tồi tệ hơn vì hiện tại kswapd0 không có tùy chọn nào ngoài việc trao đổi bộ nhớ được ánh xạ, chẳng hạn như các tệp thực thi. Nếu bạn trao đổi các tệp thực thi, nhiều khả năng chúng sẽ được hoán đổi lại một cách nhanh chóng.

Tôi đã thử kích hoạt hành vi này trong NetBSD để thử nghiệm và điều xảy ra là quá trình vi phạm trở nên chậm đáng kinh ngạc trong khi bản thân HĐH rất phản hồi. Có nghĩa là vấn đề hoán đổi xảy ra nhưng không có sự đảo ngược ưu tiên. Tuy nhiên, NetBSD không có trình điều khiển AMDGPU nên tôi vẫn gắn bó với Linux. Có lẽ NetBSD không thực thi bản đồ bộ nhớ và đó là lý do tại sao nó không nhập các vòng lặp hoán đổi nhưng tôi không thực sự biết đủ về việc triển khai để nói lý do tại sao nó không trở nên không phản hồi.

Facebook cũng gặp vấn đề này và tạo ra OOMD, đó là Daemon hết bộ nhớ. Đây là daemon phát hiện hoạt động kswapd0 và bắt đầu giết các quá trình. Và theo Facebook, điều này gần như đã loại bỏ hoàn toàn vấn đề máy chủ Linux trở nên không phản hồi. Tuy nhiên tôi chưa thử nghiệm nó và tôi không biết nó sẽ hoạt động tốt như thế nào trên các máy chủ hoặc máy tính để bàn / máy tính xách tay khác. OOMD hấp dẫn có một số logic quyết định các quy trình cần giết trước để bảo toàn các quy trình hệ thống và một phần của hệ thống máy chủ của chúng chịu trách nhiệm khởi chạy lại bất cứ thứ gì đã bị giết.

Tuy nhiên đây không phải là cách giải quyết. OOMD là một HACK UGLY. Giải pháp thực sự là khắc phục sự đảo ngược ưu tiên mà vòng lặp hoán đổi gây ra cũng như làm cho hạt nhân OOM Killer trở nên hung hăng hơn trong việc tiêu diệt các tiến trình để giải phóng bộ nhớ. Bản sửa lỗi thuộc về kernel vì đó là nơi duy nhất mà chúng ta có thể chắc chắn rằng sự cố được phát hiện kịp thời và các quy trình đang được xử lý đúng cách.

Đặt swappiness = 0 không phải là giải pháp vì khi hệ thống hết RAM miễn phí, nó bắt đầu hoán đổi bất kể là gì. Không có tùy chọn để đảm bảo rằng hệ thống không bắt đầu hoán đổi.

Và cũng sửa các ứng dụng vi phạm không phải là một sửa chữa. Đặc biệt là không nếu người dùng muốn khai thác lỗi này để cố tình làm cho hệ điều hành không phản hồi. Để được đáp ứng là trách nhiệm của hạt nhân. Nếu Firefox không phản hồi thì ứng dụng sẽ khắc phục được ứng dụng. Tuy nhiên, nó không chỉ khiến bản thân không phản hồi mà khiến toàn bộ HĐH trở nên rất chậm và không phản hồi. Đến mức có thể mất nửa giờ để đăng nhập vào SSH. SSH không có gì để làm và nếu nó không chạy được thì đó là một lỗi trong kernel, không phải ở bất kỳ phần nào khác của hệ thống. Và nó không phải là một lỗi mà là hai lỗi. Một lỗi là đảo ngược ưu tiên trong đó chu trình hoán đổi đường ray được phép can thiệp vào các quy trình khác ngoài quy trình vi phạm và bản thân nó là xấu. Lỗi khác là nó không ' Không phát hiện ra rằng nó đang ở trong một vòng lặp trao đổi và gây ra sự hao mòn điên cuồng trên ổ cứng / SSD hoặc bất kỳ bộ lưu trữ nào đang sao lưu trao đổi. Khi hoán đổi thực thi, đây không phải là vấn đề vì chúng chỉ đọc các bản đồ bộ nhớ không được ghi lại vào đĩa nhưng kswapd0 vẫn bị khóa đọc lại những gì nó đồng thời xóa khỏi bộ nhớ.

Oh và có một lỗi thứ ba. Thực tế là không có cách nào để bảo vệ đĩa CACHE khỏi bị ăn khi các ứng dụng đói bộ nhớ nuốt hết bộ nhớ khả dụng. Đây là một trong những lý do mà kswapd0 làm cho hệ thống không phản hồi. Dữ liệu ánh xạ bộ nhớ nóng nhất thường được lưu trữ trong bộ đệm của đĩa nhưng khi firefox ăn bộ đệm đó, rõ ràng điều đó có nghĩa là việc đọc đĩa sẽ phải xảy ra.

Không nhất thiết Firefox gây ra sự cố của bạn nhưng đây là trình duyệt mặc định, không phải Chrome. Và cả hai đều được biết đến rộng rãi để kích hoạt vấn đề này khi họ coi bộ nhớ khả dụng là một thứ gì đó bị lãng phí, bao gồm bộ nhớ cache và bộ nhớ trao đổi trong Linux được coi là "bộ nhớ khả dụng". Vì vậy, để không bị "bộ nhớ khả dụng", hãy sử dụng nó để lưu vào bộ nhớ cache và các nội dung khác. Rõ ràng việc sử dụng SWAP cho DISK CACHE là một IDEA RẤT RẤT NHIỀU nhưng các nghiên cứu sinh ở cả Firefox và Chrome đều phản ứng với điều đó với "bộ nhớ miễn phí là bộ nhớ lãng phí".

Vì vậy, những gì chúng ta có ở đây là ba lỗi kernel mà nhóm kernel dường như không xem xét các lỗi. Và một lỗi trong Firefox, Chrome và tất cả các dẫn xuất mà họ không coi là lỗi. Tôi đã thử xây dựng Firefox trên máy tính xách tay Fedora của mình để xem xét vấn đề này và có thể vá nó. Đoán xem. Xây dựng Firefox với GCC trên CPU 4 lõi với ram 4GB kích hoạt LAPP SWAP với HÓA ĐƠN ƯU TIÊN. Vì vậy, một trong những ứng dụng phải viết lại là GCC. Trên NetBSD, những gì xảy ra chỉ là 4 phiên bản đang chạy của GCC bị chậm hơn so với việc chạy một phiên bản nhưng nó không đóng băng hệ thống.

Vâng, đây là một chút giận dữ nhưng tôi hy vọng rằng nó làm rõ vấn đề hiện tại với các hệ thống con bộ nhớ Linux cũng như các ứng dụng gây ra nó.

Nếu bạn không có trao đổi và kswapd0đang chạy, hệ thống của bạn thực sự đang sử dụng gần như tất cả RAM tại thời điểm đó. Đã đến lúc có các công cụ tốt hơn để giám sát việc sử dụng bộ nhớ (hoặc bộ nhớ trống / có sẵn trong hệ thống).

Cách khắc phục thực sự là giảm mức sử dụng bộ nhớ (chạy các quy trình với ít rò rỉ bộ nhớ hơn, chạy ít quy trình hơn, bỏ qua việc chạy một số quy trình, giới hạn số lượng quy trình con / công nhân của một số phần mềm máy chủ) hoặc để có thêm RAM. Nếu nhu cầu về RAM là do rò rỉ bộ nhớ, bạn có thể chọn sử dụng trao đổi thay thế. Linux nên khá thông minh khi lấy các phần bị rò rỉ để trao đổi đủ thời gian. Có trao đổi là tốt hơn không có gì nhưng đó không phải là một thay thế thực sự để có đủ RAM.