On Thu, Feb 12, 2009 at 5:23 PM, Monty Taylor <[email protected]> wrote: > Brian Aker wrote: >> Hi! >> >> Here would be good. I think the blueprints are wiki... but here is just >> fine. > > Well, the blueprints are intended to be used _with_ a wiki. So a > blueprint can be associated with a wiki page on drizzle.org. If there's > something that needs more than a one-sentence explanation, the best > practice is to write the spec for the work up on the wiki. > > But, as Brian said, a discussion here first is fine while we figure it > out, and then someone can stick all of that onto the wiki. > > Monty > >> Cheers, >> -Brian >> >> On Feb 12, 2009, at 5:03 PM, MARK CALLAGHAN wrote: >> >>> On Thu, Feb 12, 2009 at 11:53 AM, Brian Aker <[email protected]> wrote: >>>> Hi! >>>> >>>> On Feb 12, 2009, at 6:25 AM, MARK CALLAGHAN 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 >>>> >>>> >>>> As others have pointed out, there are blueprints to the user >>>> interface up on >>>> Launchpad. >>>> >>>> To get to that work though we have to complete the FRM/Discovery work >>>> and >>>> the re-implementation of the information schema. I am expecting this >>>> to be >>>> done by April and that we will be able to go over the performance >>>> interface >>>> when we do the Drizzle developer day on the Friday after the conference >>>> (location to be announced as soon as I figure out who is hosting). >>>> >>>> It would be really helpful to get a review of the LP blueprints from >>>> people >>>> like yourself. >>>> >>>> Cheers, >>>> -Brian >>>> >>> >>> Where do we post review feedback? Here or the blueprint? I didn't see >>> a feedback area on the blueprint page. >>> >>>> -- >>>> _______________________________________________________ >>>> Brian "Krow" Aker, brian at tangent.org >>>> Seattle, Washington >>>> http://krow.net/ <-- Me >>>> http://tangent.org/ <-- Software >>>> _______________________________________________________ >>>> You can't grep a dead tree. >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Mark Callaghan >>> [email protected] >> >> -- >> _______________________________________________________ >> Brian "Krow" Aker, brian at tangent.org >> Seattle, Washington >> http://krow.net/ <-- Me >> http://tangent.org/ <-- Software >> _______________________________________________________ >> You can't grep a dead tree. >> >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~drizzle-discuss >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~drizzle-discuss >> More help : https://help.launchpad.net/ListHelp >> > >
OK. The next step is to make the blueprint more specific about what will be collected and how it can be aggregated and to choose a target audience (DBAs, server developers). There are a few things you should reference: * performance data for other RDBMS servers (Postgres, Oracle) * http://code.google.com/p/google-mysql-tools/wiki/UserTableMonitoring * the performance schema in MySQL 6 The target audience determines what data you want to export. I have access to much of the low-level data to be exported by the MySQL 6 performance schema. I reference that data about once per month as part of my development effort. I also have access to the SHOW USER_STATS and SHOW TABLE_STATS data. I use that every day because I can act based on it. Low-level data will tell everyone using standard MySQL that the hot locks are LOCK_open, LOCK_mdl, the MyISAM key buffer lock and the HEAP engine lock. What do you do with that? Performance data aggregated by user, table and database allow you to determine which part of your application should be fixed. So, my bias should be clear by now. Give me higher level data aggregated by user and table. In our build, we have the following columns in SHOW USER_STATS and I think you should try to provide the same, but with a much better implementation. User -- account name Total_connections Concurrent_connections -- current # connections for this user Connected_time Busy_time - # wall clock seconds for which commands are run Cpu_time - should be # CPU seconds for which commands are run, but without a very recent Linux kernel this is the same as Busy_time Bytes_received - bytes sent to the server by this account Bytes_sent - bytes sent from the server for this account Binlog_bytes_written Rows_fetched Rows_updated -- # rows changed by insert, update, replace, delete statements Table_rows_read Select_commands Update_commands -- # insert, update, replace, delete statements Other_commands -- counts all other commands Commit_transactions Rollback_transactions Denied_connections Lost_connection Access_denied Empty_queries -- counts queries that return 0 rows We don't count per user: Errors -- number of commands that return a SQL error Disk activity -- this requires lots of changes to storage engines. It would be great to have though. Some of this is hard to account. For example, page writes for InnoDB may be done after statements from different accounts wrote to that page. It will be difficult to track the users per dirty page. Mutex activity For tables we have #rows read and #rows changed. -- 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
