MARK CALLAGHAN wrote:
What are the plans for performance data in drizzle?
You can see the plan blueprints here, which have existed for some time:That said, the performance data in drizzle must IMHO necessarily be preceded by the overhaul of the information_schema mechanisms, which have only partially been addressed currently.
Put another way: every wonder why MySQL doesn't use information_schema as its performance data schema? It's because it is dirt slow. So, instead of fixing the problem, they papered over it by creating yet another internal schema, with a different storage/retrieval mechanism than information_schema.
> 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 (whois attacking my server right now) workload growth.
++ And we certainly have plans to incorporate this. However, see point #1 above. :)
> 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.
Cool.
2) we try to make future merges with MySQL easy so we don't always do things the right way
This should be much less of a problem with Drizzle.
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)
Good to hear you say this.
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.
Let's discuss this at the MySQL UC in April. I've got a bunch of ideas about reworking the handler interface to be less MyISAM-specific and be more flexible and pluggable. But, it's a long way off ;)
* 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.
Well, again, this is probably due to the information_schema being a load of crud. With a fast, row-level-locking information schema (hint: stored in InnoDB), performance problems can likely go away and we can standardize on a handler interface easily.
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.
++ Cheers, Jay _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
