3 ms·

I wouldn't recommend to blindly change his setup. This is the sysadmin equivalent of changing lines of code almost randomly to fix a bug. When there is a probl

by samuel 16y ago

I wouldn't recommend to blindly change his setup. This is the sysadmin equivalent of changing lines of code almost randomly to fix a bug. When there is a problem the very first step is to find out what's happening. Apache is rock solid software so there must be something in his setup or software that isn't right. My line of action would be: - check the logs(apache and system ones), looking for errors or limits reached. - if no clue, try to reproduce it, same os, software versions. Make scripts to simulate the load. - strace the processes when they lockup (dtrace 'em in Solaris). - get a coredump(kill -SIGABRT), compile apache and their module with symbols (-g CFLAG), an gdb it. I'm not a sysadmin anymore, but that's what I would have done when I was one.

c00p3r 16y ago
good luck in debugging mpm_worker with all loaded modules and their dependencies. btw, who will pay for hours and hours of such 'practicing'? Is that never crossed your mind that the solution I recommended were battle-tested one?
- samuel 16y ago
  That's the last resort: almost never you need to get that far(stracing/trussing usually do the trick), and it doesn't have to take "hours and hours" if you have done it before, specially if it's a locking issue. I don't remember if I have had to gdb apache(I think I have), but sendmail + milters for sure. I don't doubt that your solution has been "battle-tested", but I assure you that apache + mod_php also has. Now if he has a different problem with that new setup what you will recommend then? Change again to cherokee or lighttpd? Or do you really think that nginx + fpm is a silver bullet? I accept that spending some time cheap shooting randomly(raising os limits, changing threading model, upgrading to new version...) may be worth the time, though. But changing completely your middleware isn't a cheap shot in my book.
  - c00p3r 16y ago
    Re-read the OP - the problem is with threads. Switch apache to a prefork mpm - is a good solution, but replace apache with simple and more efficient setup is a much better solution. nginx + fpm isn't a silver bullet, but it is much more efficient an flexible solution. And avoiding using threads with such a terrible mess as PHP is also good solution, which will save you a lot of time and effort. Just think about how many things will be dynamically loaded, and how much of this code is really thread-safe and properly tested. btw, I bet there is a mere sigsegv.
samuel 16y ago
I forgot to add, in this case, check the DB. It could be some sort of deadlock...

by samuel 16y ago

c00p3r 16y ago

good luck in debugging mpm_worker with all loaded modules and their dependencies. btw, who will pay for hours and hours of such 'practicing'? Is that never crossed your mind that the solution I recommended were battle-tested one?

samuel 16y ago
That's the last resort: almost never you need to get that far(stracing/trussing usually do the trick), and it doesn't have to take "hours and hours" if you have done it before, specially if it's a locking issue. I don't remember if I have had to gdb apache(I think I have), but sendmail + milters for sure. I don't doubt that your solution has been "battle-tested", but I assure you that apache + mod_php also has. Now if he has a different problem with that new setup what you will recommend then? Change again to cherokee or lighttpd? Or do you really think that nginx + fpm is a silver bullet? I accept that spending some time cheap shooting randomly(raising os limits, changing threading model, upgrading to new version...) may be worth the time, though. But changing completely your middleware isn't a cheap shot in my book.
- c00p3r 16y ago
  Re-read the OP - the problem is with threads. Switch apache to a prefork mpm - is a good solution, but replace apache with simple and more efficient setup is a much better solution. nginx + fpm isn't a silver bullet, but it is much more efficient an flexible solution. And avoiding using threads with such a terrible mess as PHP is also good solution, which will save you a lot of time and effort. Just think about how many things will be dynamically loaded, and how much of this code is really thread-safe and properly tested. btw, I bet there is a mere sigsegv.

samuel 16y ago

I forgot to add, in this case, check the DB. It could be some sort of deadlock...