합동회사 코무라소프트
문의하기
메뉴

디스크 사용률 100%는 무엇을 멈추면 해결될까 ── SysMain·Windows Search·Defender 구분법

· 업데이트: · · Windows 11, 성능, 장애 조사, SysMain, Windows Search, Microsoft Defender, PowerShell

작업 관리자를 열었더니 디스크가 100%. 앱을 여는 것도, 글자를 입력하는 것도 느립니다. 이때 「SysMain을 사용 안 함」「Windows Search를 중지」「Defender를 끔」 같은 대책을 발견하면, 일단 전부 멈추고 싶어집니다.

하지만 여기에서 나누고 싶은 것은 「무엇이 읽고 쓰고 있는가」와 「왜 조작이 기다려지는가」입니다. 작업 관리자 상위에 뜬 이름만으로는 그 구분이 되지 않습니다.

이 글은 Windows 11 PC를 쓰는 일반 사용자를 주된 대상으로, 표시를 읽는 법, 세 기능의 역할, 설정을 되돌릴 수 있는 조사 절차를 설명합니다. 화면 이름과 사용할 수 있는 기능은 Windows의 빌드와 관리 정책에 따라 다릅니다. 관리자용 조작은 명시합니다. 출처는 2026년 9월 5일에 확인한 Microsoft의 1차 자료입니다. 특정 실제 장비에서 개선율을 측정한 글은 아닙니다.

1. 먼저 결론: 세 가지를 똑같이 멈추지 않습니다

이 글에서 권하는 순서는 관찰 → 대상 좁히기 → 하나만 변경 → 원래대로 되돌려 비교입니다. 중요한 파일을 저장하고, 회사가 관리하는 PC라면 설정을 바꾸기 전에 관리자에게 문의하십시오.

기능 먼저 무엇을 보는가 처음에 검토할 것
SysMain 문제가 난 시간대에 그 서비스와의 관련이 있는지 보통은 유지. 근거가 있을 때만 일시 중지와 다시 시작을 비교
Windows Search 인덱스의 진행 상황과 검색 대상 검색하지 않는 폴더가 들어가 있지 않은지 재검토
Microsoft Defender Antivirus 검사와 느린 조작이 겹치는지 보호를 유지한 채 기록·분석

이 표는 단순히 중지의 위험도를 늘어놓은 것이 아닙니다. SysMain은 시스템 성능의 유지·개선, Search는 검색을 위한 인덱스 작성, Defender는 맬웨어 대책이라는 서로 다른 역할을 가집니다. 잃게 되는 기능도 각각 다릅니다.123

디스크 100%를 조사하는 기본 순서디스크 100%를 보면 느린 조작과 대상을 관찰하고, 하나의 변경만 비교한 뒤 되돌리는 순서를 나타냅니다.디스크 100%와 조작의 느림시간대와 대상을 기록하나의 가설을 시험원래대로 되돌려 재확인필요한 대책만 남김

그림 1: 설정을 한꺼번에 바꾸기 전에, 비교할 수 있는 상태를 만듭니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 13건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 100%는 「용량이 가득 참」도 「최고 속도」도 아닙니다

작업 관리자의 「성능」에서 대상 디스크를 열면 활성 시간, 읽기·쓰기 속도, 평균 응답 시간을 확인할 수 있습니다. 바빴던 시간의 비율과, 실제로 옮긴 데이터 양은 다른 것입니다. 여유 용량이 부족한지 여부도 따로 확인해야 합니다.

예를 들어 처리 한 건 한 건에 대기 시간이 걸리면, 계속해서 일을 하고 있어도 진행되는 데이터 양은 적어집니다. 이는 「큰 상자를 한꺼번에 옮기는 것」과 「작은 상자를 하나씩 건네는 것」의 차이와 비슷합니다. 잘게 쪼개진 읽기·쓰기나 스토리지 쪽의 지연이 있으면, 적은 MB/s로도 100% 근처가 될 수 있습니다. Microsoft의 성능 조사 자료에서도 전송량뿐 아니라 I/O의 응답 시간을 확인합니다.4

따라서 「100%이니 SSD의 속도를 다 쓰고 있다」와 「몇 MB/s이니 디스크는 원인이 아니다」는 둘 다 성급합니다. 먼저 문제가 일어나고 있는 디스크 번호와 드라이브 문자를 함께 봅니다. C:와 D:가 같은 물리 디스크에 있다면, D:에 대한 작업이 C: 쪽 조작과 경합할 가능성도 있습니다.

