3 ms·

The obvious idea (for admins) is to convert the setup to nginx + php 5.3.3 in fpm-mode + eaccelerator. (fpm patches are already part of the php distribution as

by c00p3r 16y ago

The obvious idea (for admins) is to convert the setup to nginx + php 5.3.3 in fpm-mode + eaccelerator. (fpm patches are already part of the php distribution as from 5.3.2) There are millions of step-by-step tutorials for these keywords. If you have a test installation you can do it yourself and then change settings on your production server. If not you should setup an another copy on the same server with a different port nginx should listen to and empty drupal instance, test it. Then you can stop apache and start nginx on a correct port with proper drupal instance.

brandnewlow 16y ago
We are running Nginx to serve all our anonymous traffic. It works great. We've been front-paged on Digg and REddit in the last few months and the site didn't even flinch. You could drop a bomb on us and Nginx would behave like a champ. But then we still crash every 80 minutes or so no matter how many or how few visitors we have to the site. So nginx is awesome and we're using it bigtime and with great results. Not solving this one though I don't think.
- c00p3r 16y ago
  The idea isn't about nginx itself, but of using php in an fpm mode along with eaccelerator. In an fpm more php runs as a standalone FastCGI-server, outside of apache or other web server. It could run on the same machine with a web server (in that case you should configure them to use unix-sockets, which is even better) or on a separate one. You will save a lot of memory, and will gain even more speed due to php script's caching.
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...
roel_v 16y ago
We used to run a site with an order of magnitude more visitors on a couple of Pentium III's, over 10 years ago, on Apache and 2.0 something Linux kernels. PHP 3, too. Now I guess that the memory requirements have gone up in those years, but still I find it hard to believe that the current setup can't be made to work. Switching to prefork seems the first obvious step. I haven't done real sysadmin work since then though so what do I know ;)

by c00p3r 16y ago

brandnewlow 16y ago

We are running Nginx to serve all our anonymous traffic. It works great. We've been front-paged on Digg and REddit in the last few months and the site didn't even flinch. You could drop a bomb on us and Nginx would behave like a champ. But then we still crash every 80 minutes or so no matter how many or how few visitors we have to the site. So nginx is awesome and we're using it bigtime and with great results. Not solving this one though I don't think.

c00p3r 16y ago
The idea isn't about nginx itself, but of using php in an fpm mode along with eaccelerator. In an fpm more php runs as a standalone FastCGI-server, outside of apache or other web server. It could run on the same machine with a web server (in that case you should configure them to use unix-sockets, which is even better) or on a separate one. You will save a lot of memory, and will gain even more speed due to php script's caching.

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...

roel_v 16y ago

We used to run a site with an order of magnitude more visitors on a couple of Pentium III's, over 10 years ago, on Apache and 2.0 something Linux kernels. PHP 3, too. Now I guess that the memory requirements have gone up in those years, but still I find it hard to believe that the current setup can't be made to work. Switching to prefork seems the first obvious step. I haven't done real sysadmin work since then though so what do I know ;)