 |
 |
Hi Andy, Thanks for your answers. On 06/22/11 15:35, Andrew Hanushevsky wrote: > 3. The 'r' contributions from all servers connected to this manager (all read-only, > so no write ops) sum up to '4058'. So, what is really the meaning of 'sel.t' and > 'sel.r' then? > > With time, both 'sel.r' and 'sel.t' grow, but the difference changes (in my case > it got smaller which seems strange). > ***The deviation between (r+w) vs t is noted in the manual. 't' represents all > selections, whether they yield a result or not. The 'r' and 'w' represent only > those selections that actually yielded a result. So, one should expect that the > divergence would get smaller over time. Sorry, where in what manual? I sense I'm missing something important about cmsd here :) > What happens if a server disconnects and then re-connects? Will there be a > discontinuity of some kind in those numbers? Or will the manager cmsd just keep > the host identification and reuse it when the server comes back up? > ***The answer is yes but only if the server reconnects within its "drop" window > (by default, 10 minutes). OK, makes sense, I was just restarting some servers and numbers kept growing. > 4. After writing all this ... is anybody actually using this? What would be a > reasonable thing to store into MonALISA (or equivalent)? Is cmsd ever the > bottleneck / problematic part? > ***No one but you at the moment because these values were not available nor > documented until just recently. In general, the cmsd has never been an issue > since it has such low over head. But, one person's "no issue" is another > person's view of neglect. I suspect that the only thing you would want is the > number of times a host is selected for redirection. I think that Brian would be > interested in how well server redirection shares are actually met. Yup, that was why I started looking into this ... but, if I understand correctly, this only works for meta-managers and Brian is in control of the only one we have. Cheers, Matevz