29.4.1 Performance Schema Event Timing

29.4.1 Performance Schema Event Timing

Event는 서버 소스 코드에 추가된 instrumentation을 통해 수집됩니다. Instrument는 event에 대해 시간을 측정하며, 이를 통해 Performance Schema는 event가 얼마나 오래 걸리는지에 대한 개략적인 정보를 제공합니다. Instrument를 timing 정보를 수집하지 않도록 설정하는 것도 가능합니다. 이 섹션에서는 사용 가능한 timer와 그 특성, 그리고 event에서 timing 값이 어떻게 표현되는지에 대해 설명합니다.

Performance Schema Timers

Performance Schema timer는 정밀도와 오버헤드의 양이 서로 다릅니다. 사용 가능한 timer와 그 특성을 확인하려면 performance_timers table을 확인하십시오:

1mysql> SELECT * FROM performance_schema.performance_timers;
2+-------------+-----------------+------------------+----------------+
3| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
4+-------------+-----------------+------------------+----------------+
5| CYCLE       |      2389029850 |                1 |             72 |
6| NANOSECOND  |      1000000000 |                1 |            112 |
7| MICROSECOND |         1000000 |                1 |            136 |
8| MILLISECOND |            1036 |                1 |            168 |
9| THREAD_CPU  |       339101694 |                1 |            798 |
10+-------------+-----------------+------------------+----------------+

주어진 timer 이름에 연관된 값이 NULL이면, 해당 timer는 현재 플랫폼에서 지원되지 않는 것입니다.

각 컬럼의 의미는 다음과 같습니다:

• TIMER_NAME 컬럼은 사용 가능한 timer의 이름을 보여 줍니다. CYCLE은 CPU(프로세서) 사이클 카운터를 기반으로 하는 timer를 나타냅니다.

• TIMER_FREQUENCY는 1초당 timer 단위의 개수를 나타냅니다. 사이클 timer의 경우, frequency는 일반적으로 CPU 속도와 관련됩니다. 표시된 값은 2.4GHz 프로세서를 가진 시스템에서 얻은 값입니다. 다른 timer는 고정된 초 단위 분수에 기반합니다.

• TIMER_RESOLUTION은 timer 값이 한 번에 증가하는 timer 단위의 개수를 나타냅니다. timer의 해상도가 10이면, timer 값은 증가할 때마다 10만큼 증가합니다.

• TIMER_OVERHEAD는 주어진 timer로 타이밍을 한 번 얻기 위한 최소 사이클 수의 오버헤드입니다. event당 오버헤드는 표시된 값의 두 배인데, timer가 event의 시작과 끝에서 각각 한 번씩 호출되기 때문입니다.

Performance Schema는 timer를 다음과 같이 할당합니다:

• wait timer는 CYCLE을 사용합니다.

• idle, stage, statement, transaction timer는 플랫폼에서 NANOSECOND timer를 사용할 수 있는 경우 NANOSECOND를 사용하고, 그렇지 않으면 MICROSECOND를 사용합니다.

서버 시작 시, Performance Schema는 빌드 시점에 가정된 timer 할당이 올바른지 검증하고, timer를 사용할 수 없는 경우 경고를 표시합니다.

wait event의 타이밍에서 가장 중요한 기준은 timer 정확도를 어느 정도 희생하더라도 오버헤드를 줄이는 것입니다. 따라서 CYCLE timer를 사용하는 것이 가장 좋습니다.

statement(또는 stage)가 실행되는 데 걸리는 시간은 일반적으로 단일 wait를 실행하는 데 걸리는 시간보다 몇 자릿수 이상 더 깁니다. statement 타이밍에서는 프로세서 주파수 변화의 영향을 받지 않는 정확한 측정값을 얻는 것이 가장 중요한 기준이므로, 사이클 기반이 아닌 timer를 사용하는 것이 가장 좋습니다. statement의 기본 timer는 NANOSECOND입니다. CYCLE timer에 비해 추가되는 “오버헤드”는 중요하지 않은데, timer를 두 번(한 번은 statement 시작 시, 한 번은 종료 시) 호출하는 데 따른 오버헤드는 statement 자체를 실행하는 데 사용되는 CPU 시간에 비해 몇 자릿수 이상 작기 때문입니다. 이 경우 CYCLE timer를 사용하는 것은 이점 없이 단점만 가져옵니다.

사이클 카운터가 제공하는 정밀도는 프로세서 속도에 의존합니다. 프로세서가 1 GHz(초당 10억 사이클) 이상으로 동작한다면, 사이클 카운터는 서브 나노초 정밀도를 제공합니다. 사이클 카운터를 사용하는 것은 실제 시각(time of day)을 얻는 것보다 훨씬 비용이 적게 듭니다. 예를 들어, 표준 gettimeofday() 함수는 수백 사이클이 소요될 수 있으며, 이는 1초에 수천, 수백만 번 발생할 수 있는 데이터 수집 작업에 대해서는 받아들일 수 없는 오버헤드입니다.

그러나 사이클 카운터에는 다음과 같은 단점도 있습니다:

• 최종 사용자는 초의 분수와 같은 벽시계 단위로 타이밍을 보고자 합니다. 사이클을 초의 분수로 변환하는 작업은 비용이 많이 들 수 있습니다. 이러한 이유로 변환은 빠르고 상당히 대략적인 곱셈 연산으로 수행됩니다.

• 노트북이 절전 모드로 들어가거나 CPU가 발열을 줄이기 위해 속도를 낮추는 경우처럼 프로세서 사이클 속도가 변할 수 있습니다. 프로세서의 사이클 속도가 변동하면, 사이클을 실제 시간 단위로 변환하는 과정에서 오차가 발생할 수 있습니다.

