> 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