무슨 일이 있어도 프로세스가 종료되는 것을 방지할 수 있는 방법이 있습니까? 나는 알고 있지만 nice장기 실행 메모리 집약적 작업과 같은 작업에 rake가장 높은 우선 순위를 부여하면 해당 작업이 종료되는 것을 방지할 수 있는지 확실하지 않습니다.
nice -n -20 rake xyz
편집: 원본 포스터는 서버의 리소스가 부족하더라도 우선 순위가 높기를 원할 가능성이 높으므로 다른 프로세스가 먼저 종료됩니다.
답변1
루트가 프로세스를 종료하는 것을 막을 수는 없습니다. 또는 그 문제에 대해서는 서버가 모든 리소스를 소모하는 프로세스를 종료하는 것을 막을 수 없습니다.
당신이 할 수 있는 일은 명령을 분기하여 종료되면 다시 시작되도록 하는 것입니다.
코드 사용 예:
답변2
이제 나는 이것이 오래된 질문이라는 것을 이해하지만 두 답변 모두 명백한 것을 무시하거나 기껏해야 표면을 긁기 때문에 직접 작성해야 한다는 느낌을 받았습니다. 질문의 표현을 보면 내 마음 속에 가장 먼저 떠오른 것은 "OOM 킬러!"였습니다. 다른 답변 중 하나는 사용자 관점에서 볼 때 터무니없는 "무언가가 자동으로 죽는 것이 아니다"라고 주장합니다. 자동화가 아니라면 OOM 킬러란 무엇일까요?
그만큼OOM 킬러링크된 기사에서 볼 수 있듯이 설명된 것과 같은 시나리오에서 가장 큰 적입니다.
이제 정확한 시나리오가 무엇인지(시스템 구축, 일부 서버 ...)에 따라 다르지만 일반적으로 저는하다내 OS가 내 컴퓨터의 리소스를 최대한 사용하기를 원합니다. 그래서 처음에 그것들을 구입했습니다.
귀하의 질문은 다음과 같습니다.
무슨 일이 있어도 프로세스가 종료되는 것을 방지할 수 있는 방법이 있습니까?
아니요,다행스럽게도아니다. 예를 들어 커널은 오작동하는 프로세스를 종료합니다(예:SIGSEGV). 이는 리소스 제한으로 인해 작업이 오작동하는 경우에도 적용됩니다(참조:제한.conf,getrlimit/setrlimit). 즉, rake작업 내부의 무언가(일부 작업을 수행하기 위해 다른 프로세스를 사용할 가능성이 높음)가 널 포인터를 역참조하는 경우 여전히 운이 좋지 않으며 해당 부분이 실패하고 결과적으로 작업이 실패할 수 있습니다.
루트는 또한 다음을 보낼 수도 있습니다.신호귀하의 프로세스에. 그리고 만약 당신이어떻게든사용자 공간과 관련된 모든 것으로부터 프로세스를 보호하더라도 root여전히 커널 모듈을 로드하고 커널의 노력을 약화시킬 수 있습니다(활성 커널 잠금을 제외하고).
나는 알고 있지만 장기 실행 메모리 집약적 작업과 같은 작업에 가장 높은 우선 순위를 부여하면 해당 작업이 중단되는 것을 방지할 수 있는지
nice확실하지 않습니다 . [...]rake
막지는 못하겠지만,~ 할 것이다다음과 같이 사용된다하나OOM 킬러에 대한 여러 경험적 방법 중 하나입니다. 그렇죠, 실제로 그 nice가치는~ 할 것이다도와주세요...조금. 그만큼LWN 기사위에서 이미 연결한 내용은 다음과 같은 경험적 방법을 제공합니다.
- 작업이 있는 경우0보다 좋은 값, 점수가 두 배로 늘어납니다.
- 수퍼유저 또는 직접 하드웨어 액세스작업(CAP_SYS_ADMIN, CAP_SYS_RESOURCE 또는 CAP_SYS_RAWIO)의 점수는 4로 나누어집니다. 이는 누적입니다. 즉, 하드웨어 액세스 권한이 있는 슈퍼 사용자 작업의 점수는 16으로 나누어집니다.
- OOM 조건이 하나에서 발생한 경우CPU세트확인된 작업은 해당 세트에 속하지 않으며 점수는 8로 나뉩니다.
- 결과 점수에 oom_adj의 거듭제곱에 2를 곱합니다(예: 양수인 경우 <<= oom_adj 점, 그렇지 않은 경우 >>= -(oom_adj) 점).
값 외에도 nice이를 루트로 실행하거나(또는 지정된 기능을 사용하여) 추가로 진행할 수도 있습니다.~이다 root, 다음과 같은 방법으로 프로세스가 OOM 킬러에 의해 종료되는 경향이 없는지 확인할 수 있습니다(기사에는자세한 내용) cgroup 생성:
mount -t cgroup -o oom oom /mnt/oom-killermkdir /mnt/oom-killer/invinciblesecho 0 > /mnt/oom-killer/invincibles/oom.priorityecho <pid> > /mnt/oom-killer/invincibles/tasks,<pid>레이크 작업의 프로세스 ID는 어디에 있습니까?
그럼 됐어요. OOM 킬러의 분노에서 특정 프로세스 그룹을 제외시킬 수 있습니다.
그러나 이 큰 망치 방식이 적합한지 확실하지 않습니다.첫 번째가장 좋은 일. 나는 oom_adj그것이 당신의 프로세스가 다른 프로세스와의 경쟁에서 살아남는 데 도움이 되는지 확인하기 위해 먼저 고민해야 한다고 생각합니다 . 특히 이것이 서버라면 전반적으로서비스서비스에 필수적이지 않은 특정 작업보다 더 중요할 수도 있습니다. 따라서 주의해서 사용하세요. 또한 메모리를 많이 차지하는지 모니터링할 수도 있습니다(sysstat 및 친구들이 도움을 주어야 합니다). 시계열 데이터베이스를 통해 작업을 수행하고 그래프를 그리는 경우 메모리 누수가 발생할 수도 있습니다.
그 어느 것도 작동하지 않으면 다음으로 가십시오.브렌든 그레그의 웹사이트그리고 시작자질다양한 성과 지표; 또한 그의 책 중 하나를 얻을 수 있는지 확인하십시오. 예를 들어 작업 내부의 메모리 할당과 관련하여 폭주 상황과 같은 상황이 발생할 수 있습니다 rake. 강조하신다고 해서장기 실행그리고메모리 집약적그러나 이것이 반드시 연결되는 것은 아닙니다. BPF와 친구들을 통해 다른 방법으로는 얻을 수 없는 통찰력을 얻을 수 있습니다.
답변3
왜~일 것이다죽여버릴까?
무언가가 죽는 것은 자동이 아니기 때문입니다. 이에 답하고 왜 어떤 것을 파기하도록 선택했는지 설명하면 해결책을 찾을 수 있을 것입니다.
Rails의 명령에 대해 이야기하고 있는 것을 보면 rake이것이 서버에서 실행되는 프로세스인 것으로 추측됩니다. 당신이 그것이 죽는 것에 대해 걱정한다는 것은 너무 많은 리소스를 사용하여 서버 호스트에 의해 그것이 죽임을 의미합니다. 이와 같은 경우에는 프로세스가 종료되어 프로세스를 중지할 수 있는 방법이 없습니다(있어도 안 됩니다).
자원이 많이 드는 작업이 있다면 더 많은 자원을 구입하세요. 자신의 서버 시간을 사용하십시오. 아니면 호스트가 원하는 대로 실행할 수 있도록 합의해 보세요.