디스크를 보는 세 가지 지표활성 시간, 전송 속도, 응답 시간은 서로 다른 지표이며, 같은 시간대에 함께 보아야 함을 나타냅니다.같은 시간대를 관찰바쁨: 활성 시간처리량: 읽기·쓰기 속도대기: 응답 시간조작의 느림과 대조

그림 2: 퍼센트만으로는 처리량이 많은 것인지, 대기 시간이 긴 것인지 구별할 수 없습니다.

3. 첫 관찰: 언제, 어느 파일에서 느려지는가

처음부터 서비스를 멈추지 말고 Ctrl + Shift + Esc로 작업 관리자를 엽니다. 「프로세스」의 디스크 열을 정렬하고, 동시에 「성능」에서 해당 디스크를 확인합니다. 이어서 Win + R에서 resmon.exe를 실행해, 리소스 모니터의 「디스크」에서 프로세스 이름·파일·읽기·쓰기·응답 시간을 봅니다. 표시할 수 있는 정보가 부족하면 관리자에게 조사를 요청하십시오.5

기록은 「부팅 후 3분」「ZIP을 푸는 동안」「동기화가 끝날 때까지」처럼 작업과 연결합니다. 화면의 한순간만이 아니라, 느려지기 전·느린 동안·돌아온 뒤를 비교하는 것이 이 글에서 권하는 방법입니다. 업데이트나 복사가 진행 중이라 완료 후에 가라앉는 상태와, 같은 작은 조작에서 매번 오래 멈추는 상태는 다음에 조사할 것이 다릅니다.

참고로 응답 시간의 평균은 개별 조작의 최악값 그 자체가 아닙니다. 한 번 나온 높은 숫자만으로 고장이라고 단정하지 말고, 재현되는 멈춤이나 오류와 대조합니다. System이나 svchost.exe가 상위에 있어도 이름만 보고 강제 종료하지 마십시오. System에는 커널이나 드라이버의 처리도 관계합니다.4

조사에 남길 관찰 기록느려진 시각과 조작을 기점으로 디스크, 프로세스, 파일, 회복된 조건을 기록합니다.느린 조작과 시각해당 디스크를 확인프로세스와 파일을 봄끝난 뒤에도 관찰회복된 조건을 기록

그림 3: 「무거웠다」만이 아니라, 재현에 쓸 수 있는 기록을 남깁니다.

4. 이름이 보인 것과, 그것이 근본 원인인 것은 다릅니다

파일을 대량으로 만드는 앱이 돌면, 그 앱의 쓰기뿐 아니라 검색 인덱스의 갱신이나 보안 검사가 겹치는 경우가 있습니다. Search는 파일의 정보를 검색용으로 인덱싱하고, Defender는 파일이나 처리에 대한 검사를 수행합니다.26

여기서부터는 원인을 생각하기 위한 예입니다. 압축 해제 프로그램이 대량의 파일을 만드는 도중에 Defender의 부하가 늘었다고 해서, 「Defender만 잘못되었다」고 할 수는 없습니다. 파일 생성의 빈도, 대상 폴더, 스토리지의 응답이 함께 작용하고 있을 가능성이 있습니다.

반대로 정규 Windows 기능이니 무관하다고 단정하는 것도 잘못입니다. 필요한 기능이라도 실제 환경에서는 경합 요인이 될 수 있습니다. 알고 싶은 것은 선악이 아니라, 어떤 처리를 얼마나 줄이면 필요한 작업이 개선되는가입니다.

한 작업에서 여러 읽기·쓰기가 생기는 예대량의 파일 생성에, 검색 대상이면 인덱스 갱신이, 보호 대상이면 검사가 겹칠 가능성을 나타냅니다.대량의 파일 생성앱 자신의 쓰기검색 대상이면 인덱스 갱신보호 대상이면 검사같은 저장 위치에서 경합할 수 있음

그림 4: 점선의 처리가 매번 반드시 발생한다는 뜻이 아니라, 조사할 후보의 관계입니다.

5. SysMain: 먼저 유지하고, 의심이 있을 때만 일시 비교

