DetailPage-MSS-KB

기술 자료

기술 자료: 156932 - 마지막 검토: 2013년 5월 30일 목요일 - 수정: 6.0

 

이 페이지에서

요약

Microsoft Windows NT, Windows 2000 및 Windows XP에서 파일 I/O 동기적 이거나 비동기적일 수 있습니다. 기본 동작은 i/o 동기 것: I/O 함수를 호출 되 고 I/O 완료 되 면 반환 합니다. 비동기 I/O 반면, I/O 함수 실행을 다시 호출자에 게 즉시 반환 있습니다. 있지만 I/O 일부 향후 시간까지 완료 된 것으로 간주 되지 않습니다. I/O가 완료 되 면 운영 체제는 호출자에 게를 알립니다. 또는 호출자가 운영 체제의 서비스를 사용 하 여 처리 중인 I/O 작업의 상태를 확인할 수 있습니다.

비동기 I/O 장점은 호출자가 다른 작업을 실행할 수 없는 것입니다. 작업 또는 I/O 작업이 완료 되는 동안 많은 요청을 발급 합니다. 는 비동기 I/O에 대 한 및 비-중복 용어 Overlapped I/O 많이 사용 됩니다. 동기 I/O에 대 한 I/O를 제공 합니다. 비동기 조건이이 문서를 사용 하 고 Windows NT I/O 작업에 대 한 동기 합니다. 이 문서에서는 가정에서 판독기가 특정 익숙한 CreateFile 등의 파일 I/O 함수 ReadFile, WriteFile입니다.

자주, 비동기 I/O 작업은 동기 I/O.로 특정 동작 조건에는 다음 절에서 설명 하는 게 작업이 동기적으로 완료 합니다. 호출자에 게 배경에 대 한 시간이 되었습니다. I/O가 완료 될 때까지 I/O 함수를 반환 하지 않는 때문에 작동 합니다.

여러 함수는 동기 및 비동기 I/O는 관련이 있습니다. 이 문서는 ReadFile 및 WriteFile 예제로 사용합니다. ReadFileEx 및 WriteFileEx는 훌륭한 대안 것입니다. 이 문서를 특히 디스크 I/O 설명 하지만 원칙은 많은 I/O 직렬 I/O 또는 네트워크 I/O와 같은 다른 유형의 적용할 수 있습니다.

참고: 때문에 Windows 95 지원 하지 않는 비동기 I/O 디스크 장치에서 (다른 유형의 I/O 장치에서 수행 하는 있지만), 그 동작을이 문서에서 다루지 않습니다.

추가 정보

비동기 I/O 작업 설정

파일을 열 때 FILE_FLAG_OVERLAPPED 플래그를 CreateFile에서 지정 되어야 합니다. 이 플래그를 I/O 작업을의 파일 비동기적으로 수행할 수 있습니다. 예를 들어 다음과 같습니다.
   HANDLE hFile;

   hFile = CreateFile(szFileName,
                      GENERIC_READ,
                      0,
                      NULL,
                      OPEN_EXISTING,
                      FILE_FLAG_NORMAL | FILE_FLAG_OVERLAPPED,
                      NULL);

   if (hFile == INVALID_HANDLE_VALUE)
      ErrorOpeningFile();
				
시스템에 예약 되어 있기 때문에 비동기 I/O 코딩할 때 주의 해야 하는 경우 작업 동기 확인 하는 권한입니다. 따라서 올바르게 동기적 또는 비동기적으로 완료 된 I/O 작업을 처리 하기 위해 프로그램을 작성 하는 경우 가장 좋습니다. 이 고려 사항은 샘플 코드를 보여 줍니다.

