> I 've been working on a few changes to radrelay, mainly regarding making
the
> sleep time configurable and adding a few more things. The changes have
been
> made
> in radsqlrelay initialy but they 'll go in radrelay also. That won't
change
> your
> numbers but at least make a few things configurable.
>
good, that's a useful intermediate step - will allow to tune without
changing code.
> > I also tried various values of NR_SLOTS, but it doesn't change the
overall
> > time it takes to transfer a large backlog of accounting requests.
>
> Well, NR_SLOTS does not really matter if your accounting is quick enhough.
> Try commenting out the ms_sleep() between the do_send() calls.
I had tried this too, and just retried again, and the rate goes down to ~30
packets/sec.
Looks like the trafic becomes quite bursty, and the retransmission pattern
causes intermittent silent periods.
For example, packet 434 is a response from RS2 to RS1, and packet 435 goes
out 14.52
seconds after it (request from RS1 to RS2). I saw 37 periods of 1-sec or
more silence,
listed in this below:
No. Time Source Destination Info
65 1.900217 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=616)
129 2.741964 192.168.12.80 192.168.12.34 Accounting Response(5)
(id=7, l=20)
288 1.857164 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=618)
290 5.989420 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=616)
356 11.695879 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=616)
435 14.520559 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=618)
736 1.346075 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=618)
911 2.044088 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=618)
1079 2.088782 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=1, l=618)
1264 1.970677 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=618)
1463 1.826821 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=618)
1660 1.881720 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
1916 1.593158 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
2065 1.727769 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=1, l=620)
2762 1.740835 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
2831 4.966427 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
2885 8.717565 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
3230 2.007186 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
3376 2.199381 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
3597 1.820478 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
3731 1.794183 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
4167 2.125003 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
4707 2.043159 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=1, l=620)
4965 1.586214 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
5131 2.111933 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
5298 2.088369 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
5521 1.750188 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
5892 1.934175 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
6459 1.809148 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=1, l=620)
6855 1.856238 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
7029 2.015883 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
7390 1.962640 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
7764 1.936479 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
8246 1.374217 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
8492 1.877480 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=1, l=620)
9022 2.055465 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
9491 1.375418 192.168.12.34 192.168.12.80 Accounting Request(4)
(id=0, l=620)
> > Note that the CPU on RS1 (running the radrelay instance that is
processing
> > the backlog) still takes less than 1% of CPU, with or without the above
> > changes.
>
> That's normal it's an I/O bound application.
well, CPU is ~0%, and so is disk usage, and bandwidth usage. For the moment,
no resource is pushed to its limit.
> threading sound like an idea yes. Another idea is to get load-balancing
code
> inside freeradius. Then you could do something like the following:
> accounting {
> loadbalance {
> relay_detail1
> relay_detail2
> relay_detail3
> }
> }
>
> radrelay relay_detail1
> radrelay relay_detail2
> radrelay relay_detail3
>
>
> That way you don't need to change much (apart from a few changes to the
> server
> core) and you increase the overall performance by parallelizing radrelay
and
> the detail module.
Agree that would work too. I'd be glad to give it a try as soon as it's
available.
thanks,
Bruno
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