SysMain은 Microsoft의 서비스 목록에서 시스템 성능의 유지·개선을 목적으로 하는 서비스입니다. 그 자료에서는 사용 안 함으로 두지 않는 분류에 들어 있습니다. 다만 자료의 대상은 Windows IoT Enterprise이며, 「일반 Windows 11 PC 전부에서 반드시 빨라진다」는 실측 보증은 아닙니다.1

이 글에서는 디스크 100%라는 표시만을 근거로 시작 유형을 「사용 안 함」으로 바꾸는 것을 권하지 않습니다. 중지 직후에 숫자가 내려가도, 단지 백그라운드의 일이 줄었을 뿐일 수 있습니다. 앱을 여는 시간이나 평소 작업이 개선되었는지까지 봅니다.

작업 관리자에서 서비스 호스트 그룹을 펼쳐 관련을 확인하고, SysMain을 의심할 재료를 얻은 경우에 한해 관리자로서 짧은 시간의 비교를 합니다. 중지 전에 services.msc에서 SysMain의 상태와 시작 유형을 기록해 두십시오. 서비스의 일시 중지와, 다음부터도 시작되지 않게 하는 설정은 별개의 조작입니다.78

SysMain의 일시 비교와 영구적인 사용 안 함의 차이이번 조사에서는 실행 중인 서비스를 일시 중지했다가 되돌리며, 시작 설정의 영구 변경과는 나누어 다룹니다.SysMain과의 관련을 확인원래 상태를 기록실행 중이면 일시 중지같은 조작을 비교다시 시작해 확인시작 설정은 변경하지 않음

그림 5: 「멈춰서 차이를 본다」와 「계속 사용 안 함으로 둔다」를 혼동하지 않도록 합니다.

관리자용: 90초의 비교와 복귀를 하나의 처리로 만들기

다음은 관리자로 연 Windows PowerShell 5.1에서 블록 전체를 실행하는 예입니다. 원래 실행 중이던 SysMain만을 대상으로 하고, 중지 후 90초 동안 다른 창에서 같은 작업을 시험합니다. 시작 유형은 변경하지 않습니다.

# 관리자의 Windows PowerShell 5.1에서 블록 전체를 실행한다.
$service = Get-Service -Name SysMain -ErrorAction Stop
if ($service.Status -ne 'Running') {
    throw 'SysMain은 실행 중이 아닙니다. 현재 설정을 바꾸지 않고 종료합니다.'
}

try {
    Stop-Service -Name SysMain -ErrorAction Stop
    $service.WaitForStatus('Stopped', [TimeSpan]::FromSeconds(30))
    Write-Host '90초 동안 다른 창에서 같은 조작을 비교하십시오.'
    Start-Sleep -Seconds 90
}
finally {
    Start-Service -Name SysMain -ErrorAction Stop
    $service.WaitForStatus('Running', [TimeSpan]::FromSeconds(30))
    Get-Service -Name SysMain | Select-Object Name, Status
}

finally는 정상 종료나 예외 시에 복귀를 시도하기 위한 것입니다. PowerShell 창을 강제로 닫거나, 프로세스를 종료하거나, 전원이 꺼지는 경우까지 복귀를 보증하지는 않습니다. 도중에 중단되었다면 services.msc에서 상태를 확인하고, 이 절차로 멈춘 SysMain이 중지된 채라면 시작하십시오. 복귀에 실패한 경우에도 그대로 두지 말고 관리자에게 문의합니다.9

일시 중지 시험을 끝낼 때의 확인보통은 finally에서 다시 시작을 시도하고, 강제 종료나 재시작 실패 뒤에는 서비스 화면에서 상태를 확인합니다.예아니오비교를 종료다시 시작을 확인했는가원래 상태에서 재비교서비스 화면에서 확인시작하거나 관리자에게 문의

그림 6: 자동으로 되돌리는 코드가 있어도, 마지막 상태 확인을 생략하지 마십시오.

6. Windows Search: 멈추기 전에 「무엇을 검색하고 싶은가」를 재검토

Windows Search의 인덱스는 파일 이름이나 내용 등을 빠르게 찾기 위한 구조입니다. 인덱스를 만들거나 갱신하는 동안에는 일이 발생하지만, 이는 검색을 빠르게 하기 위한 준비이기도 합니다.2

