Magento Forum

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away ISSUE- Tried everything! 
 
azores
Jr. Member
 
Total Posts:  12
Joined:  2011-06-29
 

OK, here’s a problem that we\\\’ve been experiencing, wonder if anyone can help us on. I’ll try to keep it brief but I want to provide as much info as possible:

We run 3 Magento websites (Magento Professional Ed.) AND our MySQL server on one dedicated Peer1 server with the following specs:

-Red Hat Enterprise Linux 5
-2 x Intel Xeon E5620 2.50 GHz Quad-Core Processor
-24GB 1333 Mhz DDR3 RAM
-4 x 146GB 15 SAS drives in RAID 10
-Tivoli Managed Backups

For all three of our websites COMBINED, we have the following 2012 website visitor metrics:

---2012 Non Peak Months (February-July & September-December): 120,341 visitors (12,034/mo over a 10-month average)
---2012 Peak Periods: January: 22,006 visitors and August: 29,119 visitors.

We have 6,000 Item SKUs.

We’ve had little problem with Magento until, suddenly, in early Dec. 2012, we noticed that whoever tried to initially log into our Magento Admin Panel would experience a time-out. Second attempt to log-in would generally work fine. Error message displayed: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away.

This log-in timeout happens every morning. Slowly, it came to our attention that not only was this timeout problem occurring during admin panel log-in attempt, but at other points as well, including customer website searches, had it timeout when saving an item in admin panel, and, most importantly, time-outs after a customer submits an order from checkout.

Developer told us from logs, looks like error happens anywhere from 5 to 20 times daily. Aside from regular early morning admin panel timeout, it is hard to replicate on demand, but when it happens, it seems to fix itself shortly afterwards, only to fail again later.

Researched error message on Internet: virtually all posts we came across indicated it has to do with MySQL settings. However, we optimized these settings for Magento up and down, (including wait_timeout and max_allowed_packet). Did not fix it. We implemented Cloudflare to reduce server load and regulate malicious traffic. Did not fix it. Cleared out large MySQL logs. Did not fix it. We migrated from our basic MySQL to more stable Percona MySQL. Did not fix it. Database admin at server company said, in these instances, 80% of time error is with Magento, not database. We did not believe him until we exhausted all of the above database fix attempts with no luck.

At this point, our websites are still unstable, timing out randomly on customer orders, etc. Although, the timeout error to access Magento Admin Panel still occurs regularly on the intial log-in attempt each morning.

Has anyone else experienced this or any other ideas that might help us solve this (aside from the solution attempts I indicated above that we have already tried)? At this point, anything would be appreciated.

Thanks!

 
Magento Community Magento Community
Magento Community
Magento Community
 
MagenX
Enthusiast
 
Total Posts:  791
Joined:  2008-05-26
Dublin
 

hi
the problem is - the wrong people maintain your sites/server.
If you see a problem, and the error log, and you have server/database admins I wonder what they have done, if the problem persists?

we can fix all your problems in about 15 minutes.

cheers

 
Magento Community Magento Community
Magento Community
Magento Community
 
dmagalska
Jr. Member
 
Total Posts:  1
Joined:  2012-11-20
 

We are having the EXACT same issue, however I haven’t gotten as far as trying all of the fixes you mentioned above.  We have about 45k SKUs but the store is brand new with only about 150 visitors a day.  We started having the admin login issue before the site even went live so it seems like it’s not a traffic issue as much as something to do with the database itself (perhaps the large number of products?).

If anyone has an answer to this I’d really appreciate it - I’m at a loss right now and our store is going to be dead in the water without a fix.  We are running Magento SE 1.7.0.2

 
Magento Community Magento Community
Magento Community
Magento Community
 
azores
Jr. Member
 
Total Posts:  12
Joined:  2011-06-29
 

Hi:

Here’s an update:

I tossed this to our host, Peer1 and they let us know:

“While investigating the performance degradation you have reported we noticed none of the platform’s cache layers have been implemented in the Magento configuration. Usually the implementation of cache layers is handled by your Magento Solution Partner at the time the initially deploy and test the store.” They discovered that the APC cache was installed but had never been turned on or configured/optimized. Memcache had never even been installed.

--------
Peer1 did the following for us:
---------------
“installed the following packages:

php-pecl-memcache
memcached
(php-pecl-apc was already installed)

Started the memcached service, and set it to start at boot.

Thenbacked up your local.xml file to local.xml-20130129, and added the following to the <global> section of the local.xml file:

<cache>
<prefix><![CDATA[MAGE_cache_]]></prefix>
<backend><![CDATA[apc]]></backend>
<slow_backend>database</slow_backend>
<slow_backend_store_data>0</slow_backend_store_data>
<auto_refresh_fast_cache>0</auto_refresh_fast_cache>
</cache>
<session_save><![CDATA[memcache]]></session_save>
<session_save_path><![CDATA[tcp://localhost:11211?persistent=1]]></session_save_path>

Then restarted the httpd service which caused the new configuration to be re-read. The site seemed quite quick, and your shopping cart would accept items and they stayed there.

Finally cleaned out the old file based cache directories:

/home/barbksmgnto/live/var/cache
/home/barbksmgnto/live/var/session”
-----

Since this was done, to our knowledge, we have not had any website issues.

Good luck!

 
Magento Community Magento Community
Magento Community
Magento Community
Magento Community
Magento Community
Back to top