4 replies to this topic

[awww]

I updated to PageLines 2.3.6 a couple of days ago, and then 2.3.7 this morning. Before the problem occurred, nothing else on the site changed, which leads me to believe that PageLines is the culprit. For the last 24 hours, all new visits to the site have been spiking memory in Apache to the point where the site is slowed to crawl when it works at all. Most visits fail completely. Most of the Apache processes time out. 

 

Here's a typical list of processes since the problem started.

 

 

 

27358 userid    20   0  343m  83m 6284 R 33.3 17.0   0:43.52 apache2            

27357 userid    20   0  346m  87m 7120 R 22.6 17.8   0:43.59 apache2            

27353 userid    20   0  339m  79m 6312 R 19.3 16.1   0:50.17 apache2            

27354 userid    20   0  343m  83m 6336 R 12.6 16.9   0:53.22 apache2            

27324 userid    20   0  342m  83m 6948 R 12.0 17.0   1:48.83 apache2

 

12192 userid    20   0  344m  84m 6516 R 30.3 17.2   0:18.72 apache2            

12197 userid    20   0  344m  84m 6532 R 30.3 17.2   0:18.53 apache2            

12199 userid    20   0  339m  79m 6480 R 23.0 16.2   0:14.82 apache2            

12200 userid    20   0  340m  80m 6508 R 10.6 16.4   0:12.01 apache2            

12198 userid    20   0  338m  80m 7180 D  5.3 16.3   0:15.27 apache2 

 

I am working with my service provider but welcome any advice you have. I foresee that the advice will be "disable all your plugins," which is the go-to advice around here but I'm looking for something further. What changed in the latest versions of PageLines Framework that would cause this? What could help solve this?

 

W3 Cache works and is properly configured. All unnecessary plugins (that won't destroy the look of the site) have been disabled since the problem started. Minify is not enabled in W3 Cache.

[Simon_P]

Disk based object caching will slow any site to a crawl:

 

Database Caching 59/67 queries in 16.681 seconds using disk: basic
Object Caching 6679/6716 objects using disk: basic

 

So wordpress has to search through nearly 7000 object files, your depending on a fast filesystem on a shared host.

 

Page cache is fine, it uses .htaccess to serve a static page if found.

 

The other methods should only be used if there are memory caches available, and shared hosts thats guaranteed to be a no.

[awww]

Disk-based object caching was only enabled after the PageLines problem appeared. It's part of an attempt to resolve potential conflicts. It is not part of the problem.

[awww]

By the way, Simon, would you recommend Database Caching and Object Caching at all? I have the option of using Opcode APC for both, which is what was running (and had been running since July) when the current PageLines slowdown appeared.

[Simon_P]

You shouldn't need either of those two 'optimisations' if the page cache is working properly.

 

As I said before, it uses .htaccess to serve a static page, PHP is never even loaded if the cache is a HIT.

 

2.3.6 => 2.3.7 was a very minor release, there is nothing in there to slow a site down.