거의 가득 찬 RAM에서 컴퓨터 정지, 디스크 캐시 문제


74

내가 생각하는 문제는 스레드 와 다소 유사합니다 .

스왑을 활성화 또는 비활성화했는지 여부는 실제로 사용 된 RAM 양이 최대에 가까워지고 디스크 캐시를위한 공간이 거의 없을 때마다 시스템이 완전히 응답하지 않게됩니다.

디스크는 격렬하게 회전하며 때로는 10-30 분 동안 기다린 후에는 고정이 풀리지 않으며 때로는 타당하지 않습니다. 때로는 빨리 행동하면 천천히 콘솔을 열고 브라우저와 같은 램 먹는 응용 프로그램을 죽일 수 있으며 시스템이 거의 즉시 정지됩니다.

이 문제로 인해 스왑에서 아무것도 볼 수 없으며 때로는 몇 MB 만 있고이 문제가 나타난 직후에 있습니다. 교육을받지 않은 추측은 디스크 캐시에 너무 욕심이 많거나 메모리 관리가 관대하다는 것입니다. 따라서 메모리가 필요할 때 메모리가 빨리 풀리지 않고 시스템이 고갈됩니다.

디스크 캐시에로드 된 이후에 시스템이 충분히 빨리 언로드 할 수없는 lagrge 파일 (500MB +)을 사용하여 작업하면 문제가 실제로 빠르게 달성 될 수 있습니다.

어떤 도움이나 아이디어라도 대단히 감사하겠습니다.

지금은 컴퓨터가 멈출 수 있고 항상 다시 시작해야 할 때 끊임없이 두려움에 따라 살아야합니다. 실제로 램이 부족하면 broser와 같은 사용자 공간 응용 프로그램을 죽이는 것이 훨씬 좋습니다. 가급적이면 먼저 죽일 마크를 표시 할 수 있다면)

이 상황에서 미스터리가 바뀌지 않는 이유는 무엇입니까?

업데이트 : 한동안 멈추지 않았지만 이제 여러 번 다시 발생했습니다. 나는 항상 화면에 램 모니터를 유지하고 있으며 중단이 발생해도 여전히 ~ 30 %의 여유 공간을 보여줍니다 (디스크 캐시에 사용됨). 추가 증상 : 비디오 (VLC 플레이어)를 시청할 때 몇 초 후에 소리가 먼저 멈춰지고 이미지가 멈 춥니 다. 소리가 멈추는 동안 나는 여전히 PC를 제어 할 수 있지만 이미지가 멈 추면 더 이상 마우스를 움직일 수 없으므로 잠시 기다린 후에 다시 시작했습니다. Btw, 이것은 비디오를보기 시작했을 때 발생하지 않았지만 (20 분)에 시간이 있었고 브라우저와 oowrite가 항상 두 번째 화면에서 열려 있었지만 그 당시에는 다른 일을하지 않았습니다. 기본적으로 무언가는 한 시점에서 발생하기로 결정하고 시스템을 정지시킵니다.

의견의 요청에 따라 교수형 직후 dmesg를 실행했습니다. 내가 지금 여기있다, 아무것도 이상한 알 didnt는하지만,보고 무엇을 몰랐어요 : https://docs.google.com/document/d/1iQih0Ee2DwsGd3VuQZu0bPbg0JGjSOCRZhu0B05CMYs/edit?hl=en_US&authkey=CPzF7bcC


11
더주의를 기울여야합니다. 수년 동안 제기 된 버그가 있음을 알고 있습니다.
n3rd

1
@ n3rd : 이것은 버그 입니다.
Dan Dascalescu

@ Krišjānis Nesenbergs : 긴 파일을 붙여 넣을 때 잘못된 사본이 있으면 중단됩니다.
Rick2047

이 질문을하고 해결책을 찾아 주셔서 감사합니다. 업데이트에 날짜를 추가하십시오. 그렇지 않으면 작동하지 않는 것과 작동하지 않은 것이 명확하지 않습니다. 나는 같은 문제를 겪고 있고, 항상 메모리 레벨을 점검하고 있으며, 16GB를 가지고 있으며 32GB를 계획하고 있는데, 그런 식으로 고칠 수 있는지
알아볼

답변:


63

이 문제를 해결하려면 다음 설정을 총 실제 RAM의 약 5 % -6 %로 컴퓨터의 코어 수로 나눈 값으로 설정해야합니다.

sysctl -w vm.min_free_kbytes=65536

