로드가 심한 상태에서 UNC 경로를 사용할 경우 다음과 같은 이벤트 뷰어 오류 메시지가 표시될 수 있습니다.

"Windows에서 네트워크 경로를 찾을 수 없습니다. 네트워크 경로가 올바른지, 대상 컴퓨터가 사용 중이거나 꺼져 있지 않은지 확인하십시오. 네트워크 경로를 계속 찾을 수 없으면 네트워크 관리자에게 문의하십시오. 오류 코드 0x80070033.”

"네트워크 위치를 찾을 수 없습니다. 네트워크 문제 해결에 대한 내용은 Windows 도움말을 참고하십시오. 오류 코드 0x800704CF."

이러한 오류는 UNC 연결을 설정할 때 IIS 서버에 아웃바운드 TCP 포트가 부족한 경우에 반환될 수 있습니다. 이러한 경우에는 TCP 포트를 다시 사용할 수 있을 때까지 IIS가 모든 요청에 대해 HTTP 500 오류를 반환합니다. 이 문제를 해결하려면 MaxUserPor 레지스트리 설정(IIS 서버의)을 사용하여 사용 가능한 포트 수를 늘리십시오. MaxUserPort 에 대한 자세한 내용은 다음 링크를 참조하십시오. 레지스트리 키(페이지는 영문일 수 있음): http://www.microsoft.com/resources/documentation/isa/2000/enterprise/proddocs/en-us/isadocs/cmt_regkey.mspx(페이지는 영문일 수 있음).

예를 들어 가상 디렉터리 수가 많거나 통과 인증을 사용 중이고 인증된 사용자가 많은 경우, UNC 경로에서 리소스를 사용하는 인증된 사용자 수가 동시에 너무 많아질 수 있습니다. IIS 서버에서 원격 파일 서버로 연결되는 각 개별 사용자에 대해서는 서로 다른 SMB 연결이 열립니다. 이러한 각각의 SMB 연결마다 포트가 하나씩 사용됩니다. 기본적으로 아웃바운드 TCP 연결에 대해서는 포트 수가 1,024에서 5,000개 정도로 제한되므로(사용 가능한 포트 수 4,000개 이하) 각 SMB 연결을 위한 추가 포트를 사용할 수 있도록 10,000이나 20,000 정도로 값을 늘려야 할 수 있습니다. 하지만 이러한 상위 포트 번호에서 소켓을 만드는 다른 응용 프로그램에 문제가 발생할 수 있으므로 주의해야 합니다. 자세한 내용은 다음 TechNet 문서를 참조하십시오. Windows Server 2000(페이지는 영문일 수 있음).

일부 경우에는 IIS가 아닌 파일 서버 상의 문제로 인해 UNC 경로 이름과 관련된 오류가 IIS에서 보고될 수 있습니다. 위에서 설명한 바와 같이 UNC 연결 이후에는 SMB 연결이 설정됩니다. 그러면 SMB 연결에 사용되는 작업 항목이 하나 이상 만들어집니다. 작업 항목은 SMB에서 I/O 작업을 위해 사용되는 데이터 구조 개체이며, 다양한 방식으로 다양한 기간 동안 사용될 수 있습니다. 예를 들어 CreateFile 또는 GetFileAttributes와 같이 파일을 대상으로 한 작업을 수행하면 짧은 기간 동안만 I/O 작업 항목이 사용되지만 디렉터리 구조에 대한 변경 알림을 요청할 경우에는 IIS 서버에 대한 접속 기간 내내 작업 항목이 사용됩니다. 따라서 작업 항목으로 수행되는 작업의 종류에 따라 SMB 연결을 지원하기 위한 작업 항목의 전반적인 가용성에 영향을 줄 수 있습니다.

작업 항목은 일반적으로 비페이징 풀이라고 부르는 파일 서버의 비페이징 풀 메모리에 만들어집니다. 이 메모리는 시스템 페이지 파일에 동적으로 스왑하거나 페이징할 수 없기 때문에 비페이징이라고 부릅니다. 따라서 서버가 올바르게 작동할 수 있으려면 비페이징 풀의 여유 공간이 충분하게 있어야 합니다.

