tăng khả năng phản hồi của máy tính để bàn trên linux trong khi hoán đổi


15

Tất cả các bản phân phối GNU / Linux mà tôi đã thử nghiệm cho đến nay có một vấn đề là bất cứ khi nào ram được lấp đầy và hệ thống bắt đầu hoán đổi, toàn bộ giao diện người dùng máy tính để bàn và đồ họa trở nên không phản hồi đến mức đôi khi tôi phải chờ khoảng 5-10 giây sau đã di chuyển chuột vật lý cho đến khi con trỏ chuột thực sự di chuyển.

Đây là một loại hành vi gây phiền nhiễu, đặc biệt là trên các hệ thống có ram thấp.

Có cách nào để cung cấp một số ứng dụng / công việc, như môi trường máy tính để bàn, v.v., ưu tiên cao hơn trong ram so với các ứng dụng khác, để ứng dụng thực sự ăn cắp tất cả bộ nhớ bị tráo đổi trước môi trường máy tính để bàn, v.v.?

EDIT: Tôi đang nói về trường hợp khi toàn bộ RAM được sử dụng để nó luôn bắt đầu hoán đổi nếu nó không bị vô hiệu hóa (tôi không muốn các quá trình bị giết ngẫu nhiên). Tôi gặp vấn đề này không chỉ trong môi trường ram thấp, mà còn với 8GiB ram trên máy tính để bàn của tôi, một phần do nhiều máy ảo một phần do rò rỉ bộ nhớ. ZRAM không phải là một giải pháp vì nó chỉ trì hoãn vấn đề. Giải pháp duy nhất tôi có thể nghĩ đến cho vấn đề này là một số tiện ích không gian người dùng hoặc API kernel cho phép ngăn chặn một số công việc nhất định bị tráo đổi hoặc ít nhất là làm cho nó rất khó xảy ra. Có ai biết giải pháp khác hoặc biết bất cứ điều gì về một công cụ hoặc API như vậy đang tồn tại hoặc đang được lên kế hoạch không?

EDIT thứ 2: ulatencyd dường như không hoạt động với các phiên bản mới hơn của systemd, theo https://aur.archlinux.org/packages/ulatencyd-git/https://wiki.archlinux.org/index.php/Ulatencyd . Điều này có thể là do systemd chiếm toàn quyền kiểm soát các nhóm từ góc độ không gian người dùng nếu tôi hiểu chính xác.


3
các nhóm, nếu bạn đã kích hoạt nhóm bộ nhớ và bật tính năng hoán đổi ( cgroup_enable=memory swapaccount=1trên dòng lệnh kernel; lưu ý rằng điều này có chi phí hiệu năng nhỏ). Ví dụ thực hiện: ulatencyd .
derobert

@derobert Tuyệt vời điều này có vẻ như chính xác những gì tôi đang tìm kiếm. Tôi sẽ bắt đầu thử nghiệm điều này ngay khi có thời gian.
FSMaxB

Tuyệt vời, ulatencyd thậm chí còn có gói AUR, đoán tôi may mắn là người dùng Archlinux.
FSMaxB

Thậm chí còn có một bài viết wiki wiki.archlinux.org/index.php/Ulatencyd
FSMaxB

Nếu tôi có thể bỏ phiếu Q này nhiều hơn tôi sẽ! Có thực sự không có cách trực tiếp nào để nói với GUI và một vài chương trình chính ở lại RAM để nó vẫn phản hồi? Ý tôi là, trường hợp xấu hơn của việc cung cấp cho người dùng linux tùy chọn này là gì? Máy tính gặp sự cố? AI ĐÃ LÀM SAU ĐÓ? :) Ý tôi là đôi khi, tôi vô tình khởi động quá nhiều máy ảo vì tôi không thể thêm (số RAM) một cách chính xác và sau đó phải mất FOREVER để đưa mọi thứ trở lại trong tầm kiểm soát. Nói với GUI và có lẽ thiết bị đầu cuối ở trong RAM sẽ khắc phục điều đó đúng không?! Xin vui lòng, ai đó trả lời này!
Damon

Câu trả lời:


1

