[RADIATOR] Slow response from Radiator

Jim Tyrrell jim at scusting.com
Mon Mar 11 05:01:31 CDT 2013


I would suggest testing the LDAP search on the Radiator server to the 
local address 127.0.0.1.

Your Radiator debug shows it connecting to LDAP on 127.0.0.1:
 >Fri Mar  8 09:08:13 2013: INFO: Connecting to 127.0.0.1:389

But the ldapsearch you did was to 10.44.85.165 so not a valid comparison:
 > time ldapsearch -D"uid=apt,ou=xxxx,dc=xxxx,dc=net" -wxxxx 
-b"dc=colt,dc=net" -h10.44.85.165 uid=mlavende

Jim.

On 11/03/2013 08:16, Arya, Manish Kumar wrote:
> Hi,
>
>   Can anyone help please. I am using Radiator version 4.9 on Solaris 10
>
> [xxxx at rxxxxx:/var/log/radiator]$ cat /etc/release
>                        Solaris 10 11/06 s10s_u3wos_10 SPARC
>            Copyright 2006 Sun Microsystems, Inc.  All Rights Reserved.
>                         Use is subject to license terms.
>                            Assembled 14 November 2006
>
>
> Regards,
> -Manish
>
> ------------------------------------------------------------------------
> *From:* "Arya, Manish Kumar" <m.arya at yahoo.com>
> *To:* Radiator <radiator at open.com.au>; "manishkumar.arya at colt.net" 
> <manishkumar.arya at colt.net>
> *Sent:* Friday, March 8, 2013 2:59 PM
> *Subject:* Slow response from Radiator
>
> Hi,
>
> Radius server takes approx 7-10 seconds to handle one request, there 
> not much load on this radius server.
>
> Radius Packet dump
>
> *** Received from 127.0.0.1 port 32812 ....
> Code:       Access-Request
> Identifier: 102
>
> Fri Mar  8 09:08:11 2013: DEBUG: Rewrote user name to xxxxxx
> Fri Mar  8 09:08:12 2013: DEBUG:  Deleting session for xxxxxxx at alu, 
> 10.174.2.2,
> Fri Mar  8 09:08:12 2013: DEBUG: Handling with Radius::AuthLDAP2: 
> alu_msp_user_auth-7750
> Fri Mar  8 09:08:13 2013: INFO: Connecting to 127.0.0.1:389
> Fri Mar  8 09:08:13 2013: INFO: Attempting to bind to LDAP server 
> 127.0.0.1:389
> Fri Mar  8 09:08:14 2013: DEBUG: LDAP got result for 
> uid=xxxxx,ou=people,o=COLT,ou=customers,dc=colt,dc=net
> Fri Mar  8 09:08:14 2013: DEBUG: LDAP got userPassword: xxxxxx
> Fri Mar  8 09:08:15 2013: DEBUG: LDAP got radius-sam-sec-grp-name: 
> TAC_SUPPORT2
> Fri Mar  8 09:08:15 2013: DEBUG: LDAP got radius-7750-Timetra-Access: 3
> Fri Mar  8 09:08:16 2013: DEBUG: LDAP got radius-7750-Timetra-Profile: 
> administrative
> Fri Mar  8 09:08:16 2013: DEBUG: LDAP got 
> radius-7750-Timetra-Default-Action: 1
> Fri Mar  8 09:08:17 2013: DEBUG: Radius::AuthLDAP2 looks for match 
> with xxxxxx [xxxxxx at alu]
> Fri Mar  8 09:08:17 2013: DEBUG: Radius::AuthLDAP2 ACCEPT: : xxxxxx 
> [xxxxxx at alu]
> Fri Mar  8 09:08:18 2013: DEBUG: AuthBy LDAP2 result: ACCEPT,
> Fri Mar  8 09:08:18 2013: DEBUG: Access accepted for xxxxxx
> Fri Mar  8 09:08:19 2013: DEBUG: Packet dump:
> *** Sending to 10.174.2.2 port 50838 ....
> Code:       Access-Accept
> Identifier: 167
> Authentic: <245><217>Un<184>Ge<144>.<213>QE<1>u4.
> Attributes:
>         Sam-security-group-name = "TAC_SUPPORT2"
>         Timetra-Access = 3
>         Timetra-Profile = "administrative"
>         Timetra-Default-Action = 1
>         Service-Type = Login-User
>
>
> ldapsearch for uid with above attributes is also very quick, no 
> complaints of indexes too
>
> real    0m0.020s
> user    0m0.006s
> sys     0m0.010s
>
> hardware config
>
> [root at rad-lon1:/var/log/radiator]# prtdiag
> System Configuration: Sun Microsystems  sun4u Sun Fire V245
> System clock frequency: 188 MHZ
> Memory size: 4GB
>
> ==================================== CPUs 
> ====================================
>                E$          CPU CPU
> CPU  Freq      Size        Implementation Mask    Status      Location
> ---  --------  ----------  --------------------- -----   ------      
> --------
> 0    1504 MHz  1MB         SUNW,UltraSPARC-IIIi 3.4    on-line     MB/P0
> 1    1504 MHz  1MB         SUNW,UltraSPARC-IIIi 3.4    on-line     MB/P1
>
>
> CPU usage (uptime)
>
> [root at rad-lon1:/var/log/radiator]# uptime
>   9:21am  up 262 day(s), 20:18,  5 users,  load average: 0.04, 0.04, 0.04
>
>
> CPU/Memory usage with top states no processes are using very minimal 
> CPU and memory.
>
> last pid: 11066;  load avg:  0.04,  0.04, 0.04;       up 
> 262+20:19:30     09:22:51
> 68 processes: 67 sleeping, 1 on cpu
> CPU states: 98.7% idle,  0.6% user,  0.7% kernel, 0.0% iowait,  0.0% swap
> Memory: 4096M phys mem, 1718M free mem, 8005M total swap, 8005M free swap
>
>    PID USERNAME LWP PRI NICE  SIZE   RES STATE TIME    CPU COMMAND
>  22797 dsadmin   41  59    0  297M  261M sleep 468:00  0.44% ns-slapd
>  23543 root       1  59    0  355M  353M sleep 174:26  0.29% perl
>  10858 root       1  59    0 2888K 1784K cpu/0 0:00  0.09% top
>  23137 root      41  59    0  196M  162M sleep 329:16  0.05% ns-slapd
>  22899 root      30  59    0  134M   92M sleep 167:34  0.02% java
>    691 noaccess  25  59    0  177M   96M sleep 231:51  0.02% java
>  10823 root       1  59    0 3008K 2488K sleep 0:00  0.02% bash
>  10821 root       1  59    0 8304K 2728K sleep 0:00  0.01% sshd
>  26407 daemon     4  59    0  620M  559M sleep 19:44  0.01% nfsmapid
>    331 root       1 100  -20 2312K 1512K sleep 31:05  0.01% xntpd
>   5013 root      25  59    0 6544K 4576K sleep 1:01  0.01% nscd
>    114 root       6  59    0 4128K 3248K sleep 341:09  0.01% picld
>   7312 root       1  59    0 1984K 1576K sleep 0:00  0.00% tail
>   1148 root       1  59    0 9000K 3352K sleep 0:00  0.00% sshd
>      7 root      13  59    0 9784K 7728K sleep 4:47  0.00% svc.startd
>
> Regards,
> -Manish
>
>
>
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20130311/bd225ce9/attachment.html 


More information about the radiator mailing list