[wplug] Apache/Mysql performance question ...
Bill Moran
wmoran at potentialtech.com
Mon Aug 16 15:08:45 EDT 2004
"Chris" <vze2f6h6 at verizon.net> wrote:
> We have a RH 7.3 box that isn't doing much but host a few websites.
> These sites are very dynamic and are doing a log of queries via PHP, but
> the stats below seem a little high. Does apache or MySQL usually take
> up about 10M of RAM per connection/child? I know that I haven't given
> that much info but does something look wrong or is this typical?
Are you having actual performance problems?
This isn't unusual. Keep in mind a few things:
1) The kernel will use all the memory available to buffer data. In the
case that memory becomes scarce, buffered data can be converted to
free memory with almost no overhead. The fact that you've got less
than 1M of swap in use tells me that it's not running low on RAM
much.
2) Many processes (the best one I know if is the NFS server on FreeBSD)
will request a whole lot of memory that they never actually use. The
VM system will make it available but it doesn't really get allocated
until it's used.
3) MySQL is a threaded program, which means there _aren't_ really that
many MySQL processes each using that much memory, it's just that top
doesn't have a better way to display it (although exactly how this
works depends on your kernel version)
4) Apache is not really using up all that memory. Most of the memory
will be COW (copy on write) or the program code. The kernel recognizes
that each process needs to have access to the code as if it's part of
it's address space, but also recognizes that none of them will be
writing to those memory pages. Thus the VM does some magic by making
each process see the memory space as if it's its own, but the kernel
really only allocates enough RAM to put it in memory once.
On the other side of the argument:
If you do big queries, PHP will store the entire contents of the result
in RAM. This can take up a huge amount of RAM. In fact, the easiest
way I know of to cause PHP to suck up all the ram is to do a SELECT *
FROM some_huge_table. So there _may_ be a a problem in you PHP code
that can optimize away some of this RAM usage.
If you've got PHP statically compiled into Apache, then 11M isn't really
unexpected for each httpd.
HTH
> 87 processes: 86 sleeping, 1 running, 0 zombie, 0 stopped
> CPU states: 2.3% user, 0.5% system, 0.0% nice, 97.0% idle
> Mem: 513364K av, 509476K used, 3888K free, 80K shrd, 97268K
> buff
> Swap: 1020116K av, 724K used, 1019392K free 247100K
> cached
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> 30994 apache 8 0 11612 11M 5584 S 0.0 2.2 0:35 httpd
> 1104 mysql 9 0 11348 10M 1704 S 0.0 2.1 0:09 mysqld
> 1112 mysql 8 0 11348 10M 1704 S 0.0 2.1 0:09 mysqld
> 1113 mysql 9 0 11348 10M 1704 S 0.0 2.1 0:04 mysqld
> 3857 mysql 9 0 11348 10M 1704 S 0.0 2.1 0:00 mysqld
> 7751 mysql 9 0 11348 10M 1704 S 0.0 2.1 0:00 mysqld
> 7752 mysql 9 0 11348 10M 1704 S 0.0 2.1 0:00 mysqld
> 7771 mysql 9 0 11348 10M 1704 S 0.0 2.1 0:00 mysqld
> 15023 mysql 9 0 11348 10M 1704 S 0.0 2.1 0:00 mysqld
> 15024 mysql 9 0 11348 10M 1704 S 0.0 2.1 0:00 mysqld
> 15063 mysql 9 0 11348 10M 1704 S 0.0 2.1 0:00 mysqld
> 15071 mysql 9 0 11348 10M 1704 S 0.0 2.1 0:00 mysqld
> 30990 apache 9 0 10708 10M 5588 S 0.0 2.0 0:38 httpd
> 2749 apache 9 0 10332 10M 5584 S 0.0 2.0 0:36 httpd
> 30991 apache 9 0 10320 10M 5584 S 0.0 2.0 0:37 httpd
> 30996 apache 9 0 10092 9.9M 5576 S 0.0 1.9 0:36 httpd
> 30993 apache 9 0 9396 9396 5580 S 0.0 1.8 0:35 httpd
> 30997 apache 9 0 9156 9156 5576 S 0.0 1.7 0:28 httpd
> 30992 apache 9 0 9096 9096 5548 S 0.0 1.7 0:35 httpd
> 30995 apache 9 0 8896 8896 5604 S 0.0 1.7 0:35 httpd
> 15798 apache 18 0 8896 8896 5568 S 2.1 1.7 0:02 httpd
> 17340 root 9 0 5064 5064 4544 S 0.0 0.9 0:17 httpd
>
> Thanks,
> Chris
>
>
> _______________________________________________
> wplug mailing list
> wplug at wplug.org
> http://www.wplug.org/mailman/listinfo/wplug
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
More information about the wplug
mailing list