Re: Memory leak in FR 2.1.10 and 2.2.0 ?
On 08/01/13 08:37, Philippe MARASSE wrote: - valgrind log on my production server What did the valgrind log show? It's normally pretty good at catching actual leaks. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak in FR 2.1.10 and 2.2.0 ?
Philippe MARASSE wrote: I'm experiencing an infinitely growth of memory footprint of freeradius process in our production environment (of course, in our test env. everything goes right). That's an issue. As I cannot reproduce this on my test environment by using eapol_test, I suspect alcatel frames to trigger a kind of memory leak in freeradius. Possible. I collected different things : - pcap of eap-md5 exchange between freeradius and a switch - valgrind log on my production server - pidstat showing memory usage of freeradius process So... what were the results? Did valgrind say anything useful? The main issue is that the memory might not be leaked. It might be referenced, but unused. That's much harder to track down. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak in FR 2.1.10 and 2.2.0 ?
First, thanks for the two answers. Le 08/01/2013 14:55, Alan DeKok a écrit : Philippe MARASSE wrote: I'm experiencing an infinitely growth of memory footprint of freeradius process in our production environment (of course, in our test env. everything goes right). That's an issue. As I cannot reproduce this on my test environment by using eapol_test, I suspect alcatel frames to trigger a kind of memory leak in freeradius. Possible. I collected different things : - pcap of eap-md5 exchange between freeradius and a switch - valgrind log on my production server - pidstat showing memory usage of freeradius process So... what were the results? As the complete log is pretty big (around 1 Mb) I did not post the entire result (and it exceeds 500kb limit of pastebin), but I can send by mail valgrind log, pcap and other possibly useful things. Did valgrind say anything useful? I've never used valgrind before but here's some extract that I've think relevant and the summary : ==00:01:17:29.869 24818== 10,033,120 (16,016 direct, 10,017,104 indirect) bytes in 143 blocks are definitely lost in loss record 723 of 724 ==00:01:17:29.869 24818==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==00:01:17:29.869 24818==by 0x806B2EC: rad_malloc (in /usr/sbin/freeradius) ==00:01:17:29.869 24818==by 0x47FBBE5: ??? ==00:01:17:29.869 24818==by 0x47F9A15: ??? ==00:01:17:29.869 24818==by 0x47F8E99: ??? ==00:01:17:29.869 24818==by 0x8065C0A: modcall (in /usr/sbin/freeradius) ==00:01:17:29.869 24818==by 0x8061CDF: indexed_modcall (in /usr/sbin/freeradius) ==00:01:17:29.869 24818==by 0x80620FB: module_authenticate (in /usr/sbin/freeradius) ==00:01:17:29.869 24818==by 0x804FFAD: rad_authenticate (in /usr/sbin/freeradius) ==00:01:17:29.869 24818==by 0x8074089: radius_handle_request (in /usr/sbin/freeradius) ==00:01:17:29.869 24818==by 0x806AAF5: ??? (in /usr/sbin/freeradius) ==00:01:17:29.869 24818==by 0x4081954: start_thread (pthread_create.c:300) ==00:01:17:29.869 24818== ==00:01:17:29.869 24818== LEAK SUMMARY: ==00:01:17:29.869 24818==definitely lost: 51,904 bytes in 382 blocks ==00:01:17:29.869 24818==indirectly lost: 26,398,375 bytes in 15,411 blocks ==00:01:17:29.869 24818== possibly lost: 2,145,153 bytes in 1,719 blocks ==00:01:17:29.869 24818==still reachable: 40,292 bytes in 2,493 blocks ==00:01:17:29.869 24818== suppressed: 0 bytes in 0 blocks ==00:01:17:29.869 24818== Reachable blocks (those to which a pointer was found) are not shown. ==00:01:17:29.869 24818== To see them, rerun with: --leak-check=full --show-reachable=yes ==00:01:17:29.869 24818== ==00:01:17:29.869 24818== For counts of detected and suppressed errors, rerun with: -v ==00:01:17:29.869 24818== Use --track-origins=yes to see where uninitialised values come from ==00:01:17:29.869 24818== ERROR SUMMARY: 493967 errors from 561 contexts (suppressed: 97 from 12) I don't know if I've missed something as there's some ??? in the call stacks ? The main issue is that the memory might not be leaked. It might be referenced, but unused. That's much harder to track down. Rgds. -- Philippe MARASSE Service Informatique - Centre Hospitalier Henri Laborit BP 587 - 370 avenue Jacques Coeur 86021 Poitiers Cedex Tel : 05.49.44.57.19 smime.p7s Description: Signature cryptographique S/MIME - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak in FR 2.1.10 and 2.2.0 ?
Philippe MARASSE wrote: As the complete log is pretty big (around 1 Mb) I did not post the entire result (and it exceeds 500kb limit of pastebin), but I can send by mail valgrind log, pcap and other possibly useful things. For this, send valgrind logs to me personally. I've never used valgrind before but here's some extract that I've think relevant and the summary : ==00:01:17:29.869 24818== 10,033,120 (16,016 direct, 10,017,104 indirect) bytes in 143 blocks are definitely lost in loss record 723 of 724 ==00:01:17:29.869 24818==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==00:01:17:29.869 24818==by 0x806B2EC: rad_malloc (in /usr/sbin/freeradius) ==00:01:17:29.869 24818==by 0x47FBBE5: ??? ==00:01:17:29.869 24818==by 0x47F9A15: ??? ==00:01:17:29.869 24818==by 0x47F8E99: ??? Well... that needs to be fixed. I don't know if I've missed something as there's some ??? in the call stacks ? You need to build the server with debugging symbols. See doc/bugs The ??? indicates that valgrind couldn't find symbols for one of the modules which was loaded. And even the above trace might not be useful. This is leaked at *exit*. The server might be tracking memory correctly, so it's not exactly a leak. And that tracked memory is cleaned up at exit. i.e. there may be one of two issues here: - actual leaked memory - memory which SHOULD have been free'd, but wasn't. It's still tracked, just not used. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak in FR 2.1.10 and 2.2.0 ?
Le 08/01/2013 16:24, Alan DeKok a écrit : Philippe MARASSE wrote: As the complete log is pretty big (around 1 Mb) I did not post the entire result (and it exceeds 500kb limit of pastebin), but I can send by mail valgrind log, pcap and other possibly useful things. For this, send valgrind logs to me personally. I've never used valgrind before but here's some extract that I've think relevant and the summary : ==00:01:17:29.869 24818== 10,033,120 (16,016 direct, 10,017,104 indirect) bytes in 143 blocks are definitely lost in loss record 723 of 724 ==00:01:17:29.869 24818==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==00:01:17:29.869 24818==by 0x806B2EC: rad_malloc (in /usr/sbin/freeradius) ==00:01:17:29.869 24818==by 0x47FBBE5: ??? ==00:01:17:29.869 24818==by 0x47F9A15: ??? ==00:01:17:29.869 24818==by 0x47F8E99: ??? Well... that needs to be fixed. I don't know if I've missed something as there's some ??? in the call stacks ? You need to build the server with debugging symbols. See doc/bugs The ??? indicates that valgrind couldn't find symbols for one of the modules which was loaded. I'm a bit confused : I built debian package with rules provided in tarball, configure options are : ./configure --build i486-linux-gnu \ --prefix=/usr \ --exec-prefix=/usr \ --mandir=/usr/share/man \ --sysconfdir=/etc \ --libdir=/usr/lib/freeradius \ --datadir=/usr/share \ --localstatedir=/var \ --with-raddbdir=/etc/freeradius \ --with-logdir=/var/log/freeradius \ --enable-ltdl-install=no --enable-strict-dependencies \ --with-large-files --with-udpfromto --with-edir \ --enable-developer \ --config-cache \ --without-rlm_eap_tnc \ --with-rlm_sql_postgresql_lib_dir=`pg_config --libdir` \ --with-rlm_sql_postgresql_include_dir=`pg_config --includedir` \ --without-rlm_eap_ikev2 \ --without-rlm_sql_oracle \ --without-rlm_sql_unixodbc \ --with-system-libtool \ --with-system-libltdl unless I've missed something, --enable-developer should be sufficient to generate debugging symbols for freeradius modules ? And even the above trace might not be useful. This is leaked at *exit*. The server might be tracking memory correctly, so it's not exactly a leak. And that tracked memory is cleaned up at exit. i.e. there may be one of two issues here: - actual leaked memory - memory which SHOULD have been free'd, but wasn't. It's still tracked, just not used. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Regards -- Philippe MARASSE Service Informatique - Centre Hospitalier Henri Laborit BP 587 - 370 avenue Jacques Coeur 86021 Poitiers Cedex Tel : 05.49.44.57.19 smime.p7s Description: Signature cryptographique S/MIME - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak in FR 2.1.10 and 2.2.0 ?
Philippe MARASSE wrote: I'm a bit confused : I built debian package with rules provided in tarball, configure options are : It should work. If it doesn't, check that there aren't *other* modules on the system. They could have been built without debugging symbols. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak in FR 2.1.10 and 2.2.0 ?
Le 08/01/2013 21:56, Alan DeKok a écrit : Philippe MARASSE wrote: I'm a bit confused : I built debian package with rules provided in tarball, configure options are : It should work. If it doesn't, check that there aren't *other* modules on the system. They could have been built without debugging symbols. I found that I've forgotten to install freedebug-dbg package, it's much more explicit now. I'll try to do a valgrind log tomorrow within business hours. Rgds. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak on reload
Derek Chee wrote: I have a FreeRADIUS 2.1.9 installation (compiled from source) running on Solaris 10 Sparc and I've run into a memory leak issue when reloading the configuration with a HUP signal. I have a very simple RADIUS setup with just an authorize and a users file. The users file is rather large at 41MB and over 110,000 records, but I've noticed that problem with the default empty users file, too. Starting up FreeRADIUS with -X, waiting until FreeRADIUS says Ready to process requests. and checking the memory usage, I get this: ... Eventually the radiusd process takes up all of the memory on the system and the system grinds to a halt. Does anybody have any suggestions on what might be causing this and how to fix it? It's not a memory leak. The server keeps the old configuration around for a while after a HUP. This is because a request might still be in the middle of being processed, and therefore is using the old configuration. If you wait at least 60 seconds between HUPs, the old users file configuration will be freed. There will still, however, be portions of the configuration that *cannot* be free'd without drastic changes to the server core. i.e. The server will user a small amount of additional memory on every HUP. If this is a problem, then patches are welcome. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak on reload
On Aug 25, 2010, at 3:14 AM, Alan DeKok wrote: Derek Chee wrote: I have a FreeRADIUS 2.1.9 installation (compiled from source) running on Solaris 10 Sparc and I've run into a memory leak issue when reloading the configuration with a HUP signal. I have a very simple RADIUS setup with just an authorize and a users file. The users file is rather large at 41MB and over 110,000 records, but I've noticed that problem with the default empty users file, too. Starting up FreeRADIUS with -X, waiting until FreeRADIUS says Ready to process requests. and checking the memory usage, I get this: ... Eventually the radiusd process takes up all of the memory on the system and the system grinds to a halt. Does anybody have any suggestions on what might be causing this and how to fix it? It's not a memory leak. The server keeps the old configuration around for a while after a HUP. This is because a request might still be in the middle of being processed, and therefore is using the old configuration. If you wait at least 60 seconds between HUPs, the old users file configuration will be freed. There will still, however, be portions of the configuration that *cannot* be free'd without drastic changes to the server core. i.e. The server will user a small amount of additional memory on every HUP. If this is a problem, then patches are welcome. Ah, okay, thanks for explaining it. I was HUP'ing the server rather fast, so I wasn't giving it a break. -- Derek - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory Leak
Zhang, Ge (Gina) wrote: Thanks for your advise. I ran radiusd with valgrind. The only leak when processing a request is in rlm_wimax. After I fixed it, I still see RES memory increases with each request processing. Could you please help with the following questions? 1. Where does the caches happen with the authentication protocol suite set to eap-ttls+mschapv2? 2. How big is the caches or it is unlimited? 3. Is there a timer associating with the cached data? If yes, how long it is and it is configurable? These are more properly questions for the -devel list. All caches are either automatic, or controlled by configuration variables. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Memory Leak
Alan, Thanks for your advise. I ran radiusd with valgrind. The only leak when processing a request is in rlm_wimax. After I fixed it, I still see RES memory increases with each request processing. Could you please help with the following questions? 1. Where does the caches happen with the authentication protocol suite set to eap-ttls+mschapv2? 2. How big is the caches or it is unlimited? 3. Is there a timer associating with the cached data? If yes, how long it is and it is configurable? Thanks, Gina Zhang -Original Message- From: freeradius-users-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org [mailto:freeradius-users-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Thursday, March 25, 2010 6:58 PM To: FreeRadius users mailing list Subject: Re: Memory Leak on version 2.1.3 Zhang, Ge (Gina) wrote: I tried 2.1.8 and it leaks memory exactly like 2.1.3. Any other suggestions? Are you sure it's a memory leak? The server *is* supposed to use memory for various kinds of caching. See valgrind for tracking down memory leaks. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory Leak on version 2.1.3
Hi, The server is in production and we won't upgrade for a while. but you're willing to patch and recompile the old/obsolete 2.1.3 version? whats the difference? its pretty much the same situation. go for 2.1.8. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Memory Leak on version 2.1.3
Alan, Does 2.1.8 have the fix for the problem? Regards, Gina -Original Message- From: freeradius-users-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org [mailto:freeradius-users-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org] On Behalf Of Alan Buxey Sent: Thursday, March 25, 2010 4:42 AM To: FreeRadius users mailing list Subject: Re: Memory Leak on version 2.1.3 Hi, The server is in production and we won't upgrade for a while. but you're willing to patch and recompile the old/obsolete 2.1.3 version? whats the difference? its pretty much the same situation. go for 2.1.8. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory Leak on version 2.1.3
Hi, Alan, Does 2.1.8 have the fix for the problem? its got many fixes - check the source code. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Memory Leak on version 2.1.3
Alan, I tried 2.1.8 and it leaks memory exactly like 2.1.3. Any other suggestions? Thanks, Gina -Original Message- From: freeradius-users-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org [mailto:freeradius-users-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org] On Behalf Of Alan Buxey Sent: Thursday, March 25, 2010 4:42 AM To: FreeRadius users mailing list Subject: Re: Memory Leak on version 2.1.3 Hi, The server is in production and we won't upgrade for a while. but you're willing to patch and recompile the old/obsolete 2.1.3 version? whats the difference? its pretty much the same situation. go for 2.1.8. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory Leak on version 2.1.3
Zhang, Ge (Gina) wrote: I tried 2.1.8 and it leaks memory exactly like 2.1.3. Any other suggestions? Are you sure it's a memory leak? The server *is* supposed to use memory for various kinds of caching. See valgrind for tracking down memory leaks. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory Leak on version 2.1.3
there are at least 3 newer versions. Have you tried the latest and/or read the changelog? - Original Message - From: freeradius-users-bounces+ggatten=waddell@lists.freeradius.org freeradius-users-bounces+ggatten=waddell@lists.freeradius.org To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Sent: Wed Mar 24 18:24:54 2010 Subject: Memory Leak on version 2.1.3 Hi, I am using 2.1.3 freeradius server and found memory leak. I use ttls+mschapv2 for authentication. After each authentication, the memory usage increases. Is there a patch fix for this? Thanks, Gina Zhang - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Memory Leak on version 2.1.3
The server is in production and we won't upgrade for a while. Where to find the changelog? Thanks for your help! Regards, Gina -Original Message- From: freeradius-users-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org [mailto:freeradius-users-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org] On Behalf Of Gary Gatten Sent: Wednesday, March 24, 2010 6:31 PM To: 'freeradius-users@lists.freeradius.org' Subject: Re: Memory Leak on version 2.1.3 there are at least 3 newer versions. Have you tried the latest and/or read the changelog? - Original Message - From: freeradius-users-bounces+ggatten=waddell@lists.freeradius.org freeradius-users-bounces+ggatten=waddell@lists.freeradius.org To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Sent: Wed Mar 24 18:24:54 2010 Subject: Memory Leak on version 2.1.3 Hi, I am using 2.1.3 freeradius server and found memory leak. I use ttls+mschapv2 for authentication. After each authentication, the memory usage increases. Is there a patch fix for this? Thanks, Gina Zhang - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory Leak on version 2.1.3
Hi, Even though you're running it in production I'd recommend updating every now and again. IMHO it's worth it, RADIUS is used for Authentication after all. I tend to keep a copy of my last build in case I need to revert anyway. Regards, Matt Harlum On 25/03/2010, at 10:35 AM, Zhang, Ge (Gina) wrote: The server is in production and we won't upgrade for a while. Where to find the changelog? Thanks for your help! Regards, Gina -Original Message- From: freeradius-users-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org [mailto:freeradius-users-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org] On Behalf Of Gary Gatten Sent: Wednesday, March 24, 2010 6:31 PM To: 'freeradius-users@lists.freeradius.org' Subject: Re: Memory Leak on version 2.1.3 there are at least 3 newer versions. Have you tried the latest and/or read the changelog? - Original Message - From: freeradius-users-bounces+ggatten=waddell@lists.freeradius.org freeradius-users-bounces+ggatten=waddell@lists.freeradius.org To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Sent: Wed Mar 24 18:24:54 2010 Subject: Memory Leak on version 2.1.3 Hi, I am using 2.1.3 freeradius server and found memory leak. I use ttls+mschapv2 for authentication. After each authentication, the memory usage increases. Is there a patch fix for this? Thanks, Gina Zhang - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak or misunderstanding - rlm_perl?
Alan DeKok al...@deployingradius.com wrote: I am running freeradius-2.1.6 with all AAA logick hidden in perl module, thus using rlm_perl. Having about 1000-1 client connections per day radiusd consumes about 1Gb of memory per day (I restart it daily). The only (possibly) important thing - I am using several external modules in my main perl module. Perl's garbage collector isn't perfect. It may be that you really do need to restart to get memory cleaned up. At the end of the request handling function, it might be work getting your script to look at how much memory it has consumed[1] and then commit Seppuku; hopefully FreeRADIUS is primed to notice the suicide and restart the perl module from scratch. A trivial fix, but if you have long running state information you might need to do some reworking to move some data into a DB file or something (*not* an SQL database...please :) Cheers [1] http://www.perlmonks.org/?node_id=115098 -- Alexander Clouter .sigmonster says: Beware of a tall black man with one blond shoe. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak or misunderstanding - rlm_perl?
Alexander Clouter Alan DeKok al...@deployingradius.com wrote: I am running freeradius-2.1.6 with all AAA logick hidden in perl module, thus using rlm_perl. Having about 1000-1 client connections per day radiusd consumes about 1Gb of memory per day (I restart it daily). The only (possibly) important thing - I am using several external modules in my main perl module. Perl's garbage collector isn't perfect. It may be that you really do need to restart to get memory cleaned up. At the end of the request handling function, it might be work getting your script to look at how much memory it has consumed[1] and then commit Seppuku; hopefully FreeRADIUS is primed to notice the suicide and restart the perl module from scratch. A trivial fix, but if you have long running state information you might need to do some reworking to move some data into a DB file or something (*not* an SQL database...please :) Well, I actualy already do it - I store the actual data in memcached, running as a stand-alone process. Well, thank you anyway. Cheers [1] http://www.perlmonks.org/?node_id=115098 -- Alexander Clouter .sigmonster says: Beware of a tall black man with one blond shoe. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak or misunderstanding - rlm_perl?
Mihail Vasiliev wrote: Hello, all. I am running freeradius-2.1.6 with all AAA logick hidden in perl module, thus using rlm_perl. Having about 1000-1 client connections per day radiusd consumes about 1Gb of memory per day (I restart it daily). The only (possibly) important thing - I am using several external modules in my main perl module. Perl's garbage collector isn't perfect. It may be that you really do need to restart to get memory cleaned up. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak or misunderstanding - rlm_perl?
On Oct 7, 2009, at 8:58 PM, Mihail Vasiliev wrote:
thread pool {
start_servers = 5
max_servers = 32
min_spare_servers = 3
max_spare_servers = 10
max_requests_per_server = 300
}
Try run it with fixed pool size. This will reduce memory consumption.
Best Regards,
Boian Jordanov
RD Expert
Orbitel - Next Generation Telecom
tel. +359 2 4004 723
tel. +359 2 4004 002
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak in rlm_perl
On Mon, 25 Oct 2004 10:27:14 +0200 Nils Rønhovde [EMAIL PROTECTED] wrote: On Tue, 14 Sep 2004 13:29:23 -0400 Alan DeKok [EMAIL PROTECTED] wrote: =?ISO-8859-1?Q?Jo=E3o_S=E1?= [EMAIL PROTECTED] wrote: Until now everything is fine but now I need to use a module in perl to do credit control. I verified that when I start, the freeradius process begins with about 26 Mb in memory growing until I eat all memory available (I already had a process with 400 Mb). The Perl module has issues in 0.9.3. There's a patch for 1.0.0 on bugs.freeradius.org, which will go into 1.1.0. Alan DeKok. Forgive me for asking a maybe stupid question (or request). I have tried to apply the patch for bug 111 found on bugs.freeradius.org (after some careful editing of html-tags etc.), but patch fails after some hunks. I am not very experienced in using patch, so it may be my problem. After a few hours more, and some lunch, I figured it out. Don't ask me how, though.. BTW is it tested and found OK? This still applies... -- best regards Nils Rønhovde - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory leak in rlm_perl
=?ISO-8859-1?Q?Jo=E3o_S=E1?= [EMAIL PROTECTED] wrote: Until now everything is fine but now I need to use a module in perl to do credit control. I verified that when I start, the freeradius process begins with about 26 Mb in memory growing until I eat all memory available (I already had a process with 400 Mb). The Perl module has issues in 0.9.3. There's a patch for 1.0.0 on bugs.freeradius.org, which will go into 1.1.0. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory Leak for Accounting using Oracle
Hello It is not a problem but optimization of userspace allocating memory system. If you allocate some amount of userspace memory and then free it, memory scheduler will never return all the amount back to the kernel. It is needed to decrease number of kernel calls. Sorry for my english. Regards, Nik - Original Message - From: Yasser Ahmed Hosny [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 2:50 PM Subject: Memory Leak for Accounting using Oracle Dear All I am using Freeradius 1.0.0 pre03 version running on Sun Solaris 8 and I am connecting to an Oracle DB for accounting. My Oracle DB is located on another Sun Solaris server 8i and I am using oracle client version 8.1.7.4. I realized that I am loosing memory on the DB machine after pushing few START requests using radclient. This was tracked using TOP utility for SUN and I was tracking the Free memory, which was declining and tracking the oracle connection memory utilization, which was increasing significantly, it started with 12M and ended by 39M after 1500 START requests. Other tests were carried out on older version of Freeradius (0.7.1 and 0.9.0) and all reported the same problem. Appreciate your help. Regards Yasser Ahmed Hosny - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory Leak for Accounting using Oracle
Yasser Ahmed Hosny [EMAIL PROTECTED] wrote: I am using Freeradius 1.0.0 pre03 version running on Sun Solaris 8 and I am connecting to an Oracle DB for accounting. My Oracle DB is located on another Sun Solaris server 8i and I am using oracle client version 8.1.7.4. I realized that I am loosing memory on the DB machine after pushing few START requests using radclient. No one else has reported this so far. If you don't have access to Purify, I suggest building the server on a Linux box, with the Oracle client libraries there, and running valgrind. But don't build the server with OpenSSL support... valgrind reports so many errors in the OpenSSL code that you won't see any errors from the servers Oracle module. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Memory Leak for Accounting using Oracle
--__--__-- Message: 4 Date: Tue, 03 Aug 2004 12:50:13 +0400 From: Yasser Ahmed Hosny [EMAIL PROTECTED] Subject: Memory Leak for Accounting using Oracle To: [EMAIL PROTECTED] Organization: Emirates Internet Multimedia Reply-To: [EMAIL PROTECTED] Dear All I am using Freeradius 1.0.0 pre03 version running on Sun Solaris 8 and I am connecting to an Oracle DB for accounting. My Oracle DB is located on another Sun Solaris server 8i and I am using oracle client version 8.1.7.4. I realized that I am loosing memory on the DB machine after pushing few START requests using radclient. This was tracked using TOP utility for SUN and I was tracking the Free memory, which was declining and tracking the oracle connection memory utilization, which was increasing significantly, it started with 12M and ended by 39M after 1500 START requests. Other tests were carried out on older version of Freeradius (0.7.1 and 0.9.0) and all reported the same problem. Appreciate your help. Regards Yasser Ahmed Hosny If you can i would suggest upgrading Oracle. I'm running 9.2.0.4 on Sol8 on the same box as my radius server (was 0.8.3 now 1.0.0-pre3) and i don't have any problems with memory usage. I do have problems with sockets but that is a different thing. Also, the system is using much less memory and cpu on 1.0.0 than it was on 0.8.3. And supposedly it gets even better on 10g. -- Terry J Fike Jr System Administrator MTA Solutions 907-793-4100 [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
