-
Marc Alff authored
Before this fix, statistics for the memory instrumentation were inaccurate, in the following scenario: At T1, thread A allocates some memory, of size N At T2, thread A gives ownership of the allocated memory to thread B At T3, thread B de allocates the block memory, of size N The event at T1 is instrumented with the performance schema, and an allocation of size N is counted against thread A. The event at T2 is not instrumented. The performance schema is unaware of the memory transfer. The event at T3 is instrumented with the performance schema, and a de allocation of size N is counted against thread B. The problem with this approach is with statistics maintained by thread. When the same code is executed many times (in a loop with the event scheduler), - thread A appears to use an ever increasing amount of memory - thread B appears to consume an ever increasing amount of memory - the global statistics for the server diverge. To r...
Marc Alff authoredBefore this fix, statistics for the memory instrumentation were inaccurate, in the following scenario: At T1, thread A allocates some memory, of size N At T2, thread A gives ownership of the allocated memory to thread B At T3, thread B de allocates the block memory, of size N The event at T1 is instrumented with the performance schema, and an allocation of size N is counted against thread A. The event at T2 is not instrumented. The performance schema is unaware of the memory transfer. The event at T3 is instrumented with the performance schema, and a de allocation of size N is counted against thread B. The problem with this approach is with statistics maintained by thread. When the same code is executed many times (in a loop with the event scheduler), - thread A appears to use an ever increasing amount of memory - thread B appears to consume an ever increasing amount of memory - the global statistics for the server diverge. To r...
Loading