Thanks, Michael. That's a very good point about SessionDatabase.
Especially in Farm environment NULL SessionDatabase is a good idea if
simultanous use tracking is not needed. If it is needed, then the farm
workers should use for example SQL for common storage.
The latest ref.pdf now has a note ab
Note that Perl never frees memory back to the OS once it has allocated
it although it might be unused internally.
Am 2011-09-30 14:41, schrieb Michael:
> I noticed an increase of memory usage over time as well on radiusd. Quite a
> long time though, but an increase non-the-less. 10% right now for
I noticed an increase of memory usage over time as well on radiusd. Quite a
long time though, but an increase non-the-less. 10% right now for example. When
I stop/start the service, it drops and remains at about 0.5% again. I have 4
identically synced config servers, where 2 are constantly use
On 09/30/2011 10:35 AM, Elias wrote:
Hello Elias,
> We're running RADIATOR with Farms and have noticed that the RADIATOR
> processes eat up huge chunks of memory. Has anybody else experienced this?
Memory leaks are very rare but certainly possible. Can you reply with
your configuration (no secr
Hi,
We're running RADIATOR with Farms and have noticed that the RADIATOR
processes eat up huge chunks of memory. Has anybody else experienced
this?
last pid: 27248; load avg: 3.88, 3.97, 3.98; up
196+02:04:57
Thanks Heikki,
that has been the solution.
Making sleep this way, without threads, does not affect the memory
consumption.
Thank you
--
Gerard
Al 28/02/11 20:25, En/na Heikki Vatiainen ha escrit:
> On 02/25/2011 03:32 PM, Gerard Alcorlo Bofill wrote:
>
>> the error I'm receiving by mail is:
>>
On 02/25/2011 03:32 PM, Gerard Alcorlo Bofill wrote:
> the error I'm receiving by mail is:
>
>
> Your program
>
>/usr/local/bin/radiusd -config_file
> /etc/radiator/radiuscesca/radiuscesca.cfg -foreground
>
> exited unexpectedly with exit status 25,
> signal number 0 and dump indication 0.
Sorry,
the error I'm receiving by mail is:
Your program
/usr/local/bin/radiusd -config_file
/etc/radiator/radiuscesca/radiuscesca.cfg -foreground
exited unexpectedly with exit status 25,
signal number 0 and dump indication 0.
The STDERR output was Not a HASH reference at (eval 135) line 28
Hello,
thanks Christian and Heikki for your advise.
I've done some short code with the timeout but every time this code is
executed Radiator restarts.
I'm trying to remove the timeout at the end of the "important things".
Do you know why when I execute this Radiator exits?
sub {
&main::log($
On 02/24/2011 11:00 AM, Gerard Alcorlo Bofill wrote:
> sorry for resending the same question. But I sent this question at the
> end of another mail with a not related subject, (Re: [RADIATOR]
> Assigning IP's directly from the Radius server), and maybe that's de
> reason because no one could help
Hello,
sorry for resending the same question. But I sent this question at the
end of another mail with a not related subject, (Re: [RADIATOR]
Assigning IP's directly from the Radius server), and maybe that's de
reason because no one could help me.
I'm using a home made PostProcessingHook. But it'
We have experienced it running 2.19 on Solaris and running 3.1 on RedHat.
Both of these are using the kerberos 5 pam from redhat.
The config is below.
Mike
LogDir /var/log/radius
DbDir /usr/local/radiator
# Use a low trace level in production systems. Increase
# it to 4 or 5
Hello Mike,
On Tue, 30 Jul 2002 10:32, Hugh Irvine wrote:
> Hello Mike -
>
> I have copied this mail to Mike for his comments.
I would normally expect to see a Radiator process to stabilise at 5 to 10 MB
(depending on the exact config in use).
Dan has independently indicated that his problem
Hello Mike -
I have copied this mail to Mike for his comments.
regards
Hugh
On Tuesday, July 30, 2002, at 05:40 AM, Forbes Mike wrote:
>
>
> What is the standard memory usage for radiator? We have 900 or so
> modems
> authenticating to this, is radiator keeping a state table of the
> ses
What is the standard memory usage for radiator? We have 900 or so modems
authenticating to this, is radiator keeping a state table of the sessions
and if so how much space would that take up per user. I am seeing
memory continuing to ramp up from almost nothing to 30megs oon up to
250megs.
I
Hello Dan,
I wasnt able to reproduce this problem here with Radiator 3.1, your config
file and testing with
./radpwtst -service_type Authenticate-Only -nas_port_type Virtual -notrace
-user mikem-fred -iterations 10
On my linux box, size of raadiusd stabilised quickly at 5616 Kb.
What ver
Hugh Irvine writes:
>
> Hello Dan -
>
> Mike is travelling this week, but he will look at this when he returns.
>
> In the meantime, can you please tell me how you are testing? And could you
> also send me the details of how you are testing and the outputs of "ps",
> "top" or whatever you
Hello Dan -
Mike is travelling this week, but he will look at this when he returns.
In the meantime, can you please tell me how you are testing? And could you
also send me the details of how you are testing and the outputs of "ps",
"top" or whatever you are using to measure the memory usage?
I noticed the perl process is growing linearly as the requests come in.
Grows in size quite rapidly, eventually needs to be restarted. I suspected
FreeTDS or OpenLDAP libraries (and these may too have leaks and probably do,
but that testing is later).
To see if it could be something else, I
Hello Marc -
On Sunday 25 February 2001 13:11, Marc Langer wrote:
> I have read the FAQ, but it does not help:
>
> The radiator process is always growing, after a day it is taking 20 MB,
> still growing. A few days later the whole memory (Sun Ultra 5, 512 MB
> RAM, Solaris 2.6) is exhausted, "df
I have read the FAQ, but it does not help:
The radiator process is always growing, after a day it is taking 20 MB,
still growing. A few days later the whole memory (Sun Ultra 5, 512 MB
RAM, Solaris 2.6) is exhausted, "df -k" shows 0 bytes for /tmp partition
and processes begin to crash.
Versions
I am observing a small but significant memory leak in Radiator 2.16.3
under Perl 5.6, Solaris 2.7.
The rate of leakage is about 4-8k per second, and it's steady... I've
run Radiator for a number of hours without any sign of slowing.
Here's my config:
## ##
#
Hello Christophe -
On Tue, 26 Sep 2000, Christophe Wolfhugel wrote:
> I believe there is a severe memory leak in Radiator 2.16.3. The
> server is configured as a Proxy-Radius only (10 Realms only), no
> DB_File, no LDAP.
>
> Radiusd grows to over 50 MB in around 12 hours. The same configuration
I believe there is a severe memory leak in Radiator 2.16.3. The
server is configured as a Proxy-Radius only (10 Realms only), no
DB_File, no LDAP.
Radiusd grows to over 50 MB in around 12 hours. The same configuration
on a 2.15 running since July is only 25 MB in size.
--
Christophe Wolfhugel
On 1999-10-14T15:45:44,
"Mike McCauley" <[EMAIL PROTECTED]> said:
> A more common cause of leaks is in add-on perl modules: these often have C
> code (or call third paryy APIs) that do mallocs, and under some
> circumstances fail to free.
I also found that the IO::Socket code in Perl 5.005_0
correspondence.
-Original Message-
From: tom minchin <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, October 14, 1999 3:10 PM
Subject: Re: (RADIATOR) memory leak in 2.14.1 ?
>On Wed, Oct 13, 1999 at 09:08:46PM -0700, Ric O'Connell wrote:
>>
>&
On Wed, Oct 13, 1999 at 09:08:46PM -0700, Ric O'Connell wrote:
>
>
> We have also seen extreme memory leaks in 2.14.1. We backed off to 2.13 and have
> not had problems. I doubt it is Perl, unless 2.14 is using some parts of Perl that
> Radiator 2.13 is not. I find it hard to understand how a
We have also seen extreme memory leaks in 2.14.1. We backed off to 2.13 and have
not had problems. I doubt it is Perl, unless 2.14 is using some parts of Perl that
Radiator 2.13 is not. I find it hard to understand how a Perl program has memory
leaks - Perl should do automatic Garbage collect
On Tue, 12 Oct 1999, Volker Klau wrote:
> Help!
>
> we are running in problems here, using version 2.14.1 under Linux.
> ( 2.0.36
> perl 5.004_05
> Oracle 8.0.5 )
>
> radiusd grows about 100 megabytes per day.
>
> Looks like a memory leak in handling accounting requests,
> because a daemon
On Wed, 13 Oct 1999, Volker Klau wrote:
> Help!
>
> we are running in problems here, using version 2.14.1 under Linux.
> ( 2.0.36
> perl 5.004_05
> Oracle 8.0.5 )
>
> radiusd grows about 100 megabytes per day.
>
> Looks like a memory leak in handling accounting requests,
> because a daemon
Help!
we are running in problems here, using version 2.14.1 under Linux.
( 2.0.36
perl 5.004_05
Oracle 8.0.5 )
radiusd grows about 100 megabytes per day.
Looks like a memory leak in handling accounting requests,
because a daemon on another machine, doing the authenication most of the time
g
On Mon, 10 May 1999, Mike McCauley wrote:
|o| > For some reason we use Authby EXTERNAL and obtain memory leak
|o| > (about 4k for each 2-3 requests).
|o| > Does anyone have same problem?
|o|
|o| I have been able to reproduce this. It appears to be a leak in in
|o| the perl IPC::Open2. I havenet
On May 7, 8:35pm, Vadim Gashibayazov wrote:
> Subject: (RADIATOR) Memory leak.
> Hi all.
>
> We evaluate Radiator-2.13 on RedHat 5.2 box with 2.0.36 kernel and
> Perl 5.005_02.
> For some reason we use Authby EXTERNAL and obtain memory leak
> (about 4k for each 2-3 requests
Hi all.
We evaluate Radiator-2.13 on RedHat 5.2 box with 2.0.36 kernel and
Perl 5.005_02.
For some reason we use Authby EXTERNAL and obtain memory leak
(about 4k for each 2-3 requests).
Does anyone have same problem?
tia for any advice,
--
Vadim Gashibayazov (VG3-RIPE)
===
To unsubscribe
34 matches
Mail list logo
