0

I'm working on a setup which uses fcgi/nginx.

It seems to be running correct (24 children and 500 max requests), except that all of the phpfcgi instances are piling on one core. When I run top, I see 1 core around 3%, the one running the fastcgi processes around 99%, and 6 more between 0 and .5%.

Please let me know of any potential reasons we are locked to 1 cpu core.

Thanks

2 Answers2

0

When you logged in, is it possible your shell session had taskset in the .profile/.bashrc/whatever that locked your cpu affinity? If I recall, they removed the cpu affinity options from fcgi in 2007 or so.

karmawhore
  • 3,865
  • 17
  • 9
  • A locae of .profile and .bashrc find nothing fast cgi related. Sorry I'm not too sure where else to look. –  Jun 30 '10 at 00:11
  • it isn't fastcgi related, taskset is a command line option that pins processes to a single cpu. I thought that possibly your shell session when you logged in was pinned, and anything you started from there may have been pinned also. Can you update your issue with the relevant pieces of your fastcgi config files? – karmawhore Jun 30 '10 at 00:18
  • It wasn't started from there (actually, the service was). WOuld a reboot if its sitting in init.d fix it if that was the case? Also, I'm not too familiar with where all the fastcgi files sit, could you help me there. Thanks –  Jun 30 '10 at 03:00
  • TO add: A reboot did nothing, so I don't think its account related since I restarted with a ./phpfcgi stop & start and with a system reboot. –  Jun 30 '10 at 03:59
  • 2
    Wouldn't it be a better to just taskset -p $PID for all of your running processes? That gets the actual reading. – Joris Sep 28 '10 at 06:31
0

It's unlikely given that this is a relatively new feature, but it's possible that your system is set up to use cgroups to group these processes into a cpuset. See kernel docs at Documentation/cgroups/cpusets.txt

mattdm
  • 6,550
  • 1
  • 25
  • 48