Theo như tôi biết thì đây không phải là vấn đề cụ thể đối với Linux, đó là cách SWAP (hoặc bộ nhớ ảo) hoạt động. Nếu HĐH cần tra cứu dữ liệu trong ổ cứng trái ngược với RAM, nó sẽ chạy chậm lại. Không có gì bạn có thể làm về điều đó, truy cập vào đĩa chậm hơn so với truy cập RAM.

Bạn sẽ không thể đặt mức độ ưu tiên cho các quá trình được hoán đổi, được xác định bởi kernel sẽ cố gắng tối đa hóa hiệu quả, bạn sẽ không thể làm điều đó tốt hơn. Những gì bạn có thể làm là đặt mức độ ưu tiên CPU của một tiến trình và điều đó có thể giúp ích. Hệ thống của bạn đang bị hạ thấp do thời gian cần đọc từ / đến SWAP, điều này có nghĩa là CPU sẽ phải chờ dữ liệu liên quan được lấy ra bởi quá trình yêu cầu trước khi có thể tiếp tục. Nếu bạn đặt DE của mình có mức ưu tiên cao hơn cho truy cập CPU, điều đó sẽ đẩy hoạt động của nó lên hàng đầu và tăng tốc mọi thứ lên một chút.

Vì vậy, mức độ ưu tiên của CPU được đặt bằng các lệnh nicerenice:

 Renice alters the scheduling priority of one or more running processes.
 The following who parameters are interpreted as process ID's, process
 group ID's, or user names.  Renice'ing a process group causes all pro‐
 cesses in the process group to have their scheduling priority altered.
 Renice'ing a user causes all processes owned by the user to have their
 scheduling priority altered.  By default, the processes to be affected
 are specified by their process ID's.

Các ưu tiên đi từ -20 (ưu tiên cao nhất) đến 20 (ưu tiên thấp nhất). Để thay đổi mức độ ưu tiên của quy trình đang chạy, bạn có thể làm:

renice -15 $PID

đâu $PIDPID của quá trình mà bạn muốn tăng mức độ ưu tiên. Bạn có thể sử dụng pgrepđể tìm ra đó là. Ví dụ:

renice -15 $(pgrep gnome-session)

Tùy chọn khác sẽ là đặt 'swappiness' của hệ thống để xác định khi nào nó sẽ bắt đầu hoán đổi. Giá trị swappiness bằng 1 có nghĩa là nó sẽ chỉ trao đổi để tránh lỗi bộ nhớ. Giá trị cao hơn có nghĩa là nó sẽ bắt đầu hoán đổi ngay cả khi vẫn còn bộ nhớ vật lý. Bạn có thể đặt giá trị này thành một giá trị tương đối thấp để làm cho hệ thống của bạn trao đổi ít nhất có thể. Thêm dòng này vào /etc/sysctl.conf:

vm.swappiness=1

CẨN THẬN: Đó không phải là một ý tưởng tốt nếu bạn không có nhiều RAM, trao đổi là một điều tốt, nói chung, bạn sẽ cần phải chơi xung quanh với các giá trị một chút để tìm sự cân bằng phù hợp cho hệ thống của mình.


Khi bạn nói điều này có thể được giải quyết trong không gian kernel, điều đó có nghĩa là nó rất có thể là đặc thù của linux. Thay đổi sự thay đổi sẽ không thay đổi bất cứ điều gì vì khi sử dụng toàn bộ RAM, hệ thống sẽ hoán đổi mọi cách. Và ưu tiên của một quá trình sẽ không thay đổi bất cứ điều gì về quản lý bộ nhớ mà chỉ hành vi của bộ lập lịch cpu và thời gian cpu không thực sự hữu ích để tăng tốc truy cập đĩa.
FSMaxB

@FSMaxB Ưu tiên CPU có thể giúp ích vì nó sẽ ưu tiên DE, nó sẽ không hữu ích nếu bản thân DE bị tráo đổi nhưng sẽ có một thứ gì đó đang giữ CPU và do đó làm chậm máy.
terdon

Khi DE không hoạt động trong một thời gian, theo kinh nghiệm của tôi, DE luôn bị tráo đổi khi hết bộ nhớ.
FSMaxB

@FSMaxB yeah, điều đó có ý nghĩa vì DE là bộ nhớ. Tuy nhiên, việc tăng mức độ ưu tiên của nó có thể giúp ích, ít nhất là bộ lập lịch sẽ không giữ lại.
terdon
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.