Linux 서버를 얼마나 자주 재부팅해야합니까? 데이터를 제공하는 웹 서비스를

대규모 계산 그리드에 데이터를 제공하는 웹 서비스를 실행하는 데 사용되는 많은 Linux 서버 (SUSE 9 & 10)가 있습니다. 최근에 우리는 가동 중단을 설명하기가 어려웠습니다 (예 : 하드웨어 및 소프트웨어 로그에 명백한 오류가 표시되지 않음). 긴 가동 시간 (일반적으로 200-300 일)이 문제인지 궁금해지기 시작했습니다. 이러한 서버를 많이 사용한다고 가정하면 정기적 인 재부팅주기를 고려해야합니까?



답변

KSplice를 사용하지 않는 한 커널 업데이트 후 재부팅해야합니다. 다른 옵션은 선택 사항입니다. 개인적으로 유지 관리 기간 동안 월 단위로 재부팅하여 서버와 모든 서비스가 예상대로 돌아 오도록합니다. 이 방법으로 시스템이 제대로 백업 될 수 있도록 일정이 지난 재부팅 (즉, 중요한 커널 업데이트)을 수행해야한다면 합리적으로 확신 할 수 있습니다. 서버 및 서비스 (예 : Nagios)의 자동 모니터링도이 프로세스를 지원하는 데 먼 길을갑니다 (재부팅, 표시등이 빨간색으로 바뀐 다음 모두 다시 녹색으로 바 watch).

PS 정기적으로 재부팅하는 경우 fsck 검사를 조정해야합니다 (즉, 검사 사이의 최대 마운트 수는 적절하게 검사해야합니다. 그렇지 않으면 서버가 몇 테라 바이트의 데이터를 fsck하기 시작하면 빠른 2 분 재부팅이 30 분이 걸릴 수 있습니다. 필자는 일반적으로 마운트 횟수를 0 (tune2fs -c 0)으로 설정하고 검사 간격을 6 개월 정도로 설정 한 다음 가끔씩 fsck를 수동으로 강제 설정하고 카운트를 재설정합니다.


답변

실제로 주요 구성이 변경 될 때마다 서버를 상당히 정기적으로 재부팅합니다. 비상시 서버 소프트웨어가 번거 로움없이 나타날 것임을 아는 것이 중요합니다. 마지막으로 원하는 것은 중단에서 복구하려고하지만 설정시 철저하게 테스트하지 않았기 때문에 서버 구성을 망쳐 놓아야하는 위치에있는 것입니다.


답변

실행중인 커널 버전 을 절대 변경 하지 않으면 Linux 서버를 다시 부팅 할 필요가 없습니다. 구성 파일을 변경하고 init 스크립트로 서비스를 다시 시작하면 대부분의 문제를 해결할 수 있습니다.

서비스 구성 파일의 변경 사항을 반영하지 않고 “즉석에서”변경 ​​한 내용은 재부팅 후 적용되지 않습니다.

그래도 예약 된 시스템 업데이트 후에 보통 재부팅합니다. 일반적으로 필요하지는 않지만 아무도 사무실에 없을 때 수행합니다. 왜 그렇지 않습니까? 어쨌든 업데이트를 할 때 종종 커널 업그레이드가 있습니다.


답변

실제로 필요하지는 않지만 리눅스 메모리 처리는 훌륭합니다. 그러나 가동 시간이 길면 취약점으로 알려진 커널을 실행하고있을 가능성이 높습니다.


답변

최근 커널 업데이트 또는 libc 업데이트가 있으면 재부팅해야한다고 생각합니다. 많은 것들이 libc와 연결되어 있으며 재부팅하지 않으면 메모리에서 해당 lib를 완전히 언로드하고 새 버전으로 바꿀 수는 없습니다.

예를 들어, / bin / ls와 같은 기본 항목 및 / bin의 다른 항목도 libc를 사용합니다. 콘솔을 실행하고 bash를 사용하는 경우 libc를 사용하는 것입니다.

$ ldd /bin/bash
        linux-gate.so.1 =>  (0xffffe000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
        libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
        libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
        /lib/ld-linux.so.2 (0xb804b000)

$ ldd /bin/ls
        linux-gate.so.1 =>  (0xffffe000)
        librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
        libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
        libc.so.6 => /lib/libc.so.6 (0xb7de7000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
        /lib/ld-linux.so.2 (0xb7f61000)
        libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)

그리고 예, 어떤 식 으로든 시작에 영향을 미치는 /etc/init.d의 파일을 변경하면 재부팅하는 것이 좋습니다. 작업이 필요할 때 다시 시작해야 할 때 시작 파일에서 약간의 실수를했다는 것을 알고 싶지 않습니다.

서버를 재부팅하지 않고 며칠이 지났다면 실제로 서버가 다시 제대로 작동하는지 확인할 방법이 없다는 것을 의미합니다. 다시 한번 이것은 많은 구성 파일이 변경되었을 수 있으며 아무도 그것을 다시 부팅하지 않았기 때문입니다. 또한 서버에 업데이트가 많고 오랫동안 재부팅 하지 않은 경우 업데이트를 적용 하기 전에 재부팅 하십시오. 오래 전에 또는 새로운 업데이트를 적용했습니다.

마지막으로 매우 긴 시간 후에 중요한 서버를 재부팅하는 경우 fsck는 서버가 다시 작동하기 위해 오랜 시간을 기다려야한다는 것을 의미 할 수 있습니다. 이것을 피하기 위해 tune2fs를 사용할 수는 있지만 정기적으로 확인하는 것이 좋습니다. 그렇기 때문에 단 하나의 서버에 의존하는 위치에 있지 않아야하며, 그렇게되면 전체 웹 사이트가 사라집니다. 대기중인 다른 장치가 있어야합니다.


답변

이 예기치 않은 가동 중지 시간이 발생하는 동안 찾아야 할 또 다른 사항은 메모리와 프로세서가 정확히 사용되는 방식과 프로그램이 무엇인지 확인하는 것입니다.
top자원 손실의 원인이되는 프로세스를 파악한 다음 직접 관리 할 수 ​​있어야합니다. 또 다른 아이디어는 특정 일정에 따라 프로세스를 종료하고 다시 시작하기 위해 cronjob을 초기화하는 것입니다.


답변

루트 파티션에서 디스크 검사 (fsck)를 실행할 수있을 정도로 오래 지속 된 경우 재부팅하는 것은 좋지 않습니다. 이것이 데이터 무결성을 보장하는 데 도움이된다고 주장 할 수 있습니다.