Hi, Tuesday, December 11, 2007, 6:42:18 AM, you wrote: RF> Hello,
RF> I have a command-line PHP script--called Listener--that is designed RF> to run indefinitely with a predictable CPU usage and memory RF> footprint. In a nutshell, it's a multi-client socket server that RF> waits for incoming connections, processes incoming data, stores RF> results in a MySQL database, and basically gets on with its life. And RF> it works. No errors or serious problems to speak of. And I've been RF> running it for a couple years on an Xserve dual-G5 2GHz w/ OS X RF> Server 10.4.11). Six months ago, the program would run for days, even RF> a couple weeks, without a hitch. The only reason I would stop the RF> script is for some other purpose, like a software update. RF> However, the number of socket clients connecting in the past 3-4 RF> months has steadily increased, and this seems to have exposed (if not RF> created) a strange performance "issue" with PHP 5.2.4, MySQL 5.0.45 RF> and/or Mac OS X Server 10.4.11. (I say "and/or" because I am unsure RF> where the problem's cause really lies.) Basically, after the script RF> has been running for a day or so (processing essentially the amount RF> data that used to take two weeks), the CPU usage of the machine goes RF> from 30% (normal) to 80-90%. This appears to be irrespective of the RF> number of clients connected to the server at the time, but rather the RF> amount of time the script has been running (and therefore cumulative RF> cycles it's operated, data processed, MySQL queries executed, etc.). RF> And the CPU usage stays high, even when the actual load (number of RF> clients) decreases. At this time, if I run top, I get the following RF> info: RF> 22512 mysqld 91.6% 8:22:12 31 106 125 305M+ 3.20M RF> 260M 475M RF> 17104 php 7.2% 81:14.01 1 15 145 5.08M 7.80M RF> 10.9M- 87.5M RF> 22537 Terminal 6.6% 2:59:59 22 176 240 12.3M 21.2M RF> 18.3M- 236M RF> [...] RF> At first I thought, okay, it's MySQL's fault. Maybe a lot of slow- RF> running queries. But the slow query log is pretty clean. So maybe RF> it's a combination of Mac OS X and MySQL and PHP? I Googled for a RF> similar problem, and finally ran across this article: RF> http://www.shawnhogan.com/2005/10/mysql-problems-on-mac-os-x-server.html RF> ...where the author describes a very similar CPU usage pattern. I RF> tried his suggested fixes and they seemed to have helped a little (or RF> maybe it's my wishful thinking--hard to tell), since the high CPU RF> load issue doesn't appear to happen as soon... But it still happens. RF> Anyway, I'm really stumped as to what to do next, where to look, etc. RF> If I stop the script, and restart it (but not the MySQL itself), CPU RF> usage goes back to normal--for about a day or two. RF> The only thing I thought might be connected is how many short-lived RF> PHP child processes Listener creates--around 20-30,000 per day. RF> Sounds higher, but on average it's just one every 2-3 seconds. RF> Anyway, although the number of child processes isn't concurrent, RF> would there be a problem with the number of historical child RF> processes in view of ulimits or kern.maxfilesperproc? RF> Anyway suggestions, tips, or links are much appreciated. Thanks. RF> ...Rene Put a usleep(1000) in the listen while() loop and give the cpu a break. -- regards, Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