이것은 코어 당 설정이므로 2GB RAM과 2 개의 코어가있는 경우 1GB의 6 % 만 계산하고 안전을 위해 약간만 추가했습니다.

이로 인해 컴퓨터는이 양의 RAM을 사용 가능하게 유지해야하므로 디스크 파일을 캐시하는 기능이 제한됩니다. 물론 여전히 캐시를 시도하고 즉시 스왑 아웃하려고하므로 스왑을 제한해야합니다.

sysctl -w vm.swappiness=5

(100 = 가능한 한 자주 교환, 0 = 필요한 경우에만 교환)

결과적으로 리눅스는 더 이상 무작위로 약 1GB의 전체 동영상 파일을 램으로로드하지 않고 시스템을 죽이는 것을 결정하지 않습니다.

이제 메모리 부족 현상을 피할 수있는 예약 된 공간이 충분 해 문제가되었습니다 (이전처럼 더 이상 정지가 없는지 확인).

하루 동안 테스트 한 후-잠금이 사라지면 물건이 더 자주 캐시되기 때문에 사소한 속도 저하가 발생하지만 몇 시간마다 컴퓨터를 다시 시작할 필요가 없으면 그와 함께 살 수 있습니다.

여기서 교훈은-기본 메모리 관리는 유스 케이스 중 하나이며 일부 사람들이 달리 제안하려고하더라도 최상의 것은 아닙니다. 홈 엔터테인먼트 우분투는 서버와 다르게 구성해야합니다.


이러한 설정을 다음 /etc/sysctl.conf과 같이 추가하여 영구적으로 설정하려고 할 수 있습니다 .

vm.swappiness=5
vm.min_free_kbytes=65536

문제를 더 잘 인식 할 수 있도록 버그를보고하십시오. 누군가가 전체 영화를 무작위로로드하지 않는 해결책을
찾길 바랍니다

고마워, 세부 사항 및 내 문제를 설명합니다. 매우 감사!
odedbd

1
글쎄, 나는 거의 모든 것을 시도했고, 당신의 제안 만 개선되었습니다. 감사합니다
vitalii

1
스왑 파티션없이 실행중인 경우 5-6 %보다 많은 양을 사용해야합니까? 그런 vm.swappiness경우에는 설정 이 아무 효과가 없습니다.
Jarett Millard 18

1
"[vm.min_free_kbytes]는 컴퓨터가이 양의 RAM을 사용 가능하게 유지하도록하므로 디스크 파일을 캐시하는 기능을 제한합니다." -귀찮게해서 미안하지만, 이것은 전혀 관련이 없습니다 vm.min_free_kbytes. __GFP_WAIT높은 시스템 메모리 경합에서 원자 (즉, 채우기 또는 종료 / 비 ) 할당 을 용이하게하기 위해 예약 된 페이지 블록 역할을합니다 . 그것은 실제로 (아마이 포장 마차가 시스템 메모리 경합에 관련된으로) 의미는 여기를 제기 할 수 있도록하지만, 그것은 확실히이 답변에 설명 된 이유로 없을 것이다.
Chris Down

9

이것은 우분투 14.04의 새로운 설치에서 나에게 일어났다.

필자의 경우 언급 한 sysctl 문제와 관련이 없습니다.

대신, 문제는 설치 중 스왑 파티션의 UUID가 설치 후와 다르다는 것입니다. 따라서 스왑이 활성화되지 않았으며 몇 시간 후에 컴퓨터가 잠겼습니다.

솔루션은 스왑 파티션의 현재 UUID와를 확인했다

sudo blkid

다음 sudo nano /etc/fstabBLKID에 의해보고 된 하나 잘못된 스왑의 UUID 값을 대체합니다.

변경 사항에 영향을주는 간단한 재부팅 및 voila.


3
정말 고맙습니다! 나는 1 년 가까이에 무언가에 대한이 엄청나게 격렬한 버그로 어려움을 겪고 있으며, 그것을 고치기 위해 모든 것을 시도 했습니다. 리눅스가 왜 이런 행동을합니까? 스왑이없는 것처럼 행동하고 OOM 킬러를 호출하는 것처럼 보입니다. 대신 스왑이있는 것처럼 보이지만 실제로 스왑이 실패합니다 (실제로 구성되지 않았기 때문에 실제로는 없기 때문에).
crazy2be

@ crazy2be 실패하지 않고 끝없이 성공하고 있습니다. 스왑이 없어도 Linux는 여전히 프로그램 및 수정되지 않은 파일을 메모리에 페이징하여 디스크에서 다시 읽을 수 있습니다.
마틴 손튼