여러 가지 프로그램이 있습니다 비동기 기다리는 동안 수행할 작업이 완료, 추가 작업 대기열 또는 수행 등 백그라운드 작업입니다. 예를 들어, 다음 코드를 제대로 처리 겹쳐진 및 겹쳐진 비 읽기 작업의 완료. 그렇게 아무 이상 기다려 해결 되지 않은 I/O 완료.
   if (!ReadFile(hFile,
                 pDataBuf,
                 dwSizeOfBuffer,
                 &NumberOfBytesRead,
                 &osReadOperation )
   {
      if (GetLastError() != ERROR_IO_PENDING)
      {
         // Some other error occurred while reading the file.
         ErrorReadingFile();
         ExitProcess(0);
      }
      else
         // Operation has been queued and
         // will complete in the future.
         fOverlapped = TRUE;
   }
   else
      // Operation has completed immediately.
      fOverlapped = FALSE;

   if (fOverlapped)
   {
      // Wait for the operation to complete before continuing.
      // You could do some background work if you wanted to.
      if (GetOverlappedResult( hFile,
                               &osReadOperation,
                               &NumberOfBytesTransferred,
                               TRUE))
         ReadHasCompleted(NumberOfBytesTransferred);
      else
         // Operation has completed, but it failed.
         ErrorReadingFile();
   }
   else
      ReadHasCompleted(NumberOfBytesRead);
				
이때 & NumberOfBytesRead ReadFile에 전달 되 다 & NumberOfBytesTransferred GetOverlappedResult에 전달 합니다. 작업의 경우 GetOverlappedResult 사용 확인 하 여 비동기 작업을 했습니다. 실제가 면 작업에서 전송 된 바이트 수 완료. & NumberOfBytesRead ReadFile에 전달 되어 의미가 없습니다.

한편, 작업 즉시 다음 완료 되 면 & ReadFile에 전달 하는 NumberOfBytesRead를 읽은 바이트 수를 잘못 되었습니다. 이 경우 ReadFile에 전달 된 OVERLAPPED 구조체를 무시 합니다. WaitForSingleObject GetOverlappedResult와 사용 하지 마십시오.

비동기 작업을 다른 주의 보류 중인 작업이 완료 될 때까지 OVERLAPPED 구조체에 사용 하면 안 것입니다. 다른 경우에 단어 세 처리 중인 I/O 작업의 경우 세 OVERLAPPED 구조체를 사용 해야 합니다. OVERLAPPED 구조체에 다시 사용할 경우 예기치 않은 결과가 I/O 작업에서 발생 합니다 및 데이터 손상이 발생할 수 있습니다. 왼쪽 위에 데이터가 없는 새 작업에 영향을 하므로 또한 처음, OVERLAPPED 구조체에 사용 하기 전에 또는 이전 작업이 완료 된 후 다시 전에 올바르게이 초기화 해야.

사용 데이터 버퍼 제한 같은 유형을 적용 되는 작업입니다. 데이터 버퍼 합니다 수 읽거나 기록의 해당 I/O 작업이 완료 되었습니다. 읽기 또는 쓰기 버퍼 오류 및 손상 된 데이터를 발생할 수 있습니다.

비동기 I/O 여전히 동기 것으로 나타납니다

그러나이 문서의 앞부분에 나오는 지침을 따른 경우 모든 I/O 작업을 동기적으로 여전히 일반적으로 발급 된 순서 대로 완료 및 ReadFile 작업을 FALSE와 GetLastError() ERROR_IO_PENDING을 반환 반환 하려면 이것은 시간이 모든 백그라운드 작업에 대 한 의미. 이유는 무엇입니까?

여러 가지 이유로 I/O 작업이 동기적으로 완료 하는 이유는 비동기 작업에 대해 사용자가 코딩 한 경우에.

압축

비동기 작업을 하나의 장애물 NTFS 압축 됩니다. 파일 시스템 드라이버 압축된 파일에 비동기적으로 액세스 하지 않습니다. 대신 모든 방금 작업 동기 이루어집니다. 이 파일에는 적용 되지 않습니다. 압축 또는 PKZIP 유사한 유틸리티를 압축 합니다.

NTFS 암호화

유사 하 게 압축 파일 암호화 시스템 드라이버를 비동기 I/O를 하는 동기 변환 하면 됩니다. 파일의 암호를 해독 하면 I/O 요청을 비동기 수 있습니다.

파일 확장

I/O 작업이 동기적으로 완료 되도록 하는 또 다른 이유는 작업입니다. Windows NT 작성할 작업의 길이 확장 하는 파일을 동기화 됩니다.

참고: 응용 프로그램 만들 수 있습니다 앞에서 설명한 쓰기 작업이 비동기 SetFileValidData 함수를 사용 하 고 다음은 WriteFile 발급 하 여 파일의 유효한 데이터 길이 변경 하 여.

응용 프로그램은 SetFileValidData Windows XP 및 이후 버전에서는 사용할 수 있는 사용에 해당 하는 0 채우기는 성능 저하 없이 파일 효율적으로 확장할 수 있습니다.

NTFS 파일 시스템은 하지 않기 때문에 0 채우기 SetFileValidData에서 정의 된 올바른 데이터 길이 (VDL)까지 데이터를이 함수에 있습니다 보안 의미에 대해 다른 파일에서 이전에 사용 된 클러스터 파일 지정할 수 있습니다. 따라서 SetFileValidData 호출자는 새 SeManageVolumePrivilege를 사용 해야 (기본적으로 이것은 관리자 에게만 할당 된). Isv는 의미에서이 함수를 사용 하 여 신중 하 게 고려 하는 것이 좋습니다.

캐시

대부분 I/O (디스크, 통신, 및 기타) 특수 사례 코드 위치는 I/O 요청을 "즉시" 완료할 수 있으면 작업을 완료할 수 및 ReadFile 또는 WriteFile 함수는 TRUE를 반환 합니다 드라이버가 있습니다. 모든 방법으로 이러한 유형의 작업 동기 것 처럼. 디스크에 대 한 장치를 "즉시" 데이터 메모리에 캐시 되는 경우 일반적으로 I/O 요청을 완료할 수 있습니다.

데이터 캐시에 없는 경우

그러나 캐시 구성표 사용자에 대 한 데이터가 없는 경우 작동 수는 캐시 합니다. Windows NT 캐시 내부적으로 파일 매핑을 사용 하 여 구현 됩니다. 비동기 페이지는 Windows NT 메모리 관리자를 제공 하지 않습니다. 캐시 관리자가 사용 하는 파일 매핑을 관리 하려면 내결함성 메커니즘입니다. 는 그러나 캐시 관리자가 요청한 페이지를 메모리에 있는지 여부를 확인 수 하면, 비동기 캐시 된 읽기 문제 및 페이지는 메모리에 없는 경우, 파일 시스템 드라이버 스레드가 차단 되지 않도록 요청 제한 된 작업자 스레드 풀에 의해 처리 됩니다 간주 합니다 때문입니다. 컨트롤은 여전히 보류 중인 읽기 ReadFile 호출 이후에 프로그램에이 반환 됩니다.

이 요청 수가 적은 경우에 우연 있지만 작업자 스레드의 풀이 있기 때문에 없습니다 (현재 3의 16 MB 시스템), 제한 된 여전히 몇 가지 요청만 디스크 드라이버에 특정 시간에 대기 합니다. 캐시에 없는 데이터에 대 한 I/O 작업 많이 실행할 경우, 캐시 관리자 및 메모리 관리자는 포화 상태가 및 사용자 요청이 동기 수행 됩니다.

에 따라 캐시 관리자의 동작 또한 여부에 따라 달라질 수 파일에 순차적으로 또는 임의로 액세스할. 캐시의 이점은 볼 수 파일을 순차적으로 액세스할 때 가장입니다. FILE_FLAG_SEQUENTIAL_SCAN 플래그 에 CreateFile 호출 캐시에 대 한 이러한 유형의 액세스를 최적화 합니다. 그러나 임의의 방식으로 파일을 액세스 하는 경우 사용 하는 FILE_FLAG_RANDOM_ACCESS 플래그는 캐시 관리자에 게 지시를 내리는 데는 CreateFile에서 해당 동작에 대 한 임의 액세스를 최적화 합니다.

캐시를 사용 하지 마십시오.

FILE_FLAG_NO_BUFFERING 플래그 대부분의 동작에 효과가 있는 비동기 작업에 대 한 파일 시스템입니다. 이 보장 하는 가장 좋은 방법은 I/O 요청이 실제로 비동기 인지 여부. 이 파일 시스템에 지시 사용 하는 메커니즘 전혀 캐시합니다.

경고: 데이터 버퍼 맞춤 및 장치의 섹터 크기와 관련이 있는이 플래그를 사용 하 여 일부의 제한이 있습니다. 설명서를이 플래그를 올바르게 사용 하는 방법에 대 한 자세한 내용은 CreateFile 함수에는 함수 참조를 참조 하십시오.

실제 세계 테스트 결과

다음 샘플 코드에서 일부 테스트 결과입니다. 규모는 숫자 컴퓨터 마다 다르며 여기에 중요 하지 않습니다 하지만 비추는 숫자의 관계를 서로 비교 하면 플래그 성능에 영향을 줍니다 일반.

다음과 비슷한 결과를 기대할 수 있습니다.
  • 테스트 1
    Asynchronous, unbuffered I/O:  asynchio /f*.dat /n
    
       Operations completed out of the order in which they were requested.
       500 requests queued in 0.224264 seconds.
       500 requests completed in 4.982481 seconds.
    						
    이 테스트 앞서 설명한 프로그램 500 I/O 요청을 신속 하 게 발급 하 고 많은 시간을 다른 작업을 수행 하거나 더 많은 요청을 발급할 수 있는 방법을 보여 줍니다.
  • 테스트 2
    Synchronous, unbuffered I/O: asynchio /f*.dat /s /n
    
       Operations completed in the order issued.
       500 requests queued and completed in 4.495806 seconds.
    						
    이 테스트 프로그램 4.495880 초 투자 방법을 보여 줍니다. 반면 ReadFile 해당 작업을 완료 하려면 호출 테스트 1 0.224264 같은 요청을 발급할 초만 소요 됩니다. 2 테스트, 모든 배경 실행 프로그램에 대 한 "기타" 시간이 없었습니다. 작동 합니다.
  • 테스트 3
    Asynchronous, buffered I/O: asynchio /f*.dat
    
       Operations completed in the order issued.
       500 requests issued and completed in 0.251670 seconds.
    						
    이 테스트 캐시 동기 특성을 보여 줍니다. 모든 읽기 발급 및 0.251670 초 내에 완료 되었습니다. 즉, 비동기 요청은 동기적으로 완료 되었습니다. 이 테스트도 데이터가 있는 경우 캐시 관리자의 높은 성능을 보여 줍니다. 캐시입니다.
  • 테스트 4
    Synchronous, buffered I/O: asynchio /f*.dat /s
    
       Operations completed in the order issued.
       500 requests and completed in 0.217011 seconds.
    						
    이 테스트는 테스트 3 동일한 결과 보여 줍니다. 캐시에서 동기 읽기 캐시에서 비동기 읽기 보다 약간 더 빨리 완료 하는 note입니다. 이 테스트 데이터는 캐시에 있으면 캐시 관리자의 성능을 높은 방법을 보여 줍니다.

결론

모든 형식, 크기 및 프로그램을 수행 하는 작업의 수에 따라 달라 지므로 어떤 적합을 결정할 수 있습니다.

기본 파일 액세스 CreateFile 모든 특수 플래그 지정 하지 않고 동기 및 캐시 된 작업이입니다.

참고: 파일 시스템 드라이버가 예측 비동기 미리 읽기 및 비동기 지연 쓰기 수정 된 데이터의 않기 때문에이 모드에서 일부 자동 비동기 동작을 가져올 수행 합니다. 이 응용 프로그램 [ASCII 146] s I/O 비동기 만들지 않습니다 있지만 대부분의 단순한 응용 프로그램 위한 이상적인 경우입니다.

반면, 응용 프로그램이 간단 하지 않습니다 경우 사용 해야 할 수 있습니다. 일부 프로 파일링 및 성능 가장 좋은 방법을 결정 하려면 모니터링, 이 문서의 앞부분에서 설명한 테스트와 비슷합니다. 에 데 소요 된 시간은 프로 파일링 된 ReadFile 또는 WriteFile 함수 및 다음 방법으로이 시간 긴 비교 걸리는 실제 I/O 작업을 완료 하는 매우 유용한 도구입니다. 경우는 대부분 I/O 되 고 시간, I/O를 실제로 발급 시 소요 된 동기적으로 완료 되었습니다. 그러나 발급 I/O 요청이 소요 된 시간 경우를입니다. 비교적 작은 I/O 작업을 수행 하는 시간과 그 비교 완료 다음 작업을 비동기적으로 처리 되 고 됩니다. 샘플 이 문서의 앞부분에 나와 있는 코드 QueryPerformanceCounter 함수를 사용 하 여 자체를 내부 프로 파일링 합니다.

성능 모니터링 프로그램이 얼마나 효율적으로 확인할 수 있습니다. 디스크 및 캐시를 사용합니다. 하나는 성능 카운터에 대 한 추적 Cache 개체는 캐시 관리자의 성능을 나타냅니다. 실제 디스크 또는 논리 디스크에 대 한 성능 카운터 추적 디스크 시스템의 성능 개체를 나타냅니다.

성능 모니터링에 도움이 되는 여러 유틸리티는 있습니다. 성능 모니터링 및 DiskPerf 특히 유용합니다. 시스템에서 디스크 시스템의 성능 데이터를 수집 하 여 diskperf-y 명령을 먼저 발급 해야 합니다. 명령을 실행 한 후 데이터 수집을 시작 하려면 시스템을 다시 시작 해야 합니다.

참조

이러한 유틸리티 및 성능 모니터링에 대 한 자세한 내용은 "최적화 Windows NT" Windows NT 리소스에 볼륨을 참조 하십시오. 키트 설명서를 참조 합니다.
SQL Server 시스템에서 Microsoft SQL Server Always-On 저장소 솔루션 검토 프로그램에서 설명한 것 처럼 '안정적인 미디어에 보장 된 배달'을 지원 하기 위해 필요 합니다. 용SQL Server 데이터베이스 엔진에 대 한 입력 및 출력 요구 사항에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조를 클릭 합니다.
967576  (http://support.microsoft.com/kb/967576/ ) Microsoft SQL Server 데이터베이스 엔진 입출력 요구 사항

본 문서의 정보는 다음의 제품에 적용됩니다.
  • Microsoft Win32 Application Programming Interface
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
키워드: 
kbapi kbfileio kbinfo kbkernbase kbmt KB156932 KbMtko
기계 번역된 문서기계 번역된 문서
이 문서는 Microsoft 기계 번역 소프트웨어를 이용하여 번역되었으며 Microsoft Community에 의한 Community Translation Framework(CTF) 기술 혹은 사람이 번역한 내용에 의하여 사후 편집될 수 있습니다. Microsoft는 Knowledge Base에 있는 모든 문서에 다양한 언어로 접근할 수 있도록 하기 위하여 기계 번역, 사람에 의한 번역 및 커뮤니티가 편집한 내용을 모두 제공합니다. 번역된 문서는 어휘, 구문 및/혹은 문법에 오류가 있을 수 있습니다. Microsoft는 번역 오류로 인한 부정확성, 오류 및/또는 손해와 이를 고객이 사용하는 데에 대하여 책임을 지지 않습니다.
이 문서의 영문 버전 보기:156932  (http://support.microsoft.com/kb/156932/en-us/ )
공유
추가 지원 옵션
Microsoft Community 지원 포럼
직접 문의하기
Microsoft Certified Partner 찾기
Microsoft Store
소기업이 아닙니까?
다음에서 팔로우하십시오.