빈 테이블을 쿼리하는 응용 프로그램

우리 회사는 상당히 중대한 성능 문제가있는 응용 프로그램을 사용합니다. 데이터베이스 자체에는 여러 가지 문제가 있지만 작업 중이지만 많은 문제는 순전히 응용 프로그램 관련 문제입니다.

내 조사에서 빈 테이블을 쿼리하는 SQL Server 데이터베이스에 도달하는 수백만 개의 쿼리가 있음을 발견했습니다. 약 300 개의 빈 테이블이 있으며이 테이블 중 일부는 분당 100-200 회까지 쿼리됩니다. 이 테이블은 비즈니스 영역과 아무 관련이 없으며 본질적으로 벤더가 당사와 소프트웨어 계약을 맺기 위해 계약을 체결했을 때 공급 업체가 제거하지 않은 원래 응용 프로그램의 일부입니다.

응용 프로그램 오류 로그에이 문제와 관련된 오류가 발생했다는 사실을 제외하고, 공급 업체는 응용 프로그램이나 데이터베이스 서버에 성능이나 안정성에 영향을 미치지 않습니다. 진단을 수행하는 데 2 ​​분 이상의 오류가 표시되지 않을 정도로 오류 로그가 넘칩니다.

이러한 쿼리의 실제 비용은 CPU주기 등의 측면에서 분명히 낮아질 것입니다. 그러나 SQL Server와 응용 프로그램에 미치는 영향을 제안 할 수 있습니까? 요청을 보내고 확인하고 처리하고 반환하고 응용 프로그램에서 영수증을 확인하는 실제 메커니즘이 성능에 영향을 줄 것이라고 생각합니다.

우리는 응용 프로그램을 위해 SQL Server 2008 R2, Oracle Weblogic 11g를 사용합니다.

@ Frisbee- 간단히 말해서, 응용 프로그램 데이터베이스의 빈 테이블에 충돌하는 쿼리 텍스트가 포함 된 테이블을 만든 다음 비어있는 것으로 알려진 모든 테이블 이름에 대해 쿼리하여 매우 긴 목록을 얻었습니다. 가장 큰 인기는 30 일의 가동 시간 동안 270 만 건의 실행으로 앱이 일반적으로 오전 8시에서 오후 6 시까 지 사용되므로 해당 숫자가 운영 시간에 더 집중되어 있다는 점을 명심하십시오. 여러 테이블, 여러 쿼리, 아마도 일부는 조인을 통한 관련성이 있습니다. 최고 히트 (당시 270 만)는 조인이없는 where 절이있는 단일 빈 테이블에서 간단하게 선택했습니다. 빈 테이블에 조인이있는 더 큰 쿼리에는 연결된 테이블에 대한 업데이트가 포함될 수 있지만 확인 하고이 질문을 최대한 빨리 업데이트하겠습니다.

업데이트 : 실행 횟수가 1043-4622614 (2.5 개월 이상) 인 1000 개의 쿼리가 있습니다. 캐시 된 계획이 언제 시작되는지 알아 내려면 더 많이 파헤쳐 야합니다. 이것은 단지 쿼리의 범위에 대한 아이디어를 제공하기위한 것입니다. 대부분 20 개가 넘는 조인으로 합리적으로 복잡합니다.

@ srutzky- 그렇습니다. 계획이 컴파일 될 때 관련이있는 날짜 열이 있다고 생각하므로 관심을 가질 것입니다. SQL Server가 VMware 클러스터에있을 때 스레드 제한이 전혀 문제가되지 않을까요? 곧 전용 Dell PE 730xD가 될 것입니다.

@Frisbee-늦게 응답해서 죄송합니다. 제안한 바와 같이 SQLQueryStress (실제 240,000 반복)를 사용하여 24 개의 스레드에서 10,000 번 빈 테이블에서 select *를 실행하고 즉시 10,000 배치 요청을 기록했습니다. 그런 다음 24 스레드에서 1000 배로 줄이고 4,000 배치 요청 / 초 미만으로 적중했습니다. 또한 12 스레드 (총 120000 회 반복)에 대해 10,000 회 반복을 시도하여 6,505 Batches / sec가 지속되었습니다. CPU에 미치는 영향은 실제로 각 테스트 실행 동안 총 CPU 사용량의 약 5-10 %입니다. 네트워크 대기 시간은 무시할 만하지 만 (워크 스테이션에서 클라이언트와의 3ms와 같은) CPU에 미치는 영향은 확실합니다. CPU 사용량과 약간의 불필요한 데이터베이스 파일 IO로 요약됩니다. 총 실행 / 초는 3000 미만으로 작동합니다. 프로덕션보다 많지만 이와 같은 수십 가지 쿼리 만 테스트하고 있습니다. 따라서 분당 300-4000 배의 속도로 빈 테이블에 충돌하는 수백 개의 쿼리의 결과는 CPU 시간과 관련하여 무시할 수 없습니다. 모든 테스트는 듀얼 플래시 어레이와 256GB RAM, 12 개의 최신 코어를 갖춘 유휴 PE 730xD에 대해 수행되었습니다.

@ srutzky- 좋은 생각. SQLQueryStress는 기본적으로 연결 풀링을 사용하는 것처럼 보이지만 어쨌든 살펴보고 연결 풀링 상자가 선택되어 있음을 알았습니다. 따라 업데이트

@ srutzky- 응용 프로그램에서 연결 풀링이 활성화되어 있지 않거나 작동하지 않는 것 같습니다. 프로파일 러 추적을 수행하고 연결에 감사 로그인 이벤트에 대한 EventSubClass "1-Non pooled"가 있음을 발견했습니다.

RE : 연결 풀링-weblogics를 확인하고 연결 풀링을 사용하도록 설정했습니다. 라이브에 대해 더 많은 추적을 실행하고 풀링이 올바르게 / 전혀 발생하지 않는 징후를 발견했습니다.

그리고 여기에 채워진 테이블에 대한 조인없이 단일 쿼리를 실행할 때의 모습이 있습니다. 예외는 "SQL Server에 연결하는 동안 네트워크 관련 또는 인스턴스 별 오류가 발생했습니다. 서버를 찾을 수 없거나 액세스 할 수 없습니다. 인스턴스 이름이 올 바르고 SQL Server가 원격 연결을 허용하도록 구성되어 있는지 확인하십시오. (제공자 : 명명 된 파이프 공급자, 오류 : 40-SQL Server에 대한 연결을 열 수 없습니다) "배치 요청 카운터를 기록하십시오. 예외가 생성되는 동안 서버를 핑하면 성공적인 핑 응답이 발생합니다.

업데이트-두 번의 연속 테스트 실행, 동일한 워크로드 (select * fromEmptyTable), 풀링 활성화 / 비활성화 약간 더 많은 CPU 사용량과 많은 오류가 발생하며 초당 500 회의 일괄 요청을 초과하지 않습니다. 테스트는 10,000 Batches / sec와 풀링이 켜져있는 상태에서 실패하지 않았으며, 약 400 개의 배치 / 초와 풀링이 비활성화되어 많은 실패를 보여줍니다. 이러한 오류가 연결 가용성 부족과 관련이 있는지 궁금합니다.

@ srutzky- sys.dm_exec_connections에서 카운트 (*)를 선택하십시오.

• 풀링 가능 :로드 테스트가 중지 된 후에도 일관성있게 37

• 풀링 비활성화 됨 :
  SQLQueryStress에서 예외가 발생 하는지 여부에 따라 11-37 : 예를 들어 이러한 트로프가
  Batches / sec 그래프에 나타나는 경우 SQLQueryStress에서 예외가 발생하고
  연결 수가 11로 감소한 다음 점진적으로 최대 37까지 백업 배치가 정점에 도달하고 예외가 발생하지 않는 경우 매우 흥미 롭습니다.

테스트 / 라이브 인스턴스 모두의 최대 연결은 기본값 0으로 설정됩니다.

