스케줄에 따라 서버를 재부팅하는 것이 성능에 좋을까요?

일정에 따라 서버를 재부팅하는 것이 성능에 좋은 아이디어인지 궁금합니다.

2 박에 02:00 AM에 서버를 재부팅한다고 가정 해 봅시다.

여기 서버는 Windows Server 2008 R2입니다. 주로이 서버에서 SQL Server 및 IIS 7.5 (약 15 개의 앱이 실행 중)가 실행되고 있습니다. 서버에 4GB 메모리가 있습니다.

SQL Server 에이전트가 중지되고 있다는 의견에 따라 상자를 다시 부팅해도 아무런 문제가 없다는 데 동의하지만 추가 근본 원인 분석을 권합니다. 서비스는 일반적으로 중단되지 않으며 SQL Server 에이전트 서비스는 일반적으로 저의 경험으로는 그렇게하지 않았습니다.

재부팅 외에는 이벤트 로그를 검사하고 PAL ( Performance Analysis of Logs )로 분석하여 잘못된 내용이 있는지 확인하는 장기 성능 카운터 로그를 실행하는 것이 좋습니다 . 다른 요소가 없으면 SQL 에이전트 중지와 관련된 이벤트를 상관 시키도록 시도해야합니다.

성능을 향상시키기 위해 컴퓨터를 재부팅하려는 경우 아마도 메모리 관리 문제가 발생했을 수 있습니다.

캐싱이 좋다

무엇보다 서버를 재부팅하면보다 이상적인 환경 에서 성능과 가동 시간이 저하 될 수 있습니다 . 컴퓨팅 성능의 기본 중 하나는 캐싱 (고속 메모리에서 데이터를 사용할 수 있음)을 활용하는 것입니다. 재부팅 할 때마다 캐시가 사라집니다. 이것은 SQL 서버와 IIS 모두에 해당됩니다. 이상적인 환경이 아닐 수 있지만 다음은 스케줄에 따라 서버를 재부팅하는 것보다 더 나은 옵션을 안내하는 데 도움이됩니다.

IIS 메모리 누수?

이제 이것이 IIS 7.5라고 언급했습니다. IIS 7.5에서 실행되는 많은 웹 응용 프로그램에는 메모리 누수가 발생하여 IIS의 기본값은 X 분마다 APP를 다시 시작하고 APP 풀이 유휴 상태이면 종료하는 것입니다. 메모리 누수를 해결하는 것이 이상적입니다. 그러나 메모리 누수 와 타이머를 포함 하여 이러한 설정 을 조정할 수없는 경우가 있습니다 . perfmon을 사용하여 메모리를 사용하는 w3wp 프로세스를 파악할 수 있습니다. 약간의 고통이지만 앱 풀로 다시 묶을 수 있습니다 %systemroot%\system32\inetsrv\APPCMD list wps.

SQL 메모리

캐싱으로 돌아 가면 SQL은 가능한 메모리를 사용합니다. SQL Server의 속성에서이를 제한 할 수 있습니다. 메모리를 제한하지 않고 상자에서 IIS를 실행하는 경우 메모리 킬링 성능을 위해 전투를 시작할 수 있습니다. 이 훌륭한 기사는이 내용을 자세히 설명합니다. Microsoft SQL 메모리에 대한 Sysadmin 안내서 .

균형

같은 상자에 IIS와 SQL이 모두 있으므로 메모리 사용량의 균형을 유지해야합니다. 그렇지 않으면 디스크로 다시 스왑 아웃 될 수있는 메모리를 얻을 수 있습니다. 이곳은 끔찍한 곳입니다 (스왑 활동에는 perfmon 카운터가 있어야 함). IIS 재활용 설정과 SQL 메모리 제한을 사용하면이 시스템을 안정적으로 만들 수 있습니다. 이 균형을 맞추려면 4GB보다 많은 메모리가 필요할 수 있습니다. 또한 옵션 인 경우 SQL Server를 전용 컴퓨터에 배치하는 것이 좋습니다. 성능을 훨씬 향상시키고 작업을 크게 단순화 할 것입니다.

나는 일정에 따라 서버를 재부팅하는 것을지지하지 않으며, 특히 근본적인 문제를 해결하는 수단이 아닙니다. 성능 문제를 해결하기 위해이 서버를 재부팅해야하는 경우 더 나은 조치는 문제의 원인을 찾아서 해결하는 것입니다. 정기적 인 일정으로 서버를 재부팅하면 근본적인 문제가 난독 화됩니다.

상당한 메모리 누수가 발생했다면 확실하지 않습니다. 그렇지 않으면 매월 업데이트로 재부팅하십시오.

위에서 언급 한 메모리 누수 또는 업데이트 또는 기타 이유로 인해 일정대로 서버를 재부팅하려는 경우 클러스터 솔루션을 보지 않겠습니까? 다른 서버를 병렬로 배치하고로드 밸런서에 연결하면 (간단한 서버도 가능) 서비스 가동 시간을 잃거나 서버가 전혀 부팅되지 않을까 걱정하지 않고 원하는만큼 재부팅 할 수 있습니다. 넌 나갈거야

그것은 끔찍한 생각은 아니지만 단지 '부두'라면 아마 당신에게별로 도움이되지 않을 것입니다.

