많은 양의 메모리를 소비하는 프로세스가 있거나 CPU에 바인딩된 프로세스가 많이 실행 중인 경우 시스템에 로그인하는 것조차 어려워지는 경우가 많습니다. 나는 이를 방지하고 항상 시스템의 응답성을 유지하고 싶습니다. 이 작업을 수행할 수 있는 방법이 있나요?
편집 내용을 명확히 함:
나는 동일한 증상을 경험하는 두 가지 다른 상황에 대해 이야기하고 있습니다.
메모리 부하가 매우 높습니다. 단일 프로세스는 사용 가능한 64GB RAM에 가깝거나 그 이상을 소비합니다. 시스템 사용량이 100%에 가까워지면 프로그램이 응답하지 않게 됩니다.
CPU 부하가 매우 높으며 예약 문제가 있습니다. 실행 가능한 프로세스가 10,000개 있으면 동일한 문제가 발생합니다. 이는 CPU 로드 100%의 문제가 아니라는 점에 유의하세요. 해당 프로세스 중 200개를 제외한 모든 프로세스를 종료 -STOP하면 32개의 CPU가 모두 100% 로드 상태를 유지하지만 시스템은 훨씬 더 유용합니다.
그리고 내가 "시스템"이라고 생각하는 문제에 대해. 나는 쉘 프로세스와 다른 사용자 프로세스 중 하나 사이에 개념적 차이가 없다는 것을 이해하지만 이는 단지 그들을 다르게 만드는 문제일 뿐입니다. 이를 수행하는 친절함과 같은 옵션이 있습니다. 그러나 위에서 언급한 것처럼, 적어도 (2.)의 경우에는 친절함이 문제를 해결하지 못했습니다.
나는 이러한 시스템을 완벽하게 제어할 수 있으며 모든 경우에 kill -STOP 또는 참조만 사용하여 작업을 중지할 수 있었습니다.제가 고치고 싶은 것은 이것이 엄청나게 어려워지고 GUI를 사용할 때 때로는 입력이 엄청나게 느리게 처리되기 때문에 불가능하다는 것입니다. 일부 특정 작업을 변경하지 않고 일반적으로 이 문제를 해결하고 싶습니다.
내가 시도한 것들:
현재 실행 중인 많은 프로세스의 경우 실행 중인 모든 프로세스를 +5로 설정했지만 별 도움이 되지 않는 것 같습니다. 19. 친절하게 설정하지도 않습니다.
답변 중 하나에서 제안한대로. 및를 사용하여 스케줄러 정책을 IDLE로 변경해 보았습니다
sudo schedtool -D $(pgrep -u myuser progname -d " ").sudo sh -c 'for pid in $(pgrep -u myuser progname); do chrt -i -p 0 $pid; done;'이렇게 하면 상황이 다소 개선될 것 같습니다.
답변1
문제는 메모리가 포화되어 결과적으로 운영 체제가 디스크 캐시를 해제하고 프로그램과 해당 데이터를 교환해야 한다는 것입니다.
스왑은 물리적 메모리 제한에 도달했을 때 시스템을 계속 작동시키는 방법입니다. 로드가 적은 시스템에서는 시스템이 계속 작동하고 핀치가 발생하면 페이지 아웃되었다가 필요할 때 사소한 효과만 적용되어 다시 들어오는 것을 의미할 수 있습니다.
대부분의 운영 체제는 "가장 최근에 사용한" 기준으로 교체하기 위해 프로그램과 코드를 플러시합니다. 메모리 로드가 변하고 "우선순위"는 무엇이 더 중요한지에 대한 주관적 판단의 미끄러운 경사면이기 때문에 메모리의 "우선순위"에 대해 어떤 종류의 가정도 하기 어렵습니다. 한 시스템에서 더 중요한 것은 다른 시스템에서는 덜 중요합니다. 명령줄 프로그램은 단지 다른 프로그램일 뿐이며 사용자가 실행하는 다른 프로그램과 구별하는 것은 불가능합니다.
많은 메모리를 사용하는 많은 프로세스로 인해 로드가 많은 시스템이 있으므로 경합 문제가 발생합니다. 운영 체제가 일부 메모리를 확보하기 위해 디스크에 무언가를 페이징하려고 시도하는 순간 다른 프로세스가 이미 다시 가져와야 하는 다른 페이지를 요청했습니다. 무언가를 다시 가져오려는 모든 요청은 다른 것을 밀어냅니다.
10,000개의 프로세스 중에서 시스템이 다른 프로그램 요청처럼 보이는 "시스템" 명령줄 프로그램 요청보다 우선순위를 두어야 할 항목을 어떻게 결정할 수 있습니까?
또 다른 문제는 하드 드라이브 검색 시간입니다. 이전 스타일 HDD의 경우 드라이브 헤드를 이동하고 읽기 또는 쓰기를 시작하는 데 걸리는 시간은 약 9.5밀리초입니다. 여러 영역에 대해 동시에 많은 요청이 발생하면 시간을 찾는 것이 다른 모든 것을 지배할 수 있으며 실제 유용한 시간과 대역폭을 놀라울 정도로 작은 수치로 줄일 수 있습니다. SSD가 도움이 될 수 있지만, 메모리가 제한된 경우에는 너무 많은 도움이 될 수 있습니다.
유사한 병목 현상이 시스템 전체에서 발생할 수 있으며 다양한 증상이 나타날 수 있습니다. 운영 체제는 많은 수의 동시 프로그램을 관리할 수 있지만 여전히 프로그램 자체일 뿐이며 다른 모든 것 사이에서 시간이 필요합니다. 스왑 파일 사용은 가장 극심한 병목 현상 중 하나일 뿐입니다.
이러한 방식으로 시스템을 플러딩하고 시스템이 "처리"할 것이라고 기대하는 것은 좋은 생각이 아닙니다.
가지고 있는 것보다 더 많은 메모리를 지속적으로 사용하고 있다면 더 많은 메모리를 구입하는 것이 답입니다. 데이터를 읽거나 쓰기 위한 하드 드라이브 시간을 놓고 경합하는 수천 개의 프로세스가 있는 경우 더 많은 시스템이나 드라이브에 로드를 분산해야 합니다.
다른 상황에서는 10,000개의 활성 프로세스가 있는 경우 문제는 경합과 비현실적인 기대 중 하나입니다.
한 가지 문제는 "좋은 것"이 항상 우선순위가 낮은 것은 아니라는 것입니다. 이는 운영 체제 스케줄러에 따라 다르며 점점 더 많은 프로세스를 추가하면 특정 프로세스에 할당된 시간이 줄어들기 때문에 실제로 공정하고 유용한 시스템을 갖추는 데 방해가 될 수 있습니다.
Unix 자매 사이트에서 이 질문을 참조하세요.잘 지내요?완전히 공정한 스케줄러를 설명합니다.
CFS에는 예약 기간에 대한 목표 대기 시간이 있습니다. 대상 지연 시간이 짧을수록 상호작용성이 향상되지만, 대상 지연 시간이 감소하면 스위칭 오버헤드가 증가하여 전체 처리량이 감소합니다.
...
이제 두 프로세스를 고려해 보겠습니다. 하나는 niceness 0(기본값)이고 다른 하나는 niceness 5입니다. 해당 가중치 간의 비례 차이는 대략 1/3입니다. 즉, 우선 순위가 높은 프로세스가 약 15밀리초의 타임슬라이스를 받는다는 의미입니다. 우선 순위가 낮은 프로세스는 5밀리초의 타임슬라이스를 받습니다.
이 스케줄러에서 훌륭하다는 것은 10,000개의 프로세스가 있다는 것을 의미합니다.~해야 한다더 적은 시간을 얻을 수 있지만 그 수가 너무 많기 때문에 "공정한" 일정에 대한 시간 조각 값의 하한에 도달할 수 있으며 이는 누구도 적절한 크기의 시간 조각을 얻지 못함을 의미합니다. CPU에서 작업을 가져오거나 끄는 것이 시간상 지배적인 한계에 도달할 수도 있습니다.
이는 사실상 하드 드라이브 경합과 동일합니다. 시스템이 특정 프로세스에서 유용한 시간을 보내는 것보다 프로세스 간 교환에 더 많은 시간을 소비하도록 강요하고 있습니다.
스케줄러에 대한 자세한 내용은 다음에서 확인할 수 있습니다.http://man7.org/linux/man-pages/man7/sched.7.html
보다 합리적인 수의 프로세스(100~200개)를 사용하면 OS 작업과 프로세스 간에 합리적인 시간이 분할됩니다.
10,000개의 작업을 한 번에 시작하는 대신 이전 작업이 끝나면 새 작업을 시작해야 합니다.