Windows 11에서는 「설정」→「개인 정보 및 보안」→「Windows 검색」을 열어 인덱스의 진행 상황과 검색 범위를 확인합니다. 표시 이름이 다르면 설정 안에서 「인덱스」를 검색하십시오. 쓰지 않는 대량의 파일이 대상이라면 「제외된 폴더」나 「인덱싱 옵션」의 「수정」에서 범위를 좁힐 수 있습니다.10

예를 들어 개발용 PC의 node_modules나 빌드 산출물은, Windows의 검색으로 찾을 필요가 없다면 재검토 후보입니다. 다만 이는 폴더 이름만으로 일률적으로 빼라는 권고가 아닙니다. 검색에서 뺀 위치의 내용이 예전처럼 검색되지 않아도 곤란하지 않은지를 먼저 생각합니다. 변경 전의 범위를 기록해 두면, 검색에 지장이 생겼을 때 되돌릴 수 있습니다.

여기에서 말하는 「검색 대상에서 제외」는 뒤에 나오는 「Defender의 보호 대상에서 제외」와는 별개입니다. 양쪽 설정을 한꺼번에 변경하지 마십시오.113

검색 범위를 좁히는 판단인덱스 대상 폴더를 확인하고, 그 위치를 Windows 검색에서 쓸 필요가 있는지에 따라 대상을 재검토합니다.필요불필요인덱스 대상 위치를 확인검색에서 필요한 위치인가대상을 유지기록하고 검색 대상을 재검토부하와 검색 결과를 확인

그림 7: 검색 기능 전체를 멈추기 전에, 준비할 정보의 양을 줄일 수 없는지 생각합니다.

다시 작성을 「일단 누르는 복구 버튼」으로 삼지 않습니다

인덱스 다시 작성은 인덱스를 새로 만드는 조작입니다. 이미 작성 중이라면 그 일을 한 번 더 시작하는 셈입니다. Microsoft는 다시 작성에 최대 24시간 정도를 예상하는 안내를 하고 있으며, 작성 중에는 검색 결과가 불완전할 수 있습니다.10

따라서 디스크가 바쁘다는 이유만으로 몇 번씩 다시 작성하는 것은 권하지 않습니다. 먼저 진행 상황과 오류를 확인하고, 대상 범위를 조정한 뒤나 검색 결과에 문제가 있는 등 다시 작성이 필요한 경우에 실행합니다. 실행했다면 전원에 연결하고 작업이 끝날 수 있는 시간을 확보하며, 다시 작성 중의 부하를 정상 상태의 부하와 구분합니다.

인덱스 다시 작성 중과 완료 후를 나눈다다시 작성에서는 새로 만드는 부하와 일시적인 검색 결과의 부족이 있으며, 효과는 완료 후에 판단합니다.필요성을 확인하고 다시 작성인덱스를 새로 만드는 기간완료를 기다림검색 결과와 부하를 확인

그림 8: 다시 작성을 시작한 직후의 바쁨만으로 대책의 성패를 판단하지 않습니다.

7. Defender: 보호를 끄지 말고 「무엇을 검사하고 있는지」를 조사

Antimalware Service Executable이나 MsMpEng.exe가 눈에 띄더라도, 일상적인 속도 개선책으로 실시간 보호를 끄는 것은 권하지 않습니다. 보호를 사용하지 않는 동안에는 연 파일이나 다운로드한 파일을 평소대로 검사할 수 없게 됩니다. 디스크의 숫자가 내려가도 필요한 기능을 잃었다면, 같은 조건에서 빨라졌다고 할 수 없습니다.3

조사에 쓸 수 있는 것이 Microsoft Defender Antivirus의 성능 분석기입니다. 검사를 기록해, 검사에 시간이 걸린 파일이나 관련 프로세스를 보고서로 만듭니다. 이는 PC 전체의 디스크 지연을 모두 재는 도구가 아닙니다. 리소스 모니터에서 본 느린 시간대와 조합해, Defender의 검사가 관계하는지를 조사하는 용도입니다.6

Defender의 부하를 보호한 채 조사한다실시간 보호를 유지하면서 느린 조작을 기록하고, 검사 보고서와 조작 시간을 대조합니다.실시간 보호를 유지느린 조작을 기록검사 시간의 보고서실제 대기 시간과 대조파일 생성 등도 조사

그림 9: 보안 기능을 없애 숫자를 낮추는 것이 아니라, 부하의 내용을 봅니다.

