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
Hi All,
I've converted my site to mod_perl and everything seems great..
Sometimes it will run for days without an issue and other times the machine
will die, normally because of out of memory problems.
My question is, should I be doing anything to worry about memory? I mean I
would think when th
rpreter not to eat a lot of memory. Is
> there any solution to avoid such memory usage?
Simple: dont load this into memory. You can achieve this in multiple ways:
- (if you really need to get this as hash) use DBM hash, mapping those
resources to disk instead of memory
- (if you can reconsid
t of memory with mod_perl soon anyway.
> Is there any solution to avoid such memory usage?
Don't load the data into memory that way. There are also ways to
share data between processes, check the archives for discussions on
the topic - it gets discussed a lot.
73,
Ged.
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
to the OS. I must set a little number for MaxRequestsPerChild in
>>>order
>>>to restart perl interpreter not to eat a lot of memory. Is there any
>>>solution to avoid such memory usage?
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 a lot of memory.
>>Is there any solution to avoid such memory usage?
atabase 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 a lot of memory.
> Is there any
a lot of memory.
Is there any solution to avoid such memory usage?
[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
>
> [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:4
[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 met
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
reference at
Andrei A. Voropaev wrote:
> Hi!
>
> Just wanted to check if it is possible to trace memory usage of each
> mod_perl modules. It's kind of does not look very realistic, but I do not know
> the whole truth...
Sure you can, arm yourself with B::TerseSize. Look at Apache::Stat
Hi!
Just wanted to check if it is possible to trace memory usage of each
mod_perl modules. It's kind of does not look very realistic, but I do not know
the whole truth...
Thanks
Andrei
On Wed, 7 Feb 2001, rene mendoza wrote:
> Hi, i have a question regarding mod_perl/apache mysql memory usage
>
> I have a Linux box running Red Hat 6.1, Apache 1.3.14,
> compiled statically with mod_perl 1.24_01, mod_ssl, and Open SSL,
> mod_dav and mod_gzip running as DSO
necting via ethernet from a windows box with Internet Explorer
> and with Netscape, after a few requests httpd memory usage grows to
> 80MB, and mysqld to over 20MB
> it still feels fast but im wondering if its normal???
Perfectly normal. See http://perl.apache.org/guide (and many, many
Hi, i have a question regarding mod_perl/apache
mysql memory usage
I have a Linux box running Red Hat 6.1, Apache
1.3.14, compiled statically with mod_perl 1.24_01, mod_ssl, and Open
SSL,mod_dav and mod_gzip running as DSO's, MYSQL
ismysql-3.23.28-gamma-pc-linux-gnu-i686 (binary)
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
gt; DBD Pg v0.93
> > PostgreSQL v6.5.3
> >
> > 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.
> >
> > Has anyo
"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
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 &qu
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
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 increases by about 30
megabytes, and continues to do so after each we
> > Apache::Status seems like a nice module, but I don't understand
> > what the Memory usage section is telling me.
> >
> > For a given package, I have a function foo() that has a line
> > like this.
> >
> >
> > foo 48293 bytes
de?, stack?, data? or a combination
>of some of the three?
TerseSize measures the sizeof() all structures (and strlen() of any
strings) pointed to by the syntax (op) tree, lexical variables and
globals.
> 2) 1172 OPs - what's an OPs? Is it good to have more or less? How does
>
k?, data? or a combination
>of some of the three?
Code and data combined, AFAIK. Its data from some B::Terse or B::TerseSize
module. See the documentation in that for more details.
> 2) 1172 OPs - what's an OPs? Is it good to have more or less? How does
>that affect memory
This is my first time posting to this list, so forgive me
if this question has been asked before (I did not see it in
the archives or in the mod_perl guide).
Apache::Status seems like a nice module, but I don't understand
what the Memory usage section is telling me.
For a given package, I
Joshua Chamas wrote:
>
> As long as you are loading CGI in your PerlRequire startup.pl
> with the compile option, CGI should not be hurting you as
> its loaded in the parent httpd. You can also precompile
> your CGI scripts with Apache::RegistryLoader for a big win
> in processor speed and memor
Sean Kelly <[EMAIL PROTECTED]> writes:
> Hello there,
>
> I'm currently developing a few web based applications using
> Apache, mod_perl, Perl 5 and the Postgres relational database. This
> applications are running on an Intel Linux 2.0.38 machine, with 32Mb
> memory.
I have to say, 32M
Sean Kelly wrote:
> Yes, I am also using CGI.pm and thought this was a bit of a hog
> ... I am planning to finish off my cut-down version of CGI.pm to handle
> just the CGI I need in an OO sense (this is a very small amount). I will
> be monitoring improvements when this goes into devel.
On Thu, 27 Jul 2000 [EMAIL PROTECTED] wrote:
> Wow, is the guide for you!
>
> They have a whole section on optimizing mod_perl with respect to memory.
>
> http://perl.apache.org/guide. Thank Stas Bekman for it.
>
> The two biggest perl modules that get sucked into Apache are the
> IO:: family
amount of virtual memory, but much of that is physically
shared. The virtual memory usage remains the same. You need to check
your system-wide physical resource usage to see if there were any
changes before and after your tuning efforts.
SK> Is there any advice that people could give to me
e, but for the
moment this is what I am playing with :(
Looking at the output from 'top' I see that each of my 3 mod_perl
enabled http servers are reporting between 25 and 30% memory usage. To
cut down on this, I turned to the performance tuning guide and the user
guide from
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
Way back in the annals of history (well, err, 24 Feb 2000, anyway) there
was some discussion about uploads chewing up memory in libareq...
Jim Winstead said:
Is it just me, or is it pretty dodgy code? It allocates memory like
its going out of style (it doesn't appear to reuse any of the
buffers
On Thu, 4 May 2000 [EMAIL PROTECTED] wrote:
> Sounds like a good plan. The first piece to put together is the
> script that can register callbacks, and iterate through the perl
> threads. Do we have a devel version that's got the mip->avail type
> stuff together, or is this something that will
[chopping down the digital forest because the light has turned on :)]
> just a seperate thread that plucks a mip->avail interpreter, puts it in
> the mip->busy list, analyzes, puts back, plucks the next mip->avail, over
> and over.
Sounds like a good plan. The first piece to put together is the
On Wed, 3 May 2000 [EMAIL PROTECTED] wrote:
> So what you want is something more general, climbs through the symbol
> table and can register callbacks for various things, right? One of
right.
> which, the area I'm most interested in, is the PADLIST? Well, that's
same here!
> certainly some
> what i'd really like to see is a generic symbol table walker (written in
> c), where you can register callbacks foreach symbol type (SVt_*). then
> once you hit an SVt_PVCV, there can be any number of registered callbacks
> that fiddle with the padlist (cleaner, reporter, etc.)
So what you wan
On Tue, 25 Apr 2000 [EMAIL PROTECTED] wrote:
> Let me know when you want the garbage collector. I'll re-write it in
> apache style, and add some debugging stuff. I figure there should be
> two pieces. One that analyzes the packages that are running, the
> other that actually kills off variabl
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
ave an idea of what´s going on...
That's not a huge amount of help, but you reading the mod_perl guide will
be: http://perl.apache.org/guide/
Look for the bits on memory usage (I'm sure someone here will give you a
direct URL in about 5 minutes...).
--
Fastnet Software Ltd. High Perfor
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
> Everything gets slowed down some by context switching, but my point is
> that a long request doesn't hold up short requests in the same way if you
> are processing in parallel. Also, if all of your requests are n seconds
> long, and you process 10 of them that arrive at the server simultaneousl
On Wed, 26 Apr 2000, Leslie Mikesell wrote:
> According to Perrin Harkins:
> > On Tue, 25 Apr 2000 [EMAIL PROTECTED] wrote:
> > > With mod_proxy you really only need a few mod_perl processes because
> > > no longer is the mod_perl ("heavy") apache process i/o bound. It's
> > > now CPU bound. (o
According to Perrin Harkins:
> On Tue, 25 Apr 2000 [EMAIL PROTECTED] wrote:
> > With mod_proxy you really only need a few mod_perl processes because
> > no longer is the mod_perl ("heavy") apache process i/o bound. It's
> > now CPU bound. (or should be under heavy load)
>
> I think for most of
On Tue, 25 Apr 2000 [EMAIL PROTECTED] wrote:
> With mod_proxy you really only need a few mod_perl processes because
> no longer is the mod_perl ("heavy") apache process i/o bound. It's
> now CPU bound. (or should be under heavy load)
I think for most of us this is usually not the case, since mo
Justin,
On Tue, Apr 25, 2000 at 11:26:00PM -0400, [EMAIL PROTECTED] wrote:
> On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
> >
> > > It is very memory inneffecient basically. Each process of apache has
> > > it's registry which holds the compiled perl scripts in..., a copy of
> > > each for each
Doug & modperlers...
> however, padlists are not shared. as i mentioned, i'd like to look at
> using your "garbage collector" for 2.0. if it could run in it's own
> thread and examine the padlists of idle interpreters, it could be big win.
> i wouldn't want it to release all allocations in th
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
>
> > It is very memory inneffecient basically. Each process of apache has
> > it's registry which holds the compiled perl scripts in..., a copy of
> > each for each process. This has become an issue for one of the
> > companies that I work for, and
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
> Modperlers...,
>
> I'd like to start a discussion about the deficiences in Apache/modperl
> and get you feedback with regard to this issue. The problem as I see
> it is that the process model that Apache uses is very hard on modperl.
mod_perl-2.0/
On Mon, 17 Apr 2000, Perrin Harkins wrote:
> What I know about Perl internals could fit on the head of a pin, but
> this strikes me as a very odd statement. If the garbage collector is
> never used, why do my lexical variables go out of scope and get
> destroyed? There are mod_perl packages li
> 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
> On Tue, 18 Apr 2000, Stas Bekman wrote:
>
> > What do you say? 1003520 bytes are returned to OS when @x goes out of
> > scope. Note that this doesn't happen if you use a global @x instead.
>
> because under linux Perl defaults to system malloc:
> % perl -V:usemymalloc
> usemymalloc='n';
>
>
s. I started a server with a clean config and
> slowly added the perl configs, and came up with the following memory
> analysis.
>
> No perl configs (numbers are actual/shared memory usage, hup by hup)
>
> 3588/2228 -> 3636/2284 -> 3680/2324 -> 3724/2364 -> 3768/240
with the following memory
analysis.
No perl configs (numbers are actual/shared memory usage, hup by hup)
3588/2228 -> 3636/2284 -> 3680/2324 -> 3724/2364 -> 3768/2404 -> 3812/2444
Adding a (very) small Apache::Registry section results in:
4332/3024 -> 4732/3436 -> 5132/3832 ->
>From: "Jeff Stuart" <[EMAIL PROTECTED]>
>To: "Gunther Birznieks" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
>Subject: RE: Modperl/Apache deficiencies... Memory usage.
>Date: Tue, 18 Apr 2000 02:07:24 -0400
>
>I understand that. :) And th
written to be a persistent language, so again, the tradeoff of
> > operational speed seems to make sense versus persistent memory usage.
> >
> > Later,
> >Gunther
> >
>
>Gunther,
>
>Curiosity leads me to the following question...:
>
>So what your talking
not
> really written to be a persistent language, so again, the tradeoff of
> operational speed seems to make sense versus persistent memory usage.
>
> Later,
>Gunther
>
Gunther,
Curiosity leads me to the following question...:
So what your talking about is lets say a v
On Tue, Apr 18, 2000 at 02:07:24AM -0400, Jeff Stuart wrote:
> I understand that. :) And that was something that I had to learn myself.
> :) It's a BAD thing when suddenly your httpd process takes up 100 MB. :)
> It's just that it sounded like Shane was saying that his httpds were
> starting O
On Tue, 18 Apr 2000 [EMAIL PROTECTED] wrote:
> On Mon, Apr 17, 2000 at 01:33:08PM -0600, Jason Terry wrote:
> > This is the first i have seen "delete" referenced. What does it do? How is it
>used?
> >
> > Thank you
> > -Jason
>
> It's the stack cleaner... but it only works for scalars,
Since you are talking about garbage collection (memory shrinking) you
might want to re-read the thread I've started back in Aug, 99:
http://forum.swarthmore.edu/epigone/modperl/zarwhegerd
It includes the real show case of memory shrinking (at least on Linux).
Consider this code:
--
il 18, 2000 1:24 AM
To: [EMAIL PROTECTED]
Subject: RE: Modperl/Apache deficiencies... Memory usage.
If you aren't careful with your programming, an apache HTTPD can always
grow pretty quickly because Perl never releases the RAM it allocates
previously. While it does that reference count garbage coll
> [ By the way, Stas - is there a CVS version of the guide that I can make
> patches against? I found a few inaccuracies. ]
Yeah, but it's not accessible for people from the outside. I think I'll
start using the same mechanism apache.org does -- rolling out CVS
snapshots every few hours. At thi
1 - 100 of 135 matches
Mail list logo
