On Aug 23, 2006, at 6:05 PM, Jonathan Tweed wrote:
I'm not clear on how these numbers are interpreted, but it looks to
me that the FreeBSD is allocating all 30MB at startup. Have I
missed something in httpd.conf that will cause this? It also looks
like 64656 has been replaced by 64835 but I don't see any errors in
the error log.
First off, I get the exact same behavior in terms of sizes re: osx /
freebsd -- which is why I started this.
In terms of the 30MB-- take off sizelimit, and you'll see the
numbers. Apache::Sizelimit doesn't seem to have any effect on freebsd.
If I then modify the handler to return the $max_rss and $max_ixrss
from BSD::Resource:
BSD resource seems f'ing broken too. note that i also said i get a
different size in memory from every measurment app i tried.
Where did 163MB come from?!
163 is about the resident memory size of the parent ( 60564 ) , and
the child ( 101764 ).
its also possible that its 60mb child res, 100mb parent res, and 3mb
child res on the process you didn't request yet-- if you hit it again
until you hit the other process ( log $$ to STDERR and tail it until
you see 2 seperate processes ) can you bump up to 220 ?
that doesn't solve whether or not the reporting is bad or actual
memory sharing is.
On OS X it said both were 0, which I presume means it doesn't work
properly on OS X.
osx is severely crippled. cpu /user time works for getrusage. thats
it. top doesn't even work right on osx.
I've been meaning to do something like that for while, but I work
on something else during the day so my only reason is a lack of
time. What benefits can I expect from doing this? The only things
that searching have turned up are that a years ago they stamped all
over each other but I haven't had any such issues so I assume that
has been fixed.
the big benefit is that apache is slow, apache is a memory hog.
every php hit you process with apache is less time/memory for apache
to focus on mod_perl.
fastcgi + eaccelerator (cache only mode. code optimizers will break
all your code ) is about 20% faster than mod_php with no
eaccelerator. ( eaccelerator will compile a memory cache of your
php code. 16mb of memory dedicated to that got PHPtal- the slowest
templating system in the world - working as fast as 'print "hello world"
if you're only running php on the box, then the benefits of migrating
from apache aren't all that great. the big benefit is just freeing
up more cpu and memory for mod_perl.
On Aug 23, 2006, at 6:10 PM, angie ahl wrote:
I'm running MP2/Apache2 on FreeBSD 5.3 and under OSX (10.4.6) and my
can you dist upgrade to 6.0 ? i dont know if 6.1 is stable for
apache/postgres yet (pg did not like it 2 months ago), but the 5.x
branch of freebsd is kind of nightmarish. i wouldn't be surprised if
your segfaults had to do with something in freebsd.
also , are you using Apache::Reload ? I've found a lot of segfaults
stem from that under freebsd ( but not under osx ). chances are you
have some module in there that doesn't like your environment.
I'm seeing huge problems with uploads which is something to
investigate further. I've been forced to remove the from modperl
are you using libapreq? that should cut down. i believe that you're
seeing an expected behavior though. that should just be process
growth, not memory loss. if you load a 10mb file, then a 5mb file,
you should see a growth of 10mb, then 0 mb. if you load a 5, then a
10, you should see a growth of 5 and 5 respectively.
having 3 seg faults a minute doesn't help as an apachectl gracfeul
doesn't get the ram back like it does on my OSX server. I just thought
graceful shouldn't recover memory- it should eat it. known memory
leak. you need to stop, wait for the pid to clear, then start.
otherwise you just load more and more stuff into memory.
On Aug 23, 2006, at 6:21 PM, Jonathan Tweed wrote:
I looked at lighttpd a few days ago but wasn't overly impressed.
There seems to be a lot of people with stability issues (as your
"restart it every day" comment proves) and in my completely
unscientific tests images seemed to served visibly faster by a fat
Apache than by lighty which greatly surprised me.
lighty is stable, it just has a memory leak. its big in distributed
setups, like 3 processes deep, so people don't often see it. there
was a memleak in the bug db for 6mb in one day. my friend tried it
on his high-traffic server , just as a reverse proxy, it leaked 60mb
in a few hours.
most people i know are migrating to nginx, which is way stable, to
handle reverse proxy.
again though, the benefit isn't in speed so much as it in resource
allocation. a single 4mb server dispatching to modperl or vanilla
apache (possibly serving static), vs a pool of apache children
4-10mb each.