관리자용: 기록을 남기고 상위 항목을 본다

공식 전제는 Windows 10 이상, Defender 플랫폼 4.18.2108.X 이상입니다. 관리자 권한이 필요합니다. 다른 보안 제품을 쓰고 있거나, 조직 관리로 기능을 제한하고 있는 경우에는 이 절차를 무리하게 적용하지 말고 관리자나 제품 창구에 확인합니다.12

다음은 관리자로 연 Windows PowerShell 5.1에서 실행합니다. 기록을 시작하면 다른 창에서 문제의 조작을 재현하고, 기록 쪽의 안내에 따라 Enter로 종료합니다. 일상적인 문제라면 짧은 재현 구간으로 좁히고, 오래 기록을 계속하지 않도록 합니다.6

# 관리자의 Windows PowerShell 5.1에서 실행한다.
Get-Command New-MpPerformanceRecording, Get-MpPerformanceReport -ErrorAction Stop |
    Select-Object Name, Source

# 기존 기록을 덮어쓰지 않도록 고유한 이름을 쓴다.
$trace = Join-Path $env:TEMP ('Defender-' + [guid]::NewGuid().ToString('N') + '.etl')
Write-Host "기록 위치: $trace"
New-MpPerformanceRecording -RecordTo $trace -ErrorAction Stop

# 기록을 끝낸 뒤에 보고서를 읽는다.
Get-MpPerformanceReport -Path $trace -TopFiles 10 -TopProcesses 10 -ErrorAction Stop

여기에서 상위에 나오는 것은 기록한 구간의 검사에 미친 영향이 컸던 항목입니다. 「상위 10건을 제외하면 안전하게 빨라진다」는 뜻이 아닙니다. Microsoft도 이 분석기를 제외 설정의 제안 도구로 자리매김하지 않습니다.12

먼저 그 파일을 무엇이 몇 번이고 다시 만들고 있는지, 같은 작업이 중복되고 있지 않은지, 앱 쪽에서 조정할 수 없는지를 조사합니다. 제외가 정말 필요하다면, 영향 범위와 보호의 저하를 이해한 관리자가 개별적으로 판단합니다. C: 전체나 사용자 프로필 전체를 이 글의 절차만으로 제외하지 마십시오. 기록에는 파일 경로나 프로세스 정보가 들어가므로, 외부에 넘기기 전에는 기밀 정보의 취급도 확인합니다.

분석 보고서에서 조사하는 순서검사 부하의 상위 항목은 조사의 입구이며, 생성원과 빈도를 확인한 뒤에 대책을 생각합니다.보고서 상위의 항목생성원과 빈도를 확인앱 쪽의 개선을 검토필요하면 관리자와 개별 판단그대로 제외 목록으로 삼지 않음

그림 10: 보고서는 원인 조사의 재료이지, 보호를 풀어도 되는 파일의 목록이 아닙니다.

8. 세 가지 외에도 봅니다: 메모리와 스토리지의 상태

앱을 여러 개 열었을 때 느려진다면 작업 관리자의 메모리도 확인합니다. 메모리에 없는 페이지를 스토리지에서 다시 읽어 오는 「하드 폴트」가 늘어날 수 있지만, 이것이 디스크의 물리적 고장을 뜻하지는 않습니다. 다시 읽어 오는 원본은 페이지 파일만이 아니라 실행 파일이나 메모리 매핑 파일인 경우도 있습니다. 값이 나왔다는 것만으로 메모리 부족이라고 단정할 수도 없습니다.13

「필요 없는 앱을 닫으면 디스크의 대기와 조작이 함께 개선되는가」는 비교할 가치가 있습니다. 한편 페이지 파일을 사용하지 않게 해서 읽기·쓰기를 없애는 방법은 권하지 않습니다. 커밋할 수 있는 메모리의 상한을 낮춰, 다른 실패나 불안정을 부를 수 있습니다.14

하드 폴트를 읽는 법하드 폴트는 메모리에 없는 페이지를 디스크에서 읽는 처리이며, 물리적 고장이나 메모리 부족 자체를 단정하는 지표가 아닙니다.필요한 페이지가 메모리에 없음파일에서 다시 읽음디스크 I/O가 발생메모리 사용량과 조작을 비교물리적 고장이라는 뜻이 아님

