Có thể làm cho kẻ giết người OOM can thiệp sớm hơn?


34

Tôi cố gắng điều chỉnh hệ thống phát triển của mình để có độ tin cậy tối đa. Tôi đã vô hiệu hóa trao đổi, vì để sử dụng GUI, nó chủ yếu làm cho máy không phản hồi theo cách không thể sử dụng được nữa. Tuy nhiên, nếu các ứng dụng gây khó chịu ăn hết bộ nhớ, một số cơ chế dường như phát huy tác dụng trong việc tận dụng tối đa nó với chi phí tốc độ. Không có hoạt động trao đổi ổ cứng, nhưng hệ thống cũng không phản hồi. Vì vậy, tôi muốn để kẻ giết người OOM khởi động trước khi hệ thống thực hiện bất kỳ nỗ lực đặc biệt nào về việc tăng trí nhớ. Có thể định cấu hình trình diệt OOM để hành động nếu có ít hơn 100 MB bộ nhớ vật lý miễn phí không?


2
Tôi nghĩ vấn đề thực sự ở đây là, không có đủ ram để bắt đầu. Bạn sẽ không sử dụng trao đổi trừ khi không có ram. Bằng cách tắt trao đổi ... bạn hết ram và không có nơi nào để trang nó. Mà gây ra những điều xấu xí xảy ra. Hệ thống của bạn dường như được thiết lập tồi và không có số lượng điều chỉnh nào sẽ khắc phục điều đó.
Journeyman Geek

8
Tôi không đồng ý. Phát triển và "sử dụng năng lượng" thường liên quan đến việc sử dụng thử nghiệm. Ví dụ, khi sử dụng một công cụ xử lý hình ảnh dòng lệnh, không có thông số kỹ thuật mà hoạt động của nó chiếm bao nhiêu bộ nhớ so với kích thước hình ảnh. Vì vậy, tôi chỉ cho nó một chạy. Và tôi không hy vọng nó sẽ khiến toàn bộ máy của tôi trở nên vô dụng. Đối với một thử nghiệm duy nhất, tôi có thể sử dụng ulimit để giữ an toàn cho nó, nhưng đối với toàn bộ hoạt động của hệ thống đôi khi có nhiều hoạt động, việc ngăn chặn một quy trình không quá hữu ích mà là "bảo hiểm nhân thọ" cho toàn bộ máy chắc chắn là.
dronus

1
Thực tế là hệ thống của bạn dừng lại khi sử dụng trao đổi là nghi ngờ. Máy tính của bạn đang sử dụng trao đổi khiến nó hết bộ nhớ. Hoán đổi đang chậm lại vì truy cập đĩa chậm. Truy cập đĩa bị chậm do ???. Vấn đề của nó tất cả các cách xuống. Nó không chỉ là bạn thấp về ram. Đó là bạn không thể sử dụng một cách để giảm nhẹ điều đó do một thứ khác.
Journeyman Geek

7
@JTHERmanGeek, bạn đang ở trong trường bên trái. Đĩa chậm so với ram, thời gian, do đó trao đổi nặng luôn làm hệ thống dừng lại. Tất nhiên anh ấy đã hết bộ nhớ vì anh ấy đã thử chạy một chương trình sử dụng nhiều bộ nhớ. Câu hỏi là làm gì khi hết bộ nhớ? Giết con lợn hoặc làm chậm do không còn bộ nhớ cho bộ đệm đĩa.
psusi

2
@TomWijsman, Disk IO chậm hơn nhiều so với IO bộ nhớ, vì vậy sử dụng trao đổi đĩa luôn có nghĩa là làm chậm rất nhiều. Đôi khi (đặc biệt là vào thời xưa, nơi ram đắt tiền và vì vậy hầu hết mọi người không có nhiều) điều đó tốt hơn là không thể làm những gì bạn đang cố gắng. Những ngày này các đĩa là SO chậm hơn nhiều so với ram và ram là đủ rẻ tiền mà hầu hết mọi người có rất nhiều, vì vậy nhân dịp hiếm hoi mà họ vô tình chạy cái gì mà sử dụng nhiều ram hơn những gì họ có, nó thường tốt hơn là từ bỏ hơn mất 1000 thời gian để làm điều đó
psusi

Câu trả lời:


36

Tôi cũng vật lộn với vấn đề đó. Tôi chỉ muốn hệ thống của mình luôn phản hồi, bất kể điều gì và tôi thích mất các quy trình hơn để chờ đợi một vài phút. Dường như không có cách nào để đạt được điều này bằng cách sử dụng kernel killer oom.

