1

I'm not sure what's happening but it's since a while that I'm experiencing using my dev site (running on a VM) on the local Ubuntu machine. The site runs on a Wordpress instance using MySQL setup to use innodb table on a separate folder. I don't have permission problems, as far as I know.

It I try to use MySQL CLI I can query the database without problems; the same using phpmyadmin. But when it comes to access via the site it takes ages and more often than not I need to stop the service.

And that's again another symptom something doesn't work as it should. Stopping the service via sudo service mysql stop I can see it immediately stops (phpmyadmin can't log in anymore) but the command line prompt keep on hold like it is working. The only way I have to get the CLI ready is to brutally stop the service with a CTRL+C.

Any idea of what's wrong? Thanks

0

You can see if this is a MySQL issue by running (swap the caps out for your runtime variables):

mysql -uUSERNAME -pPASSWORD DATABASE "show processlist;"

...while actioning a request. It'll show you the running-at-that-time queries along with how long they've taken. If you have a particularly slow query, it'll be in there. If that's too quick, there are methods of logging queries.

It could also be Wordpress (or your theme, or whatever) hammering the database with small queries. As somebody who builds online systems I'm perfectly qualified to let you in on a secret: Wordpress sucks. Oh okay, that's not a secret. You need to do a lot to make it perform well. To set you off in the right direction (assuming it's not a poorly written template): caching plugins!

In the same vein, watch htop while making requests. PHP+Wordpress will likely monster through a huge chunk of CPU to generate the page. It could just be that which is taking so long. If you can't fix it with caching (and you're on a 64bit computer) you could try HHVM (the almost-drop-in replacement for PHP-CGI from Facebook). It's much, much faster but needs installing. It's not as simple as apt-get install lamp-server^.

And finally, it does sound like it could be a DNS issue. If you're specifying a domain name as your database address and its resolution is taking forever (or worse, failing half the time), that's going to stuff up a connection. Switch it to an IP (127.0.0.1 if it's local) and try again.

  • Hi Oli, thanks for you bits. Re the last part, where am I supposed to switch it to local? Are you referring to the WP configuration or is it in the mysql configuration? – Andrea Moro Jun 11 '14 at 19:33
  • I'm talking about the DB_HOST settings in wp-config.php – Oli Jun 11 '14 at 19:34
  • ok thanks. In that file I've localhost, which in theory should be the same 0f 127.0.0.1, isn't it? – Andrea Moro Jun 11 '14 at 20:16
  • Ok, so that's the query that seems to cause the problems | 203 | jumpinuk | localhost:60327 | jumpinuk | Query | 0 | closing tables | INSERT INTO wp_options (option_name, option_value, autoload) VALUES ('_transient_doing_cron' | .... ny idea? – Andrea Moro Jun 13 '14 at 6:37
0

As suggested from @Oli in the other other it was a matter of DNS and name resolution. However, it was not in the same direction as he suggested.

It turned out to be that MySQL was trying to do IP resolution on each call, causing a DNS lookup. Because the db server is internal and had no connection to the outside world, the lookup would eventually timeout.

I resolved the problem by adding the skip-name-resolve directive in the my.conf SQL configuration file located beneath /etc/mysql of my VM.

Now my local WP rocks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.