• 프로세서나 운영 체제에 따라 사이클 카운터가 신뢰할 수 없거나 사용할 수 없을 수도 있습니다. 예를 들어, Pentium에서는 해당 명령어가 RDTSC(C 명령어가 아닌 어셈블리 언어 명령어)이며, 운영 체제가 유저 모드 프로그램이 이를 사용하지 못하도록 막는 것도 이론적으로 가능합니다.

• out-of-order execution 또는 멀티프로세서 동기화와 관련된 일부 프로세서 세부 사항 때문에 카운터가 최대 1000 사이클 정도 빠르거나 느리게 보일 수 있습니다.

MySQL은 x386(Windows, macOS, Linux, Solaris 및 기타 유닉스 계열), PowerPC, IA-64에서 사이클 카운터를 사용합니다.

Performance Schema Timer Representation in Events

현재 event와 과거 event를 저장하는 Performance Schema table의 row에는 타이밍 정보를 표현하기 위한 세 개의 컬럼이 있습니다. TIMER_START와 TIMER_END는 event가 시작되고 종료된 시점을 나타내고, TIMER_WAIT는 event duration을 나타냅니다.

setup_instruments table에는 어떤 instrument에 대해 event를 수집할지 나타내는 ENABLED 컬럼이 있습니다. 또한 어떤 instrument가 타이밍 대상인지 나타내는 TIMED 컬럼도 있습니다. instrument가 enabled 상태가 아니면 event를 생성하지 않습니다. enabled 상태인 instrument가 timed가 아니면, 해당 instrument가 생성하는 event는 TIMER_START, TIMER_END, TIMER_WAIT timer 값에 대해 NULL을 가집니다. 이는 다시 summary table에서 집계 시간 값(sum, minimum, maximum, average)을 계산할 때 이러한 값이 무시되도록 합니다.

내부적으로 event 내의 시간 값은 event 타이밍이 시작될 때 적용 중인 timer가 주는 단위로 저장됩니다. Performance Schema table에서 event를 조회하여 표시할 때는, 선택된 timer와 관계없이 시간을 표준 단위로 정규화하기 위해 피코초(1조분의 1초) 단위로 보여 줍니다.

Timer baseline(“time zero”)은 서버 시작 동안 Performance Schema가 초기화될 때 발생합니다. event 내의 TIMER_START와 TIMER_END 값은 baseline 이후 경과한 피코초를 나타냅니다. TIMER_WAIT 값은 피코초 단위의 duration입니다.

Event 내의 피코초 값은 근사치입니다. 이 값들의 정확도는 한 단위에서 다른 단위로 변환할 때 수반되는 일반적인 오차의 영향을 받습니다. CYCLE timer가 사용되고 프로세서 속도가 변할 경우, 드리프트가 발생할 수 있습니다. 이러한 이유로, event의 TIMER_START 값을 서버 시작 이후 경과 시간의 정확한 측정치로 간주하는 것은 합리적이지 않습니다. 반면, ORDER BY 절에서 event를 시작 시각이나 duration 기준으로 정렬하기 위해 TIMER_START 또는 TIMER_WAIT 값을 사용하는 것은 합리적입니다.

Event에서 마이크로초와 같은 값이 아닌 피코초를 사용하는 선택에는 성능상의 이유가 있습니다. 한 가지 구현 목표는 timer 종류에 관계없이 결과를 하나의 통일된 시간 단위로 보여 주는 것이었습니다. 이상적으로 이 시간 단위는 벽시계 단위처럼 보이고 어느 정도 정밀해야 합니다. 다시 말해 마이크로초 정도가 적합합니다. 그러나 사이클 또는 나노초를 마이크로초로 변환하려면, instrumentation마다 나눗셈을 수행해야 합니다. 나눗셈은 많은 플랫폼에서 비용이 많이 듭니다. 곱셈은 비용이 크지 않으므로, 실제로 사용되는 것은 곱셈입니다. 따라서 시간 단위는 가능한 가장 높은 TIMER_FREQUENCY 값에 어떤 multiplier를 곱한 정수배가 되며, 주요 정밀도 손실이 없도록 충분히 큰 multiplier가 사용됩니다. 그 결과 시간 단위는 “피코초”가 됩니다. 이 정밀도는 실제보다 과도하지만, 이 결정 덕분에 오버헤드를 최소화할 수 있습니다.

Wait, stage, statement, transaction event가 실행 중일 때, 해당 current-event table은 current-event 타이밍 정보를 표시합니다:

1events_waits_current
2events_stages_current
3events_statements_current
4events_transactions_current

아직 완료되지 않은 event가 얼마나 오랫동안 실행되고 있는지 알 수 있도록, timer 컬럼은 다음과 같이 설정됩니다:

• TIMER_START가 채워집니다.

• TIMER_END는 현재 timer 값으로 채워집니다.

• TIMER_WAIT는 지금까지 경과한 시간(TIMER_END − TIMER_START)으로 채워집니다.

아직 완료되지 않은 event의 END_EVENT_ID 값은 NULL입니다. event에 대해 지금까지 경과한 시간을 평가하려면 TIMER_WAIT 컬럼을 사용하십시오. 따라서 아직 완료되지 않았고 현재까지 N 피코초보다 오래 걸린 event를 식별하기 위해, 모니터링 애플리케이션은 query에서 다음 expression을 사용할 수 있습니다:

1WHERE END_EVENT_ID IS NULL AND TIMER_WAIT > N

방금 설명한 event 식별은 해당 instrument의 ENABLED와 TIMED가 YES로 설정되어 있고, 관련 consumer가 enabled 상태라고 가정합니다.