Tuy nhiên, trong không gian người dùng, chúng tôi có thể làm bất cứ điều gì chúng tôi muốn. Vì vậy, tôi đã viết Daemon OOM sớm ( https://github.com/rfjakob/earlyoom ) sẽ giết quá trình lớn nhất (bằng RSS) khi RAM khả dụng xuống dưới 10%.

Nếu không có máy chiếu sớm, thật dễ dàng để khóa máy của tôi (RAM 8GB) bằng cách bắt đầu http://www.unrealengine.com/html5/ một vài lần. Bây giờ, các tab trình duyệt có tội bị giết trước khi mọi thứ vượt quá tầm tay.


3
Cảm ơn đã gãi ngứa này! Yêu sớm cho đến nay.
Thomas Ferris Nicolaisen

1
Chỉ cần tìm ra Android làm điều tương tự trong một thời gian dài. Tôi không chắc chắn nếu nó đang sử dụng mã tùy chỉnh như của bạn cho điều đó.
dronus

1
Tôi đang thử nghiệm earlyoom, nó hoạt động tốt trong thử nghiệm kích hoạt đầu tiên. Tôi chỉ tự hỏi tại sao điều này không thể được thực hiện bởi cấu hình kernel hoặc các công cụ hệ thống.
dronus

12

Chính sách mặc định của kernel là cho phép các ứng dụng tiếp tục phân bổ bộ nhớ ảo miễn là có bộ nhớ vật lý miễn phí. Bộ nhớ vật lý thực sự không được sử dụng cho đến khi các ứng dụng chạm vào bộ nhớ ảo mà chúng phân bổ, do đó, một ứng dụng có thể phân bổ bộ nhớ nhiều hơn hệ thống, sau đó bắt đầu chạm vào nó sau đó, khiến kernel hết bộ nhớ và kích hoạt hết bộ nhớ của bộ nhớ (OOM) kẻ giết người. Trước khi quá trình ăn cắp bị giết, nó đã khiến bộ đệm đĩa bị xóa, điều này làm cho hệ thống chậm phản hồi trong một thời gian cho đến khi bộ đệm được nạp lại.

Bạn có thể thay đổi chính sách mặc định để không cho phép bộ nhớ quá mức bằng cách viết giá trị từ 2 đến /proc/sys/vm/overcommit_memory. Giá trị mặc định /proc/sys/vm/overcommit_ratiolà 50, vì vậy kernel sẽ không cho phép các ứng dụng phân bổ hơn 50% ram + trao đổi. Nếu bạn không có trao đổi, thì kernel sẽ không cho phép các ứng dụng phân bổ hơn 50% ram của bạn, để lại 50% miễn phí khác cho bộ đệm. Điều đó có thể hơi quá, vì vậy bạn có thể muốn tăng giá trị này để nói, 85% hoặc hơn, vì vậy các ứng dụng có thể phân bổ tới 85% ram của bạn, để lại 15% cho bộ đệm.


1
Thay đổi các giá trị này từ đó mặc định mà không có nền tảng lý thuyết sẽ không đạt được trong một hệ thống đáng tin cậy hơn, bạn chỉ có thể biện minh cho sự thay đổi đó bằng các số liệu thống kê phù hợp. Chỉ vì bạn có thể thay đổi nó không có nghĩa là bạn nên. Nếu bạn liên tục trong điều kiện bộ nhớ thấp, điều đó có nghĩa là bạn đang sử dụng nhiều bộ nhớ hơn mức bạn có và nên mua thêm bộ nhớ, điều đó không có nghĩa là bạn nên sử dụng các thiết lập của mình và giết các ứng dụng ngẫu nhiên. Làm gián đoạn công việc hàng ngày của bạn hoặc giới thiệu tham nhũng, đó thực sự không phải là cách để đi ...
Tamara Wijsman

3
@TomWijsman, câu hỏi cho thấy rõ rằng anh ta không liên tục trong điều kiện bộ nhớ thấp; đôi khi anh ta chỉ chạy một lệnh chiếm một lượng lớn bộ nhớ bất ngờ. Mua thêm bộ nhớ không phải là giải pháp duy nhất khi bạn hết tiền. Các giải pháp tiềm năng khác bao gồm tìm ra những cách tốt hơn để sử dụng bộ nhớ bạn có hoặc không làm bất cứ điều gì cần nhiều bộ nhớ đó. Câu hỏi làm rõ rằng cái sau dễ chấp nhận hơn là đi ra ngoài và mua nhiều ram hơn.
psusi

Dòng nào trong câu hỏi làm cho điều này rõ ràng? Tôi thấy điều ngược lại được đưa ra I disabled swap, because for GUI usage it mostly renders the machine unresponsive in such a way not useable anymore.. Anh ta đề cập đến GUI, trong khi bạn cho rằng anh ta chạy một lệnh. Mua thêm bộ nhớ là giải pháp đầu tiên, sử dụng ít bộ nhớ hơn là giải pháp thứ hai, làm cho hệ thống của bạn không ổn định bằng cách thay đổi mặc định ổn định là giải pháp cuối cùng. Câu hỏi không cần phải trả lời theo nghĩa đen, vì vậy tôi không thấy vấn đề của bạn là gì mà bạn phải làm phiền cả hai chúng tôi trong các bình luận. Rant không giúp ...
Tamara Wijsman

4
Này, câu trả lời này nghe khá tuyệt. Thật không may, 'cam kết' đề cập đến nhu cầu bộ nhớ ảo dường như khá tệ đối với các lập trình viên ứng dụng. Ví dụ với tôi (không swap) máy tính để bàn chạy, có khoảng 400 2000MB bộ nhớ vật lý được sử dụng, nhưng 1600mb 'commit'ted như /proc/meminfo' s Committed_AStiểu bang. Với một số ứng dụng đang chạy, giá trị này dễ dàng vượt quá bộ nhớ vật lý nên khó có thể đặt giới hạn khả thi bằng cách này.
dronus

3
Lưu công việc của bạn trước khi thử điều này! : PI đã thất bại ngay lập tức từ mọi thứ (bash, trình quản lý cửa sổ, v.v.).
jozxyqk

8

Đối với tôi, cài đặt vm.admin_reserve_kbytes = 262144 thực hiện chính xác điều này. Kẻ giết người OOM can thiệp trước khi hệ thống hoàn toàn không phản hồi.


1
Tôi thích ý tưởng, nhưng nó có nghĩa là bạn có 256MiB bộ nhớ vật lý không bao giờ được sử dụng?
Jérôme Pouiller

1
256MiB sẽ được sử dụng cho bộ nhớ cache. Bộ nhớ cache thực sự quan trọng, nó không chỉ chạy nhanh hơn, hệ thống sẽ không hoạt động nếu không có đủ bộ nhớ cho bộ nhớ cache. Mã của mọi chương trình đang chạy có thể được tải khỏi bộ nhớ vì nó bị khóa và có thể được đọc lại từ đĩa. Không có bộ nhớ cache, mọi chuyển đổi tác vụ sẽ yêu cầu đọc đĩa và hệ thống sẽ hoàn toàn không phản hồi.
Michael Vigovsky

4

Các câu trả lời khác có giải pháp tự động tốt, nhưng tôi thấy nó cũng hữu ích khi cũng bật SysRqchìa khóa khi mọi thứ vượt quá tầm tay. Với SysRqkhóa, bạn sẽ nhắn tin cho kernel một cách thủ công và bạn có thể thực hiện những việc như khởi động lại an toàn (với SysRQ + REISUB) ngay cả khi không gian người dùng đã hoàn toàn đóng băng.

Để cho phép kernel nghe yêu cầu, thiết lập kernel.sysrq = 1hoặc chỉ kích hoạt các chức năng bạn có thể sử dụng với bitmask (tài liệu ở đây ). Ví dụ, kernel.sysrq = 244sẽ cho phép tất cả các combo cần thiết để khởi động lại an toàn ở trên cũng như gọi thủ công của kẻ giết người OOM với SysRq + F.


-2

Độ tin cậy không đạt được bởi các điều kiện bộ nhớ thấp và một kẻ giết người OOM.

Thật sai lầm khi tổ chức một bữa tiệc trong tủ quần áo và đặt "dọn dẹp tủ quần áo của tôi" trong danh sách nhạc nhỏ của bạn.

Có thể làm cho kẻ giết người OOM can thiệp sớm hơn?

Làm điều này sẽ có kết quả phụ ngoài ý muốn, bởi vì bạn không kiểm soát được những gì bị giết.

Tôi cố gắng điều chỉnh hệ thống phát triển của mình để có độ tin cậy tối đa.

Độ tin cậy tối đa liên quan đến việc kiểm tra hệ thống của bạn và cải thiện hệ thống của bạn dựa trên các thử nghiệm này.

Chỉ cần điều chỉnh những thứ ngẫu nhiên sẽ không đưa bạn đến bất cứ đâu ...

Tôi đã vô hiệu hóa trao đổi, vì để sử dụng GUI, nó chủ yếu làm cho máy không phản hồi theo cách không thể sử dụng được nữa. Tuy nhiên, nếu các ứng dụng gây khó chịu ăn hết bộ nhớ, một số cơ chế dường như phát huy tác dụng trong việc tận dụng tối đa nó với chi phí tốc độ.

Do điều kiện bộ nhớ thấp, việc vô hiệu hóa trao đổi sẽ không cải thiện hành vi , nó ngược lại .

Để tăng độ tin cậy trong tình huống này, hãy thêm nhiều bộ nhớ để hệ thống của bạn phản ứng nhanh hơn và không có quá trình ngẫu nhiên nào bị giết mà không có ý định của người dùng. Bạn không nên dùng đến điều kiện bộ nhớ thấp và một cơ chế như thế này, đặc biệt là không phải trong môi trường phát triển ...

Không có hoạt động trao đổi ổ cứng, nhưng hệ thống cũng không phản hồi.

Điều kiện bộ nhớ thấp thực sự dẫn đến sự không đáp ứng, cho dù bạn có trao đổi hay không.

Vì vậy, tôi muốn để kẻ giết người OOM khởi động trước khi hệ thống thực hiện bất kỳ nỗ lực đặc biệt nào về việc tăng trí nhớ.

Những nỗ lực đặc biệt sẽ gây hại nhiều hơn lợi, như tôi đã giải thích ở trên. Thay vào đó, bạn có thể giết các quá trình bạn không cần chính mình, nhưng tôi đoán bạn không thể làm điều đó để OOM sẽ giết các quy trình mà bạn cần.

Có thể định cấu hình trình diệt OOM để hành động nếu có ít hơn 100 MB bộ nhớ vật lý miễn phí không?

Có thể, nhưng bạn có được lợi tức đầu tư cao hơn nếu bạn chỉ mua một số bộ nhớ bổ sung mà thực sự không tốn nhiều tiền trong những ngày này. Hãy xem xét rằng bạn sẽ tự đánh vào chân mình trong thời gian dài nếu bạn tiếp tục làm việc trong điều kiện bộ nhớ thấp. OOM giống như một người bảo lãnh, nó không hỗ trợ bạn, nó hỗ trợ HĐH ...


7
Tất nhiên việc vô hiệu hóa trao đổi sẽ cải thiện hành vi vì thay vì đập đĩa, OOM sẽ kích hoạt và giết chết bộ nhớ. Hết ram không phải là vấn đề (và thêm nhiều hơn chỉ có nghĩa là bạn phải cố gắng nhiều hơn để hết). Vấn đề là phải làm gì khi bạn hết. Bạn muốn OOM giết lợn, và do đó làm giảm tình trạng bộ nhớ thấp.
psusi

7
Bởi vì việc giết một ứng dụng đang cố gắng sử dụng nhiều bộ nhớ hơn bạn có, tốt hơn là đưa toàn bộ hệ thống đến đầu gối của nó. Trong một thế giới hoàn hảo, bạn sẽ có bộ nhớ không giới hạn và không bao giờ cạn kiệt, nhưng trong thực tế, đôi khi bạn hết tình cờ và thà bị nói là "không đủ bộ nhớ" hơn là khiến hệ thống bị đình trệ.
psusi

5
Mua thêm một số bộ nhớ có thể giải quyết một số vấn đề, tùy thuộc vào số lượng mua. Nhưng nó không thay đổi thực tế rằng có thể có những công dụng bất ngờ bởi những mệnh lệnh lớn. Vì vậy, tôi muốn ứng dụng bị lỗi, nhưng KHÔNG phải hệ thống theo các điều kiện đó. Một số ví dụ: Xử lý một thư mục chứa đầy ảnh nén, hầu hết có kích thước "bình thường", nhưng một số trong số chúng thực sự lớn. Một lỗi nhỏ có thể khiến vòng lặp chết với bộ nhớ chạy mất 1GB / s. Vô tình mở một tập tin video trong một trình soạn thảo văn bản. Thông thường, điều này kết thúc với các triệu chứng như chuột giật và giao diện người dùng gần như đã chết cho đến khi
OOM

6
@TomWijsman cũng có những vòng lặp gần như đã chết vì có những thuật toán hoạt động tuyến tính trong trường hợp trung bình nhưng theo cấp số nhân trong trường hợp xấu nhất, tùy thuộc vào dữ liệu đầu vào. Và tôi không thể gửi tín hiệu tiêu diệt nếu chuột bị giật và nhấp cũng như nhập bàn phím cho thấy độ trễ một phút. Tôi thường thay đổi sang một thiết bị đầu cuối chế độ văn bản sau đó và đợi vài phút để đăng nhập được tiến hành chỉ để đưa ra một killcách gõ mù.
dronus

7
Tôi không có vấn đề gì với việc giết các ứng dụng cũng sẽ chết. Hãy xem xét một hệ thống với 2GB vật lý + 2GB trao đổi. Một ứng dụng nhanh chóng hết bộ nhớ vật lý cũng có thể dễ dàng ăn trao đổi. Nó sẽ chết sau đó, sau khi khiến hệ thống không phản hồi trong vài phút đến vài giờ. Vậy tại sao không giết nó một cách nhanh chóng trước khi thao tác GUI bị lỗi? Nhiều quy trình thực hiện tất cả công việc của họ với 10mb, một số mất 1gb và một số hiếm sẽ cần 10gb, đó là cuộc sống.
dronus
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.