Hi Guilhem
Guilhem Bichot wrote:
> Hello,
>
> Marc Alff a écrit, Le 07.04.2009 18:13:
>> Guilhem Bichot wrote:
>>> Marc Alff a écrit, Le 23.03.2009 18:34:
>>>> Guilhem Bichot wrote:
>
>>>> ./mysqld --performance-schema-max-mutex-instruments=200
>>>>
>>>> Let's assume 150 mutex instruments have been loaded already.
>>>>
>>>> Let's assume "a_plugin" contains 40 mutex instruments.
>>>> Let's assume "b_plugin" contains 20 mutex instruments.
>>>>
>>>> INSTALL PLUGIN a_plugin
>>>> --> the server now has 150+40 = 190 mutex instruments.
>>>>
>>>> UNINSTALL PLUGIN a_plugin
>>>> --> the server still has 190 instruments
>>>> All the historical data generated by the plugin code is still available
>>> And thus, room in mutex_info_array (for example) is never freed, and as
>>> you explained, takes up space which the next to-be-installed plugin
>>> cannot use.
>>> Is there a way to force uninstalled plugins to free space occupied in
>>> the above array? Is it planned?
>>>
>>
>> There is a way to force a plugin to not consume slots during execution
>> of instrumented code:
>> - UPDATE SETUP_INSTRUMENTS set ENABLED='NO' WHERE ...
>> This avoids consuming the memory allocated by
>> --performance-schema-max-mutex
>
> Bah, if the plugin has been uninstalled, there is no execution of its
> instrumented code anyway.
>
>> There is currently no way to prevent a plugin from consuming slots for
>> registering the instruments themselves, which is the memory allocated by
>> --performance-schema-max-mutex-instruments
>>
>> I don't see this as an issue, since only a few bytes per instrument will
>> be used, and the number of instruments in a plugin should be very low.
>> There are no plans to selectively exclude instrumentation when loading a
>> plugin with some filtering options.
>>
>> To see how much memory is used, use:
>>
>> SHOW ENGINE PERFORMANCE_SCHEMA STATUS
>>
>> (PFS_MUTEX_INFO).ROW_SIZE is 248 bytes
>>
>> So, if a plugin has 10 instrumented mutexes, it will "waste" 2480 bytes.
>
> And in the default config:
> --performance-schema-max-rwlock-instruments=<number>
> default=20
> Maximum number of rwlock instruments.
> So, if a plugin has 2 rwlocks, it takes 10% of the allowed space. No
> matter if that's only a few hundreds of bytes, it's still 10%.
> If it has 10 types of rwlocks (quite possible with a not-trivial
> engine), that will take 50%.
>
That is correct, although I don't understand why it's relevant.
The default value is meant to be sufficient for all the MySQL provided
plugins, and will be revised when more instrumentation or more plugin
are implemented.
If a third party plugin needs more slots, that's what the
--performance-schema-max-rwlock-instruments=<number> is for.
Please describe what the problem is, I just don't see one here.
>> The best option if space is a concern is to not use space by avoiding
>> loading instrumented code. Space can *never* be freed, as doing this
>> while the code is running and executing instrumented code will lead to
>> crashes.
>
> In my case, the plugin's instrumented code is not running as UNINSTALL
> PLUGIN has been executed. So I don't follow the explanation.
All the code performing a SELECT from the performance schema can be
executed during or after a plugin is uninstalled, and this code relies
on the underlying data structures to be valid and stable, for the
instruments themselves.
I should have said just "while the code is running" then ...
>
>> That's not a bug, it's a conscious design choice, to have lock-free code.
>
> There is a shortcut above. For example lf_hash is lock-free, though it
> reuses memory (recycles) when an element has been deleted and nobody is
> looking at it anymore.
>
Sure.
But lf_hash is not the only way to implement lock free code either.
The choice here is to have an array as static as possible, which makes
it much easier to access elements directly without performance hits.
Also, you seem to be assuming that memory should be freed after
UNINSTALL plugin, which is not the case.
Instruments used by a plugin survive UNINSTALL plugin, for the data in
the collected by the performance schema to be still meaningful (_HISTORY
tables, aggregates, and later state or lock data).
Regards,
-- Marc
