Is it possible to track usage/performance on a per-database basis? The app I work on is vertically partitioned per-customer-account, each one with its own database. Since the app handles security (and customers can't connect directly to MySQL), there's no need for MySQL authentication.
But the usage stats would still be extremely useful, if I could analyze them per-database and per-table. Pete. On Thu, Feb 12, 2009 at 7:25 AM, MARK CALLAGHAN <[email protected]> wrote: > 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<https://launchpad.net/%7Edrizzle-discuss> > Post to : [email protected] > Unsubscribe : > https://launchpad.net/~drizzle-discuss<https://launchpad.net/%7Edrizzle-discuss> > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
