On Fri, Apr 20, 2018 at 07:22:59PM +0200, Willy Tarreau wrote:
> On Fri, Apr 20, 2018 at 07:23:37PM +0300, Slawa Olhovchenkov wrote:
> > On Fri, Apr 20, 2018 at 05:33:34PM +0300, Slawa Olhovchenkov wrote:
> >
> > > On Fri, Apr 20, 2018 at 04:23:00PM +0200, Willy Tarreau wrote:
> > >
> > > > > > Thus for you it's better to stick to a single listener, and if you
> > > > > > want to
> > > > > > increase the fairness between the sockets, you can reduce
> > > > > > tune.maxaccept in
> > > > > > the global section like below :
> > > > > >
> > > > > > global
> > > > > > tune.maxaccept 8
> > > > >
> > > > > No significant differenece: average load rised, unequal CPU load still
> > > > > at same level
> > > >
> > > > Then you can try setting it even lower (1) and decreasing maxpollevents
> > > > :
> > > >
> > > > global
> > > > tune.maxaccept 1
> > > > tune.maxpollevents 20
> > >
> > > No difference, disbalance about same.
> > >
> >
> > Can I got per-thread stats like connections count, bytes transfered?
>
> Not by default, as such information are per-socket, per-frontend etc.
> However, by having on listening socket per thread, and "option socket-stats"
> you would have this. But in your case it doesn't work since only one socket
> receives all the traffic in any case.
Hmm, may be 2 socket?
frontend balancer
bind :80
bind :443 ssl crt
I mean difference caused by disbalance ssl/nonssl per-thread.
> The most detailed per-thread info you can get in your situation is by issuing
> "show activity" on the CLI, you will then get the information of the thread
> that processes the request :
>
> thread_id: 0
> date_now: 1524244468.204596
> loops: 754
> wake_cache: 576
> wake_tasks: 0
> wake_applets: 14
> wake_signal: 0
> poll_exp: 590
> poll_drop: 9
> poll_dead: 0
> poll_skip: 0
> fd_skip: 0
> fd_lock: 0
> fd_del: 109905
> conn_dead: 0
> stream: 109922
> empty_rq: 170
> long_rq: 414
>
> These information are quite internal, but the following ones will be
> useful :
> - loops : number of calls to the event loop
> - stream : cumulated number of streams processed
> (~= connections for HTTP/1, ~= requests for HTTP/2)
> - long_rq : number of passes via the scheduler where the runqueue had
> more than 200 tasks active
> - empty_rq : number of passes via the scheduler where the runqueue was
> empty
>
> The rest is probably irrelevant in your case. By doing it a few times
> you'll iterate over all threads. Or you can even have multiple stats
> sockets as well, but no need to do complex things first.
>
> Willy
>
