Replace the PROXY_OPTIONS variable to the following:

PROXY_OPTIONS="--daemon --admin-address=127.0.0.1:4402 --proxy-address=/var/lib/mysql/mysql.sock --proxy-backend-addresses=10.1.1.1:3306"

10.1.1.1 being your remote MySQL node. Once that’s done, go ahead and restart mysql-proxy:

/etc/init.d/mysql-proxy restart

If all goes well, you should be able to grep the process:

5 S root      5970     1  4  75   0 - 11330 -      Oct05 ?        03:20:35 /usr/local/sbin/mysql-proxy --daemon --admin-address=127.0.0.1:4402 --proxy-address=/var/lib/mysql/mysql.sock --proxy-backend-addresses=10.1.1.1:3306 --pid-file /var/run/mysql-proxy.pid


Be sure to set php.ini to the following:

mysql.allow_persistent = On
mysql.max_persistent = -1
mysql.protocol = "TCP"
mysql.max_links = -1
mysql.default_port = 3306
mysql.default_socket =
mysql.default_host =
mysql.default_user =
mysql.default_password =
mysql.connect_timeout = 60
mysql.trace_mode = Off


That’s all folks! We hope you enjoyed this short article.

Cheers!

Howdy!

The above error can come up quite often on a busy database-driven website or it could happen at one time or the other for different reasons. Today, we are going to cover the main two reasons for it happening. I shall break this down by architecture.

The Out of memory error indicates that the whole system has run out of memory at that point in time. For example, I happened to be loading a customer’s database that required more than 4GB of free RAM on the system. The system had 2GB of free RAM to work with so the MySQL process failed to import the database due to a lack of memory. The solution here is to add more memory into the system.

Here, the error indicates that either the system ran out of memory, just like in x86_64 above, or that the process cannot address more memory even if it is available. This is more peculiar to the architecture than it is a shortcoming of MySQL. 32-bit operating systems are not capable of letting a process address more than roughly 4GB of memory. The best approach here is to install a 64-bit OS that is capable of addressing that much RAM.

Keep in mind that UNIXy fully manages its customers’ servers. Should this particular problem occur while assisting a customer, we are always more than happy to provide a complimentary memory upgrade to complete the task.

That’s all folks!

This error is not specific to Litespeed but can be encountered while building PHP with MySQL support on 64-bit systems. The fix is to tell the build that the MySQL client is indeed installed, but in a different directory, by adding the following flag to the configure line in Litespeed:

--with-libdir=lib64

The reason being the build doesn’t know at this point that it is dealing with a 64-bit OS. If adding the above switch does not work, be sure to install the MySQL client and libraries.

That’s all folks!