그러나 이것이 성과 향상에 대한 조사가 끝나지 않게하는 두 가지 이유가 있습니다.

하나는 미래의 확장 성입니다. 중단으로 인해로드, 특정 수의 쿼리, 캐싱, 쿼리 컴파일 또는 btree 인덱싱 버그에 부딪 치는 특정 쿼리 또는 현재 매일 발생하는 기타 문제의 결과로로드가 자주 발생할 수 있습니다. 시간이 지남에 따라 증가합니다. 새싹에 Ni.

다른 문제는 다시 시작하는 동안 종속 서비스에서 들어오는 요청을 중단해야한다고 생각합니다. 방금 운영 케이던스를 만들었습니다. 매일의 일부 작업을 실행해야 할 때마다 다시 시작해야합니다. 어느 시점에서 6 시간이 걸리는 대규모 롤링 재시작이있을 것입니다 (여기서는 과장하지 않습니다. 여러 회사에서 발생하는 것을 보았습니다). 왜 중간에 모든 것을 중지하고 다시 시작해야하는지 아무도 기억하지 못합니다 밤.

SQL 프로세스를 모니터링하고 필요에 따라 다시 시작하는 것이 좋습니다. 이전 포스터에서 언급했듯이 SQL에는 사람들이 생각하는 메모리 누수가 없습니다 (90 년대 중반 MSSQL 팀에 속한 사람이라고 말합니다). 당신은 원하는 데이터베이스 서버가 거의 100 %의 메모리와 CPU를 사용합니다. 적은 것은 자원 낭비입니다.

코드를 잘못 작성하고 메모리 누수가 발생한 경우 다시 부팅하는 것이 할당 된 메모리를 다시 풀로 되 돌리는 유일한 방법 일 수 있습니다. 메모리 바인딩 프로세스가있는 경우 풀을 새로 고친 상태로 새로 고치면 성능이 확실히 향상 될 수 있습니다. 그러나 이것은 실제로 성능 문제를 처리하는 나쁜 방법이므로 실제 원인을 수정하고 수정해야합니다.

그렇지 않으면 패치 / 응용 프로그램 / 복원 데이터를 적용하기 위해 유지 관리 기간이 필요할 때까지 실행하십시오. 성능 엔지니어가 문제가 발생한 서버를 정확히 왜 / 어떤 문제가 발생하는지 살펴 보라고 제안하기에 좋은시기입니다.

완전한 대답 은 아니지만 서버에 RAM을 더 추가하는 것이 가능한 옵션입니까? 4GB는 IIS / SQL Server 시스템의 낮은 편입니다. 실제로 전용 서버 장치인지 또는 서비스를 제공하는 데스크탑인지에 따라 상당히 저렴한 비용으로 8GB 이상을 얻을 수 있습니다. 서버 인 경우 표준 데스크톱 RAM보다 약간 더 비쌀 수 있지만 강제 재부팅 사이에는 시간이 조금 더 걸립니다.

즉, SQL Server가 RAM의 최대 80 %를 사용하도록 제한 할 수 있는지 확인하거나, 무엇이 잘못되고 있는지 및 / 또는 서비스가 중지되는 이유를 정확하게 파악하기 위해 로그를 살펴보십시오.

Windows 서버가 있고 어떤 종류의 패칭 루틴을 따르는 경우 처리 할 수있는 SQL 문제와 관련이 없으며 "이유로"재부팅하지 않아도 정기적으로 서버를 재부팅합니다. "BIG MULTINATIONAL"에서 일할 때 우리는 매월 패치해야했고, 따라서 모든 서버는 적어도 한 달에 한 번씩 월 단위로 재부팅되었습니다.

3 서버 에서이 작업을 수행하고 있으며 1은 2 명의 고객입니다. 여러 가지 이유로 설정했습니다. 하나의 서버 2008R1에 설치 대기중인 많은 업데이트가 있지만 배치 설치를 할 수 없으므로 매일 하나씩 설치해야합니다. 다른 서버 2012R2-부팅 문제 해결 및 일부 성능 문제 등 다른 하드에서 정기적으로 재부팅을 예약하는 것은 나쁜 습관이라고 생각하지 않습니다. 다양한 하드웨어 및 소프트웨어 문제, 특히 자동 시작과 관련된 문제를 추적하는 데 도움이 될 수 있습니다 .

Windows 서버를 매일 밤 재부팅하는 대기업을 알고 있지만 24 시간마다 다시 설치하는 회사도 있습니다. 그들에게는 소프트웨어 및 보안 문제에 메모리가 부족하기 때문에 필요합니다.

일부 회사는 24 시간마다 재부팅하는 것처럼 보입니다. 리눅스 관리자에게는 이상해 보입니다. 분명히하기 위해 : 메모리 문제로 인해이 작업을 수행하지 않는 것이 좋습니다. 문제를 추적하고 해결하십시오.

메모리 사용량이 몇 달 동안 75 %로 고정 된 경우 다시 부팅 할 필요가 없습니다. 서버 응용 프로그램에서 사용 가능한 모든 메모리를 사용하는 것이 정상입니다. 데이터를 캐시하는 RAM.