4

Keep banging my head against this and can't seem to get anywhere. I've got a dev site up on Centos 6.6 using KVM, with 4 cores and 8 GB of RAM allocated and PHP 5.3.3. I'm testing a large import via the web interface import. When I do, I've noticed that the box never uses more than 25% CPU and only has one thread for Apache. That 25% CPU usage all sits on one CPU core, effectively maxing it out. The worrisome thing is, I also can't open another instance of WordPress while this is running. That means that one user could lock out the whole box with a large report or mass deletion! (BTW, same thing happens on mass deletion of the 35,000 records, so it's not just the web import script.)

BTW: The host server isn't that busy and is nowhere near maxed out. Also, other tasks show that there is no bottle-necks in the usual places like CPU, network, or disk usage.

Things I've tried:

  • Upping php.ini memory_limit - No changes
  • Changing a thousand parameters in MySQL, mainly memory - No changes
  • Upping max children in php.ini - No changes
  • Adding FastCGI+PHP-FPM - No changes
  • Adding WP-Super Cache - No changes
  • Adding Memcached - No changes
  • Upping file descriptors - No changes
  • Adding Max Memory line to wp-config - No changes Who knows what else I've forgotten I've tried

Anybody have any ideas here?

  • Still learning the system. Thanks for the excellent job on the readability cleanup. – G H May 15 '15 at 16:16
  • Just to add a little more info. Opening another browser allows the system to respond while a major deletion/addition is ongoing. So Firefox won't respond in a second tab while this is going on, but another browser on the same machine will pull pages quickly, so that's good news. – G H May 20 '15 at 15:09
  • Apparently WordPress has also added a couple of new "features" to the wp-config.php file for PHP memory management. For more information on this see: codex.wordpress.org/… It defaults to a max of 40 MB for single site install or 64 MB for multi-site installs. (Still experiencing a lot of the same issues though. – G H Dec 18 '15 at 20:36
3

Have you tried running mod_php as opposed to fastcgi mode?

In the past when we've had this with our servers our first point of call is to determine which part of the stack is limited to 1 core. Our experience has been that its normally mysql. Could you load up mysql with a few concurrent large DB operations and see if it uses multiple cores? This should then good you a direction to head in i.e. which part of the LAMP stack is being limited.

  • Centos builds mod_php into PHP 5.3.3 as is evidenced by 'yum provides mod_php' with a return of 'Repo: base'. httpd.conf does not even have php in the config file, so I must assume that it is active by default. Additionally, the php.conf file in the conf.d dir is active. Did I miss activating mod_php somehow? – G H May 15 '15 at 14:21
  • Oh, and fastcgi was added as an attempt to figure out what was going on and is now removed with no change in behavior between it being active and being removed. – G H May 15 '15 at 14:23
  • Sorry, realized that I made it look like I'm not using yum provides correctly. The package is php-5.3.3-38.el6.x86_64 inside Repo: base and is also listed in Repo: installed. – G H May 15 '15 at 14:29
  • if you have access to the database then try checking the civicrm_mailing_trackable_url table to see exactly where the URL's are going. This should identify if they're incorrect. You'll need to know the mailing id of the job you've run but you should be able to get that easily enough from the URL of the mailing reports. – Parvez Saleh May 18 '15 at 9:31
  • Um ... This comment looks like it was intended for a different question. Hope you can easily find the correct question for this one. – G H May 18 '15 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.