On Fri, Aug 07, 2009 at 09:10:15AM -0400, Jay Pipes wrote: >>> and there's a number of tricks to do this pretty easily for all the >>> possible points to hook in profiling stuff. >> >> Modifying code is an option, but at the same time it is quite a hack. A >> major disadvantage is that it has to be done for each type of hardware >> supported. > > Exactly, and I believe it's a non-starter approach for that reason > alone.
I disagree. It only needs special code to do it if you want to run without the slight degredation of the compare... you can have a bunch of if() there instead. Realistically though, if we cover x86 (32 and 64) and sparc, we're home free. In fact, if we are able to use DTrace on Solaris to do the same thing, we're just down to x86 (32 and 64) linux (x86 should be the same as x86-64 and FreeBSD should be the same as Linux). >> I have another suggestion, which I have found works well for PBXT >> (http://pbxt.blogspot.com/2008/12/xtstat-tells-you-exactly-what-pbxt-is.html). >> >> >> >> A simple increment is a very cheap operation, as long as it can be done >> without requiring a lock. > > This is essentially what we already have in the way of the current > sys_var system for thread-local data that is "merged" upong > Session::cleanup() > >> (And, if you are just doing an increment, then you don't have to bother >> with a if(profiling_enabled), you just do the increment all the time.) > > ++ This does fairly limit what you can work out as profiling data though - it cannot very easily find out what IO is caused by this query and how long it waits for it, what queries are causing what type of IO, is my query waiting on a mutex and if so which one, what time is spent executing what parts of the query. It also means you don't always have to have these counters on, which does cost. Think about it... for a lot of these, 99.999% of the time you don't care about them. > b) Alternately, the Session's local status variables need to be > persisted to a system table in a row-level locking storage engine using > the standard write_row() interface of the storage engine interface. > Stewart currently is working on this (see his i_s storage engine > branches...) not quite... will just access current data and present it as a table. > Either way, you incur locking and instruction costs. These costs have > been deemed too high by MySQL engineering for the hundreds (thousands?) > of metrics that the MySQL performance schema monitors (or is able to > monitor). This is likely because the frequency of certain events in the > performance schema is quite high? Yep. Anything you're going to care about is going to be in a hot code path. >> But, this is OK, because this price is only paid when you are actually >> profiling. > > Agreed in principle, yes. No, it's not. It's partially paid *all the time*. Just the compare to see if profiling is on is *REALLY* expensive. You pay this price if you've compiled your binary with profiling support - even if you never use it. Your processor can do a LOT more NOPs per second than compares. > Marc Alff took an approach that causes almost no overhead if the > performance schema is not *compiled in*. There is an overhead if the > performance schema is compiled in and the DBA is not careful to specify > only those things she is interested in. > > I'd love to find a perfect medium between Marc's approach (which nicely > NOOPs the performance schema code behind #define templates when it is > not compiled in) and your discussion above of non-storage of all data > pieces automatically. I'm saying I can NOP it (the CPU instruction) at runtime until you enable it, and un-NOP it when needed. This will be a lot cheaper and will have a near 0 (maybe 1/400,000th) performance impact when not monitoring something. -- Stewart Smith _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