응용 프로그램 로그를 확인했지만 연결 문제를 찾을 수 없지만 많은 수의 크기, 즉 많은 스택 추적 오류로 인해 몇 분 분량의 로깅 만 사용할 수 있습니다. 앱 지원에 대한 동료는 연결과 관련하여 상당한 수의 HTTP 오류가 발생한다고 조언합니다. 이것은 어떤 이유로 응용 프로그램이 연결을 올바르게 풀링하지 않아서 서버에 연결이 반복적으로 부족한 것으로 보입니다. 앱 로그를 더 살펴볼 것입니다. SQL Server 측에서 프로덕션 환경에서 이것이 일어나고 있음을 증명하는 방법이 있는지 궁금합니다.

@ srutzky- 감사합니다. 내일 weblogic 설정을 확인하고 업데이트하겠습니다. 나는 단지 37 개의 연결에 대해서만 생각하고 있었다-SQLQueryStress가 10,000 반복 = 120,000 개의 select 문을 풀링하지 않고 12 개의 스레드를 수행하는 경우 각 선택이 SQL 인스턴스에 대한 고유 한 연결을 생성한다는 것을 의미하지 않아야합니까?

@ srutzky- Weblogics는 연결을 풀링하도록 구성되었으므로 제대로 작동해야합니다. 연결 풀링은 4 개의로드 밸런스 웹 로직 각각에서 다음과 같이 구성됩니다.

• 초기 용량 : 10
• 최대 수용 인원 : 50
• 최소 수용 인원 : 5

빈 테이블 쿼리에서 선택을 실행하는 스레드 수를 늘리면 연결 수가 약 47입니다. 연결 풀링을 사용하지 않으면 최대 배치 요청 / 초가 10,000에서 400까지 줄어 듭니다. 매번 일어날 일은 SQLQueryStress의 '예외'가 배치 / 초가 최저점에 도달 한 직후에 발생한다는 것입니다. 연결과 관련이 있지만 이것이 왜 일어나는지 정확히 이해할 수는 없습니다. 테스트가 실행되고 있지 않으면 #connections는 약 12로 줄어 듭니다.

연결 풀링을 사용하지 않으면 예외가 발생하는 이유를 이해하는 데 어려움이 있지만 Adam Machanic에 대한 다른 모든 스택 교환 질문 / 질문 일 수 있습니까?

@ srutzky SQL Server에 연결이 부족하지 않은 경우에도 풀링을 사용하지 않고 예외가 발생하는 이유는 무엇입니까?

요청을 보내고 확인하고 처리하고 반환하고 응용 프로그램에서 영수증을 확인하는 실제 메커니즘이 성능에 영향을 줄 것이라고 생각합니다.

예, 몇 가지 추가 요소가 있지만 시스템에 실제로 영향을 미치는 정도는 시스템을 분석하지 않고는 말할 수 없습니다.

즉, 당신은 문제 가 될 수 있는 것을 요구 하고 있으며, 그중 일부가 현재 특정 상황에 영향을 미치지 않는 경우에도 언급 할 것이 있습니다. 너는 ~라고 말한다:

약 300 개의 빈 테이블이 있으며이 테이블 중 일부는 분당 100-200 회까지 쿼리됩니다.