In this post, we shall go through the steps required to optimize a WordPress blog. If you are a current customer of UNIXy (http://www.unixy.net), do know that we are happy to implement these changes for your blog free of charge. We are a fully managed provider so do take advantage of it. Contact us today!

There are times when hardware upgrades are not feasible due to either budgetary limits or time constraints. We understand that a WordPress blog could be hosted on a shared platform or dedicated server (VPS included) so we have written this post with that in mind. The first 5 steps can be completed in a shared environment where access to global configuration files is not permitted by the provider. All 11 steps can be completed on a dedicated server or Virtual Private Server (VPS).

1. WP Supercache

WP Supercache is a WordPress plugin that once installed alleviates some of the burdens on the server. Essentially, it takes every visited PHP page, generates the HTML content, and stores it on disk for subsequent visits. This is called PHP caching. The performance gain is noticeable. Not only does it speed up requests and improves responsiveness but it also leads to less resource utilization on the server. To install WP Supercache, follow this link:

http://ocaoimh.ie/wp-super-cache/

2. Turn Autosave Off

The WP global variable AUTOSAVE_INTERVAL controls the how often WordPress auto saves posts as they are edited. For example, while editing or writing a new posts, WP could be automatically saving tens of copies of your posts to the main WordPress table. Each time such automatic save process kicks off the main posts table is locked in order to be updated, which prevents visitors from briefly accessing your blog. It also causes the load average to spike up. One could either increase the autosave interval or completely disable the functionality. To increase the interval to X number of seconds (the higher the better), do it as such inside the wp-config.php file:

define('AUTOSAVE_INTERVAL', 2200); // 2200 second autosave interval

To disable the autosave feature completely, create a simple plugin file and enable via wp-admin:

3. Disable Revisioning

This feature saves several revisions of the same post into the database. It clutters the posts table and ends up bloating indexes unecessarily. It’s best to disable this feature altogether if you don’t need it. Add this line to your wp-config.php to disable this feature:

define('WP_POST_REVISIONS', false);

No further action is needed.

4. Disable Non-Cacheable SQL Plugins

While it is a good idea to disable as many unneeded plugins as possible, it’s not always practical to do. But this step requires that you go through the code of each plugin and locate SQL queries that use the MySQL RAND() function. Because MySQL does not cache queries that use the random number generator function RAND(), there is a performance penalty associated with such plugins. For example, Random Post plugin uses RAND() in its select SQL, which forces the SQL to run against the database time and time again. You can locate the PHP scripts that use the RAND() function inside your plugin folder using this command:

grep -i "rand()" -r wp-content/plugins

Once located, one could either disable such plugin or replace MySQL RAND() with a PHP rand function. This way the PHP random function will be cached. The randomization will, however, not work as intended. The good news is that perceived functionality will not be much impacted.

5. Convert MyISAM Tables to InnoDB

The InnoDB engine is superior. There is no reason to run MyISAM anymore. Here is a Bash script that will convert all tables, that can be converted, to InnoDB. If you do not have access to a script shell, you can accomplish the same using phpMyAdmin or other MySQL management tools. Be sure to take a backup of the WordPress database before running this script. Also, be sure to define a maintenance window for this change as the alter locks up tables temporarily making the blog inaccessible:

#!/bin/bash
DBNAME="database";
DBUSER="user";
DBPASS="pass";

for t in $(mysql -u$DBUSER -p$DBPASS --batch --column-names=false -e "show tables" $DBNAME);
do
echo "Converting table $t";
mysql -u$DBUSER -p$DBPASS -e "alter table ${t} type=InnoDB" $DBNAME;
echo "Repair table $t";
mysql -u$DBUSER -p$DBPASS -e "repair table ${t}" $DBNAME;
done

Remember that those who are hosting their WordPress blog on a shared provider's server will not be able to proceed with the rest of the instructions. The following instructions require root-level access to the server and a technical understanding of systems.

Update (2011-02-16): If you’re interested in running Varnish with cPanel, UNIXY has created a cPanel Varnish plugin. Our Varnish VCL configuration performs much better than Litespeed. Read more about it here: http://www.unixy.net/varnish

Update (2010-10-09): Should you be interested in a managed vBulletin dedicated server know that UNIXy has built a system that is ideal for those that want to run a lightening fast vBulletin forum. Visit the following product link:

https://www.unixy.net/secure/cart.php?a=add&pid=216

Varnish is an excellent Web accelerator that can be made to proxy requests in and out of a cluster of somewhat more fully fledged Web servers like Apache or Litespeed. It has some great features like its compiled language, called VCL, and C-like programming API.

Large vBulletin deployments tend to be heavy on CPU and memory due to PHP script processing. For a large vBulletin forum, we recommend a cluster of 5 physical servers with three of those running Xen virtualization. One of those servers will be dedicated to the MySQL master database. Three to be setup as “headless” PHP nodes and Varnish load balancing and failover. And finally one as the NFS file store. The three headless servers need to run Varnish in their own VM and Litespeed or Apache in their own VM similarly.

The varnish backend director functionality makes it ideal to balance incoming traffic across all PHP headless nodes. It makes the configuration scalable and plug and play especially when needing to scale out within hours. The challenge in this setup is in making Varnish work correctly with vBulletin. Otherwise, session problems will occur.

We have a lot to share on this implementation so keep checking this blog as we will post it all. In the next installment, we’ll go through our deployment of a large vBulletin forum for a customer. In the mean time, feel free to get in touch should you have a question or comment. If you are interested in us helping you accelerate your server, we have a page explaining the different technologies we deploy on our clients’ dedicated servers. Read up here: http://www.unixy.net/accelerate-your-server

Update: we are offering a Varnish configuration for vBulletin (3 & 4) for a one-time fee. We can also configure it free of charge should you decide to rent your fully managed dedicated server from UNIXY (http://www.unixy.net). Please contact us today to get your forum running with a blazing fast speed!

That’s all folks!

The MySQL query cache is used to store data retrieved using SELECT statements. The advantage of the query cache is that subsequent and identical SELECT statement results are retrieved directly from the query cache, which resides in memory. So instead of executing the SELECT statements again and again, the stream of data is pulled from memory. The end result is lower CPU and disk hits, which can improve server load average and most importantly responsiveness.

The query cache functionality has enough smartness that once configured, it runs itself. MySQL will make sure to flush cached data if there’s an update that takes place. This ensures stale data is flushed out and replaced with fresh entries. There is, however, an extra step that is required. The cache tends to become fragmented over time. But nothing that cannot be addressed with a simple script (see below).

Stock MySQL configurations set the query cache to 32MB. This means that 32MB worth of server memory is pre-allocated to MySQL. If you have a relatively large database, you will most certainly gain from increasing that value. After configuring the query cache, it takes a while for MySQL to build the cache depending on how busy your MySQL server is.

Let’s get the query cache configured. Inside the [mysqld] section in the MySQL configuration file (ex: /etc/my.cnf), configure the options below. For a server with 8GB memory and a very busy database, set the cache to 1GB:

[mysqld]

query_cache_size = 1024M

Then restart MySQL for the new option to take effect. Run this command to verify that the new query cache value is in place and that the query cache feature is indeed enabled:

# mysql -u root -e “show variables like ‘%query%’”
+——————————+————+
| Variable_name                | Value      |
+——————————+————+
| ft_query_expansion_limit     | 20         |
| have_query_cache             | YES        |
| long_query_time              | 10         |
| query_alloc_block_size       | 8192       |
| query_cache_limit            | 1048576    |
| query_cache_min_res_unit     | 4096       |
| query_cache_size             | 1073741824 |
| query_cache_type             | ON         |
| query_cache_wlock_invalidate | OFF        |
| query_prealloc_size          | 8192       |
+——————————+————+

If the have_query_cache option is set to YES, it means that the query cache is indeed up and running. query_cache_size represents the cache size in bytes. You can also monitor the mysqld process using top and you will see its RES value increase over time to above 1gb. This would be a good sign asb MySQL fills up the query cache with result sets from SELECT. There is another way to check on cache usage and health. Run the following command:

# mysql -u root -e “show status like ‘qc%’”
+————————-+———–+
| Variable_name           | Value     |
+————————-+———–+
| Qcache_free_blocks      | 69776     |
| Qcache_free_memory      | 756433256 |
| Qcache_hits             | 9518567   |
| Qcache_inserts          | 3878394   |
| Qcache_lowmem_prunes    | 49447     |
| Qcache_not_cached       | 173233    |
| Qcache_queries_in_cache | 122754    |
| Qcache_total_blocks     | 315609    |
+————————-+———–+

If Qcache_free_memory stays high over a few days means that the query_cache_size value is set too high. A high Qcache_free_blocks means that memory is fragmented. So it is time to coalesce (make memory blocks contiguous) the region. This is done with the following command:

# mysql -u root -p -e “flush query cache”

Contrary to the command name, this does not flush the cache in the sense that all entries become invalid. It simply defragments the memory region that is assigned to the query cache. The above command should be put in a script that run every 6 hours or so. Create a root crontab entry as such:

* 6/* * * * /root/coalesce.sh

Where coalesce.sh is a shell script:

#!/bin/bash

mysql -u root -pyour_root_password -e "flush query cache";

The query cache can be further configured to match your database’s usage pattern. Be sure to read the MySQL documentation for the details. Hopefully, this post will come in handy for those that have unused memory and need to make the most out of their server. As our customer, we configure the query cache on your server from the get-go. Be sure to ask us how we can help with your online project!