How query cache can cause performance problems?

How query cache can cause performance problems?

Whenever query cache is enabled, any query executed has to access it for one reason or another. For example, the text of a reading query has to be looked up against the cache contents in search for the previously buffered result that could be returned, a freshly generated result from a SELECT statement has to be stored into the cache, but also writing to any table triggers invalidation of all cache entries associated with the particular table, regardless of the original modification size. All this activity relies on a single, global mutex lock. The lock is used to guarantee consistency for the cache contents and for the results returned from it. It implements concurrency control in such way that, while one thread (i.e. one query) is changing anything in the cache, no other query can access it until the lock is released.

Such architecture is not a problem unless a combination of factors occurs that results in the query cache mutex being locked extremely frequently or for extended periods of time. When it happens, in the best case it just builds some serialization around the execution of queries, which means higher response times. In the worst cases, it may bring a database instance almost to a stop when very few queries can make it past the lock. The factors mentioned earlier are:

• high concurrency – many queries sent concurrently over a large number of connections
• workload type – often a good mix of reads and writes
• query cache size – invalidating results, which all happens under the lock, takes longer with more data cached

There are no rules that would allow anyone to predict what combination of these can actually trigger the problem and therefore enabling the query cache always exposes MySQL instance to the possibility of it occurring. Since out of the three factors only size can be controlled, to minimize the risk, it is advised to be conservative when setting database options and never allow query cache size larger than one or two hundred megabytes. In many opinions, it is even best to disable it entirely as there are not too many workloads, where the cache can actually be efficient.

nconf stopped working after update to nagios 4

I recently updated our nagios monitoring system from Nagios 3 to Nagios 4 and nconf started giving below error when I generate the new configuration files.

Error: Service has no hosts and/or service_description (config file 'nconf/temp/Default_collector/advanced_services.cfg', starting on line 195)

It was no surprise because the last release of nconf was on Dec 2011 which is around 6 years back. So no wonder it was not working with nagios 4.

Solution:

I searched a lot with no solutions and was thinking of switching to NagiosQL when I came across this post http://forum.nconf.org/viewtopic.php?f=17&t=872#p3050 I gave it a try and it worked like charm.

[root@nagios nconf]# unzip nconf-1.3.0-0_not_used_advanced_services_wont_be_written.patch.zip
 Archive:  nconf-1.3.0-0_not_used_advanced_services_wont_be_written.patch.zip
 inflating: nconf-1.3.0-0_not_used_advanced_services_wont_be_written.patch

[root@nagios nconf]#  patch -p0 --verbose < nconf-1.3.0-0_not_used_advanced_services_wont_be_written.patch
 Hmm...  Looks like a unified diff to me...
 The text leading up to this was:
 --------------------------
 |--- bin/lib/NConf/ExportNagios.pm.orig 2011-12-24 13:57:38.620626845 +0100
 |+++ bin/lib/NConf/ExportNagios.pm      2011-12-24 14:02:16.870751718 +0100
 --------------------------
 Patching file bin/lib/NConf/ExportNagios.pm using Plan A...
 Hunk #1 succeeded at 1014.
 Hunk #2 succeeded at 1078.
 Hunk #3 succeeded at 1111.
 done

You will also have to add below line in config/nconf.php

define('CHECK_STATIC_SYNTAX', 0);

How to check if the disk is SSD?

Most of the data centers and hosting providers are now offering SSD (Solid-state drive). If you run the fdisk command to check the drives it’s still going to show as sda/hda. Since kernel 2.6.29 Linux automatically detects SSD. Now to verify sda for SDD. Simple cat the /sys/block/sda/queue/rotational file. If the output is “0” then that  means it’s a SSD.

root@host [~]# cat /sys/block/sda/queue/rotational
0
root@host [~]#

If the result is
1 -> Regular SATA disk
0 -> SDD

How to install VIRTUALIZOR on OVH Servers

OVH provide dedicated servers with their own customized kernels. Also the loaded disk partitions too will look odd to you. Now if you directly run the virtualizor installation script then it will get installed but it will not work. Because the Xen/KVM kernel and modules will not be loaded.

So we will have to first have to replace it with normal kernel and also remount the partitions too.

Install the kernel

[root@server ~]# yum install kernel
.....................
Installed:
  kernel.x86_64 0:2.6.32-431.20.3.el6
Complete!

Now remount the partitions

[root@server ~]# rm -rf /etc/mtab
[root@server ~]# mount -o remount -a

Add kernel new kernel entries to grub file and reboot the server.

[root@server ~]# new-kernel-pkg --mkinitrd --depmod --install  2.6.32-431.20.3.el6.x86_64
[root@server ~]# reboot

NOTE: Check grub.conf and make sure that regular vmlinuz kernel is configured to load instead of bzImage kernel provide by OVH. Then reboot the server.

Now all is set and we can start the installation of Virtualizor. Below are the steps for installing XEN virtualization.

[root@server ~]# wget -N http://files.virtualizor.com/install.sh
[root@server ~]# chmod 0755 install.sh
[root@server ~]# ./install.sh email=user@domain.com kernel=xen lvg=vg0

“vg0” is the logical volume that I created.

It will take some time fo the installation to complete and you will see something like this

Congratulations, Virtualizor has been successfully installed

API KEY : f3bm1ds8iq3nmcrgt2gf8wqy3zk2xiqk
API Password : ctm3qbnxzuux9i8uwnwji39d0urgu8qf

You can login to the Virtualizor Admin Panel
using your ROOT details at the following URL :
https://xx.xx.xx.xx:4085/
OR
http://xx.xx.xx.xx:4084/

You will need to reboot this machine to load the correct kernel
Do you want to reboot now ? [y/N]

Press “y” and reboot the server. And all is done. You can now access the Virtualizor admin panel from https://xx.xx.xx.xx:4085/. You should login with your severs root login details.

NOTE: In case you are not able to access the admin panel then your firewall must be blocking it. You should unblock the ports

iptables -I INPUT -p tcp --dport 4084 -j ACCEPT
iptables -I INPUT -p tcp --dport 4085 -j ACCEPT

dovecot: auth: Error: Cpanel::MailAuth: Failed to getpwnam

If you are not able to access email even with correct username and password and you see below error in the /var/log/maillog

Jul  5 18:15:20 hostname dovecot: auth: Error: Cpanel::MailAuth: Failed to getpwnam for user webmaster
Jul  5 18:15:38 hostname dovecot: auth: Error: Cpanel::MailAuth: Login not permitted to account with a uid lower then 500 (498)
Jul  5 18:15:56 hostname dovecot: auth: Error: Cpanel::MailAuth: Failed to getpwnam for user admin
Jul  5 18:54:38 hostname dovecot: auth: Error: Cpanel::MailAuth: Failed to getpwnam for user info
Jul  5 18:54:45 hostname dovecot: auth: Error: Cpanel::MailAuth: Failed to getpwnam for user info
Jul  5 18:55:06 hostname dovecot: auth: Error: Cpanel::MailAuth: Failed to getpwnam for user info

Reason:

This happens if hostname is same as domain. The mail server will try to authenticate against system user of the server instead of virtual domains on the server.

Solution:

Change the hostname of the server to something else other than domain name. e.g. if your domain is domain.com then you can set the hostname as host.domain.com

Also make sure that there is entry of the domain in both /etc/localdomains and /etc/userdomains.