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%.
> 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.
> 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.
