Video: https://data-artisans.com/flink-forward-berlin/resources/monitoring-flink-with-prometheus
Live Demo Code: https://github.com/mbode/flink-prometheus-example
Prometheus is a cloud-native monitoring system prioritizing reliability and simplicity – and Flink works really well with it! This session will show you how to leverage the Flink metrics system together with Pronetheus to improve the observability of your jobs. There will be a live demo establishing how everything ties in together. The talk is aimed at people already building and running Flink jobs who would like to gain more insight into them. It is fine if you are not familiar with Prometheus yet as the basic concepts will be introduced. If you have ever wondered how you could use modern monitoring tools to be alerted in the middle of the night in case your Flink job‘s 99th percentile end-to-end latency degraded for some reason, this might just be the talk you are looking for.
Under the Hood of a Shard-per-Core Database ArchitectureScyllaDB
Most databases are based on architectures that pre-date advances to modern hardware. This results in performance issues, the need to overprovision, and a high total cost of ownership. In this webinar we will discuss the advances to modern server technology and take a deep dive into Scylla’s shard-per-core architecture and our asynchronous engine, the Seastar framework.
Join us to learn how Seastar (and Scylla):
Avoid locks and contention on the CPU level
Bypass kernel bottlenecks
Implement its per-core shared-nothing autosharding mechanism
Utilize modern storage hardware
Leverage NUMA to get the best RAM performance
Balance your data across CPUs and nodes for best and smoothest performance
Plus we’ll cover the advantages of unlocking vertical scalability.
Improve PostgreSQL replication with Oracle GoldenGateBobby Curtis
PostgreSQL databases use the Write-Ahead Logging approach for the replication of data. At the same time, customers worldwide have asked for Oracle GoldenGate to support replication to and from PostgreSQL databases. The wait is over! This session will introduce Oracle GoldenGate for PostgreSQL and highlight what needs to be looked at to ensure successful replication for any PostgreSQL environment.
Video: https://data-artisans.com/flink-forward-berlin/resources/monitoring-flink-with-prometheus
Live Demo Code: https://github.com/mbode/flink-prometheus-example
Prometheus is a cloud-native monitoring system prioritizing reliability and simplicity – and Flink works really well with it! This session will show you how to leverage the Flink metrics system together with Pronetheus to improve the observability of your jobs. There will be a live demo establishing how everything ties in together. The talk is aimed at people already building and running Flink jobs who would like to gain more insight into them. It is fine if you are not familiar with Prometheus yet as the basic concepts will be introduced. If you have ever wondered how you could use modern monitoring tools to be alerted in the middle of the night in case your Flink job‘s 99th percentile end-to-end latency degraded for some reason, this might just be the talk you are looking for.
Under the Hood of a Shard-per-Core Database ArchitectureScyllaDB
Most databases are based on architectures that pre-date advances to modern hardware. This results in performance issues, the need to overprovision, and a high total cost of ownership. In this webinar we will discuss the advances to modern server technology and take a deep dive into Scylla’s shard-per-core architecture and our asynchronous engine, the Seastar framework.
Join us to learn how Seastar (and Scylla):
Avoid locks and contention on the CPU level
Bypass kernel bottlenecks
Implement its per-core shared-nothing autosharding mechanism
Utilize modern storage hardware
Leverage NUMA to get the best RAM performance
Balance your data across CPUs and nodes for best and smoothest performance
Plus we’ll cover the advantages of unlocking vertical scalability.
Improve PostgreSQL replication with Oracle GoldenGateBobby Curtis
PostgreSQL databases use the Write-Ahead Logging approach for the replication of data. At the same time, customers worldwide have asked for Oracle GoldenGate to support replication to and from PostgreSQL databases. The wait is over! This session will introduce Oracle GoldenGate for PostgreSQL and highlight what needs to be looked at to ensure successful replication for any PostgreSQL environment.
Benchmarking is hard. Benchmarking databases, harder. Benchmarking databases that follow different approaches (relational vs document) is even harder.
But the market demands these kinds of benchmarks. Despite the different data models that MongoDB and PostgreSQL expose, many organizations face the challenge of picking either technology. And performance is arguably the main deciding factor.
Join this talk to discover the numbers! After $30K spent on public cloud and months of testing, there are many different scenarios to analyze. Benchmarks on three distinct categories have been performed: OLTP, OLAP and comparing MongoDB 4.0 transaction performance with PostgreSQL's.
What would be faster, MongoDB or PostgreSQL?
Spark Operator—Deploy, Manage and Monitor Spark clusters on KubernetesDatabricks
Have you ever wondered how to implement your own operator pattern for you service X in Kubernetes? You can learn this in this session and see an example of open-source project that does spawn Apache Spark clusters on Kubernetes and OpenShift following the pattern. You will leave this talk with a better understanding of how spark-on-k8s native scheduling mechanism can be leveraged and how you can wrap your own service into operator pattern not only in Go lang but also in Java. The pod with spark operator and optionally the spark clusters expose the metrics for Prometheus so it makes it eas
Spark 의 핵심은 무엇인가? RDD! (RDD paper review)Yongho Ha
요즘 Hadoop 보다 더 뜨고 있는 Spark.
그 Spark의 핵심을 이해하기 위해서는 핵심 자료구조인 Resilient Distributed Datasets (RDD)를 이해하는 것이 필요합니다.
RDD가 어떻게 동작하는지, 원 논문을 리뷰하며 살펴보도록 합시다.
http://www.cs.berkeley.edu/~matei/papers/2012/sigmod_shark_demo.pdf
Cassandra Day NY 2014: Apache Cassandra & Python for the The New York Times ⨍...DataStax Academy
In this session, you’ll learn about how Apache Cassandra is used with Python in the NY Times ⨍aбrik messaging platform. Michael will start his talk off by diving into an overview of the NYT⨍aбrik global message bus platform and its “memory” features and then discuss their use of the open source Apache Cassandra Python driver by DataStax. Progressive benchmark to test features/performance will be presented: from naive and synchronous to asynchronous with multiple IO loops; these benchmarks tailored to usage at the NY Times. Code snippets, followed by beer, for those who survive. All code available on Github!
※다운로드하시면 더 선명한 자료를 보실 수 있습니다.
동접 200만 명이 접속할 수백 대의 게임 서버가 최소한의 MySQL 서버만으로 서비스할 수 있는 구조를 설명합니다.
고성능/고효율의 MySQL 스케일링 기법을 공유합니다. 대규모 게임 서비스에서 이미 검증된 것은 안 비밀~
목차
1. 기본적인 아기텍처
2. ProxySQL을 이용한 더 나은 아키텍처
3. 최종 아키텍처
대상
- 대규모 게임 서비스에 MySQL을 사용한 경험에 관심 있는 분
- ProxySQL에 관심이 있는 서버 개발자 혹은 DBA
- 게임 서버 개발 과정에서 DB 쪽을 유연하게 구성하고 싶은 분
■관련 동영상: https://youtu.be/8Eb_n7JA1yA
As companies adopt data processing technologies and add data-driven features to user-facing products, the need for effective automated test techniques for data processing applications increase. We go through anatomy of scalable data streaming applications, and how to set up test harnesses for reliable integration testing of such applications. We cover a few common anti-patterns that make asynchronous tests fragile, and corresponding patterns for remediation. We will also mention virtualisation components suitable for our testing scenarios.
Benchmarking is hard. Benchmarking databases, harder. Benchmarking databases that follow different approaches (relational vs document) is even harder.
But the market demands these kinds of benchmarks. Despite the different data models that MongoDB and PostgreSQL expose, many organizations face the challenge of picking either technology. And performance is arguably the main deciding factor.
Join this talk to discover the numbers! After $30K spent on public cloud and months of testing, there are many different scenarios to analyze. Benchmarks on three distinct categories have been performed: OLTP, OLAP and comparing MongoDB 4.0 transaction performance with PostgreSQL's.
What would be faster, MongoDB or PostgreSQL?
Spark Operator—Deploy, Manage and Monitor Spark clusters on KubernetesDatabricks
Have you ever wondered how to implement your own operator pattern for you service X in Kubernetes? You can learn this in this session and see an example of open-source project that does spawn Apache Spark clusters on Kubernetes and OpenShift following the pattern. You will leave this talk with a better understanding of how spark-on-k8s native scheduling mechanism can be leveraged and how you can wrap your own service into operator pattern not only in Go lang but also in Java. The pod with spark operator and optionally the spark clusters expose the metrics for Prometheus so it makes it eas
Spark 의 핵심은 무엇인가? RDD! (RDD paper review)Yongho Ha
요즘 Hadoop 보다 더 뜨고 있는 Spark.
그 Spark의 핵심을 이해하기 위해서는 핵심 자료구조인 Resilient Distributed Datasets (RDD)를 이해하는 것이 필요합니다.
RDD가 어떻게 동작하는지, 원 논문을 리뷰하며 살펴보도록 합시다.
http://www.cs.berkeley.edu/~matei/papers/2012/sigmod_shark_demo.pdf
Cassandra Day NY 2014: Apache Cassandra & Python for the The New York Times ⨍...DataStax Academy
In this session, you’ll learn about how Apache Cassandra is used with Python in the NY Times ⨍aбrik messaging platform. Michael will start his talk off by diving into an overview of the NYT⨍aбrik global message bus platform and its “memory” features and then discuss their use of the open source Apache Cassandra Python driver by DataStax. Progressive benchmark to test features/performance will be presented: from naive and synchronous to asynchronous with multiple IO loops; these benchmarks tailored to usage at the NY Times. Code snippets, followed by beer, for those who survive. All code available on Github!
※다운로드하시면 더 선명한 자료를 보실 수 있습니다.
동접 200만 명이 접속할 수백 대의 게임 서버가 최소한의 MySQL 서버만으로 서비스할 수 있는 구조를 설명합니다.
고성능/고효율의 MySQL 스케일링 기법을 공유합니다. 대규모 게임 서비스에서 이미 검증된 것은 안 비밀~
목차
1. 기본적인 아기텍처
2. ProxySQL을 이용한 더 나은 아키텍처
3. 최종 아키텍처
대상
- 대규모 게임 서비스에 MySQL을 사용한 경험에 관심 있는 분
- ProxySQL에 관심이 있는 서버 개발자 혹은 DBA
- 게임 서버 개발 과정에서 DB 쪽을 유연하게 구성하고 싶은 분
■관련 동영상: https://youtu.be/8Eb_n7JA1yA
As companies adopt data processing technologies and add data-driven features to user-facing products, the need for effective automated test techniques for data processing applications increase. We go through anatomy of scalable data streaming applications, and how to set up test harnesses for reliable integration testing of such applications. We cover a few common anti-patterns that make asynchronous tests fragile, and corresponding patterns for remediation. We will also mention virtualisation components suitable for our testing scenarios.
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
클라우드/IDC 운영자를 위한 서버 및 도커 컨테이너 모니터링 솔루션 (old version)옥시즌
‘인사이트뷰 모니터링 (insightVew Monitoring)’ 솔루션은 클라우드/IDC 운영자를 위한 서버 및 도커 컨테이너 모니터링 솔루션으로 Linux/Unix, Windows 서버 OS 및 도커 컨테이너에 대한 장애/성능/구성정보 모니터링을 통하여 IT 인프라 서버의 안정적인 운영을 지원합니다. 서버에 대한 주요 상태 정보를 직관적으로 파악하고 관리할 수 있도록 효율적인 각종 기능을 제공하고 있습니다.
- Linux/Unix, Windows 서버 통합 모니터링 관리 지원
- 계정그룹을 통한 관리자 계정 권한 위임
- 서버 OS 및 도커 컨테이너 통합 모니터링 지원
- Port 및 URL 모니터링 지원
- MySQL/MrariaDB 모니터링 지원
- 사용자 스크립트 실행을 통한 모니터링 지원
- 모니터링 설정 기본값 적용에 따른 설치 즉시 사용 가능
- 태스크 별 적용을 통한 유연한 모니터링 항목 관리
- 현 상태 정보 제공을 통한 모니터링 설정의 편의성 제공
- 통지 메시지에 대한 데이터 속성값 매핑 지원
- 장애 이벤트의 다양한 통지 방법 제공(이메일, 슬랙, 텔레그램 등)
- DB 연계를 통한 대시보드 구성
Cloud-Barista 제1차 오픈세미나 : CB-Dragonfly-멀티 클라우드 통합 모니터링 프레임워크(1st Open Seminar...Cloud-Barista Community
멀티 클라우드 서비스 공통 프레임워크 기술(Multi-Cloud Service Common Framework)
- 커뮤니티 사이트(Community Site) : https://github.com/cloud-barista
주요 내용 : 멀티 클라우드 통합 모니터링 기술(CB-Dragonfly)
- CB-Dragonfly 개요 및 차별성
- CB-Dragonfly 주요 기능 및 모듈
- CB-Dragonfly 개발 추진 방향
2014년 5월 28일 일본에서 진행된 AWS 기술 웨비나의 발표 자료를 한국의 정윤진 솔루션스 아키텍트가 한글로 번역한 자료입니다. 웨비나 당시와 현재의 내용이 상이한 부분이 있을 수 있으니 자료 열람에 이 점 참고하시기 바라며, 혹 내용에 대한 문의사항이 있으신 경우 info-kr@amazon.com으로 연락 부탁드리겠습니다.
서버, 도커 컨테이너, 데이터베이스, 네트워크, 쿨링랙, 서버 취약점 등 IT 인프라 모니터링 솔루션 (old version)옥시즌
‘인사이트뷰 모니터링 (insightVew Monitoring)’ 솔루션은 클라우드/IDC 운영자를 위한 IT 인프라 모니터링 솔루션으로 Linux/Unix, Windows 서버 OS 및 도커 컨테이너, 데이터베이스, 네트워크, 쿨링랙, 서버 취약점 등 IT 인프라 자원에 대한 장애/성능/구성정보 모니터링을 통하여 IT 인프라 자원의 안정적인 운영을 지원합니다. IT 인프라 자원에 대한 주요 상태 정보를 직관적으로 파악하고 관리할 수 있도록 효율적인 각종 기능을 제공하고 있습니다.
- Linux/Unix, Windows 서버 통합 모니터링 관리 지원
- 계정그룹을 통한 관리자 계정 권한 위임
- 서버 OS 및 도커 컨테이너 통합 모니터링 지원
- Port 및 URL 모니터링 지원
- MySQL/MrariaDB 등 데이터베이스 모니터링 지원
- SNMP를 통한 네트워크 장비 모니터링 지원
- 쿨링랙(Cooling Rack) 컨트롤러 모니터링 지원
- 서버 OS 취약점 분석 지원
- 사용자 스크립트 실행을 통한 모니터링 지원
- 모니터링 설정 기본값 적용에 따른 설치 즉시 사용 가능
- 태스크 별 적용을 통한 유연한 모니터링 항목 관리
- 현 상태 정보 제공을 통한 모니터링 설정의 편의성 제공
- 통지 메시지에 대한 데이터 속성값 매핑 지원
- 장애 이벤트의 다양한 통지 방법 제공(이메일, 슬랙, 텔레그램 등)
- DB 연계를 통한 대시보드 구성
2. 발표자 소개
2
강 성 욱
SQL 관련 블로그 운영 (http://sqlmvp.kr)
https://www.facebook.com/sqlmvp
jevida@naver.com
Microsoft SQL Server MVP
ServicePoint
Windows, IIS, SQL Server 모니터링 솔루션
http://www.nwiz.co.kr
(데모 : http://demo.nwiz.co.kr)
SQL Server 스터디 그룹 (http://sqltag.org)
SQL Server 커뮤니티 (http://sqler.com)
3. AGENDA
성능 베이스 라인의 필요성
윈도우 성능 모니터 설정 하기
SQL Server 프로파일러와 교차분석 설정
주요 성능 카운터
3
4. 성능 베이스라인 데이터의 필요성
성능 베이스라인 데이터?
일반적인 운영환경에서 시스템의 성능을 수집하여 데이터베이스 및 파일화를 통해 저장한 데이터
저장된 데이터를 분석하여 시스템의 최적화된 데이터를 산출
베이스라인 데이터는 왜 필요한가?
현재의 성능 값이 일반적인 상황과 비교했을때 다른 점을 비교하기 위해 필요
미래에 대한 계획을 수립하기 위해서 필요
4
현재 아이들링 RPM은 정상인가요?
5. 성능 베이스라인 데이터의 필요성
성능 베이스라인은 case by case
시스템 또는 비즈니스 따라 하드웨어 특성 및 리소스가 다르다.
따라서 임계치가 다르기 때문에 평소 베이스라인이 꼭 필요하다.
5
디젤 자동차 계기판 가솔린 자동차 계기판
현재 RPM이 5000으로 동일 할 경우 어떻게 판단해야하는가?
6. DBA는 운영되는 시스템 성격에 따라 모니터링 데이터를 저장하여 베이스라인 데이터로
활용
성능 문제는 다양한 원인으로 발생할 수 있기 때문에 수많은 상황을 분석하기 위해서는
신뢰하는 다양한 베이스라인 데이터가 필요
6
성능 베이스라인 데이터의 필요성
7. 윈도우 성능 모니터
Perfmon(Performance Monitor)은 Windows에서 기본적으로 제공하는 성능 수집 도구
CPU, Memory, Disk, Network를 포함한 다양한 성능 데이터 수집
Add-in으로 카운터 추가 가능 (예, SQL Server 설치시 SQL 관련 성능 카운터 추가)
실시간 성능 모니터링 가능
파일이나 DB로 성능 데이터를 저장하여 분석 가능
프로파일러와 연동
윈도우8은 29,000 이상의 표준 카운터 제공
7
8. 윈도우 성능 모니터
성능카운터는 카테고리 / 인스턴스 / 카운터 계층으로 관리
8
• 카테고리 : CPU, 디스크 응용프로그램 등 관심
영역을 나타냄.
• 인스턴스 : 기본적으로 한 개 이상의 인스턴스
가 존재하며 디스크 드라이브 경우 C, D, E처럼
다수의 인스턴스가 존재.
• 카운터 : 실제 성능정보는 개별 카운터에 기록
됨.
• 마이크로소프트는 C함수, C# 래퍼 클래스 세트
로 성능 카운터에 대한 액세스를 제공.
13. Perfmon 사용법
특정 카운터 정보를 강조해서 표시할 경우 [하이라이트] 아이콘 사용
자주 사용하는 카운터는 파일로 저장해서 사용 (htm, xml 파일로 저장됨)
13
14. Perfmon 성능 데이터 수집 (1)
데이터 수집기 집합을 설정하여 주기적으로 성능 데이터를 수집
수집된 데이터는 txt, blg등 파일 저장 가능
수집된 데이터는 ODBC를 통해 데이터베이스에 저장 가능
14
15. Perfmon 성능 데이터 수집 (1)
수집할 데이터 로그를 선택
성능카운터에 대한 정보를 수집하기 위해 성능 카운터 선택
너무 많은 성능 카운터 추가 및 짧은 샘플간격은 시스템 오버헤드를 발생 (중요)
15
16. Perfmon 성능 데이터 수집 (1)
수집된 데이터를 저장할 경로를 선택
수집기에서 사용할 계정 선택 (기본값 선택)
16
17. Perfmon 성능 데이터 수집 (1)
생성이 완료되면 수집기 집합에 작업이 추가된 것을 확인
수집 형태의 기본값은 이진 형식이며 blg 확장자로 파일 저장
17
18. Perfmon 성능 데이터 수집 (1)
저장될 파일명은 사용자가 지정 가능
설정된 내용은 하단의 [파일 이름 예]에서 확인
18
구분자 []를 사용하여 파일 이름 구성
19. Perfmon 성능 데이터 수집 (1)
하나의 폴더에 성능 데이터 파일이 위치 -> 하위 디렉터리 이름 형식 삭제
19
20. Perfmon 성능 데이터 수집 (1)
일정 등록으로 시스템 재시작 경우에도 자동으로 시작 되도록 설정
20
21. Perfmon 성능 데이터 수집 (1)
수집 자동화의 중지 조건 설정
특정 시간 또는 수집 파일 크기를 설정하여 수집 중단 가능
아래 예시의 경우 매일 1개의 데이터 수집 파일 생성
21
22. Perfmon 성능 데이터 수집 (1)
성능 데이터 수집기 시작/중지 아이콘으로 수집 시작
설정된 경로에서 성능 데이터 파일 생성되어 데이터 수집 확인
22
23. Perfmon 성능 데이터 수집 (1)
Report 메뉴에서 수집된 성능 데이터 확인 가능
성능 데이터 수집 활동이 중지되어 있을때만 데이터 확인 가능
23
데이터 수집 실행 데이터 수집 중지
24. Perfmon 데이터와 Profiler 데이터 교차 분석
프로파일러에서 수집한 trc 파일과 수집한 성능 데이터 가져오기 선택
성능 카운터 목록에서 상관 관계를 지정할 카운터를 선택
24
25. Perfmon 데이터와 Profiler 데이터 교차 분석
추적 데이터와 성능 데이터를 한번에 비교 분석.
그래프의 특정 위치를 클릭하면 프로파일러도 동일한 시간으로 이동
25
26. Perfmon 성능 데이터 수집 (2)
SQL Server에 성능 데이터를 저장하기위해 ODBC 원본 생성
26
27. Perfmon 성능 데이터 수집 (2)
SQL Server에 성능 데이터를 저장하기위해 ODBC 원본을 생성
27
28. Perfmon 성능 데이터 수집 (2)
SQL Server에 성능 데이터를 저장하기위해 ODBC 원본을 생성
28
29. Perfmon 성능 데이터 수집 (2)
SQL Server에 성능 데이터를 저장하기위해 ODBC 원본을 생성
29
30. Perfmon 성능 데이터 수집 (2)
성능 정보를 저장하기 위한 테이블이 자동으로 생성되어 데이터 저장
30
CounterData
GUID : 데이터 세트에 대한 GUID, DisplayTOID 테이블과 조인키로 사용
CounterID : 카운터 식별. CouterDetails 테이블과 조인키로 사용
RecordIndex : 특정 카운터 식별자 및 GUID의 샘플 인덱스.
CouterDateTime : 시작된 시간 (UTC 사용)
CounterValue : 실제 성능 값.
31. Perfmon 성능 데이터 수집 (2)
테이블을 조인하여 수집된 성능 데이터를 조회
31
SELECT
MachineName ,
CounterName ,
InstanceName ,
CounterValue ,
CounterDateTime ,
DisplayString
FROM dbo.CounterDetails cdt
INNER JOIN dbo.CounterData cd
ON cdt.CounterID = cd.CounterID
INNER JOIN DisplayToID d
ON d.GUID = cd.GUID
WHERE MachineName = 'KANGSUNGWOOK-PC'
AND ObjectName = 'Processor'
AND cdt.CounterName = '% Processor Time'
AND cdt.InstanceName = '_Total'
ORDER BY CounterDateTime
32. Perfmon 성능 데이터 수집 (2)
다양한 도구를 이용하여 분석
32
EXCEL
SSRS (Unplugged 5th 세미나 참고)
전문 모니터링 툴
33. SQL Server 데이터 컬렉션
다양한 데이터 집합을 수집하는 구성 요소 (SQL Server에 기본 포함)
항상 실행 또는 사용자 정의에 따라 실행 가능
수집된 데이터는 관계형 데이터베이스에 저장
데이터 수집기를 사용하면 사용자 환경에 맞는 데이터 컬렉션 범위 조정 가능
데이터 보존 기간을 설정하여 관리
데이터 컬렉션에 대한 동적 튜닝을 지원하며 API를 통해 확장 가능.(데이터 수집기 프로
그래밍 참고)
다양한 시각화 보고서 제공
33
34. SQL Server 데이터 컬렉션
다양한 시각화 보고서 제공
34
종류 설명
디스크 사용 요약 보고서
SQL Server 인스턴스에 있는 모든 데이터베이스의 디스크 공간 정보 제공
데이터 및 로그파일에 대한 증가 추세 제공(그래픽, 숫자)
데이터베이스 시작 크기와 현재 크기를 MB 단위로 표시
인덱스 페이지, 할당되지 않는 공간 등 정보 제공
쿼리 통계 기록 보고서
쿼리 실행 통계 정보 제공
총 CPU별 상위 쿼리 정보 제공 (그래프, 쿼리, 쿼리 비용 등)
물리적 읽기, 논리적 쓰기 등 상세 쿼리 세부 정보 제공
쿼리 계획 제공 (그래픽)
서버 작업 기록 보고서
서버 및 SQL Server 인스턴스의 리소스 사용 및 서버 작업 데이터 제공
CPU, 메모리, 디스크I/O, 네트워크 사용량 제공 (추세 그래프, 숫자)
SQL Server 대기 작업 분석 데이터 제공
SQL Server 컴파일, 리컴파일, 세션, 캐시 적중률, tempdb 등 정보 제공
35. SQL Server 데이터 컬렉션
데이터 수집기 아키텍처
35
• 데이터 수집기는 SQL Server 에이전트 및 SSIS와 통합되어 사용
• SSIS는 개별 데이터 공급자에서 데이터 수집 패키지 실행에 사용
• 클라이언트 : 데이터 수집기의 사용자 인터페이스
• API : 사용자 인터페이스와 데이터 수집기간의 상호작용에 사용
• 실행 : 데이터 컬렉션 및 저장소에 사용
• 저장소 : 구성 정보 및 수집된 데잍를 포함하는 데이터베이스
42. 시스템 주요 성능 카운터
임계값은 절대적인 수치가 아니며 시스템 다름 (슬라이드 값은 참고만 할것)
베이스 라인 데이터로 시스템에 최적화된 임계값을 산출 하는 것이 중요
42
43. 시스템 주요 성능 카운터
CPU 사용량
43
객체 카운터 임계값 설명
Processor % Processor Time < 80 시스템에서 사용하는 전체 CPU 사용량을 백분율로 표시
System Processor Queue Length < 코어수 * 2 프로세서 시간동안 대기하는 스레드 수 (실행되고 있는 스레드수 제외)
System Context switches/sec < 6000 초당 발생하는 컨텍스트 스위치 수
44. 시스템 주요 성능 카운터
Memory 사용량
44
객체 카운터 임계값 설명
Memory
Available Bytes > 100MB 시스템에서 사용할 수 있는 실제 메모리
Committed Bytes
< 90% (물리
메모리 대비)
커밋된 가상 메모리. 커밋 크기가 물리 메모리보다 크다면 페이징 발생.
Page Faults/sec 초당 페이지 폴트 수. 하드페이지 오류는 디스크 액세스로 인한 지연 발생 가능.
Page Reads/sec 페이지 폴트를 해결하기 위해 디스크에서 읽은 비율
Page Write/sec 메모리 공간을 비우기 위해 페이지를 디스크에 쓴 비율
Pages/sec < 30 초당 페이지 파일을 사용한 수
Pages Input/sec < 10 초당 페이징 파일을 사용한 수. 읽기 연산 중에 메모리로 읽은 평균 페이지 수
Pages Output/sec 실제 메모리 공간을 비우기 위해 디스크에 다시 쓴 페이지 비율
45. 시스템 주요 성능 카운터
Network 사용량
45
객체 카운터 임계값 설명
Network Interface Bytes Received/sec 받은 받이트 수
Network Interface Bytes Sent/sec 보낸 바이트 수
Network Interface Bytes Total/sec Bytes Sent/sec + Bytes Total/sec
Network Interface Current Bandwidth 현재 대역폭을 초당 비트로 추정한 값
Network Interface Output Queue Length < 2 출력 패킷의 큐 길이. 값이 2보다 크면 네트워크 병목 발생
46. 시스템 주요 성능 카운터
DISK 사용량
46
객체 카운터 임계값 설명
LogicalDisk,
PhysicalDisk
% Disk Time 읽기 및 쓰기 요청을 처리하는데 사용한 시간의 백분율 (낮을 수록 좋음)
% Idle Time 샘플 간격동안 디스크가 유휴 상태였던 시간의 백분율(높을 수록 좋음)
Avg. Disk Bytes/Read 읽기 평균 바이트 수
Avg. Disk Bytes/Write 쓰기 평균 바이트 수
Avg. Disk Queue Length 요청이 처리되지 못하고 디스크 큐에 쌓여있는 평균 수 (낮은 수록 좋음)
Current Disk Queue Length 성능 데이터를 수집할 당시 디스크에서 기다리는 요청 수
LogicalDisk Free Megabytes 디스크에 사용가능한 공간 (논리 디스크에 해당)
47. SQL 주요 성능 카운터
SQL Server 성능에 영향을 미치는 카운터
47
객체 카운터 임계값 설명
SQLServer:Acc
ess Methods
Page Splits/sec <20% (배치대비) 인덱스 페이지 오버플로우로 발생한 초당 페이지 분할 수
Workfiles Created/sec < 20
초당 생성된 임시 파일 수.
(해시조인 및 해시 집계에 대한 임시 결과 저장)
Worktable Created/sec < 20
초당 생성된 임시 테이블 수.
(스풀, LOB 변수, XML 변수, 커서에 대한 임시 결과 저장)
Full Scans/sec 초당 전체 검색 수
SQLServer:Buf
fer Manager
Page Lookups/sec < 100 (배치 대비) 버퍼풀에서 페이지를 찾기 위한 요청 수
Buffer cache hit ratio 디스크에서 읽기 않고 버퍼풀에서 찾은 페이지 비율
Checkpoint pages/sec 커밋되지 않은 페이지가 검사점에 의해 플러시된 페이지 수
Lazy write/sec 버퍼 관리자의 지연기록기가 기록한 버퍼 수
Page life expectancy > 300 페이지가 참조 없이 메모리에 머무르는 시간(초)
SQLServer:Dat
abases
LogBytes Flushed/sec 플러시된 총 로그 바이트 수
Log Growths 데이터베이스의 총 로그 증가 수
48. SQL 주요 성능 카운터
SQL Server 성능에 영향을 미치는 카운터
48
객체 카운터 임계값 설명
SQLServer:General Statistics User Connections 시스템에 연결된 사용자 수
SQLServer:Latch Avg Latch Wait Time(ms) 평균 래치 대기 시간
SQLServer:Locks
Number of Deadlocks/sec < 1 교착 상태를 일으킨 잠금 요청 수
Lock Wait/sec 즉시 처리 될 수 없어서 잠금을 기다리는 요청 수
Lock Requests/sec < 1000 초당 잠금 요청 수
Lock Timeouts/sec < 1 시간 초과된 잠금 요청 수 (NOWAIT 잠금에 대한 요청 포함)
SQLServer:Databases
LogBytes Flushed/sec 플러시된 총 로그 바이트 수
Log Growths 데이터베이스의 총 로그 증가 수 (누적값 기록)
49. SQL 주요 성능 카운터
SQL Server 성능에 영향을 미치는 카운터
49
객체 카운터 임계값 설명
SQLServer:
Memory
Manager
Granted Workspace
Memory(KB)
실행 중인 프로세스에 부여된 총 메모리.
해시, 정렬, 인덱스 생성에 사용
Maximum Workspace
Memory(KB)
프로세스에 부여될 수 있는 최대 메모리.
주로 해시, 정렬, 인덱스 생성에 사용
Target Server Memory (KB) SQL Server가 사용할 수 있는 전체 메모리 양
Total Server Memory (KB) < Target Server Memory SQL Server가 사용중인 총 동적 메모리 양
SQLServer:
SQL
Statistics
Batch Requests/sec 수신된 SQL 요청 수
SQL Compilations/sec < 10% (배치 대비) SQL 컴파일 횟수
SQL Re-Compilation/sec < 10% (컴파일 대비) SQL 리컴파일 횟수
SQLServer:
Wait
Statistics
Log write waits 로그 버퍼 작성을 기다리는 프로세스 통계
Network IO waits 네트워크 IO 대기와 관련된 통계
50. SQL 주요 성능 카운터
50
SQL Server 성능에 영향을 미치는 카운터
객체 카운터 임계값 설명
SQLServer:General
Statistics
Login/sec
Logout/sec
초당 시작된 총 로그인/로그아웃 수
SQLServer:Transact
ions
Longest
Transaction
Running Time
트랜 잭션 중 가장 긴 실행 시간(초)
SQLServer:Cusor
Manager by Type
Active Cusors 활성 커서 수
SQLServer:Access
Methods
Table Lock
Escalations/sec
테이블에 Lock이 발생할 때 해당 테이블에 계속적으로 발생하는 초당
Lock 수
51. 정리
현재의 성능 값이 일반적인 상황과 비교했을때 다른 점을 비교하기 위해 베이스라인 데
이터 필요하다.
성능 정보는 꾸준히 수집 보관한다. (과거 기록 비교시 중요함)
성능 데이터는 필요한 정보만 수집한다. (오버헤드 가능성)
성능 데이터의 임계값은 시스템마다 상대적이므로 베이스라인 데이터를 기초로 최적의
임계값을 찾는것이 중요하다.
시스템에 문제가 발생하였을때 특정 성능 데이터로만 찾는것은 힘들며 다양한 데이터를
교차분석하는 안목이 필요하다.
51