4

이 질문이 오래되었다는 것을 알고 있지만 Acer C720 크롬 북의 Ubuntu (Chrubuntu) 14.04에서이 문제가 발생했습니다. Krišjānis Nesenbergs 솔루션을 시도했지만 다소 효과가 있었지만 여전히 충돌했습니다.

마침내 SSD에서 물리적 스왑을 사용하는 대신 zram을 설치하여 작동하는 솔루션을 찾았습니다. 그것을 설치하려면 다음 과 같은 지침을 따르 십시오 .

sudo apt-get install zram-config

그 후 /etc/init/zram-config.conf21 행에서 수정하여 zram 스왑의 크기를 구성 할 수있었습니다 .

20: # Calculate the memory to user for zram (1/2 of ram)
21: mem=$(((totalmem / 2 / ${NRDEVICES}) * 1024))

나는 zram 크기를 내가 가지고있는 ram의 크기와 동일한 크기로 만들기 위해 2를 1로 바꿨습니다. 그렇게 한 후에 더 이상 멈추거나 시스템이 응답하지 않았습니다.


zramRAM을 더 설치할 수없는 경우에만 실행 가능한 옵션입니다. SSD로 스왑 할 때 시스템이 너무 느리고 스왑없이 RAM zram이 부족한 경우 조금 더 노력할 때까지 조금 도움이 될 수 있으며 결과는 스왑이없는 RAM에서와 동일합니다.
Mikko Rantalainen

4

아무것도 나를 위해 일하지 않았다!!

그래서 메모리 사용을 모니터링하는 스크립트를 작성했습니다. 메모리 소비가 임계 값을 늘리면 먼저 RAM 캐시를 지우려고 시도합니다. 스크립트에서이 임계 값을 구성 할 수 있습니다. 메모리 소비가 임계 값 아래로 떨어지지 않으면 메모리 소비가 임계 값 아래가 될 때까지 메모리 소비가 감소하는 순서로 프로세스를 강제 종료합니다. 기본적으로 96 %로 설정했습니다. 스크립트에서 변수 RAM_USAGE_THRESHOLD의 값을 변경하여 구성 할 수 있습니다.

높은 메모리를 소비하는 프로세스를 죽이는 것이 완벽한 솔루션은 아니지만 모든 작업을 잃지 않고 하나의 응용 프로그램을 종료하는 것이 좋습니다! RAM 사용량이 임계 값을 늘리면 스크립트에서 데스크탑 알림을 보냅니다. 또한 프로세스가 종료되면 알려줍니다.

#!/usr/bin/env python
import psutil, time
import tkinter as tk
from subprocess import Popen, PIPE
import tkinter
from tkinter import messagebox
root = tkinter.Tk()
root.withdraw()

RAM_USAGE_THRESHOLD = 96
MAX_NUM_PROCESS_KILL = 100

def main():
    if psutil.virtual_memory().percent >= RAM_USAGE_THRESHOLD:
        # Clear RAM cache
        mem_warn = "Memory usage critical: {}%\nClearing RAM Cache".\
            format(psutil.virtual_memory().percent)
        print(mem_warn)
        Popen("notify-send \"{}\"".format(mem_warn), shell=True)
        print("Clearing RAM Cache")
        print(Popen('echo 1 > /proc/sys/vm/drop_caches',
                    stdout=PIPE, stderr=PIPE,
                    shell=True).communicate())
        post_cache_mssg = "Memory usage after clearing RAM cache: {}%".format(
                            psutil.virtual_memory().percent)
        Popen("notify-send \"{}\"".format(post_cache_mssg), shell=True)
        print(post_cache_mssg)

        if psutil.virtual_memory().percent < RAM_USAGE_THRESHOLD:
            print("Clearing RAM cache saved the day")
            return
        # Kill top C{MAX_NUM_PROCESS_KILL} highest memory consuming processes.
        ps_killed_notify = ""
        for i, ps in enumerate(sorted(psutil.process_iter(),
                                      key=lambda x: x.memory_percent(),
                                      reverse=True)):
            # Do not kill root
            if ps.pid == 1:
                continue
            elif (i > MAX_NUM_PROCESS_KILL) or \
                    (psutil.virtual_memory().percent < RAM_USAGE_THRESHOLD):
                messagebox.showwarning('Killed proccess - save_hang',
                                       ps_killed_notify)
                Popen("notify-send \"{}\"".format(ps_killed_notify), shell=True)
                return
            else:
                try:
                    ps_killed_mssg = "Killed {} {} ({}) which was consuming {" \
                                     "} % memory (memory usage={})". \
                        format(i, ps.name(), ps.pid, ps.memory_percent(),
                               psutil.virtual_memory().percent)
                    ps.kill()
                    time.sleep(1)
                    ps_killed_mssg += "Current memory usage={}".\
                        format(psutil.virtual_memory().percent)
                    print(ps_killed_mssg)
                    ps_killed_notify += ps_killed_mssg + "\n"
                except Exception as err:
                    print("Error while killing {}: {}".format(ps.pid, err))
    else:
        print("Memory usage = " + str(psutil.virtual_memory().percent))
    root.update()


