얼마전에 노트북 속도가 느려지는 것과 관련해서 진행됐던 삽질 하나 정리해둘까 한다.
■현상
전사 노트북을 64비트 OS로 전환한지 얼마되지 않아서부터 기존의 32비트 OS의 노트북에서 속도가 느려지고, 마우스가 거의 응답을 하지 않는다는 보고가 있었다. 정보를 좀 더 수집해 보고서는 "가끔가다 노트북별로 거의 일정한 시간대"에 이런 현상이 일어난다는 것도 알았다. 처음에는 64비트 OS에 사용했던 표준환경 설정을 그대로 32비트 OS에 적용해서 그 설정 항목중의 하나가 문제인가 하고 지켜보고 있었다.
몇몇 파워 유저들이 "작업 관리자"의 프로세스들을 관찰한 결과, 현상이 발생하는 시점에 "svchost.exe"라는 프로세스가 메모리를 현저히 잡아먹는 다는 것을 관찰했다. 해당 프로세스는 "윈도우 서비스"를 실행하는 프로세스라는 것을 알고 있었다. 하나의 svchost.exe 프로세스에서는 몇 개의 윈도우 서비스가 함께 실행되는데, "작업 관리자"에서 해당 svchost.exe 프로세스를 오른쪽 클릭해서 "서비스로 이동"을 선택하면 해당 프로세스에서 실행되고 있는 윈도우 서비스를 확인할 수 있다. 느려지는 노트북에서 문제의 svchost.exe에 포함된 서비스를 확인해보면 거의 항상 "wuauserv"와 "BITS"라는 이름의 서비스가 포함되어 있다는 것을 확인했다. 이 두 서비스의 설명을 보면 "Windows Update"와 "Background Intelligent Transfer Service"로 되어 있는데,
이것을 보고 노트북이 느려지는 이유가 "윈도우 업데이트 기능"과 관련이 있다는 것으로 짐작을 하게 되었다.
문제는 윈도우 업데이트 모듈 자체의 버그나 기능 오류인가 아니면 업데이트 모듈 자체의 문제라기 보다는 업데이트 정책 또는 설정과 관련된 문제인가. 아니면 노트북에 설치된 노트북 제어용 써드 파티 솔루션중에서 윈도우 업데이트를 사용하는 솔루션의 문제인가를 확인하고 싶었다. 메모리가 사용되는 현상부터 확인해보는 것이 좋을 것 같다는 생각을 했다.
노트북이 느려진다는 complain이 많아졌다. 결국 삽질을 시작하기로 했다.
현상들이 발생할때 svchost.exe 프로세스에서 어떤 모듈들이 관여를 하는지를 알아보고자
해당 현상이 재현되는 노트북을 찾아서 svchost.exe 프로세스의 메모리 덤프를 추출하기 시작했다.
■테스트 과정
메모리 덤프는 몇 가지 상태에서 추출되었다.
1) 처음에는 원래의 문제가 되는 상태에서 덤프가 추출되었고,
2) 다음에는 디버깅의 범위를 좁히기 위해서 윈도우 업데이트 서비스 wuauserv만 별도의 svchost.exe에서 분리해서 이 프로세스의 덤프를 추출했다.
3) 그런 다음 마이크로소프트에서 추천하는대로 "윈도우 업데이트를 reset" 한 후 svchost.exe 프로세스의 덤프를 추출했다.
4) 마지막으로 32비트 OS 환경에서는 윈도우 업데이트 설정을 막아놨다는 것을 알고("업데이트를 확인하지 않음(권장하지 않음)"), 문제의 노트북들중 몇개를 누적된 미 적용 윈도우 업데이트를 모두 적용해 보기로 했다.
미리 말하자면 메모리 분석도 가기전에 결론이 나왔다. 마지막의 누적된 윈도우 업데이트가 노트북의 응답 속도 저하의 원인으로 결론지어졌다. 누적된 윈도우 업데이트를 모두 적용하고, 윈도우 업데이트를 자동으로 수행하도록 설정을 변경하자("업데이트 자동 설치(권장)"), 해당 노트북들에서 응답 속도 문제가 없어졌다.
진정한 삽질이었다.
하여튼 어느정도 확인된 결론은 얻었지만 그렇지만 아직 모든 것이 해결된 것은 아니다. 누적된 업데이트를 모든 32비트 OS의 노트북에 어떻게 적용하는가가 문제였다. 적용을 마치는데 소요되는 시간도 문제이고, 네트워크 대역도 고려해야 했다. 이것은 내부적으로 결정해서 진행하면 되는 문제이다.
■삽질 교훈
마이크로소프트 뿐만 아니라 어도비, 자바 등 많은 제품들은 "자동 업데이트"를 통해서 기존 문제들에 대한 패치를 적용하고자 한다.
해서 사용자들이 업데이트를 막아도 어떻게든 다른 방법들을 통해서 결국은 업데이트를 할 수 있도록 하는 듯한 인상이다. 모든 업데이트 경로가 막히면 결국에는 이 소프웨어들은 투덜대면서 부작용이 생기게 되는 듯 하다.
벤더에서 원한다면 자동 업데이트를 허용하는 것은 쉬운 일이다. 문제는 자동 업데이트를 허용함으로써 발생하는 문제에 대해서 적극적인 벤더들의 대응이 없다는 것이다.
잘 돌아가던 시스템이 업데이트 후에 돌아가지 않게 되면, 사용자 입장에서는 최소한 업데이트 이슈에 대한 대응을 할 수 있는 창구하나 쯤은 열어두고 귀를 귀울여 주기를 바라는 마음이 간절하다. 많은 벤더들은 이슈가 발생한 사람들끼리 서로 서로 논의해서 해결해 나가고 있는 과정을 지켜 보고만 있다는 인상을 지울 수 없다.
UPDATE 2016.02.15
노트북 성능 저하 문제의 "정확한 이유"가 밝혀진 듯 하다.
Windows Update Client for Windows 7: June 2015
https://support.microsoft.com/ko-kr/kb/3050265
정보 제공 : 전 마이크로소프트 수석대표
이 업데이트 모듈에 포함된 Fixes중에서 아래 fix에 주목하고 있다.
•This update addresses an issue in which system performance can be decreased during scans. This issue has the greatest effect on computers that have a small amount of physical memory. |
이 페이지에서 제공하는 패치의 의미는 이렇다.
윈도우 업데이트 적용은 "업데이트 적용 대상 스캔 후 다운로드,설치" 과정으로 될텐데,
- 누적된 업데이트를 다운로드, 설치하는 과정에서 오류가 있는 것이 아니라.
- 적용 대상 업데이트를 "스캔하는 과정"에서 문제가 있다는 거다.
위 방법은 Windows7, SP1 환경에서 아예 업데이트를 막는 방법인 듯 하다.
처음에 생각한 방법은 아래 두가지였다.
1) 최신의 윈도우 업데이트를 모두 다운로드받아서 offline 상태에서 업데이트를 할 수 있는 방법을 이용하는 것이다.
http://download.wsusoffline.net/
2) 조직의 윈도우 업데이트를 위해서 자체 WSUS 서비스를 구축한다.
https://technet.microsoft.com/ko-kr/library/hh852340.aspx
위 두 방법 모두 "다운로드 및 설치"하는 과정에 문제가 있을 것이라고 생각해서 나온 해결책이었다.
UPDATE 2016.02.16
위 업데이트 버전보다 최신 버전이 있다. 아래 업데이트는 위의 업데이트를 대체한다고 한다.
Windows Update Client for Windows 7 and Windows Server 2008 R2: July 2015
https://support.microsoft.com/en-us/kb/3065987
UPDATE 2016.02.16
윈도우 업데이트 에이전트는 계속 업데이트되고 있다.
이제는 2015 10월달에 릴리스된 버전도 있다.
Windows Update Client for Windows 7 and Windows Server 2008 R2: October 2015
https://support.microsoft.com/en-us/kb/3083710
계속 업데이트되면 자동으로 에이전트를 업데이트해줄 수 있는 방법이 필요하다.
검색을 해 봤더니 아래와 같은 결과가 나온다.
How to update the Windows Update Agent to the latest version
https://support.microsoft.com/en-us/kb/949104
이 페지이의 "Download the Windows Update Agent automatically"을 읽어보니 "자동 업데이트가 on 되어 있고, 원래 윈도우 업데이트 서비스가 정상적으로 수행된다면 항상 최신 버전의 윈도우 업데이트 에이전트도 자동으로 컴퓨터에 설치된다"는 것이다.
그럼 어떻게 하자는 거야. 윈도우 업데이트에 문제가 있는 노트북만 최신 버전의 에이전트를 다운로드받아서 수동으로 설치하라는 건가? 그런건가?