Hi!
On Mon, Jan 13, 2003 at 10:15:58AM -0500, Chris Faust wrote:
> Sometimes it will run for days without an issue and other times the machine
> will die, normally because of out of memory problems.
> ..
> Any help or direction would be appreciated.
There is quite a lot of documentation about me
Plamen Stojanov <[EMAIL PROTECTED]> writes:
> I load 2Mb data from a database in perl hash and perl takes 15Mb
> memory. As I use this under mod_perl - perl never returns this
> memory to the OS. I must set a little number for MaxRequestsPerChild
> in order to restart perl interpreter not to eat
Hi there,
On Tue, 8 Oct 2002, Plamen Stojanov wrote:
> I have a ig mem usage problem with perl.
> I load 2Mb data from a database in perl hash and perl takes 15Mb memory.
This isn't a big memory problem unless you only have 32Mb RAM in which
case you're going to run out of memory with mod_perl
Rodney Broom wrote:
> From: Eric <[EMAIL PROTECTED]>
>
>
>>What about in the case of a big query result?
>
>
> I may have come into this thread a bit late, but can't you just undefine the storage
>when you're done with it?
>
> $data = $sth->fetchall_arrayref;
> #... do some stuff;
> $d
From: Eric <[EMAIL PROTECTED]>
> What about in the case of a big query result?
I may have come into this thread a bit late, but can't you just undefine the storage
when you're done with it?
$data = $sth->fetchall_arrayref;
#... do some stuff;
$data = undef;
---
Rodney Broom
President,
Eric wrote:
> What about in the case of a big query result? That is where it seems
> like you can get killed.
Riding a bike without a helmet will get you killed; big query results
are no problem. All you have to do is write your program so that it
pages through results rather than loading the
Hi,
What about in the case of a big query result? That is where it seems like
you can get killed.
I can see my processes grow very large in that case, and there is no way
the memory will come back. But I certainly don't want to limit my processes
because I might want to get a big result from a
Also, try to find an alternative to loading all that data into memory.
You could put it in a dbm file or use Cache::FileCache. If you really
have to have it in memory, load it during startup.pl so that it will be
shared between processes.
- Perrin
Anthony E. wrote:
> look into Apache::Resour
look into Apache::Resource or Apache::SizeLimit which
will allow you to set a maximum size for the apache
process.
both can be added to your startup.pl
--- Plamen Stojanov <[EMAIL PROTECTED]> wrote:
> Hi all,
> I have a ig mem usage problem with perl.
> I load 2Mb data from a database in perl h
[EMAIL PROTECTED] wrote:
>>ok, next trace to the offending code.
> [Tue May 14 10:38:19 2002] [error] Can't call method "size" on unblessed
> reference at /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/Size.pm line
> 94.
> B::AV::size(1, 'B::AV=SCALAR(0xa063444)') called at
> /usr/lib/perl5/
> ok, next trace to the offending code. Put in your startup.pl:
>
> use Carp;
> $SIG{__DIE__} = \&Carp::confess;
>
> hopefully nobody redefines $SIG{__DIE__}
ok, this is what I get in the error log
[Tue May 14 10:38:19 2002] [error] Can't call method "size" on unblessed
reference at /usr/l
[EMAIL PROTECTED] wrote:
>>[EMAIL PROTECTED] wrote:
>>
>>>Hope someone can give me a hand on this, I am having some problem using
>>>the Memory Usage option in the main menu of Apache::Status.
>>>
>>>It always return me a 500 with the following error.
>>>
>>>[Tue May 14 08:48:21 2002] [error] Can'
>
> [EMAIL PROTECTED] wrote:
> > Hope someone can give me a hand on this, I am having some problem using
> > the Memory Usage option in the main menu of Apache::Status.
> >
> > It always return me a 500 with the following error.
> >
> > [Tue May 14 08:48:21 2002] [error] Can't call method "size"
[EMAIL PROTECTED] wrote:
> Hope someone can give me a hand on this, I am having some problem using
> the Memory Usage option in the main menu of Apache::Status.
>
> It always return me a 500 with the following error.
>
> [Tue May 14 08:48:21 2002] [error] Can't call method "size" on unblessed
Hi there,
On Mon, 13 Nov 2000, Tom Harper wrote:
> G.W. Haywood (i think?) said that he set child process expiration at
> 100 hits-- this seems small to me,
Yes, it was he.
He also said that most people think that's rather low and set it higher...
73,
Ged.
On Mon, 13 Nov 2000, Tom Harper wrote:
> was wondering what other folks set their child process
> expiration at for best performance with mod-perl (and
> why) ?
I set it to 0 and use Apache::SizeLimit. No point in killing a process
that isn't too large just because it served x number of reques
[EMAIL PROTECTED]]On Behalf
>> Of Buddy Lee Haystack
>> Sent: Tuesday, November 07, 2000 3:27 PM
>> To: Christian Gilmore
>> Cc: 'G.W. Haywood'; 'mod_perl list'
>> Subject: Re: Memory Usage
>>
>>
>> Thanks Christian!
>>
Actually, I did search through the archives for log rotation and memory leaks, but was
not able to find any information specifically linking memory issues to log rotation.
If it were not for all the helpful people on this list, I wouldn't have known about
all the options I have to minimize the
On Tue, Nov 07, 2000 at 04:26:45PM -0500, Buddy Lee Haystack wrote:
> I take it you've used DSO much more than I have, so I'm interested in
> any information in addition to that provided by the kind "G.W.
> Haywood" to the following:
>
> "What concerns me even more is the fact that I have Apache
Buddy Lee Haystack <[EMAIL PROTECTED]> wrote:
> The memory consumption increases by about 1 megabyte for each child
> process every time I issued the USR1 signal. Which is kind of what I
> expected given Jens-Uwe Mager's explanation of DSO's failings with
> mod_perl.
FWIW, I get a 240k increase i
One potential tip to offer is that if you want to rotate your logs but not
do a hard restart on the server, use something else for the log generation.
You may want to try out mod_log_spread from the mod_backhand site. If it's
not too difficult to setup, then you might be able to use another ser
PROTECTED]]On Behalf
> Of Buddy Lee Haystack
> Sent: Tuesday, November 07, 2000 3:27 PM
> To: Christian Gilmore
> Cc: 'G.W. Haywood'; 'mod_perl list'
> Subject: Re: Memory Usage
>
>
> Thanks Christian!
>
> Scripts would be nice.;-)
>
> I take it
First off, the complaint about the lack of documentation for DSO being
experimental is a bit offbase IMO. It isn't up to the mod_perl group to
make sure RedHat includes complete documentation in their build of
mod_perl.
Also, this issue has been talked about many times on this mailing list.
So
Thanks Christian!
Scripts would be nice.;-)
I take it you've used DSO much more than I have, so I'm interested in any information
in addition to that provided by the kind "G.W. Haywood" to the following:
"What concerns me even more is the fact that I have Apache restart child processes
after
> I'm leaning along the lines of just killing the
> process, rotating the logs, and restarting it. It should take
> no more than 5 seconds once a week a 4:00am.
This is exactly what I do, except I have it scripted. The downside is that
your service is unavailable for a few seconds (maybe more dep
> I also never build mod_perl as a DSO. For the life of me I can't
> understand why so many people do it, and then they act all surprised
> when things go wrong.
I do it out of a desire to not have multiple builds of apache lying around
for the various needs I have of each service I run. For tho
On Tue Nov 7 11:57:44 2000 -0500 Buddy Lee Haystack wrote:
>
> I can always rotate my logs manually, or use the Apache rotatelogs program that
>Ri?ardas ?epas recommended, although if the "rotatelogs" program restarts the server
>I'll be back to square one - the program's man page just states
On Tue, Nov 07, 2000 at 12:38:09PM -0500, Buddy Lee Haystack wrote:
> I may have missed that, but it dosen't mention the "experimental"
> nature of DSO in the "DSO has the following disadvantages:" section of
> the documentation located at "http://www.apache.org/docs/dso.html"
Wait a sec, not _Ap
Thanks!
I was under the mistaken impression that I was finally finished with the
administration side of things...
Oh well...
"G.W. Haywood" wrote:
>
> Hi there,
>
> On Tue, 7 Nov 2000, Buddy Lee Haystack wrote:
>
> > The memory consumption increases by about 1 megabyte for each child
> > p
Thanks, but as a RedHat [or other typical major distribution] user, I would never see
the documentation you mentioned below. Since DSO is still experimental, would it not
be an absolute necessity to include that information in the location where most users
are directed to look for information
Hi again,
On Tue, 7 Nov 2000, Buddy Lee Haystack wrote:
> I may have missed that, but it dosen't mention the "experimental"
> nature of DSO in the "DSO has the following disadvantages:" section
> of the documentation located at
> "http://www.apache.org/docs/dso.html"
Extract from my copy of the
I may have missed that, but it dosen't mention the "experimental" nature of DSO in the
"DSO has the following disadvantages:" section of the documentation located at
"http://www.apache.org/docs/dso.html"
"G.W. Haywood" wrote:
>
> Hi again,
>
> On Tue, 7 Nov 2000, Buddy Lee Haystack wrote:
>
>
Hi there,
On Tue, 7 Nov 2000, Buddy Lee Haystack wrote:
> The memory consumption increases by about 1 megabyte for each child
> process every time I issued the USR1 signal.
Ugh.
> I can always rotate my logs manually, I'm leaning along the lines of
> just killing the process, rotating the log
Hi again,
On Tue, 7 Nov 2000, Buddy Lee Haystack wrote:
> Maybe someone should include this information in the Apache
> documentation covering the DSO issues. It would be very helpful to
> people starting out, such as myself.
It *does* say in the docs that DSO is experimental.
73,
Ged.
Yes, I also believe that this is probably the cause of many "memory leak" issues
people experience with mod_perl using DSO. Had I known of this issue, I would have
budgeted the time to role my own version. I will do so as time permits, but not for a
while.
Maybe someone should include this inf
> What happens if you then do a graceful restart?
The memory consumption increases by about 1 megabyte for each child process every time
I issued the USR1 signal. Which is kind of what I expected given Jens-Uwe Mager's
explanation of DSO's failings with mod_perl.
I can always rotate my logs ma
On Tue, Nov 07, 2000 at 03:59:34PM +, G.W. Haywood wrote:
> I also never build mod_perl as a DSO. For the life of me I can't
> understand why so many people do it, and then they act all surprised
> when things go wrong.
It is a matter of flexibility, especially if you are a distribution
ven
Hi there,
On Tue, 7 Nov 2000, Buddy Lee Haystack wrote:
> > What happens if you then do a graceful restart?
>
> The logrotate scripts use HUP to restart the server. I don't think
> the USR1 would be appropriate for log rotation - according to the
> Apache documentation...
Yeah, I read that. I
On Tue Nov 7 09:37:02 2000 -0500 Buddy Lee Haystack wrote:
> Thank you very much! Now I know why most of the people on this list don't use DSO.
>
> Is there any other work around for this situation other than rotating my logs less
>frequently? Maybe a different method of rotating my logs like
Thank you very much! Now I know why most of the people on this list don't use DSO.
Is there any other work around for this situation other than rotating my logs less
frequently? Maybe a different method of rotating my logs like using the TERM signal
instead of the HUP signal?
Thanks!
Jens-U
"G.W. Haywood" wrote:
>
> Hi there,
>
> On Mon, 6 Nov 2000, Buddy Lee Haystack wrote:
>
> > The morning after "logrotate" runs on my system, the memory usage
> > increases by about 30 megabytes, and continues to do so after each
> > weekly run of the "logrotate" utility.
>
> What happens if yo
On Mon, Nov 06, 2000 at 05:49:05PM -0500, Buddy Lee Haystack wrote:
> I'm using
>
> RedHat Linux v6.1 on an Intel PII SMP box
> Apache v1.3.14
> mod_perl v 1.23
> Apache::DBI 0.87
> DBI v1.13
> DBD Pg v0.93
> PostgreSQL v6.5.3
>
> The morning after "logrotate" runs on my system, the memory usage
Hi there,
On Mon, 6 Nov 2000, Buddy Lee Haystack wrote:
> The morning after "logrotate" runs on my system, the memory usage
> increases by about 30 megabytes, and continues to do so after each
> weekly run of the "logrotate" utility.
What happens if you then do a graceful restart?
> Has anyon
On Tue, 6 Jun 2000, Jeremy Howard wrote:
> Jie Gao said (talking about avoiding memory problems with
> libareq::parms()):
> > What I do is kill the child process after uploading is finished:
> >
> > $r->child_terminate();
> >
> > Not an elegant way, but it works for the time being.
>
> Good
Jie Gao said (talking about avoiding memory problems with
libareq::parms()):
> What I do is kill the child process after uploading is finished:
>
> $r->child_terminate();
>
> Not an elegant way, but it works for the time being.
Good idea. I've implemented something which uses this approach if
On Tue, 6 Jun 2000, Jeremy Howard wrote:
>...
>
> Well, I'm facing this problem now. The parms() method (or parse() or
> anything else that calls parms()) chews up enormous amounts of memory
> when uploading large files. I like to give my webmail users freedom to
> upload pretty much whatever siz
On Wed, Apr 26, 2000 at 08:33:07PM -0700, Douglas Leonard wrote:
> I had the same issue on Linux. My build had mod_perl compiled in static
> but mod_so was also compiled in. PerlFreshRestart was off, I didn't have
> any sections, and no modules were loaded dynamically. My root
> process would
I had the same issue on Linux. My build had mod_perl compiled in static
but mod_so was also compiled in. PerlFreshRestart was off, I didn't have
any sections, and no modules were loaded dynamically. My root
process would grow by about 1MB each time it was HUPed. Something about
mod_so was cau
> You got me! I have sections ... but I didn't know
> it was such a crime. Pretty bizarre behavior if you ask me.
it's not a crime, but if you're running Perl code during restart there's a
strong chance you'll be growing the server size. i agree 1M is bizarre
though.
On Fri, Apr 21, 2000 at 11:28:18AM -0700, Joshua Chamas wrote:
> Doug MacEachern wrote:
> >
> > > I have a static Solaris compilation, and have the same problems
> > > where the parent seems to grow by 1M each HUP.
> >
> > that's strange, do you have PerlFreshRestart On or some sections?
> > ot
Doug MacEachern wrote:
>
> > I have a static Solaris compilation, and have the same problems
> > where the parent seems to grow by 1M each HUP.
>
> that's strange, do you have PerlFreshRestart On or some sections?
> otherwise, kill -HUP with a static modperl is a noop.
You got me! I have sec
Hi all,
On Thu, 20 Apr 2000, Doug MacEachern wrote:
> > I have a static Solaris compilation, and have the same problems
> > where the parent seems to grow by 1M each HUP.
>
> that's strange, do you have PerlFreshRestart On or some sections?
> otherwise, kill -HUP with a static modperl is a no
> I have a static Solaris compilation, and have the same problems
> where the parent seems to grow by 1M each HUP.
that's strange, do you have PerlFreshRestart On or some sections?
otherwise, kill -HUP with a static modperl is a noop.
On Thu, 20 Apr 2000, Paul Lindner wrote:
> Hello mod_perl'ers.
>
> I don't know if it's just me, but I'm having problems with growing
> memory reallocation on a HUP or graceful (USR1) restart. I've looked
> through the mailing list archives and the wonderful guide, but have
> come up short of a
Paul Lindner wrote:
>
> Hello mod_perl'ers.
>
> I don't know if it's just me, but I'm having problems with growing
> memory reallocation on a HUP or graceful (USR1) restart. I've looked
> through the mailing list archives and the wonderful guide, but have
> come up short of answers.
>
> First
55 matches
Mail list logo
