We keep running out of resources!

[predator]

well...whatever works...

 

[MAKG]

You're not going to fix a memory leak without a software engineer, board and/or database source code, and some memory tracing tools. This is not something easy. It's what makes us bald in our 30s.

As a board owner, all you can really do (aside from hire someone) is send a bug report to vBulletin and/or the backend database (whoever owns the huge file).

You can alternatively make /tmp a real filesystem instead of the usual ramdisk, but that's going to slow down the board.

 

[Jim Oaks]

Well, that should be interesting. I read some on the vBulletin forum and I get the impression that they don't willingly accept the fact that their programs could have a memory leak.

vBulletin seems like they want to blame it to any add ons you have.

I told them we were getting a database error 17 writing to the /tmp folder and they told me "You or your host will need to clear out the contents of the server's /tmp directory and try again.".

We've added iTrader, photoplog, the 'New Thread' button in the posts, Randon Banner, and google ad.

I also added the search feature to the main site.

 

[MAKG]

If I were doing this (and it were an option), I'd disable all the add-ons and see if the problem is affected. If not, your add-ons are not siginficant. If so, add half back in and do the same evaluation. Do this repeatedly until you have the culprit isolated. It's a standard technique called a "binary search," and it's guaranteed to give you the minimum number of trials.

/tmp may be filled up by something unrelated. What does "ls -l" show? Who is using all the space?

Is this the Apache web server you're running, or Tomcat? Tomcat runs JSP. It leaks memory like it has Alzheimers.

 

[Jim Oaks]

This is the initial DB error we were getting:

Database error in vBulletin 3.6.8:

Invalid SQL:

SELECT pm.*, pmtext.*
, icon.title AS icontitle, icon.iconpath
FROM pm AS pm
LEFT JOIN pmtext AS pmtext ON(pmtext.pmtextid = pm.pmtextid)
LEFT JOIN icon AS icon ON(icon.iconid = pmtext.iconid)
WHERE pm.userid=1 AND pm.folderid=0
ORDER BY pmtext.dateline DESC
LIMIT 0, 50;

MySQL Error : Can't create/write to file '/tmp/#sql_c6c_0.MYD' (Errcode: 17)
Error Number : 1
Date : Friday, November 16th 2007 @ 08:11:59 PM
Script : http://www.therangerstation.com/forums/private.php
Referrer : http://www.therangerstation.com/forums/showthread.php?p=42007#post42007
IP Address : 98.135.49.40
Username : Jim Oaks
Classname : vB_Database

The only thing in that /tmp folder when I did the ls was #sql_c6c_0.MYD.

Therefore, I think it's a problem related to the forum. I am going to start suspending things one by one to see what affect if any it has and search for other forums who have had the problem to see what we may have in common with them.

 

[camma83]

Have you tried defraging the hd's? that might hlep with things, it will make everything run a little smoother as well

 

[MAKG]

Have you tried defraging the hd's? that might hlep with things, it will make everything run a little smoother as well

Umm, this isn't Windows.

I would check that the problem isn't full main memory, though. /tmp's capacity is just the main memory size. So if it's full, it either means its capacity is zero (full memory) or something writes into it. You can check which with "df -k" If memory is full, you get to figure out what's eating it.

How big is this .MYD file?

 

[Jim Oaks]

Right now when I go to /tmp and do a ls, there isn't anything listed (I re-booted last night)

df -k shows

1K blocks - 20971520
Used - 2183936
Available - 18787584
Use% 11%

Resource capacity in Virtuozzo shows 28.21%

QoS Alerts when in the Black: (date/X's)

11/13 - 1
11/14 - 2
11/15 - 3
11/16 - 6
11/17 - 2
11/18 - 9

 

[Jim Oaks]

We were in the black again this morning around 5:30. I want to look at the logs and see what was going on around that time. The iTrader and photoplog were turned off.

 

[Jim Oaks]

I turned off iTrader and PhotoPlog, but that didn't help. I turned them back on.

Now, I'm looking at the search feature in the main part of the site looking to see if it could be drawing too much resources at times.