how do i understand inn_feed stats?

[Russ Allbery]

Pavel V Knyazev <pasha at surnet.ru> writes:

> I'm try to figure out what the following parameters are:

>   requeued:
>    spooled:
> [overflow]:
> [on_close]:
> [sleeping]:
>  unspooled:
>   no queue:

requeued are articles that innfeed tried to offer and failed to
successfully get a yes or no response on.  spooled are articles that
innfeed had to spool for some reason.  The next three break down spooled
into three categories:  articles spooled because the peer just wasn't
keeping up, articles spooled when innfeed needed to close the connection
for some reason, and articles spooled while innfeed couldn't connect to
the remote host.

unspooled are articles taken back out of the spool and fed to the site.
no queue are articles that went through immediately; if no queue is high,
the feed is extremely fast and near real-time.

> For example i have two outgoing feeds for big articles:

> a) the first one seems to be keeping up, it accepts less and refuses
> more articles, however there are 2755 articles marked as "no queue". Do
> i really keep up with the feed and offer every article to this host?

Yup.

> Should i put additional streams in both cases or not?

>    seconds: 51318     art. timeout: 600          ip name: [host-1]
>    offered: 9857     resp. timeout: 300             port: 119
>   accepted: 1821    want streaming: yes      active cxns: 1
>    refused: 7501      is streaming: yes    sleeping cxns: 0
>   rejected: 534         max checks: 64      initial cxns: 1
>    missing: 0          no-check on: 70.0%      idle cxns: 0
>   deferred: 0         no-check off: 50.0%       max cxns: 1/1
>   requeued: 0        no-check fltr: 50.0    queue length: 0.0/200
>    spooled: 0       dynamic method: 0              empty: 100.0%
> [overflow]: 0        dyn b'log low: 25.0%        >0%-25%: 0.0%
> [on_close]: 0       dyn b'log high: 50.0%        25%-50%: 0.0%
> [sleeping]: 0       dyn b'log stat: 37.5%        50%-75%: 0.0%
>  unspooled: 0       dyn b'log fltr: 25.0       75%-<100%: 0.0%
>   no queue: 2755    avr.cxns queue: 13.0             full: 0.0%
> accpt size: 784 MB   drop-deferred: true    defer length: 0.0
> rejct size: 233 MB   min-queue-cxn: true 
>                  spooling: DISABLED
>    offered:  0.24 art/s   accepted:  0.02 art/s, 5.94 KB/s
>    refused:  0.22 art/s   rejected:  0.00 art/s, 0 B/s
>    missing 0 spooled 0

This host is completely keeping up.

>    seconds: 51318     art. timeout: 600          ip name: [host-2]
>    offered: 14288    resp. timeout: 300             port: 119
>   accepted: 2632    want streaming: yes      active cxns: 1
>    refused: 11220     is streaming: yes    sleeping cxns: 0
>   rejected: 270         max checks: 64      initial cxns: 1
>    missing: 0          no-check on: 70.0%      idle cxns: 0
>   deferred: 0         no-check off: 50.0%       max cxns: 1/1
>   requeued: 279      no-check fltr: 50.0    queue length: 0.0/200
>    spooled: 2668    dynamic method: 0              empty: 100.0%
> [overflow]: 1073     dyn b'log low: 25.0%        >0%-25%: 0.0%
> [on_close]: 689     dyn b'log high: 50.0%        25%-50%: 0.0%
> [sleeping]: 906     dyn b'log stat: 37.5%        50%-75%: 0.0%
>  unspooled: 0       dyn b'log fltr: 25.0       75%-<100%: 0.0%
>   no queue: 6909    avr.cxns queue: 10.0             full: 0.0%
> accpt size: 0.993 GB drop-deferred: true    defer length: 0.0
> rejct size: 90.5 MB  min-queue-cxn: true 
>                  spooling: DISABLED
>    offered:  0.24 art/s   accepted:  0.00 art/s, 0 B/s
>    refused:  0.24 art/s   rejected:  0.00 art/s, 0 B/s
>    missing 0 spooled 0

This host is completely keeping up at the moment, which means that putting
more streams on for this host probably isn't going to help.  There was
some time in the past when it wasn't keeping up; it looked like it was
either slow or down for a while.  You don't need to add more streams, but
I would just turn on spooling.

Why don't you do any spooling?  I think it's useful to spool at least for
a little while so that your peers don't miss news when they're down for
some reason.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.