OK, it's mean that my mentioned 5.2 seconds delay example caused by previously slowly processed requests and OS rx buffer filling? I have trace 4 with LogMicroseconds logfile and I will try to analyze it. But due of lot of traffic it's not a easy task.
Does FarmSize parameter can help in this situation with pure Diameter environment? br, Arthur 28.03.2015 4:59, Hugh Irvine kirjutas: > Hello Arthur - > > The best way to see what is happening is to run Radiator at trace 4 with > LogMicroseconds enabled. > > This will show you exactly how long each processing step is taking and how > long Raditor is waiting for external resources. > > As Heikki says, this sort of problem is almost always due to slow responses > from SQL and/or LDAP databases (or sometimes slow DNS lookups). > > regards > > Hugh > > >> On 27 Mar 2015, at 19:56, Heikki Vatiainen <h...@open.com.au> wrote: >> >> On 26.3.2015 14.45, Kaspar Jasper wrote: >> >>> My Diameter peer sometimes complains about Diameter timeouts, which is 5 >>> seconds. Debugging leads me to the interesting detail - Diameter >>> messages sometimes are processing with delays in Radiator. >>> >>> For instance, Radiator's server Wireshark capture: >>> No. Time Source Destination Protocol Length Info >>> 231521 09:00:58.997242000 xxx.xxx.xx.xx xxx.xxx.xx.xx DIAMETER 1622 >>> cmd=Accounting Request(271) flags=RP-- appl=Diameter Base Accounting(3) >>> h2h=253e8654 e2e=253e8654 >>> >>> But in the Radiator this request appears 5.2 second later: >>> Thu Mar 26 09:01:04 2015 029052: DEBUG: StateMachine::event event >> Most likely you see this request as delayed because there is already a >> queue in the OS receive buffer. That is, the previous messages have >> taken longer than than usually. >> >> I would take a look at the request processing flow and consider what >> external lookups radiusd is doing. For example, DNS lookups, SQL DB >> queries and so on. Some functions in Radius/Util.pm may do DNS lookups. >> This can happen if they are given a name instead of IP address. >> >> Thanks, >> Heikki >> >> -- >> Heikki Vatiainen <h...@open.com.au> >> >> Radiator: the most portable, flexible and configurable RADIUS server >> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, >> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, >> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, >> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, >> NetWare etc. >> _______________________________________________ >> radiator mailing list >> radiator@open.com.au >> http://www.open.com.au/mailman/listinfo/radiator > > -- > > Hugh Irvine > h...@open.com.au > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, > DIAMETER, SIM, etc. > Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc. > _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator