Mobile app version of vmapp.org
Login or Join
Courtney195

: Since moving to a VPS I keep getting 500 internal server errors in GPI I moved from shared hosting to VPS a few days ago. I myself raised that VPS and it is Ubuntu 16.04 based, with Apache

@Courtney195

Posted in: #Apache2

I moved from shared hosting to VPS a few days ago. I myself raised that VPS and it is Ubuntu 16.04 based, with Apache and some virtual hosts, it's lightweight with almost no extensive software on it. All of my sites works just fine and I can change them and surf in them without any problem.

My problem is that when I run a GPI test to my site, about 50% of the time (about 50% of the tests) I get 500 Internal Server Error.

My question is, why would that happen? What's worth checking?

sudo cat /var/log/apache2/access.log, brings this:

::1 - - [05/Dec/2016:11:07:56 +0000] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.18 (Ubuntu) (internal dummy connection)"


sudo nano /var/log/apache2/error.log shows basically only this error which is very long, too much long for here I guess, so I'll paste only it's critical part:

[Mon Dec 05 14:53:26.574836 2016] [:error] [pid 31711] [client 66.249.88.155:46289] Uncaught PHP Exception DrupalCoreDatabaseDatabaseExceptionWrapper: "SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction:

10.01% popularity Vote Up Vote Down


Login to follow query

More posts by @Courtney195

1 Comments

Sorted by latest first Latest Oldest Best

 

@Harper822

Your first log entry shows Apache returning a 200 Ok, not a 500 Server Error.

You can find plenty of information online about the error message from error.log. A deadlock means that two different queries are attempting to gain a database lock at the same time and are dependent on each other finishing. This is likely an issue with poorly written code, and has always existed, but Google is requesting pages at a higher rate than you normally get through organic traffic, causing it to manifest.

If you look at the full stack trace (that you haven't included here), that should give you some good places to start looking in your code for problematic queries. You can also run show full processlistG and show engine innodb status in a MySQL shell while this is happening to try and catch some information about the queries.

10% popularity Vote Up Vote Down


Back to top | Use Dark Theme