WordPress page_rewrite_rules many URL rewrite mysql slow

There are use cases that WordPress core isn’t well optimized for. The end result is poor page load and sub optimal performance.  One of these use cases is the too-many-URLs or menu links issue. WP is then forced to break down these requests into smaller chunks to process them. Except that smaller chunks almost always amount to significant overhead especially with a high number of URLs.

WP function page_rewrite_rules is where the page rewrites happen for every URL. But for several reasons, we won’t go as far as to modify this function to reduce the overhead. After profiling this function and code, we were able to understand the culprit and implement a fix with the least resistance path (i.e. not in the code).

The fix consists of increasing the max_allowed_packet parameter in  the my.cnf configuration file for MySQL in section [mysqld] (usually located in /etc/my.cnf) like this:

max_allowed_packet = 32M

A high max_allowed_packet helps WP process the URL rewrites in one fell swoop (larger query pull leads to faster processing).

We hope you enjoyed this entry. Interesting tidbit to note is that we happily did this work for a client who didn’t care one bit about the inner workings of WP. They just wanted things to work on their managed server. And so we did.

That’s all folks!

How to backup and restore one or multiple cpanel accounts via command line / ssh

Here are a couple of one-liners that come handy when you’re about to do a big dedicated server move. The first one-liner packages each one of your accounts into its own “cpmove” file, which you then transfer to /home/ on your new/destination server. Be sure to execute this as root via SSH/Bash:

mkdir /home/backup.logs; cd /home; ls -1|while read a; do /scripts/pkgacct ${a} &> /home/backup.logs/${a}.log; done &

Depending on the number of accounts that you have and/or the amount of data to be backed up, the above command can take from a minute to several minutes or hours.

We wrote these one-liners because a client of ours needed help transferring his old server to his new fully managed unixy node. We provide fully managed servers and clusters in four of our locations around the world and are very happy to go above and beyond to make a client’s day. We LOVE helping our clients!

You can follow the progress of the above task by looking up directory /home/backups.logs/. There you’ll see the log files being created and updated as the command progresses through all accounts. So, how do you know whether the job completed? Run this shell command: jobs. If you see output similar to this it means the backup is still in progress:

# jobs
[1]+ Running ls –color=tty -1 | while read a; do
/scripts/pkgacct ${a} >&/home/backup.logs/${a}.log;
done &

Once the above one-liner finishes running, jobs won’t show any active program. In fact, the second it finishes it will show Done and will exit normally. So it completes, use scp or rsync to transfer the files over to the destination/new server. You can use this command:

scp -oPort=22 /home/cpmove*.tar.gz root@destination_server_ip:/home/

The scp command will show a visual on its progress and will tell you when it’s done transferring the files. Once it’s done, ssh in to the destination server and load up the account with this one-liner:

 mkdir /home/restore.logs; cd /home; ls -1|grep cpmove|while read a; do /scripts/restorepkg ${a} &> /home/restore.logs/${a}; done &