그림 11: 「하드 폴트」라는 이름만으로 고장이나 페이지 파일의 문제라고 단정하지 않습니다.

또한 읽기·쓰기 오류나 스토리지의 심각한 경고, 갑작스러운 연결 끊김이 있다면, 서비스를 조정하기보다 중요한 데이터의 백업을 우선합니다. Windows의 스토리지 경고에 대해서도 Microsoft는 백업을 먼저 안내합니다. 경고가 보이지 않는다는 것만으로 모든 디스크가 정상이라고 보장되지는 않습니다.15

백업 후에 PC나 스토리지 제조사가 제공하는 진단, 해당 기종에 맞는 드라이버·펌웨어 정보를 확인합니다. 오래된 글에 있는 레지스트리 일괄 변경을, 기종이나 적용 조건을 확인하지 않고 시험하는 순서로는 하지 않습니다. 예를 들어 Microsoft의 SysMain 관련 알려진 문제에도, 대상이 Windows 7의 특정 조건으로 한정된 것이 있습니다. 자료의 갱신일만으로는 현재의 Windows 11에 적용할 수 있다고 판단할 수 없습니다.16

스토리지 경고가 있을 때의 우선순위심각한 경고나 읽기·쓰기 오류가 있을 때는 설정 최적화가 아니라 백업과 기종에 맞는 진단을 우선합니다.경고나 읽기·쓰기 오류중요 데이터를 백업제조사의 진단을 확인적용 조건을 보고 수리나 대책

그림 12: 고장의 징후가 있을 때는 퍼센트를 낮추는 것보다 데이터를 지키는 것이 먼저입니다.

9. 「해결됐다」는 퍼센트가 아니라 원래의 작업으로 판정합니다

대책의 성패는 원래 곤란했던 조작으로 확인합니다. 「앱 실행이 기다려지지 않는다」「복사가 정상적으로 끝난다」「글자 입력이 걸리지 않는다」는 결과를 변경 전과 비교합니다. 디스크 100%가 짧아져도, 검색 결과가 갱신되지 않거나 보호가 멈춘 채라면 완료로 삼지 않습니다.

비교에서는 같은 조작·같은 저장 위치·되도록 같은 백그라운드 상태를 맞춥니다. SysMain 같은 일시 비교라면 원래 상태→중지 중→원래 상태의 순서로 확인하면, 시간이 지나서 일이 끝났을 가능성을 알아채기 쉬워집니다. 다만 두 번째는 캐시가 듣는 등의 차이도 있으므로, 한 번의 비교로 인과 관계를 증명했다고 다루지는 않습니다.

이는 이 글에서 제안하는 조사의 사고방식입니다. 숫자를 낮추는 설정을 모으기보다, 어떤 변경이 필요한 기능을 지킨 채 원래의 조작을 개선했는지를 기록해 두는 편이 재발했을 때에도 도움이 됩니다.

대책 완료의 판단원래의 조작이 개선된 것에 더해, 검색·보호·서비스의 상태를 확인하고 대책을 완료합니다.원래의 조작을 다시 실행대기 시간이 개선되었는가검색과 보호는 유지되었는가일시 변경을 되돌렸는가조건과 결과를 기록하고 완료

그림 13: 디스크의 숫자가 아니라, 필요한 일과 기능이 함께 회복되었는지로 판정합니다.

정리

디스크 100%에 대해 SysMain·Windows Search·Defender를 한꺼번에 멈추는 만능 절차는 없습니다. 먼저 시간대, 대상 디스크, 파일, 응답 시간을 확인합니다. 그 위에서 SysMain은 필요한 경우에만 일시 비교, Search는 검색 범위를 재검토, Defender는 보호를 유지한 채 분석한다는 구분이 출발점이 됩니다.

업무용 Windows 앱에서 「특정 조작만 느리다」「현장의 PC만 멈춘다」 같은 문제가 계속된다면, 코무라소프트의 기술 상담에서도 상담할 수 있습니다. 발생 시각, 재현 조작, 대상 파일의 종류, 변경 전후의 기록이 있으면 조사의 입구를 구체적으로 만들 수 있습니다. 로그나 기록을 공유할 때는 기밀 정보가 포함되어 있지 않은지 확인하십시오.

