Hi, I modified rlm_ippool.c to create a hash key against Calling-Station-Id, which is unique across my NAS. I only have one NAS (it's a test enviornment) so no worries about duplicate ports keys. However, I find radiusd goes up to 97% CPU when I use this IP allocation method. If I don't use any server-side IP allocation, I get CPU use hovering around 4%. I can't use an integer like Nas-Id to hash against because it's not a unique value on my NAS, hence I had to modify rlm_ipool.c. So I can't easily check whether the problem is in the rest of rlm_ippool.c or in the change of the hashing method that I've done. Thoughts? Thanks, Chris
Chris Hellberg wrote:
I modified rlm_ippool.c to create a hash key against Calling-Station-Id, which is unique across my NAS.
Why? key = %{md5: %{Calling-Station-Id}}
However, I find radiusd goes up to 97% CPU when I use this IP allocation method. If I don't use any server-side IP allocation, I get CPU use hovering around 4%. I can't use an integer like Nas-Id to hash against because it's not a unique value on my NAS, hence I had to modify rlm_ipool.c. So I can't easily check whether the problem is in the rest of rlm_ippool.c or in the change of the hashing method that I've done.
If the problem isn't in the default code, then it's difficult for us to help. Alan DeKok.
Alan, ----- Original Message ----
From: Alan DeKok <aland@deployingradius.com> To: FreeRadius developers mailing list <freeradius-devel@lists.freeradius.org> Sent: Thu, 3 March, 2011 16:57:08 Subject: Re: rlm_ippool slowness
Chris Hellberg wrote:
I modified rlm_ippool.c to create a hash key against Calling-Station-Id, which
is unique across my NAS.
Why?
key = %{md5: %{Calling-Station-Id}}
I've done this because the default behavior in freeradius of using Nas-Port and Nas-IP-Address will not generate a unique hash or rather will generate too duplicate hashes.
However, I find radiusd goes up to 97% CPU when I use this IP allocation method.
If I don't use any server-side IP allocation, I get CPU use hovering around 4%.
I can't use an integer like Nas-Id to hash against because it's not a unique
value on my NAS, hence I had to modify rlm_ipool.c. So I can't easily check
whether the problem is in the rest of rlm_ippool.c or in the change of the hashing method that I've done.
If the problem isn't in the default code, then it's difficult for us to help.
I've changed one line - the line that creates the hash key. What would you need me to provide/do to help find the source of the delay? /Chris
Chris Hellberg wrote:
key = %{md5: %{Calling-Station-Id}}
I've done this because the default behavior in freeradius of using Nas-Port and Nas-IP-Address will not generate a unique hash or rather will generate too duplicate hashes.
OK... do you understand what I posted? Do you know where that key line goes?
I've changed one line - the line that creates the hash key. What would you need me to provide/do to help find the source of the delay?
Nothing. You changed the code and broke it. Try what I suggested. Go read raddb/modules/ippool. No source code changes are necessary. Alan DeKok.
Alan,
Chris Hellberg wrote:
key = %{md5: %{Calling-Station-Id}}
I've done this because the default behavior in freeradius of using Nas-Port and
Nas-IP-Address will not generate a unique hash or rather will generate too duplicate hashes.
OK... do you understand what I posted? Do you know where that key line goes?
I do now - thanks.
I've changed one line - the line that creates the hash key. What would you need
me to provide/do to help find the source of the delay?
Nothing. You changed the code and broke it.
Try what I suggested. Go read raddb/modules/ippool. No source code changes are necessary.
It's certainly easier this way. But the same problem exists - 99% CPU for server-side pools and 4% for no server-side ippool usage. Regards, Chris
Alan,
Chris Hellberg wrote:
key = %{md5: %{Calling-Station-Id}}
I've done this because the default behavior in freeradius of using Nas-Port and
Nas-IP-Address will not generate a unique hash or rather will generate too duplicate hashes.
OK... do you understand what I posted? Do you know where that key line goes?
I do now - thanks.
I've changed one line - the line that creates the hash key. What would you need
me to provide/do to help find the source of the delay?
Nothing. You changed the code and broke it.
Try what I suggested. Go read raddb/modules/ippool. No source code changes are necessary.
It's certainly easier this way. But the same problem exists - 99% CPU for server-side pools and 4% for no server-side ippool usage.
Regards,
Chris
The ippool module is´nt a problem, it is m5 excessive usage. You can use more than one attribute to obtain a unique key.
Chris Hellberg wrote:
It's certainly easier this way. But the same problem exists - 99% CPU for server-side pools and 4% for no server-side ippool usage.
Well... how many packets are you sending to it? And have you tried just "key = %{Calling-Station-Id}" ? If it's using 99% CPU for MD5, there's likely a reason. The system either has no CPU power, or it's receiving 1000's of packets/s. Alan DeKok.
On Fri 04 Mar 2011, Alan DeKok wrote:
Chris Hellberg wrote:
It's certainly easier this way. But the same problem exists - 99% CPU for server-side pools and 4% for no server-side ippool usage.
Well... how many packets are you sending to it? And have you tried just "key = %{Calling-Station-Id}" ?
If it's using 99% CPU for MD5, there's likely a reason. The system either has no CPU power, or it's receiving 1000's of packets/s.
Hello Chris I have also had problems in the past with ippool not scaling which is why the sql based ippool module exists ;-) Cheers -- Peter Nixon http://peternixon.net/
participants (5)
-
Alan DeKok -
Chris Hellberg -
Chris Hellberg -
Peter Nixon -
Toledo, Luis Carlos