• 쿼리되지 않은 빈 테이블은 문제가되지 않습니다. 그러나 나는 당신이 그들 모두가 쿼리되고 있다는 것을 의미 할 수 있다고 생각합니다. 단지 일부는 다른 것보다 더 많이 타격을 받고 있습니다.
• 제출 된 쿼리 텍스트가 호출에서 동일하게 유지되는 경우 쿼리 구문 분석 및 실행 계획 생성은 큰 문제가되지 않습니다 . SQL Server는 쿼리 텍스트를 해시하고 계획 캐시에서 조회합니다. 발견되면 캐시에서 계획이 제거 될 때까지 구문 분석 또는 컴파일 단계를 다시 수행하지 않습니다.
• 비어 있거나 비어 있지 않은 모든 테이블은 리소스가 사용되고 있음을 나타 내기 위해 최소한 "공유"잠금이 필요합니다. 이렇게하면 리소스를 사용하는 동안 독점 잠금 (열 추가 / 변경 / 제거 등)이 필요한 작업이 변경되지 않습니다. 데이터가 없기 때문에 1 밀리 초 이내에 완료된 경우에도 잠금 및 잠금 해제는 여전히 잠금 작업을 관리하기 위해 시스템 리소스 (메모리 및 CPU)가 필요합니다.
• SQL Server에서 앱으로 결과 집합이 다시 반환되지 않더라도 쿼리 결과 결과에 관계없이 SQL Server로 전송되는 네트워크 트래픽 양은 여전히 ​​동일합니다. 쿼리 텍스트 또는 저장 프로 시저 이름을 보내야합니다. 결과가 다시 나타나지 않더라도 SQL Server는 결과 집합이 시작되고 있음을 클라이언트에게 알리는 패킷과 함께 결과 집합 구조를 포함하는 일부 네트워크 패킷을 보내야합니다. 결말로 마감해야합니다. 인쇄 문 및 / 또는 행 수에서 추가 메시지가있을 수 있습니다.
• SQL Server에 연결하려면 약간의 시스템 리소스가 필요합니다. 인증 및 네트워크 패킷을 처리하는 데 CPU와 메모리가 필요하며 시간도 걸립니다. 이것이 연결 풀링이 존재하는 이유입니다.
• 시스템 리소스 사용을 줄이는 연결 풀링을 사용하더라도 SQL Server는 여전히 이러한 연결을 유지해야하며 메모리와 최소한의 CPU가 필요합니다.
• 행이없고 실행 시간 이 매우 빠르더라도 쿼리는 여전히 실행되었습니다. 행이 10 개 또는 10,000 개이고 행이 자주 사용되므로 버퍼 풀 (예 : 메모리)에서 가져온 경우에도 스레드가 여전히 해당 작업을 수행해야합니다. 그리고이 쓸모없는 쿼리에서 작동하는 스레드 는 실제로 유용한 쿼리에서 작동 하지 않습니다 .

더 많을 수도 있지만 이것은 사물을 이해하는 데 도움이됩니다. 또한 대부분의 성능 문제와 마찬가지로 모두 규모의 문제입니다. 위에서 언급 한 모든 항목은 분당 한 번 명중되면 문제가 아닙니다. 워크 스테이션 또는 개발 데이터베이스에서 변경 사항을 테스트하는 것과 같습니다. 항상 테이블에서 10-100 행으로 만 작동합니다. 해당 코드를 프로덕션으로 옮기면 실행하는 데 10 분이 걸리며 누군가 "내 상자에서 작동합니다";-)라고 말합니다. 즉, 문제가 발생한 것은 전화가 너무 많기 때문일 뿐이지 만 이것이 존재하는 상황입니다.

따라서 백만 개의 쓸모없는 0 행 쿼리조차도 다음과 같습니다.

• 추가로 2 백만 건의 잠금 작업 (모든 잠금을 잠금 해제해야합니까?) 이는 대부분 유용한 작업 대신 쓸모없는 작업에 소요되는 시간 비용입니다.
• 포화 상태에 가까워 질 수 있는 더 많은 네트워크 트래픽 (이 정도는 확실하지 않지만 여전히)

• 더 많은 연결을 유지하여 더 많은 메모리를 차지합니다. 사용하지 않은 실제 RAM은 얼마입니까? 이 메모리는 쿼리 및 / 또는 쿼리 계획 캐시를 실행하는 데 더 적합합니다. 최악의 경우 실제 메모리가 부족하고 SQL Server에서 가상 메모리 사용 (스왑)을 시작해야하므로 속도가 느려질 수 있습니다 (SQL Server 오류 로그에서 메모리가 페이징되고 있다는 메시지가 표시되는지 확인하십시오).

  그리고 누군가가 "글쎄, 연결 풀링이있다"고 언급하는 경우를 대비하여. 그렇습니다. 필요한 연결 수를 줄이는 데 도움이됩니다. 그러나 분당 최대 200 회 쿼리가 발생하면 이는 많은 동시 작업이며 합법적 인 요청에 대한 연결이 여전히 필요합니다. 를 수행 SELECT * FROM sys.dm_exec_connections;하면 유지 얼마나 많은 활성 연결을 참조 할 수 있습니다.