참고 링크

  1. Microsoft Learn, Guidance on configuring system services. SysMain의 역할과 서비스를 사용 안 함으로 둘 때의 주의. 적용 대상은 Windows IoT Enterprise입니다. ↩ ↩2

  2. Microsoft Support, Search indexing in Windows. 검색 인덱스의 목적과 동작. ↩ ↩2 ↩3

  3. Microsoft Support, Stay protected with the Windows Security app. 실시간 보호를 사용하지 않게 했을 때의 영향. ↩ ↩2 ↩3

  4. Microsoft Learn, Troubleshoot performance problems in Windows. I/O의 응답 시간이나 System 프로세스를 조사하는 사고방식. Windows Server용 자료에 있는 수치 기준을 모든 클라이언트 PC의 합격 기준으로 쓰지는 않았습니다. ↩ ↩2

  5. Microsoft Virtualization Team, Hyper-V Replica debugging: Why are very large log files generated?. 리소스 모니터로 프로세스와 디스크상의 파일을 연결하는 조사 사례. ↩

  6. Microsoft Learn, Performance analyzer for Microsoft Defender Antivirus. 검사의 기록과 분석 절차. ↩ ↩2 ↩3

  7. Microsoft Learn, Stop-Service. 서비스를 중지하는 명령. ↩

  8. Microsoft Learn, Start-Service. 서비스를 시작하는 명령. ↩

  9. Microsoft Learn, about_Try_Catch_Finally. 종료 처리를 finally에 두는 구문. ↩

  10. Microsoft Learn, Troubleshoot Windows Search performance. 검색 대상의 조정, 다시 작성, 진행 상황을 보는 법. ↩ ↩2

  11. Microsoft Support, Windows Search and privacy. Windows Search의 설정과 검색 대상. ↩

  12. Microsoft Learn, Microsoft Defender Antivirus Performance Analyzer reference. 지원 조건, 관리자 권한, 기록·보고서 명령의 사양과 제외 설정에 대한 주의. ↩ ↩2

  13. Microsoft Learn, How to determine the appropriate page file size for 64-bit versions of Windows. 하드 페이지 폴트와 다시 읽어 오는 대상의 설명. ↩

  14. Microsoft Learn, Introduction to the page file. 페이지 파일과 커밋 상한의 관계. ↩

  15. Microsoft Support, What to do about a critical warning for a storage device. 심각한 경고가 나왔을 때의 백업 안내. ↩

  16. Microsoft Learn, Superfetch Sysmain service causes CPU usage spikes. Windows 7의 특정 조건을 대상으로 하는 알려진 문제이며, Windows 11 전반의 대책으로는 다루지 않습니다. ↩

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

디스크 사용률이 100%인데 왜 몇 MB/s밖에 나오지 않습니까?
디스크가 활성 상태였던 시간과, 1초 동안 전송할 수 있었던 바이트 수는 서로 다른 지표이기 때문입니다. 잘게 쪼개진 읽기·쓰기와 I/O의 대기 시간 때문에, 전송량이 적어도 바쁜 상태가 됩니다. 대상 디스크의 응답 시간과, 느린 조작이 동시에 발생하는지를 확인합니다.
SysMain을 사용하지 않도록 설정하면 반드시 빨라집니까?
반드시 빨라진다고 할 수는 없습니다. 먼저 일반적인 설정을 유지하고, SysMain과의 관련이 의심될 때에 한해 원래 상태를 기록한 뒤 일시 중지와 다시 시작을 비교합니다. 영구적인 사용 안 함은 그 비교만으로 결정하지 않도록 합니다.
Windows Search는 중지해도 됩니까?
검색 인덱스에 의존하는 검색의 속도나 결과의 갱신에 영향을 주므로 첫 번째 대책으로 삼지 않습니다. 인덱스의 진행 상황을 확인하고, 필요 없는 폴더가 검색 대상에 들어가 있다면 그 범위를 재검토하는 방법을 먼저 검토합니다.
Defender를 꺼서 디스크 사용률을 낮춰도 됩니까?
일상적인 속도 개선책으로 실시간 보호를 끄는 것은 권하지 않습니다. Microsoft Defender Antivirus의 성능 분석기로 검사의 부하를 기록해, 어떤 파일이나 처리가 관련되어 있는지를 조사합니다. 보고서 상위의 항목도 그대로 제외 설정에 추가해서는 안 됩니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.

문의하기
블로그 목록으로 돌아가기