Thread

walpow,

Your Relationship cache which is kept in the DB is quite large. Can you check with your host as your database may be running out of space which would make sense here. It is probably trying to cache all your relationships but running out of space and failing to return them.

I’m hosted at Enginehosting and here’s what they said:

We don’t have hard limits on the amount of database space clients are allowed so if it were running out of space it would be causing issues on the database cluster your account is on.  Your current database size is 57 mb in total and the relations table is 46 mbs. 

Does this help in the troubleshooting process.  Also did you inform the ExpressionEngine support that you are hosting on Enginehosting.  They know our servers pretty well so that may help give them some insight.

Thanks,
Nathan

Thanks, walpow. We are pinging the dev team to see if we can get to the bottom of this, and we’ll update this thread when we know more. Thanks for your patience.

Just a quick update to let you know we’re looking at it.  The issue is basically memory.  With the test data and a limit of 40- it’s pulling back around 950 reverse related entries.  I’m going to try some tweaks w/how we handle the main loop to see if we can get the memory use down.  Will update once I’m done experimenting with the options.

OK, walpow.  I’ve added a tweak that greatly reduces the memory use when handling the reverse related when dealing w/huge numbers being returned.  I’d still lean way from pulling in too many, as it may slow things down a bit.  But the ee_support/index test template is looking good w/out a limit (granted, there are not a ton of main entries).

Test out your problem spots, and see if this has solved them.  I’ll get busy getting the revised code into the official build.  Let me know how it goes.

Success! The real page that had the problem is working successfully. Thanks for everyone’s work on this.

When you say you added a tweak but it’s not in the official build, I’m assuming you’ve updated my copy of modules/weblog/mod_weblog.php, since I see the filedate has changed. Correct?

Thanks again,
Nathan

Correct- you’re running a slightly modified mod.weblog.php.  Well- for the record:

@@ -545,8 +556,10 @@
         
         $entry_data = array();
         
-        foreach($query->result as $row)
-        {    
+        for ($i = 0, $total = count($query->result); $i < $total; $i++)
+        {
+            $row = array_shift($query->result);
+
             /* --------------------------------------
             /*  If the data is emptied (cache cleared or first process), then we 
             /*  rebuild it with fresh data so processing can continue.

I replaced the foreach with the for and $row= combo.  I can’t SWEAR this will make it into the next release, in which case, you’d want to redo the hack.  It WILL make it into a release- but I want to put it through more testing as well as see if there’s another spot I can make a similar change. 

Make sense?

Perfect sense. I pulled down a copy of the module to remind me to deal with it if I install another build or release. Then I can come back to this thread and redo the hack if necessary.

walpow,

I’ll leave this thread open for now. Glad we were able to get to the bottom of this.

Just wanted to add a note to this thread to say that I had exactly the same issue, and the posted fix works for me (for now at least). I’ll also look into getting my memory increased to act as an additional protection against this happening.

Simon

Simon, glad this helped. Don’t hesitate to post again as needed.

Thanks all; closing this thread.