• 다른 어떤 것에 관계없이, 이것은 여전히 ​​유용한 일을 할 수 있었던 스레드가 대신 사용할 수 없었던 하루 동안 여전히 적어도 백만 번입니다.

내가 여기에 언급 한 내용에 대해 내가 틀리지 않은 경우, 작은 규모의 경우에도 네트워크 및 SQL Server에 가짜 요청으로 인해 시스템에 DDoS 공격이 발생하는 것으로 보입니다. 실제 요청이 SQL Server에 도착하거나 SQL Server에서 처리되지 않도록합니다.

테이블이 1 분에 100-200 회 충돌하면 메모리에 (희망적으로) 있습니다. 서버의 부하가 매우 낮습니다. 데이터베이스 서버에 높은 CPU 또는 메모리가없는 한 이것은 문제가 아닐 수 있습니다.

예, 쿼리는 공유 잠금을 사용하지만 업데이트 잠금을 차단하지 않거나 업데이트 잠금으로 차단하지 않기를 바랍니다. 이 테이블에 대한 업데이트, 삽입 또는 삭제가 있습니까? 그렇지 않다면 그냥 놓아 두십시오. 성능 문제가있는 경우 데이터베이스 서버 관점에서 볼 때 더 큰 물고기가 있어야합니다.

빈 테이블에서 100,000 개의 select count (*)에 대한 테스트를 실행했으며 32 초 안에 실행되었으며 쿼리는 네트워크를 통해 이루어졌습니다. 1/3 밀리 초입니다. 네트워크에 과부하가 걸리지 않는 한 클라이언트에도 영향을 미치지 않습니다. 주요 성능 문제가있는 경우 이러한 1/3 밀리 초 빈 쿼리가 앱을 죽이는 것이 아닙니다.

그리고 이들은 현재 응용 프로그램의 일부가 아닌 일부 정적 유형 데이터를 가져 오는 왼쪽 조인의 일부 일 수 있습니다. 다른 쿼리와 연결될 수 있으므로 추가 왕복이 아닙니다. 그렇다면 엉성하지만 더 많은 트래픽을 유발하지는 않습니다.

다시 실제 진술을 살펴보십시오. 이 테이블에서 업데이트, 추가 또는 삭제가 표시됩니까?

그렇습니다. 많은 빈 테이블과 빈 테이블에 대한 쿼리는 느슨한 코딩을 나타냅니다. 그러나 주요 성능 문제가 발생하는 경우 이러한 테이블에 대해 너무 조잡한 쓰기 작업을 수행하지 않는 한 이것이 원인이 아닙니다.

일반적으로 각 쿼리에 대해 다음 단계가 수행됩니다.

1. 신청서 요청.
2. 데이터베이스 쿼리를 구문 분석하십시오.
3. 데이터베이스 엔진은이 쿼리가 이미 RAM에 저장되어 있는지 확인합니다. 메모리에 존재하는 경우 실행 계획을 사용하십시오.
4. RAM에 존재하지 않는 경우 데이터베이스 엔진은 쿼리의 객체에 대한 기존 통계를 확인하고 실행 계획을 결정합니다.
5. 실행 계획을 실행하고 i / o를 사용하여 디스크에서 데이터를 가져 오십시오.
6. 응용 프로그램에 대한 응답.

언급 한 많은 쿼리는 이미 연결, CPU, RAM 및 I / O에 대한 추가로드가 많은 시스템에서 추가로드를 유발할 수 있습니다.