Il giorno 12/set/2012, alle ore 09:00, Łukasz Mierzwa <[email protected]> ha scritto:
> 2012/9/12 Roberto De Ioris <[email protected]>: >> Your "update resolution", is too near the "master frequency". >> >> As soon as the master slowdown a bit (like when calling fork()), the master >> clock will lose of a bunch of milliseconds (or even a whole second on a >> loaded system). >> >> Probably setting the carbon update frequency to 2 seconds will fix the >> problem, but a better solution would be allowing milliseconds cycles in the >> master. Something to look at >> for 1.4 (expecially now that we have high-resolution/highly-reliable clock >> plugins) > > I'm not sure if I understand, master cycle frequency is 1 second, > carbon update freq is 60 seconds (default). > Master cycle takes some time since it may have a lot of work to > handle, but master call carbon in every cycle and carbon will check if > it's 60 seconds or more since last update, so I don't see any way to > loose a carbon update cycle here. At worst if master had a lot of work > in that cycle, than it would delay carbon update, but still timestamp > check would work. Ops, sorry i was sure you set update frequency to 1 second in the carbon plugin. > > Machine I'm using to collect carbon stats is a VM with slow I/O, it's > possible that I'm hitting connection timeout since with current code > carbon plugin will not print any error message and probably set > last_update=now() so at next cycle stats won't be resend. > I'll try to fix that later today. > > This is probably the reason, as uwsgi_connect() do no print error messages, but simply fails with -1 -- Roberto De Ioris http://unbit.it JID: [email protected] _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
