What are the plans for performance data in drizzle? I prefer data
aggregated by user and table as that is the activity that a DBA
understands and can change. You would be surprised what happens to a
server when you are able to track all activity -- that app that
couldn't possibly be a problem is doing 10,000 QPS. We added stats via
SHOW USER_STATISTICS and SHOW TABLE_STATISTICS in the Google patch --
http://code.google.com/p/google-mysql-tools/wiki/UserTableMonitoring
and the results have been great and are used on a daily basis to
manage and debug long-term (days, weeks, months) and short-term (who
is attacking my server right now) workload growth. On the
implementation side, there were a few difficulties:
1) we created too much mutex contention (how ironic). That is fixed
now and will be in the next Google patch.
2) we try to make future merges with MySQL easy so we don't always do
things the right way
3) at times we operate in a vacuum and do the wrong thing (parts of
the code are hard to understand, prior to Drizzle the devel community
wasn't open)

Examples of the compromises (and mistakes?) we made:
* We count row activity (rows read, rows changed) per table and per
user. An easier way to do that is to modify handler.{h,cc} so that
activity for any handler is counted. We modified a few storage engines
instead. Lots of interesting things might be possible when you can
insert code between a storage engine and the code that calls it.
* We aggregate data per user and per table. It would have been easier
to extend existing USER and TABLE objects (whatever they are) and add
fields for aggregated stats to them. It isn't clear to me that such an
object exists for TABLE in MySQL 5.0 as the share isn't shared. And
for the USER object, it wasn't clear to me that the object would exist
after all connections for that user went away.

For things that cannot be instrumented at the storage engine
interface, it would help to expose an API that the engine can use. For
example, patched InnoDB doesn't have much contention on
pthread_mutex_t. But it has a lot of contention on its mutex
implementation and it counts that, but there isn't a generic way to
report that and for now SHOW MUTEX STATUS is the interface to the
data.

-- 
Mark Callaghan
[email protected]

_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help   : https://help.launchpad.net/ListHelp

Reply via email to