if __name__ == "__main__":
    while True:
        try:
            main()
        except Exception as err:
            print(err)
        time.sleep(1)

save_hang.py 파일에 코드를 저장하십시오. 다음과 같이 스크립트를 실행하십시오.

sudo python save_hang.py

이 스크립트는 Python 3에만 호환되며 tkinter 패키지를 설치해야합니다. 다음과 같이 설치할 수 있습니다.

sudo apt-get install python3-tk

도움이 되었기를 바랍니다...


2

내 생각에 당신이 vm.swappiness매우 낮은 값으로 설정 하면 커널이 너무 늦게 교환되어 시스템이 작동하기에 RAM이 너무 낮아집니다.

다음을 실행하여 현재 swappiness 설정을 표시 할 수 있습니다.

sysctl vm.swappiness

기본적으로이 값은 60으로 설정되어 있습니다. Ubuntu Wiki 는이 값을 10으로 설정하는 것이 좋지만 더 높은 값으로 설정하는 것이 좋습니다. 다음을 실행하여 변경할 수 있습니다.

sudo sysctl vm.swappiness=10

이것은 현재 세션에 대해서만 변경 되며 , 영구적으로 만들 vm.swappiness = 10려면 /etc/sysctl.conf파일 에 추가해야 합니다.

디스크 속도가 느리면 새 디스크를 구입하십시오.


실제로 교환 성을 줄이면 문제가 줄어 듭니다 (더 드물게 발생 함). 지금 5로 유지하고 있습니다. 60 세가되었을 때 영화를 보거나 큰 파일을 편집하기로 결정했기 때문에 최대 스왑 인의 또 다른 문제 일지 모르지만 전체 파일과 거의 GB가 메모리에로드 된 다음 즉시 시스템 스왑 아웃을 시작했습니다. 적극적으로 사용하고 심지어 사용자 인터페이스 자체. 문제는 스왑 부분을 이해하고 있다고 생각합니다. 원하는 것은 램이 부족할 때 기계를 정지시키는 대신 욕심 많은 사용자 응용 프로그램을 종료하는 것입니다. (그리고 캐시에서 파일 크기를 제한하는 것이 좋습니다)
Krišjānis Nesenbergs

@Krisa : 시스템에 메모리가 부족하면 (RAM 및 스왑) 커널은 oom_kill을 호출하여 메모리를 절약하기 위해 프로세스를 종료합니다. 불행히도 대상 프로세스를 제어 할 수 없습니다. 수동으로 트리거하려면 Alt + SysRq + F를 누르십시오. dmesg명령을 실행할 때 프로세스의 일부 정보 (및 프로세스 이름 + id)가 표시됩니다. 새롭고 더 빠른 디스크를 구입하는 것이 좋습니다. 또는 RAM을 업그레이드하십시오.
Lekensteyn

3
문제는 컴퓨터가 약 30 분 동안 잠기기 전에 oom_kill이 호출되지 않는다는 것입니다. 또한 어떤 프로세스가 먼저 종료되는지 알 수있는 방법이 있습니까?
Krišjānis Nesenbergs

2
2GB 램이 있고 HDD는 5400rpm입니다. 한 모니터에서 일부 비디오를보고 다른 모니터에서 20-30 개의 탭을 탐색하는 동안 30 분의 정지를 정당화하는 오래된 시스템이라고 생각하지 않습니다. 실제로 콘솔에 액세스하여 일부 프로세스를 종료 할 수 있다면 실제로 행복 할 것입니다. 사용자 입력 및 터미널을 최우선 순위로 설정하여 시스템이 멈추는 동안 작동합니까?
Krišjānis Nesenbergs

