httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis BUCHER <dbuche...@hsolutions.ch>
Subject Re: [users@httpd] Unbelievable : one single apache process uses more than whole server memory (5 gigabytes) !
Date Sun, 19 Aug 2012 15:58:34 GMT
  

Dear Igor, 

In fact I see plenty of apache processes, but only ONE
takes out the whole memory ! All others are OK. 

And the most
surprising is that it only happens with Google bot and other search
engines crawler but never with users ???
Denis 

Le 19.08.2012 14:26,
Igor Cicimov a écrit : 

> Are you saying you are seeing only one apache
process? Since you are using mpm_prefork there shoul be more than one
for sure. Can you show us your prefork settings? Any errors maybe in the
database or the php application? Anything in the apache logs? 
> On Aug
18, 2012 7:01 PM, "Denis BUCHER" wrote:
> 
>> Le 18.08.2012 10:29, Alex
Bligh a écrit : 
>> 
>>> --On 18 August 2012 10:04:12 +0200 Denis BUCHER

>>> wrote:
>>> 
>>>> And whatever page it is, is there some explanation
why apache can takes all the server memory ? PHP is limited, so how is
it possible for Apache to do that ?
>>> 
>>> Right, but it's taking lots
of virtual memory, and that appears to
>>> be larger than your physical
memory.
>> 
>> Yes the process is using SWAP (it takes all physical
memory and all SWAP just for itself !) 
>> 
>>> The pmap manpage is
woefully
>>> short but I think that's what it's saying. That itself
isn't a problem.
>>> Perhaps it's just mmap'ing a large file, for
instance? Or allocating
>>> 3G of virtual memory with an anonymous mmap
(which might be
>>> what '[anon]' means). Assuming you are on a 64 bit
server, you are
>>> never likely to run out of virtual memory.
>> 
>> I
don't know what you mean with "just mmap'ing a large file" ? I mean
whatever it is, it's a HUGE problem ! 
>> 
>> So, is it writing to
>>
that an actually using huge quantities of physical memory? IE
>> does
RSIZE on 'top' grow huge? 
>> 
>> How can I see RSIZE in top ? I don't
see it ?
>> 
>>> ys, 16:17, 2 users, load average: 1.29, 0.34, 0.16
>>>
Tasks: 142 total, 1 running, 140 sleeping, &nbs
>> 0 zombie
>> Cpu(s):
1.6%us, 3.7%sy, 0.0%ni, 0.0%id, 94.3%wa, 0.0%hi, 0.5%si, 0.0%st
>> Mem:
4041804k total, 4020816k used, 20988k free, 368k buffers
>> Swap:
4192956k total, 857500k used, 3335456k free, 36332k cached
>> 
>> PID
USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 25178 apache 18 0
4109m 3.0g 2968 D 7.0 78.8 0:09.13 httpd
>> 234 root 10 -5 0 0 0 D 3.0
0.0 203:22.33 kswapd0
>> 1 root 15 0 10364 80 56 S 0.0 0.0 0:10.65
init
>> 2 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
>> 3 root 34 19
0 0 0 S 0.0 0.0 0:00.05 ksoftirqd/0
>> 4 root RT -5 0 0 0 S 0.0 0.0
0:00.00 watchdog/0
>> 5 root RT -5 0 0 0 S 0.0 0.0 0:00.05
migration/1
>> 6 root 34 19 0 0 0 S 0.0 0.0 0:00.12 ksoftirqd/1
>> 7
root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/1
>> 8 root 10 -5 0 0 0 S
0.0 0.0 0:00.07 events/0
>> 9 root 10 -5 0 0 0 S 0.0 0.0 0:00.26
events/1
>> 10 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
>> 
>> If not,
I wouldn't worry. 
>> 
>> ???!!!! Maybe I forgot to tell you that the
server is COMPLETELY DOWN AND UNRESPONDING for two minutes every five
minutes, nobody is able to it, neither users, neither the employees and
we can't even type a letter in SSH during al
>> 
>>> remely_ worried
!
>> 5px; border-left: #1010ff 2px solid; margin-left: 5px; width:
100%;"> 
>> 
>> If so,
>> I'd guess something is allocating a large or
several large objects,
>> as IIRC libc uses anonymous mmap rather than
brk only for large
>> allocations. I wouldn't necessarily trust
php_memory_limit. So,
>> either a memory leak in php, apache or the
postgres client, or
>> you have a script sending back a huge reply, or a
DB query with
>> a huge reply, or something else. What I'd do is wait
until it
>> happens aga> to make it happen again, I just need to remove
Google Bots IPs from firewall DROP list ;-) 
>>> 
>>> But how can I
strace it ? 
>>> 
>>> I really don't know how to do it ? 
>>> 
>>>
Thanks a lot for your help, it's very nice ! 
>>> 
>>> Denis

 


Links:
------
[1] mailto:dbucherml@hsolutions.ch
[2]
mailto:dbucherml@hsolutions.ch

Mime
View raw message