내 사이트의 웹 프런트엔드와 데이터베이스는 1000M LAN으로 연결된 두 대의 서버에 분리되어 있습니다.
거의 모든 쿼리의 응답 시간이 800ms를 넘는 것으로 나타났습니다. 단일 서버에 배포할 때 문제가 나타나지 않기 때문에 쿼리가 모두 괜찮은지 확인할 수 있습니다.
웹사이트/asp.net 2.0 데이터베이스/SQL 서버 2000
답변1
DNS가 캐시된 IP 주소에 대해 800ms 지연을 일으키는 경우 네트워킹 설정에 심각한 문제가 있는 것입니다. IMHO. ping을 사용하여 문제가 있는지 확인할 수 있습니다.
Traceroute를 사용하여 패킷이 두 컴퓨터 사이의 효율적인 경로를 사용하고 있는지 확인하십시오. 이는 수행하기 쉬우므로 다른 작업을 시작하기 전에 시도해 볼 가치가 있습니다. 경로에 홉이 너무 많으면(아마도 2~3개 이상) 네트워크 담당자를 찾아서 그 이유를 물어보세요.
SQL 네트워크 문제를 해결하려고 할 때는 "SELECT GETDATE()"와 같은 매우 간단한 쿼리를 사용하고 SQLCMD.EXE와 같은 간단한 쿼리 도구를 사용하는 것이 가장 좋습니다. 간단한 쿼리는 서버가 쿼리를 구문 분석하는 데 많은 시간을 소비할 필요가 없고 중요한 잠금이나 차단이 없으며 쿼리가 네트워크를 통해 수백만 행의 데이터를 가져오지 않음을 의미합니다. 간단한 쿼리 도구를 사용하면 IIS가 수행할 작업과 수행하지 않을 작업에 대해 걱정할 필요가 없습니다. IIS 서버에 SQLCMD.EXE, OSQL.EXE 또는 유사한 도구가 설치되어 있지 않은 경우 작은 psh 또는 vbs 스크립트를 작성하여 SQL Server에 대한 연결을 테스트하는 것이 좋습니다. IIS 서버에 대한 이러한 종류의 액세스 권한이 없다면 간단한 쿼리를 실행하고 결과와 실행에 걸리는 시간을 반환하는 특별한 ASP 페이지를 작성할 수도 있습니다.
문제를 추측해야 한다면 이렇습니다. 특히 오래된 장비와 드라이버의 경우 NIC의 "자동 협상" 설정에 의존하지 마십시오. 두 카드를 모두 동일한 설정으로 수동으로 설정하십시오.
나는 이것이 문제라는 것을 알고 있지만 네트워크 담당자들이 난처한 상황에서 이 문제가 십여 가지 정도의 유사한 문제를 해결하는 것을 개인적으로 보았습니다. (이것들은 결국 서버이므로 여러 다른 스위치에 연결되지 않으며 링크 속도나 이중 설정을 재협상해야 할 필요가 없습니다.)
성능 모니터를 사용하여 MB/초 단위로 측정된 NIC의 데이터 속도를 관찰하여 이 문제를 확인할 수도 있습니다. 기준선을 설정한 후에는 NIC의 설정을 변경하고 다시 관찰하십시오.
일반적으로 해당 설정을 "실시간"으로 변경하면 문제가 해결될 수 있지만 처음으로 해당 설정을 조작할 때 최대 로드 시간에는 시도하지 않을 것입니다. 테스트 환경에서 시험해 보는 것이 더 좋습니다. 유지 관리 기간이 있다면 그게 가장 좋습니다. 서버에 NIC가 1개만 있는 경우 스위치와 통신할 수 없도록 NIC를 설정하지 않도록 주의하십시오. 그렇지 않으면 누군가에게 콘솔에 물리적으로 로그인하도록 요청해야 할 수도 있으며 이는 모두에게 당황스러운 일입니다.
답변2
가능한 이유는 다양합니다. 예를 들어 네트워크 어댑터 드라이버 중 하나에 문제가 있을 수 있습니다.
SQL 연결이 병목 현상인지 아니면 일반적인 네트워킹 문제인지 확인해야 합니다. 모든 쿼리가 영향을 받는지 확인하려면 웹 서버에서 "select getdate()" 명령을 실행해 보십시오.
데이터베이스 서버에 대한 ping도 느리나요? 또한 서버 이름 대신 IP 주소를 사용해 보십시오. DNS 확인 문제일 수도 있습니다.