Depending on which version of Varnish you have running, there is a chance the code is still experimental and the whole Varnish daemon is prone to a fatal crash.

Here is a quick and dirty monitoring script for Varnish. It essentially runs as a crontab job and requests a PING response. Should it not receive a PONG from Varnish, it will attempt a restart. There is a second round of testing within the same script. This is a second level of PING request; just in case. Be sure to set the usual defaults like -T port and varnish runlevel script.

#!/bin/bash

result=$(echo -e "ping\n\r" | nc localhost 6082|grep PONG|wc -l);

if [ "${result}" -lt "1" ];
then
/etc/init.d/varnish stop;
sleep 5;
/etc/init.d/varnish start;
echo "$(hostname): Varnish restart" | mail -s "$(hostname): Restarting varnish" alerts@example.com;
fi

sleep 5;

results=$(echo -e "ping\n\r" | nc localhost 6082|grep PONG|wc -l);

if [ "${results}" -lt "1" ];
then
/etc/init.d/varnish stop;
sleep 5;
/etc/init.d/varnish start;
echo "$(hostname): Second Varnish restart" | mail -s "$(hostname): Restarting varnish second time" alerts@example.com;
fi

exit 0;

Finally load the job into crontab:

*/5 * * * * /root/varnish.sh

A cleaner way of accomplishing the same goal would be to establish a permanent connection to the Varnish admin port (6082 in this case) and issue a PING command every other second or so. The interval can be in the sub seconds as opposed to minutes as is the case with crontab.

Here is an example:

# telnet localhost 6082
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
ping
200 19
PONG 1274931430 1.0
ping
200 19
PONG 1274931434 1.0
ping
200 19
PONG 1274931437 1.0
ping
200 19
PONG 1274931443 1.0

We deploy Varnish and other tools on our clients’ server to get the most performance out of hardware. Our clients are happy with the performance boost and we are happy of the end result. Please do get in touch if you have any question or comment

That’s all folks!

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!

phpBB is a open source forum software. The board’s index page lists the topics along with a listing of online members. While trouble shooting a customer report of a slower loading of the board “index” page, we found out that the fix in itself is simple and easy to implement. We would like to share this solution in the hope that it will benefit others. It turns out one of the hot spot table, phpbb_users, is not indexed. The performance fix is to simply add an index on column user_email of only 15 characters. Here is an example of the index creation:

create index phpbb_users_email on phpbb_users (user_email(15));

That should do it. Enjoy the quick performance bump! Keep in mind that UNIXy is a fully managed shop and is always happy to lend a hand with systems questions. This is part of our fully managed services guarantee that comes with our VPS and dedicated servers.

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!

If you receive one of the following errors, it’s very possible the Apache process is listening on port 443 but is not responding using the SSL protocol routines. In brief it is a protocol mismatch. Here’s a list of possible errors:

Firefox error: SSL received a record that exceeded the maximum permissible length

Apache error log: \x80d\x01\x03\x01

Curl CLI error: curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

The fastest way to recover from such error is to restore the most recent Apache configuration file from backup. If you do not have a backup copy, you will need to look at your virtualhost section associated with the domain and SSL port combination. Chances are it does not exist. In cPanel, this issue can be corrected with a simple run of the script rebuildhttpdconf as such:

/scripts/rebuildhttpdconf

After making the necessary changes, and whether you are running cPanel or not, you will need to stop Apache then restart it.

That’s all folks!