Hu justin,

1. Because its a production site, we are unable to disable the PHP
modules/script......From the log output below, we are having difficulty to
pinpoint the source of error. I just spent the last couple of hours to run
through the pages and see if the log shows up any systematic
error...unfortunately, wasn't able to replicate the source of problem
causing the glibc issue. Not sure if this only happen during high
loading....


*** glibc detected *** /usr/sbin/apache2: double free or corruption
(fasttop): 0x086a1170 ***
*** glibc detected *** /usr/sbin/apache2: double free or corruption
(fasttop): 0x08b48c08 ***
[Wed Dec 16 23:53:07 2009] [warn] child process 1325 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:07 2009] [warn] child process 19910 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:07 2009] [warn] child process 10569 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:07 2009] [warn] child process 16964 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:07 2009] [warn] child process 19718 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:09 2009] [warn] child process 1325 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:09 2009] [warn] child process 19910 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:09 2009] [warn] child process 10569 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:09 2009] [warn] child process 16964 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:09 2009] [warn] child process 19718 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:11 2009] [warn] child process 1325 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:11 2009] [warn] child process 19910 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:11 2009] [warn] child process 10569 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:11 2009] [warn] child process 16964 still did not exit,
sending a SIGTERM
[Wed Dec 16 23:53:11 2009] [warn] child process 19718 still did not exit,
sending a SIGTERM

2. The mem usage is correct because we are running the web server as a Xen
Virtual Machine.


On Sat, Dec 19, 2009 at 5:20 AM, Justin Pasher
<just...@newmediagateway.com>wrote:

> Just a couple things to point out (but nothing specific to fixing your
> probem) ...
>
>
> gary lim wrote:
>
>> Hi Daniel,
>>
>> After performance tuning of apache, the mem usage is now more managable.
>> However, the apache still experience intermittent crash which we suspect is
>> due to certain PHP module running in our joomla website.
>>
>
> If it really is the PHP module that is crashing it, there's really no other
> way to test that theory unless you disable it and see if the crashes
> persist.
>
>  *top output
>>
>> *top - 04:58:52 up 160 days,  4:02,  1 user,  load average: 0.08, 0.04,
>> 0.05
>> Tasks:  69 total,   2 running,  67 sleeping,   0 stopped,   0 zombie
>> Cpu(s):  1.9% us,  5.0% sy,  0.0% ni, 93.2% id,  0.0% wa,  0.0% hi,  0.0%
>> si
>> Mem:    917652k total,   908144k used,     9508k free,    32660k buffers
>> Swap:  1048568k total,    37856k used,  1010712k free,   179480k cached
>>
>>
>> Model: *Dell PowerEdge 850*
>> CPU:Intel *Pentium IV 3.0GHz* / 2MB, 800MHz FSB
>> RAM: *2GB **DDR-2 SDRAM* 533MHz w/ ECC*
>> *Harddisk: *02 x SATA* (7200RPM) HDD (non-RAID)
>>
>
> Not sure if you noticed or not, but all of your memory is not actually
> showing up as available to the kernel. Are you running a kernel with
> "bigmem"-style support? If not, you're missing out on half of your RAM.
>
>  *Apache Version
>>
>> *Server version: Apache/2.0.58
>> Server built:   Dec 12 2006 21:41:17
>>
>
> There is always the 2.2 branch, which I'd recommend trying out if possible.
> Perhaps this is a locked down distro release with only the older version
> available (RHEL/CentOS?).
>
>
> --
> Justin Pasher
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>  "   from the digest: users-digest-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

Reply via email to