Monitor the progress of this command by listing the content of folder /home/restore.logs/. There you can tell where it’s at and if there are any errors (grep -i error /home/restore.logs/*).

That’s all folks!

cPanel licensing issue when using multiple subnets / networks on the same server. Fix Inside.

With providers running out of IPv4 allocations around the world and people resorting to using multiple IP blocks/subnets on the same dedicated server, there’s a chance someone will run into this problem. If you have multiple subnets on the same box, chances are cPanel will get confused and use one of the other subnets as the outgoing IP for license verification purposes. This causes issues because now the cPanel licensing server thinks you’re not licensed (outgoing IP doesn’t match on-file IP). NB: we aren’t circumventing any licensing mechanism (unethical). This issue can happen to a wide array of software that depends on the outgoing email address (ex: email).

Here’s how your eth0:X layout might look like:

eth0     -> /

eth0:0 -> /

eth0:1  -> /

So let’s move on to the fix. Normally a cPanel server is licensed against its main IP/interface. In Linux that’s eth0 (0 for zero). So we’re going to tell the server to give eth0’s route a preference over its other interfaces. From the above example, we will increase the metric of eth0:0 and eth0:1 by 1. In metric speak, 0 has higher preference than 1. And 0 happens to be the default metric of interfaces on Linux boxes. All said and done, eth0 will keep its metric of 0 and will the de facto preferred route.

So open /etc/sysconfig/network-scripts/ifcfg-eth0:0 and add this line at the end of the file:


And here’s a visual:


METRIC option in /etc/sysconfig/network-scripts/ifcfg-eth0

Do the same for /etc/sysconfig/network-scripts/ifcfg-eth0:0 or any other interfaces you have. To effect this change on your system, you’ll need to run this next command but be warned this could knock your server offline if you end up doing things precariously and especially if you’re remoted in via SSH. Here’s the command:

nohup /etc/init.d/network restart &

The above command will freeze your terminal (understandably because you’ve restarted the network subsystem). Wait a minute or two, then open a new SSH/console and get back in as you would normally. It’s preferable to complete this work at the console or via KVMoIP.

That’s all folks!

Litespeed and Varnish Plugin on a cPanel WHM server

 Update (2013/02/07): We’ve released a Varnish Litespeed Plugin for cPanel WHM

Litespeed users on cPanel WHM servers are realizing the benefits of running Varnish Cache in front of Litespeed to improve performance. While we (UNIXy) don’t officially provide support to subscribers running the cPanel Varnish Plugin with Litespeed, it does work with only a few extra manual steps. Keep in mind that we support this configuration for our fully managed VPS, dedicated server, and cluster clients free of charge. If you are a current client and need this configured, please open a ticket request. We’ll be happy to assist with this task.

In this post, I’m going to list the steps required to pair the cPanel Varnish Plugin with Litespeed on cPanel WHM servers. These few procedures apply to a blank cPanel installation (no Litespeed, no Varnish Plugin). The order below is important so don’t skip!

  • 1. Configure your Apache / PHP with the desired options and extentions. Let EasyApache finish the build.
  • 2. Install Litespeed using the command line installer with the port offset at 2000 (default).
  • 3. From WHM -> Litespeed -> Build Matching PHP binaries. Let the Litespeed builder complete before proceeding.
  • 4. Proceed with installing the cPanel Varnish Plugin. Let it complete.
  • 5. Set the Litespeed Port offset to zero in Admin Console.
  • 6. In Admin Console, Configuration -> Server -> General Settings -> Use Client IP in header -> Yes. Restart Litespeed.



UNIXY is a long-time Varnish Cache user and evangelist. They have been offering Varnish acceleration to their clients for more than three years. They have released the first cPanel Varnish plugin as well as spun a new startup, Fastlayer, the on-demand HTTP accelerator for the cloud.

That’s all folks! I hope you find this useful.

Stable FastCGI configuration on a cPanel Apache shared or dedicated server

A default installation of FastCGI on cPanel server is dangerously simple. It’s dangerous because one cPanel account (or one vhost) is capable of crashing down a whole server if, say, traffic were to spike up. It’s also simple because it won’t allow complex scripts to run cleanly. In brief, it’s absolutely not ready for production as-is. In this post, I’ll go over what it takes to configure FastCGI on a cPanel node properly.


Did you know?

UNIXy is a fully managed server and cluster provider. What this means is we don’t expect you to know anything about servers or server management. The good news is it doesn’t cost you extra to have us manage your UNIXy server! Get in touch with us here to get the ball rolling!

Before you continue reading, be sure to have FastCGI up and running as the PHP handler on your cPanel server. The installation of FastCGI is covered in the online cPanel documentation. From here on now, I’ll assume you’re ready to add the settings for FastCGI.

The following is a list of settings that you need to add to /etc/httpd/conf/php.conf upon switching to FastCGI:

MaxRequestsPerProcess 1000
FcgidMaxProcesses 200
FcgidProcessLifeTime 7200
MaxProcessCount 500
FcgidIOTimeout 400
FcgidIdleTimeout 600
FcgidIdleScanInterval 90
FcgidBusyTimeout 300
FcgidBusyScanInterval 80
ErrorScanInterval 3
ZombieScanInterval 3
DefaultMinClassProcessCount 0
DefaultMaxClassProcessCount 3
MaxRequestLen 20468982

You’re more likely to adjust the settings in bold above. DefaultMinClassProcessCount 0 instructs FastCGI to keep zero PHP processes running for user when traffic is idle (cPanel account user) . On the other hand, DefaultMaxClassProcessCount 3 tells FastCGI to never allow more than 3 PHP processes running at a time. This settings prevents one users from crashing the server were they to receive a lot of traffic.

So go ahead and copy/paste the above into your httpd.conf and restart Apache (service httpd restart). You’re good to go now! For greater performance, be sure to check out our Varnish plugin. Whether you’re running suPHP, FastCGI, or even DSO (mod_php), Varnish will make your website load much faster.

That’s all folks!

Varnish “not responding to CLI, killing it died signal=3” Explained

We haven’t seen anyone explain the meaning of following Varnish error message found in the logs of your server in detail. So here it is for the curious:

Dec  5 12:31:31 server varnishd[28446]: Child (28447) not responding to CLI, killing it.
Dec  5 12:31:59 server varnishd[28446]: Child (28447) died signal=3
Dec  5 12:32:03 server varnishd[28446]: child (22431) Started
Dec  5 12:32:04 server varnishd[28446]: Child (22431) said Child starts
Dec  5 12:32:04 server varnishd[28446]: Child (22431) said SMF.s0 mmap'ed 268435456 bytes of 268435456

The message above comes from the Varnish Manager. The Manager is the Varnish process (there are two Varnish processes) that monitors and manages the Varnish caching process. Here it’s telling us that caching process has stopped responding back with a PONG to its PING. A ping from the Manager to the Cache process with its response look like this and happens every 3 seconds (at least in this configuration):

    0 CLI          - Rd ping
    0 CLI          - Wr 200 19 PONG 1323181633 1.0
    0 CLI          - Rd ping
    0 CLI          - Wr 200 19 PONG 1323181636 1.0

So going back to the error message, the Manager is telling us that it hasn’t received a “PONG” back from the Cache process in a while. A “while” is controlled by the variable cli_timeout which has a default of 10 seconds in Varnish 3.x and 20 seconds in Varnish 2.x. So the Manager waits for about 10 seconds before it fires a UNIX kill using signal SIGQUIT (signal=3). Next the Manager starts the child back up again afresh.

You may be asking yourself: why is the Cache process not responding? There are a few of possible causes. Either the cache process is deadlocked (deep code issue) or the server is under a very heavy disk IO load / memory shortage. So how do you determine which category you fall under? I recommend checking the load average and memory utilization levels on your server using Sysstat tools.


Did you know?

UNIXy is a fully managed server and cluster provider. What this means is we don’t expect you to know anything about servers or server management. The good news is it doesn’t cost you extra to have us manage your UNIXy server! Get in touch with us here to get the ball rolling!


That’s all folks.