파일 서버에 있는 작업 항목의 수가 많으면 비페이징 풀 메모리의 할당량이 초과될 수 있습니다. 이러한 경우에는 다음과 같은 이벤트 뷰어 오류 메시지가 표시될 수 있습니다.

"서버 저장소 공간이 부족하여 이 명령을 처리할 수 없습니다."

"풀이 비었으므로, 서버가 시스템의 비페이징 풀에서 할당하지 못했습니다."

"서버가 지난 60초 동안 작업 항목을 <n>번 할당할 수 없었습니다."

작업 관리자를 열고, 성능 탭을 선택한 후 커널 메모리 프레임 아래의 비페이징 값을 조사하면 파일 서버의 메모리 사용량을 신속하게 확인할 수 있습니다. 이러한 종류의 문제는 작업 항목 수를 줄이거나 IIS 및 파일 서버가 더 많은 작업 항목을 관리할 수 있도록 튜닝하는 두 가지 방식으로 관리할 수 있습니다.

최선의 방법을 선택하려면 먼저 시뮬레이션된 작업 부하로 몇 시간 정도 서버를 실행하고 파일 서버에서 다음과 같은 카운터 항목에서 성능 모니터 카운터를 확인해야 합니다.

• Server\Files Open - 이 카운터는 적절한 SMB 설정을 예상하는 데 도움이 되는 정보를 제공합니다.
  
  
• Server\Server Sessions - 이 카운터는 적절한 SMB 설정을 예상하는 데 도움이 되는 정보를 제공합니다.
  
  
• Server\Work Item Shortages - 이 카운터가 증가할 경우에는 더 많은 작업 항목이 필요하다는 것을 의미합니다.
  
  
• Server\Pooled NonPaged Bytes - 이 카운터가 너무 낮으면 서버에서 사용할 수 있는 비페이징 풀이 거의 소진되었음을 의미합니다. SMB 작업 항목을 줄여야 할 수 있습니다.
  
  

서버를 튜닝하는 동안 이러한 설정을 모니터링하면 조정 값이 적합한지 확인하는 데 도움이 됩니다.

중요
x86 플랫폼에서 비페이징 풀 메모리의 최대값은 256MB입니다. 하지만 최대값이 동적으로 결정되기 때문에 비페이징 풀 메모리의 실제 값은 이보다 적을 수 있습니다.

파일 서버에서 비페이징 풀 메모리의 소비량은 파일 서버에 할당된 작업 항목 수를 줄일 경우 영향을 받을 수 있습니다. 이러한 작업은 여러 가지 기술들을 사용하여 수행할 수 있습니다.

• IIS의 캐싱 알고리즘을 변경하면, 즉 캐시 업데이트에 대한 기본 방법인 마지막 수정 시간 방법을 사용하면 만들어지는 작업 항목 수가 줄어듭니다.
  
  
• 파일 서버에 연결하는 인증된 사용자의 수를 줄입니다. 연결은 각 고유 사용자에 대해 만들어집니다. 통과 인증을 사용하는 대신 연결에 대해 사용자를 지정하면 연결 수가 줄어듭니다.
  
  
• 원격 리소스를 사용하는 가상 디렉터리 또는 웹 사이트의 수를 줄입니다.
  
  

서버 튜닝

캐싱에 대해 파일 변경 알림을 사용할 경우 MaxCmds를 계산하는 수식은 다음과 같습니다. (IIS가 변경 알림을 모니터링해야 하는 고유 실제 디렉터리 수) * (1 [정적 파일이 있는 경우] + 1 [ASP 콘텐츠가 있는 경우] + 1 [ASP.NET 콘텐츠가 있는 경우]) + 50(동시 기본/정규 파일 I/O의 경우).

이 수식의 결과 값은 IIS 서버 연결이 항상 100% 활성화되어 있는 것을 전제로 합니다. 일반적으로 이러한 경우는 드물기 때문에 MaxCmds는 사용자의 작업 특성에 따라 25%에서 50% 정도 줄여야 합니다.

중요
이 계산은 대략적인 수치일 뿐입니다. 위에서 언급한 성능 모니터 카운터에 대한 설명에 따라 값을 적절하게 조정할 수 있습니다.

