답변:
첫 번째 주문 : 반응 형입니까?
로그인 할 수 없으면 더 큰 문제가 있습니다. 이는 일반적으로 하드웨어 장애와 소프트웨어 장애의 두 가지 형태로 나타납니다. 둘 다 잠재적으로 치명적입니다. DFA 오류를 방지하려면 일반적인 하드웨어 상태를 먼저 확인하십시오. 일반적으로 간단한 확인만으로도 충분합니다.
2 차 : 시스템의 기본 구조가 건강하고 질서에 있습니까?
시스템의 "골든 트라이어드"를 확인하십시오.
지난 수십 년 동안 트라이어드는 통신 (네트워킹)을 포함하는 "쿼드"로 확장되었습니다.
3 차 : 문제의 심각성은 무엇입니까?
어떤 프로그램이나 서비스가 영향을 받습니까? 심각도를 줄이면 시스템 (시스템 전체), 클러스터 (프로그램 그룹) 또는 격리 (특정 프로그램)입니까? 특정 기본 서비스가 실패했거나 응답하지 않아 프로그램 클러스터가 일반적으로 작동하지 않습니다. 체계적인 문제는 때때로 이것과 관련이 있지만 (DNS 또는 IP 충돌을 생각하십시오) 일반적으로 어디를 봐야 하는지를 아는 것이 중요합니다.
4 차 순서 : 진단 도구가 문제와 관련된 유용한 데이터를 제공합니까? 이제 시스템 상태 (2 차)와 문제가 발생한 부분 (3 차)에 대한 정보를 얻었으므로 문제가있는 곳을 쉽게 좁힐 수 있습니다.
오류 메시지 또는 로그 파일은이 과정에서 일반적인 방법입니다.
CPU 문제 :
디스크 공간 / IO 문제 :
메모리 문제 :
연결 문제 :
가장 일반적인 불만 (내가 듣는) :
이메일이 충분히 빠르지 않거나 (수신자가 1 분 이상 수신에서 수신까지) 이메일 전송 시도가 거부되었습니다. 이는 일반적으로 스팸 스톰 중에 Postfix가 시작하는 속도 제한에 해당하며 이는 내부 배달을 수락하는 기능에 영향을줍니다.
실제 예 :
그러나 항상 그런 것은 아닙니다. 한 번은 서비스 재시작과 상관없이 문제가 지속되었습니다. 3 분 후 둘러 볼 시간이었습니다. CPU는 사용 중이지만 100 % 미만 이었지만, 단지 2 개의 코어 박스에서로드가 15로 급증하여 더 높아질 위험이있었습니다. top 명령은 메일 스캐너와 함께 메일 시스템이 오버 드라이브 상태에 있었지만 볼 수있는 amavis 자식 프로세스가 없음을 보여주었습니다. 메일 큐 명령 (mailq)이 150 개 이상의 배달되지 않은 메시지를 표시 했으며 그 중 80 % 이상이 스팸이었습니다.지난 20 분 동안 하위 이메일 스캐너 프로세스 수를 늘리면서 (백 로그 처리를 돕기 위해) 속도 제한기를 낮추고 (스팸 폭풍의 섭취 속도를 줄인) 빠른 조정으로 서비스를 다시 시작하여 문제를 해결하고 시스템을 짧은 시간에 배송을 완료합니다.
문제의 원인은 Amavis 상위 프로세스가 죽은 상태에서 용감 해졌고 하위 프로세스가 결국 모든 과정을 실행했기 때문입니다 (메모리 누수를 방지하기 위해 너무 많은 스캔 후에 자체 종료 됨). 그래서 접미사에 SMTP 프로세스가 필요했습니다. 내가 사용한 배포판에는 업데이트되지 않은 오래된 패키지가있었습니다. 설치가 1 년 정도 전에 교체 될 예정이므로 몇 가지 버그 수정이 포함 된 최신 버전으로 수동으로 설치를 "오버로딩"했습니다. 그 이후로 같은 문제가 없었습니다.
일반적으로 "who"다음에 "last"
시간이 지남에 따라 내가 관리 한 컴퓨터의 문제는 "손길이 닿지 않은"에 대한 정의가 너무 느슨했기 때문에 발생했습니다.
내가 확인하는 첫 번째 것은 '맨 위'입니다 (메모리 또는 CPU 시간을 낭비하는 이상한 프로세스가 있습니까).
아무 것도 나타나지 않으면 '누구'를 확인하여 어떤 이유로 다른 사람이 내 컴퓨터에 있는지 확인합니다.
파일 시스템이 분리되었을 수 있습니다. 'cat / etc / mtab'을 호출 한 다음 'fstab'을 호출하여 부팅시 모든 것이 올바르게 나타나는지 확인하십시오.
가동 시간을 확인하여 상자에있는 사용자 수가 합리적인지 확인하고 (나 자신 만해야 함) var / log / auth.log를 통해 훑어 보면 무엇이 잘못되었는지 확인할 수 있습니다.
이것들은 모두 잡입니다. 상자에서 발생하는 오류에 따라 문제를 일으키는 특정 프로세스를 검사해야 할 수도 있습니다.
호스트 에서 (at) sar 와 같은 것을 실행 하는 것은 거의 필수입니다. CPU, 네트워크, 메모리 및 디스크 I / O의 히스토리 스냅 샷을 얻을 수있는 유용성은 과소 평가 될 수 없습니다.
지난 24 시간 동안 호스트가 수행 한 작업을 검토하고 상황이 잘못되기 시작한 시점을 확인하여 결함을 진단 할 수있는 경우가 여러 번있었습니다.
내가하는 첫 번째 일은 디스크 공간 검사 (다른 사람들이 언급했듯이)라고 가정합니다. 간단한 점검으로 "일반적인"문제가 발견되지 않으면 추가로 조사하겠습니다.
내가 좋아하는 한 가지는 시스템의 스냅 샷을 캡처하는 것입니다. 나중에 눈을 사로 잡은 것을 찾기 위해 이것들을 잡을 수 있습니다.
lsof > /tmp/lsof.tmp &
ps auxfw > /tmp/ps.tmp &
netstat -anp > /tmp/netstat.tmp &
거기에서 문제 해결은 101이지만 저장된 로그를 grep하는 것이 조금 더 빠르며 로그인 한 상태가 지워지면 계속 진행하거나 변경 사항을 찾으십시오.