29.4.2 Performance Schema Event Filtering

29.4.2 Performance Schema Event Filtering

Event는 producer/consumer 방식으로 처리됩니다:

• Instrumented 코드(instrumentation된 코드)는 event의 소스이며, 수집할 event를 생성합니다.
  setup_instruments table은 어떤 instrument에 대해 event를 수집할 수 있는지, 그것들이 활성화되어 있는지, 그리고 (활성화된 instrument에 대해) 타이밍 정보를 수집할지 여부를 나열합니다:

1mysql> SELECT NAME, ENABLED, TIMED
2         FROM performance_schema.setup_instruments;
3+---------------------------------------------------+---------+-------+
4| NAME                                              | ENABLED | TIMED |
5+---------------------------------------------------+---------+-------+
6...
7| wait/synch/mutex/sql/LOCK_global_read_lock        | YES     | YES   |
8| wait/synch/mutex/sql/LOCK_global_system_variables | YES     | YES   |
9| wait/synch/mutex/sql/LOCK_lock_db                 | YES     | YES   |
10| wait/synch/mutex/sql/LOCK_manager                 | YES     | YES   |
11...

setup_instruments table은 event 생성에 대한 가장 기본적인 형태의 제어를 제공합니다. 모니터링되는 오브젝트나 스레드의 타입에 따라 event 생성을 더 세밀하게 조정하기 위해서는,
Section 29.4.3, “Event Pre-Filtering”에 설명된 대로 다른 table을 사용할 수 있습니다.

• Performance Schema table은 event의 목적지이며 event를 소비합니다.
  setup_consumers table은 event 정보를 보낼 수 있는 consumer 타입과 그들이 활성화되어 있는지를 나열합니다:

1mysql> SELECT * FROM performance_schema.setup_consumers;
2+----------------------------------+---------+
3| NAME                             | ENABLED |
4+----------------------------------+---------+
5| events_stages_current            | NO      |
6| events_stages_history            | NO      |
7| events_stages_history_long       | NO      |
8| events_statements_cpu            | NO      |
9| events_statements_current        | YES     |
10| events_statements_history        | YES     |
11| events_statements_history_long   | NO      |
12| events_transactions_current      | YES     |
13| events_transactions_history      | YES     |
14| events_transactions_history_long | NO      |
15| events_waits_current             | NO      |
16| events_waits_history             | NO      |
17| events_waits_history_long        | NO      |
18| global_instrumentation           | YES     |
19| thread_instrumentation           | YES     |
20| statements_digest                | YES     |
21+----------------------------------+---------+

Filtering은 퍼포먼스 모니터링의 서로 다른 단계에서 수행될 수 있습니다:

• Pre-filtering.
  이는 Performance Schema 설정을 수정하여 producer로부터 특정 타입의 event만 수집하고, 수집된 event가 특정 consumer만 갱신하도록 하는 것입니다. 이를 위해 instrument 또는 consumer를 활성화하거나 비활성화합니다. Pre-filtering은 Performance Schema에 의해 수행되며 모든 사용자에게 적용되는 글로벌 효과를 가집니다.

Pre-filtering을 사용하는 이유:

• 오버헤드를 줄이기 위해서입니다. 모든 instrument를 활성화하더라도 Performance Schema 오버헤드는 최소한이어야 하지만, 이를 더 줄이고 싶을 수 있습니다. 또는 타이밍 event에 관심이 없어 타이밍 오버헤드를 제거하기 위해 타이밍 코드를 비활성화하고 싶을 수 있습니다.

• 관심이 없는 event로 current-events 또는 history table이 채워지는 것을 피하기 위해서입니다. Pre-filtering은 이러한 table에서 활성화된 instrument 타입의 row 인스턴스를 위한 더 많은 “공간”을 남겨 둡니다. Pre-filtering으로 file instrument만 활성화하면 nonfile instrument에 대한 row는 수집되지 않습니다. Post-filtering의 경우 nonfile event도 수집되어 file event를 위한 row가 더 적게 남습니다.

• 일부 종류의 event table을 유지 관리하지 않기 위해서입니다. Consumer를 비활성화하면, 서버는 그 consumer를 위한 목적지를 유지 관리하는 데 시간을 사용하지 않습니다. 예를 들어, event history에 관심이 없다면 history table consumer를 비활성화하여 성능을 개선할 수 있습니다.

• Post-filtering.
  이는 Performance Schema table에서 정보를 선택하는 쿼리에서 WHERE 절을 사용하여, 사용할 수 있는 event 중에서 어떤 것을 보고 싶은지 지정하는 것을 포함합니다. Post-filtering은 개별 사용자가 사용할 수 있는 event 중에서 어떤 것이 관심 대상인지 선택하므로 사용자별로 수행됩니다.

Post-filtering을 사용하는 이유:

• 어떤 event 정보가 관심 대상인지에 대해 개별 사용자를 대신해 결정을 내리는 것을 피하기 위해서입니다.

• Pre-filtering을 사용하여 부과할 제한을 미리 알 수 없는 경우, Performance Schema를 사용해 퍼포먼스 문제를 조사하기 위해서입니다.

다음 section에서는 pre-filtering에 대한 자세한 내용을 제공하고, filtering 작업에서 instrument나 consumer의 네이밍에 대한 지침을 제공합니다. 정보를 조회하기 위한 쿼리 작성(post-filtering)에 대한 정보는
Section 29.5, “Performance Schema Queries”를 참조하십시오.