mariadb/mysql-test/suite/perfschema/r/start_server_off.result
Marc Alff c314b3f1df Bug#56528 Increased server footprint with MTR
With recent changes in the performance schema default sizing parameters,
the memory used by a mysqld binary increased accordingly.

This negatively affects the MTR test suite,
because running several tests in parallel now consumes more ressources.

The fix is to leave the default production values unchanged,
and to configure the MTR environment to limit memory
used when running tests in the test suite, which is ok
because only a few objects are typically used within a test script.

This fix:
- changed the default configuration in MTR to use less memory
- adjusted the performance schema tests accordingly

Note that 1,000 mutex instances was too short and caused test failures
in the past in team trees, so the default used is now 10,000 in MTR.

The amount of memory used by the performance schema itself
can be observed with the statement SHOW ENGINE PERFORMANCE_SCHEMA STATUS
2010-09-08 12:01:12 -06:00

72 lines
2.7 KiB
Text

show databases;
Database
information_schema
mtr
mysql
performance_schema
test
select count(*) from performance_schema.PERFORMANCE_TIMERS;
count(*)
5
select count(*) from performance_schema.SETUP_CONSUMERS;
count(*)
8
select count(*) > 0 from performance_schema.SETUP_INSTRUMENTS;
count(*) > 0
0
select count(*) from performance_schema.SETUP_TIMERS;
count(*)
1
select * from performance_schema.COND_INSTANCES;
select * from performance_schema.EVENTS_WAITS_CURRENT;
select * from performance_schema.EVENTS_WAITS_HISTORY;
select * from performance_schema.EVENTS_WAITS_HISTORY_LONG;
select * from performance_schema.EVENTS_WAITS_SUMMARY_BY_INSTANCE;
select * from performance_schema.EVENTS_WAITS_SUMMARY_BY_THREAD_BY_EVENT_NAME;
select * from performance_schema.EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME;
select * from performance_schema.FILE_INSTANCES;
select * from performance_schema.FILE_SUMMARY_BY_EVENT_NAME;
select * from performance_schema.FILE_SUMMARY_BY_INSTANCE;
select * from performance_schema.MUTEX_INSTANCES;
select * from performance_schema.PERFORMANCE_TIMERS;
select * from performance_schema.RWLOCK_INSTANCES;
select * from performance_schema.SETUP_CONSUMERS;
select * from performance_schema.SETUP_INSTRUMENTS;
select * from performance_schema.SETUP_TIMERS;
select * from performance_schema.THREADS;
show variables like "performance_schema%";
Variable_name Value
performance_schema OFF
performance_schema_events_waits_history_long_size 10000
performance_schema_events_waits_history_size 10
performance_schema_max_cond_classes 80
performance_schema_max_cond_instances 1000
performance_schema_max_file_classes 50
performance_schema_max_file_handles 32768
performance_schema_max_file_instances 10000
performance_schema_max_mutex_classes 200
performance_schema_max_mutex_instances 10000
performance_schema_max_rwlock_classes 30
performance_schema_max_rwlock_instances 10000
performance_schema_max_table_handles 1000
performance_schema_max_table_instances 500
performance_schema_max_thread_classes 50
performance_schema_max_thread_instances 1000
show engine PERFORMANCE_SCHEMA status;
show status like "performance_schema%";
show status like "performance_schema%";
Variable_name Value
Performance_schema_cond_classes_lost 0
Performance_schema_cond_instances_lost 0
Performance_schema_file_classes_lost 0
Performance_schema_file_handles_lost 0
Performance_schema_file_instances_lost 0
Performance_schema_locker_lost 0
Performance_schema_mutex_classes_lost 0
Performance_schema_mutex_instances_lost 0
Performance_schema_rwlock_classes_lost 0
Performance_schema_rwlock_instances_lost 0
Performance_schema_table_handles_lost 0
Performance_schema_table_instances_lost 0
Performance_schema_thread_classes_lost 0
Performance_schema_thread_instances_lost 0