Editing site caused too many PHP processes consuming 2.7GB of memory

Permalink
I launched at the start of June (version 5.5.1), turning on cache (not full page) lasted about 2 weeks before a large amount of php calls blasted my ISP (see below for error).

The Site
was here thecaen.ca but know I have a dev site here:http://caen.nautiluswebdesign.com/...

The site is out of the box, minus
the removal of the text at the bottom of the footer.php,
some CSS changes to the theme and some blocks,
the importing of the Twitter widget.css and widget.js to run natively, and
the following add-ons: slate theme (which is awesome), problog, expand and collapse, and some others that i tested but didn't use.

The one work around I did was add markup (<h5></h5><p></p>) to the expand-and-collapse module’s title field to give the title some font variation.

As well, I did a lot of tweaks on the site version before going live on the site. (no localhost, because i bootstrapped a good idea to get it going)

The Problem
The breakdown would occur when updating the site. Here is the order of updating.
Enter edit mode on homepage
Open 5 pages of thecaen.ca/main-stream (currently:http://caen.nautiluswebdesign.com/index.php/main-streams/)... , the problog list page
On the 5 pages, open a new problog post pop-up.
Add new content to home page stacks and blogs
Update stacks; refresh and publish homepage
One by one, publish blogs, waiting until each one published.
Then this will occur:

From the ISP:
We had to disable your site because there were too many PHP processes running from your web site. Here's what it looked like before we shut it down. Notice the 50 simultaneous instances of PHP, running for upwards of 30 seconds and consuming a total of 2.7GB of memory. There is something wrong with your PHP code, it loads far too slowly and consumes too many system resources.

Your support staff may be able to correlate the start times and web requests in your access_log to understand what happened.


USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
raplop 49389 3.3 0.7 140704 54960 ?? R 9:44AM 0:32.17 /cp/bin/php-cgi
raplop 49450 3.2 0.6 140704 54024 ?? R 9:44AM 0:30.77 /cp/bin/php-cgi
raplop 49691 3.2 0.7 140704 55076 ?? R 9:45AM 0:30.97 /cp/bin/php-cgi
raplop 49829 3.3 0.6 136608 50640 ?? R 9:46AM 0:19.22 /cp/bin/php-cgi
raplop 49862 3.4 0.6 136608 50660 ?? R 9:46AM 0:19.70 /cp/bin/php-cgi
raplop 49936 3.3 0.7 140704 54460 ?? R 9:46AM 0:19.28 /cp/bin/php-cgi
raplop 49980 3.3 0.6 136608 50660 ?? R 9:46AM 0:20.30 /cp/bin/php-cgi
raplop 50148 3.2 0.6 136608 50660 ?? R 9:47AM 0:19.87 /cp/bin/php-cgi
raplop 50253 3.2 0.6 140704 54260 ?? R 9:47AM 0:18.15 /cp/bin/php-cgi
raplop 50366 3.2 0.6 140704 54248 ?? R 9:47AM 0:18.11 /cp/bin/php-cgi
raplop 50465 3.0 0.6 140704 53676 ?? R 9:48AM 0:17.57 /cp/bin/php-cgi
raplop 50512 2.9 0.6 140704 54136 ?? R 9:48AM 0:18.14 /cp/bin/php-cgi
raplop 50780 3.2 0.6 140704 52572 ?? R 9:49AM 0:16.24 /cp/bin/php-cgi
raplop 50787 3.1 0.6 140704 53244 ?? R 9:49AM 0:16.50 /cp/bin/php-cgi
raplop 50790 3.1 0.6 140704 53068 ?? R 9:49AM 0:16.75 /cp/bin/php-cgi
raplop 50791 3.1 0.6 140704 52180 ?? R 9:49AM 0:15.92 /cp/bin/php-cgi
raplop 50792 3.0 0.6 140704 52612 ?? R 9:49AM 0:15.80 /cp/bin/php-cgi
raplop 50793 2.7 0.6 140704 52132 ?? R 9:49AM 0:16.23 /cp/bin/php-cgi
raplop 50806 3.1 0.6 140704 52052 ?? R 9:49AM 0:15.66 /cp/bin/php-cgi
raplop 51523 2.7 0.6 136608 49560 ?? R 9:52AM 0:12.79 /cp/bin/php-cgi
raplop 51534 8.9 0.5 136608 40192 ?? R 9:52AM 0:02.65 /cp/bin/php-cgi
raplop 51993 3.3 0.6 132512 46180 ?? R 9:54AM 0:09.79 /cp/bin/php-cgi
raplop 52107 3.1 0.5 128416 43096 ?? R 9:56AM 0:07.74 /cp/bin/php-cgi
raplop 52439 3.0 0.5 128416 41516 ?? R 9:59AM 0:06.04 /cp/bin/php-cgi
raplop 52462 3.0 0.5 128416 41604 ?? R 9:59AM 0:06.18 /cp/bin/php-cgi
raplop 52512 3.3 0.5 124320 39156 ?? R 9:59AM 0:04.80 /cp/bin/php-cgi
raplop 52528 2.9 0.5 132512 44868 ?? R 9:59AM 0:07.73 /cp/bin/php-cgi
raplop 52545 3.1 0.5 128416 42168 ?? R 9:59AM 0:06.36 /cp/bin/php-cgi
raplop 52555 3.1 0.5 128416 41992 ?? R 9:59AM 0:06.24 /cp/bin/php-cgi
raplop 52574 2.8 0.5 124320 40792 ?? R 9:59AM 0:05.82 /cp/bin/php-cgi
raplop 53037 3.0 0.5 124320 38284 ?? R 10:01AM 0:04.04 /cp/bin/php-cgi
raplop 53129 2.9 0.5 124320 39080 ?? R 10:01AM 0:04.05 /cp/bin/php-cgi
raplop 53298 3.3 0.4 120224 36644 ?? R 10:02AM 0:02.52 /cp/bin/php-cgi
raplop 53300 3.3 0.4 120224 36640 ?? R 10:02AM 0:02.58 /cp/bin/php-cgi
raplop 53301 3.1 0.4 120224 36784 ?? R 10:02AM 0:02.62 /cp/bin/php-cgi
raplop 53303 3.3 0.4 120224 36648 ?? R 10:02AM 0:02.56 /cp/bin/php-cgi
raplop 53330 3.3 0.4 120224 36872 ?? R 10:02AM 0:02.75 /cp/bin/php-cgi
raplop 53331 3.1 0.4 120224 36748 ?? R 10:02AM 0:02.65 /cp/bin/php-cgi
raplop 53364 3.3 0.4 120224 36964 ?? R 10:02AM 0:02.65 /cp/bin/php-cgi
raplop 53384 3.2 0.4 120224 36672 ?? R 10:02AM 0:02.39 /cp/bin/php-cgi
raplop 53404 3.3 0.4 120224 35784 ?? R 10:02AM 0:01.80 /cp/bin/php-cgi
raplop 50779 0.0 0.0 111904 0 ?? IW - 0:00.00 /cp/bin/php-cgi
raplop 50781 0.0 0.0 111904 0 ?? IW - 0:00.00 /cp/bin/php-cgi
raplop 50785 0.0 0.0 111904 0 ?? IW - 0:00.00 /cp/bin/php-cgi
raplop 50786 0.0 0.0 111904 0 ?? IW - 0:00.00 /cp/bin/php-cgi
raplop 50789 0.0 0.0 111904 0 ?? IW - 0:00.00 /cp/bin/php-cgi
raplop 51038 0.0 0.0 111904 0 ?? IW - 0:00.00 /cp/bin/php-cgi
raplop 51690 0.0 0.0 111904 0 ?? IW - 0:00.00 /cp/bin/php-cgi


I had a review done and my tech support purchased via odesk.com found no problems with the code – it ran fine on their localhost. The emptied cache. I published twice and then it died again.

odesk.com dudes said the ISP should boost memory and bandwidth. The ISP says it’s my PHP. The ISP runs a simplescript install for V5.5.1..

Now the ISP doesn't answer my emails because the overload happened 3 times.

Any help from the C5 community would be great, or I switch to wordpress - yikes!

The problem may be on this page, i know it takes for ever to load: ttp://caen.nautiluswebdesign.com/index.php/main-streams/

should I run the native blog software?

View Replies:
Korvin replied on at Permalink Reply
Korvin
I would suggest updating concrete5 to the latest stable version, and updating chad's problog to the latest version. If this still happens, open a support request with problog. It sounds like you have an infinite loop running.

Best wishes,
Korvin
thecaen replied on at Permalink Reply
Thanks Updated C5 and PB, still slower than 96% of all websites. I will ping Problog.
RadiantWeb replied on at Permalink Reply
RadiantWeb
There is no infinate loop in problog that I am aware of. Hundreds I people use ProBlog and have never reported this. I use it myself and have never experienced this?

If you find otherwise, please let me know. ProBlog support does not really include IT and server setup? So unless there's some specific portion of code that you feel needs to be reviewed, I'm not sure there's anything I can do.

Some hosts are just not very good. Do you have another server you can test on? Doing so I think would prove to your current host that they may need to make some changes.

You may also want to see if anyone in the community hosts with the same provider and have experienced something similar?

One other thing, in your list view make sure you have pagination turned on. The social sharing API can really bog down loading when loading more than 10 posts at a time.

ChadStrat
thecaen replied on at Permalink Reply
Well i changed hosts to a friend's server. Same problem again. Going to rebuild the C5 site, with help to configure the C5 database. Used simple script in past.
RadiantWeb replied on at Permalink Reply
RadiantWeb
I'm honestly really confused at your "steps" as outlined here?

"On the 5 pages, open a new problog post pop-up.
Add new content to home page stacks and blogs
Update stacks; refresh and publish homepage
One by one, publish blogs, waiting until each one published."

This does not sound normal to me?

ProBlog is designed to really run all on it's own. It shouldn't require so many stinking steps? lol

Add post. done. lol

I'm just really confused at what you're doing here. And it's possible you are creating not only more work for yourself, but hogging memory up in the process.

If your pagetypes and blocks are set up correctly, you really shouldn't even need stacks.

I have a sneaking suspicion that you're over-complicating things here. And consequently breaking your site.

Try going raw and basic. Set your pagetypes to do the lifting for you when you create your pages so that everything simply updates when published.

Stacks are nice...but they are not always the best answer.

ChadStrat
thecaen replied on at Permalink Reply
The homepage stacks are separate from the problog process.

On the 5 pages, open a new problog post pop-up.
Add new content to blogs
One by one, publish blogs, waiting until each one published.