MapGuide Open Source 2.1의 공간 인덱스 및 CPU 사용률

Question

수십만 개의 지오메트리 유형 소포가있는 SQL Server 테이블이 있습니다. 셀 집합마다 밀도와 개체의 조합을 다르게하려고 색인을 만들었습니다. 지금까지는 셀 당 LOW, LOW, MEDIUM, MEDIUM 및 16 개 개체에 대한 설정을하고 있으며 표에있는 엔터티의 범위에 따라 경계 상자를 설정하는 SP를 만들었습니다.

인덱스없이 몇 분이 걸리는 쿼리에서 성능이 크게 향상되며 확대/축소가 가까워 질수록 개체가 더 적게 표시됩니다.

그러나 쿼리 자체가 빠르더라도 기능을 쿼리 할 때 CPU 사용률은 100 %가됩니다. 나는 이것이 생산 환경에서 날지 않을까 걱정하고있다.

이 프로젝트에 대해 MapGuide Open Source 2.1을 사용하고 있지만 CPU로드가 SQL Server에 의해 발생했기 때문에 긍정적입니다.

색인이 제대로 설정되어 있는지 궁금합니다. 제대로 설정하는 방법에 대한 명확한 문서를 찾지 못했습니다. 내가 읽은 모든 기사는 기본적으로 "그것이 달려있다"라고 말하지만 구체적인 것은 없습니다. 책, 기사 등 나에게 어떤 조언이 있으십니까?

감사합니다.

Answer 1

SQL 또는 mapguide 데몬에서 CPU 사용률이 있습니까?

우리가 만난 문제점 중 하나는 mapguide가 쿼리를 작성하는 것이 현명하지 않다는 것입니다. 최대 확대/축소 및 범례의 작은 하위 집합 (해당 확대/축소 수준에서만 전송)을 표시하면 다른 필터를 적용하지 않고보기 영역 내의 모든 개체를 쿼리합니다. 그런 다음 수천 개의 레코드를 반복하고 테마 (별도의 필터 사용)를 적용합니다.

다른 줌 레벨에 대한 레이어를 작성하고 쿼리 필터를 사용하여 SQL에서 반환되는 데이터의 양을 제한 할 수 있습니다 (이는 아마도 많은 CPU 시간을 차지합니다). 이로 인해 전송 라인과 배전 라인의 초기로드 시간이 20 초 이상으로 수 밀리 초로 줄어 들었습니다.

-

내가 당신이 해당 계층의 요구에 데이터를 요청하고 있는지 확인하고 있습니다에 대해 얘기했다. ID 1, 2, 3 및 4를 표시한다고 가정 해보십시오.

표시 1과 2는 0 -> 무한대로 표시됩니다. 3과 4가 20,000 피트에서 만 발을 차게하는 동안. 기본적으로 mapguide는 기본적으로 뷰포트의 경계 상자로 select *를 수행합니다. 그런 다음 테마를 적용하는 모든 데이터를 반복합니다.

그래서 30,000 피트에서 모든 데이터를 쿼리하지만 루프를 반복해야합니다.

Answer 2

간단한 대답은 데이터를 일반화하는 것입니다, 그래서, 그것은 시간이

즉, 적은 세부 사항이 몇 가지 추가 테이블을 만들 디스플레이에 최적화되어 있으며

Answer 3

당신이 이런 종류의 질문을 할 때마다 적은 밀도가 있어요 SQL 프로파일 러를 가져와 어떤 쿼리가 실행되고 있는지 확인하십시오. 그런 다음 쿼리 플래너를 실행하여 병목 현상이 어디인지 확인합니다.

나 같은 게으론 일 수도 있고 튜닝 템플릿을 사용하여 일반적인로드를 기록한 다음 데이터베이스 엔진 튜닝 관리자를 통해 실행하여 성능을 향상시키기 위해 인덱스를 추가 할 수 있다고 생각하는 부분을 확인할 수도 있습니다.

일반적으로 서버에 대해 실행되는 쿼리를 최적화 할 수도 있지만 MapGuide는 약간의 옵션이 있습니다. MapGuide가 SQL Server가 최적화하기 어려운 방식으로 질문을하고있을 수도 있습니다. 이 경우 찾으십시오. enter a ticket in the MapGuide Trac 시스템