캐싱에 대해 마지막 수정 시간 옵션을 사용할 경우 MaxCmds를 계산하는 수식은 다음과 같습니다. (초당 최대 요청 수 / 정체 시간) / 2. 정체 시간이란 IIS가 파일 변경을 확인하는 주기 값(기본값 5초)입니다. 이 수식의 결과 값은 사용되는 IIS 리소스의 비율이 항상 높게 유지되는 것을 전제로 합니다. 실제로 그렇지 않은 경우에는 MaxCmds를 사용자의 작업의 특성에 따라 50%에서 75% 정도 줄여야 합니다.

중요
이 계산은 대략적인 수치일 뿐입니다. 위에서 언급한 성능 모니터 카운터에 대한 설명에 따라 값을 적절하게 조정할 수 있습니다.

MaxCmds에 대한 값을 결정한 후에는 MaxWorkItems 값을 (MaxCmds * [파일 서버에 연결하는 IIS 서버 수])의 값과 동일하게 설정해야 합니다. 사용된 IIS 서버가 한 개인 경우 MaxWorkItems는 MaxCmds와 동일합니다. 사용된 IIS 서버가 4개인 경우 MaxWorkItems는 4 * MaxCmds가 됩니다.

RAM이 512MB 이상인 Windows 2003 Server에서는 각 작업 항목이 20K의 비페이징 풀 메모리를 차지합니다. 서버에서 RAM이 512MB 미만인 경우에는 각 작업 항목이 8K의 비페이징 풀 메모리를 사용합니다. 다른 서버 리소스에 대해서도 비페이징 풀 메모리가 충분하게 제공되도록 하려면 작업 항목에서 사용되는 비페이징 풀 메모리의 양을 최소화하십시오.

중요

x86 플랫폼의 비페이징 풀 최대 크기는 256MB입니다. 하지만 실제 메모리 크기와 같은 여러 요인으로 인해 서버에 이보다 적은 양이 할당될 수 있습니다. 비페이징 풀 크기는 설정된 후에도 실제 메모리 크기 및 설치된 장치를 포함하는 시스템 하드웨어 구성에 따라 동적으로 조정될 수 있습니다. 시스템 PerfMon 도구를 사용하여 현재 사용 중인 비페이징 풀 메모리의 양을 나타내는 Memory\Pool nonpaged Bytes 및 Memory\Pool nonpaged Alloc 카운터를 조사하면 비페이징 풀 사용량을 모니터링할 수 있습니다. 비페이징 풀 메모리 사용량이 최대 크기를 초과하는지를 간접적으로 확인할 수 있는 방법은 두 가지입니다. 첫째, 비페이징 풀 메모리 할당을 실패할 경우 서버 서비스가 시스템 이벤트 로그에 이벤트를 로깅합니다. 둘째, PerfMon 카운터 "Server\Pool Nonpaged Peak"에는 서버 사용 기간 중 특정 시점에 할당된 비페이징 풀 메모리의 최대 양이 표시됩니다. 비페이징 풀 메모리에 대한 서버 소비량이 실제 최대 한도에 도달했다고 생각될 경우, 해당 값이 사용 가능한 최대 비페이징 풀 메모리의 값을 대략적으로 나타내는 값이 될 수 있습니다.

일부 경우에는 작업 항목 수를 늘려야 하지만 작업 항목당 20K의 공간이 소비되기 때문에 비페이징 풀 메모리를 너무 많이 소비하게 될 수 있습니다. 서버의 RAM이 512MB 이상인 경우 작업 항목 크기를 20K 대신 8K로 구성할 수 있습니다. 파일 서버의 HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters에서 레지스트리 키 SizReqBuf의 REG_DWORD 값을 0x1104(4356d)로 설정하십시오. 이렇게 하면 너무 많은 비페이징 풀 메모리를 소비하지 않으면서도 파일 서버에서 사용 가능한 작업 항목 수를 늘릴 수 있습니다. 하지만 이 방법을 사용할 경우 대량 디렉터리의 열거 속도가 느려지고 네트워크 성능도 느려질 수 있습니다.

참고