Dnia czwartek, 1 grudnia 2011 04:40:09 Roberto De Ioris pisze:
> > Dnia wtorek, 29 listopada 2011 20:48:52 Roberto De Ioris pisze:
> >> I have committed another series of fix/optimizations.
> >>
> >> - nodes marked as dead will be skipped even if their reference is > 0
> >> (only already accepted request will continue)
> >> - added another check in auto-opmtized-list consistence (i suppose
> >> this
> >> is
> >> the one throwing your error)
> >> - a potential segmentation fault in slot removal should be fixed
> >>
> >> Let me know if it definitely fix it for you
> >
> > I've noticed one more possible issue so far, requests field for one node
> > gets
> > zeroed but that should only happen if I restart fastrouter. Below is
> > part
> > of
> > two subsequent reads from fastrouter stats socket.
> >
> > 1. first fastrouter stats output
> >
> > "hits": 433088,
> > "nodes": [
> >
> > {"name":
> > "172.16.200.55:3001",
> > "modifier1": 0,
> >
> > "modifier2": 0, "last_check": 1322681099, "requests": 12679, "tx":
> > 104686291,
> > "ref": 1, "death_mark": 0},
> >
> > {"name":
> > "172.16.200.56:3001",
> > "modifier1": 0,
> >
> > "modifier2": 0, "last_check": 1322681099, "requests": 12489, "tx":
> > 103283916,
> > "ref": 0, "death_mark": 0}
> >
> > ]
> >
> > 2. second fastrouter stats output
> >
> > "hits": 433089,
> > "nodes": [
> >
> > {"name":
> > "172.16.200.56:3001",
> > "modifier1": 0,
> >
> > "modifier2": 0, "last_check": 1322681100, "requests": 12490, "tx":
> > 103283916,
> > "ref": 1, "death_mark": 0},
> >
> > {"name":
> > "172.16.200.55:3001",
> > "modifier1": 0,
> >
> > "modifier2": 0, "last_check": 1322681100, "requests": 0, "tx": 0, "ref":
> > 0,
> > "death_mark": 0}
> >
> > ]
>
> When nodes got unsubscribed, they are completely removed. Think about
> using the form:
>
> socket = 192.168.0.*:0
>
> where the same instance could bind to random ports (for example i now
> configure most of my instances in this way), you will start to fill the
> linked-list at each restart.
>
> This is obviously not your case, but the less elements the linked list
> has, faster lookup you will get. I suppose some form of "history" could be
> added in the future.
>
> A short-term solution would be adding a "nail" option like
> --nail-subscribe-to <server> where "nailed" nodes remains in the list
> forever and non-nailed nodes (the default) continue to behave like before.
>
> The code would be as simple as
>
> (from)
>
> if (node->death_mark && node->reference == 0) {
> remove_node(node);
> }
>
> (to)
>
> if (node->death_mark && node->reference == 0 && !node->nailed) {
> remove_node(node);
> }
>
>
> What about it ?
I don't think I follow You with this nail option, if node I remove one node
from my setup then I don't need it's statistics in fastrouter stats. The issue
above is that during normal work, when nothin is restarted, no configuration is
changed and the subscribed node and fastrouter are both running all the time,
statistics for one node gets cleared between requests. Is this normal
behaviour of those linked lists?
Łukasz Mierzwa
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
