C
ChUIMonster
Guest
I have avoided trying to use it because, in the past (v9 was I think the last time I tried), it had a noticeable impact on performance. I would welcome being able to obtain that data if the impact of collecting it was not significant or painful. I think that having that data would be helpful in trying to figure out which latch tuning options to use and how well those changes have worked. Right now a lot of that sort of thing is trial and error. Even if the timing data is difficult or expensive, the current PROMON, "debghb", 11 has two columns on the far right "nap max total / hwm" that seem like they might be good candidates to add to the _Latch VST. My thinking there is that they would give better insight into how frequently the -spin limit is being reached, how much napping is actually taking place and how long those naps are. On a somewhat related note -- I was speculating to myself on a long drive home that the distribution of block accesses seems like it is very probably a Pareto distribution or something very similar to that (IOW -- the vast majority of spinning is probably to gain access to a relatively tiny number of resources) for many applications (maybe not for all applications, but I suspect it is true for the majority). I have no way to really know if that is actually true but if there is a block access counter somewhere (maybe related to how lruskips gets calculated?) and if all of those values could be dumped (or queried) relatively painlessly that would also be a fascinating bit of information. Especially if the db table/index/blob # was also available. That would be really useful in finding the source of hot spots and in designing ways to mitigate them.
Continue reading...
Continue reading...