1
어쨌든-스왑과 RAM의 양은 약간의 주제입니다. 문제는 스왑이 비활성화되어 있어도 시스템이 오랫동안 응답하지 않고 그 후에도 여전히 프로그램을 실행하고 (어딘가에서 메모리를 찾도록 관리) 다른 시간에는 oom_killer를 실행한다는 것입니다. 시스템은 램이 부족하다는 것을 알 수 있어야하며 더 많은 것을 실행시키지 않아야합니다. 따라서 고정을 중지하거나 사용자 입력의 우선 순위를 너무 높게 설정하여 콘솔이 발생할 때 콘솔로 전환하고 일부 프로세스를 직접 종료 할 수있는 방법이 있습니까?
Krišjānis Nesenbergs

2

나는이 문제로 오랫동안 어려움을 겪었지만 지금은 내 노트북에서 해결 된 것 같습니다.

다른 답변이 당신에게 도움이되지 않으면 (내가 대부분 시도했습니다) 컴퓨터 교체가 시작될 때 RAM에 더 많은 공간을 확보하기 위해 min_free_kbytes 와 함께 사용 하십시오 (빈 RAM 에서이 최소값에 도달하기 직전에).

16GB RAM이 있지만 나중에 메모리가 가득 차서 일부 항목이 스왑 될 때까지 10-30 분 동안 응답이 중지되었습니다.

적어도 나를 위해 min_free_kbytes 값을 권장 값보다 높게 설정 하면 스왑 프로세스가 훨씬 빨라집니다.

16GB RAM의 경우 다음을 시도하십시오.

vm.min_free_kbytes=500000

이 값을 설정하려면 다른 답변을 보거나 Google :)


0

나는 작은 ext4 스토리지 파티션과 하드 드라이브의 스왑 파일을 사용하여 라이브 Ubuntu SD 카드에서 랩톱 중 하나를 지속적으로 실행합니다. 거의 모든 RAM을 사용하고 swappiness 값이 너무 낮을 때 (때로는 잡음이 있기 때문에 하드 드라이브를 완전히 끄는 것을 선호합니다), Linux 성능은 나를 위해 절벽에서 떨어지는 경향이 있습니다. Firefox를 종료하려면 TTY1이 15 분이 걸립니다.

/proc/sys/vm/vfs_cache_pressure기본값 100에서 6000 값으로 올리면 이를 방지하는 데 도움이됩니다. 그러나 커널 문서는 그렇게하지 말라고 경고합니다.

Increasing vfs_cache_pressure significantly beyond 100 may have negative
performance impact. Reclaim code needs to take various locks to find freeable
directory and inode objects. With vfs_cache_pressure=1000, it will look for
ten times more freeable objects than there are.

나는 이것이 일의 부작용을 완전히 확신하지 못하므로 이것을 조심스럽게해야합니다.


vfs_cache_pressure10에 가까우면 (100보다 훨씬 작음) min_free_kbytes더 높은 설정으로 더 나은 결과를 경험할 수 있습니다. 당신이 설정 한 경우 경고 할 min_free_kbytes너무 높은, 커널의 OOM 킬러가 모두를 죽일 것이다!
Mikko Rantalainen

@MikkoRantalainen 나는 이미 min_free_kbytes262144로 올렸으며 , vfs_cache_pressure낮추는 것이 반대 효과 가 있음을 관찰 했습니다. 100보다 낮게 내리면 시스템이 훨씬 빠르게 응답하지 않습니다. 왜 정확한지 잘 모르겠습니다.
Hitechcomputergeek

일반적으로 증가 vfs_cache_pressure하면 캐싱 된 파일 내용 전에 디 렌트 리가 발생하게되므로 결과적으로 일반적으로 100 이상의 값으로 인해 전체 성능이 저하됩니다. 커널 개발자는 근본 원인을 파악할 수 있습니다. 나를 위해 경고없이 경고가 발생합니다. 가장 좋은 추측은 OOM Killer가 충분한 RAM을 확보하기 전에 OOM으로 인해 커널이 정지한다는 것입니다. 이제 min_free_kbytes = 100000, admin_reserve_kbytes = 250000 및 user_reserve_kbytes = 500000을 실행 중입니다.
Mikko Rantalainen

(계속) swappiness = 5 및 vfs_cache_pressure = 20인데도 아직 위의 구성으로 충돌하지 않았습니다. 시스템의 SSD에는 16GB의 RAM과 8GB의 스왑이 있습니다. 다른 시스템에는 32GB의 RAM과 제로 스왑이 있으며 무작위로 동일한 문제가 발생하는 것으로 보입니다. 시스템이 느리게 느껴진 후에 Alt + SysRq + f를 누르면 도움이 될 것 같습니다.
Mikko Rantalainen
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.