Lot of database errors since upgrade to 5.2.3 MySQL server has gone away

[Wayne Luke]

MySQL gone away errors are very hard to troubleshoot. It simply means that MySQL has stopped responding for the moment and didn't return an result for the query. Unless we can figure out a common query that can realistically cause this to happen, There isn't much we can do on a shared server.

[Maltair]

I wonder if it has to do with that this is originally a vb 3.8 database upgraded straight to vb 5 (no interim vb 4).

But it did start happening much more when I got to vb 5.2.3 and continues galore with vb 5.2.4

What about my two databases that are still ISAM. You had written: "Keeping those as MYISAM until you're using MySQL 5.6 or higher is appropriate." Maybe now that I am running PhP 7 I can convert those last two tables to InnoDB too. If you want to go back to the private support ticket 1518453 I have open on this matter maybe you may advise me there.

[Wayne Luke]

Upgrading from vb3 shouldn't matter. vBulletin 5 doesn't use many of the content tables from either the vB3 or vB4. It has a new storage structure. Over the last few versions, we've been deleting obsolete tables from the database to clear things up.

The only thing that really changed between 5.2.2 and 5.2.3 is the introduction of vBulletin Messenger. Does your user base use this heavily?

[Maltair]

I guess we are using the messenger some yes. But really, I'm not sure what the vb messenger is. What I mean is, we click on the private message from the pull down menu, and then send messages back and forth with that applet open. Is that using vb messenger?

*Should I ask hostgator to try to convert those last two tables to InnoDB?

[Maltair]

I think it's time to go to VPS from shared hosting? Or move to a better hosting.

vbulletin finally analyzed and came back with: "Looking at the error_log in your forums directory, the errors just appear to be a resource limitation is being hit. I've created a JIRA to handle this better. We cannot eliminate the resource limitations. It doesn't even have to be your site causing these database errors. If another site on the shared server uses the resources on MySQL, you have to wait and it can result in these errors. There could be 500, 800, 1000 sites on a single shared server."

I was looking into cloud at hostgator. Or VPS. But hostgator tech support said:

"Switching to a Cloud package would generally not assist as these are still shared hosting accounts which are shared with other users. The only way to truly ensure that other users will not have any effect on your website is to get a dedicated server as VPS are not protected from these issues either as you are still on a server with more then one customer on it. Please let us know if you have any other questions or concerns."

That's quite a jump though - from a shared server costing a few bucks a month to a dedicated. At hostgator the cheapest dedicated ends up at 179 per month after the introductory price. I suppose I can find a dedicated elsewhere that lands after introductory price at around 79 per month, maybe 69. I just find it hard to believe that I need to go from shared all the way to dedicated and that neither cloud nor VPS will solve the issue.

The main thing I find, other than the database errors, is that my messaging system is very slow.
http://www.vbulletin.com/forum/forum...eral-very-slow
my forum runs okay usually.

I suppose here I'm asking for input/suggestions from other vbulletin users as to whether cloud or VPS is working for them, with decent traffic. I'm currently reaching 10,000 per month unique visitors and I suppose I'll be going up from there. I have anywhere from 30 - 150 visitors logged on at a time it seems, and I assume some of those are just search engine bots. Those levels don't seem all that high to me.

[glennrocksvb]

They are just trying to upsell you.

A good VPS should be enough. You will get more help if you post in vBulletin Hosting Options forum at http://www.vbulletin.com/forum/forum...osting-options

[Mark.B]

Agreed, dedicated would be overkill. Whilst a VPS can theoretically still suffer from the same issues, in practice this is rare because each instance has its own allocated resources, it is. It pooled in the way ordinary shared hosting is.

In in most real world cases a good VPS should be mostly indistinguishable performance wise from a small dedicated server. It's not actually quite that simple but in basic terms that's the situation.

[Wayne Luke]

You should be able to use their Snappy 1000 VPS. Saying the problem won't be resolved by upgrading to a VPS is erroneous. While there are still multiple sites per machine, a VPS should be more segmented to keep other sites from using your resources and vice versa. If they are not doing that then they are simply lying about selling VPS accounts.

[Maltair]

I got mixed messages from hostgator. One of their top tier supports is the one that said I need dedicated, the message I posted above, and another level 3 hostgator tech said that VPS should suffice. But hostgator has only the Snappy 2000 now as their lowest priced one which while it starts off at 19.95 / month jumps to 89.95 after the introductory period. I've seen full on dedicated servers for less than 89.95 from other outfits.


By the way this same level 3 hostgator tech kept saying that each account on a shared server has the same limits imposed on it such that no one may overuse resources. In other words, trying to say that the database errors you are experiencing can't be because of a temporary overload from another user.

[Wayne Luke]

I've seen full on dedicated servers for less than 89.95 from other outfits.

Less expensive dedicated servers would be unmanaged servers. That means you're responsible to update the OS, PHP, MySQL as well as the mail server, sftp server/access. Plus you have to keep track of all security issues for every piece of software installed on the machine.

To be honest with you, we're grasping at straws on why you're getting MySQL Gone Away. Without detailed logging from the server provider that is all we have. It is like the ubiquitous 500 server error. It really doesn't mean much by itself. If the queries were all over 1 Megabyte in size or there were other consistencies than we could troubleshoot more. You're getting the error on queries that shouldn't take more than a few milliseconds to process, though.