This is another (strange) way for Windows to say that you have not inserted the Windows CD/DVD again. Put it back in again, wait a second and then the error message should disappear. (If it does not, try to hit refresh after putting the CD in)

I noticed that it was trying to look up and old proxy server which was not in use anymore, the machine itself got online without issues on other services but then i realised that the file “/etc/sysconfig/rhn/up2date” had a entry for yum proxy settings.

It is also worth checking all files in your “/etc/yum” folder and make sure that none of your repo files have dedicated proxy settings defined since that will override anything from up2date.

When commenting out that proxy setting, yum started behaving again.

It appears that when the LANG variable is not set in that file, Cron will fall back to using the POSIX charset.

To make the case even more strange, performance on other network tasks was quite normal where the gigabit  connection was maxed ASAP.

After some digging, the problem turned out to be that the server was running the old default drivers for the NIC (Broadcom BCM5708S netXtreme II GigE). Windows update has in the latest Windows versions become better on delivering driver updates but that was not the case this time.

After installing the newest drivers from Broadcom`s website the performance jumped straight to gigabit even on Data Protector.

[Critical] From: BDA-NET@ " [/boot]"  Time: 02.09.2011 09:08:03
Cannot connect to Media Agent on system , port 49708 (IPC Invalid Hostname or IP Address
System error: HOST_NOT_FOUND) =>
aborting.

The cause for this was that the client could not look up the cell manager. I solved this by simply adding the cell manager in the hosts file of the client. You can verify this problem by simply doing a ping or nslookup against the cell manager, from the client itself.

How-to:

1: Halt your virtual machine.

You need to stop your virtual machine before going wild with the drive. Virsh stop <vm name>, or virsh destroy <vm name> if it somehow wont stop.

2: Create a disk with the extra space needed:

qemu-img create -f raw 5gig.img 5G

3: Merge it into the disk you are working with

cat 5gig.img >> yourdisk.img

4: Boot up and and partition your drive.

Then start up your virtual machine again with virsh start <vm name>. If you use Windows server, all you need to do is to visit disk managent, right click your drive with little free space and choose “extend partition”. The job takes seconds and does not require any reboot.

My setup:
CPU: Intel(R) Core(TM)2 Quad CPU Q9300
RAM: 16G
Drives: 11 drives in one RAID6 with drives split over two cheap PCI-E x4 controllers and the motherboard`s internal controller.

I will test my system between each tuning by using dd for read and write testing. Since i have a nice amount of RAM available, i will use a test file of 36G. (bs=16k) Between each test (both read and write), i clear the OS disk cache with the command:

sync;echo 3 > /proc/sys/vm/drop_caches

Tuning stripe_cache_size

stripe_cache_size affects RAM used by mdadm to writing of data. Ubuntu`s default value is 256, you can verify your value by doing:

cat /sys/block/md0/md/stripe_cache_size

And changing it with:

echo *number* > /sys/block/md0/md/stripe_cache_size

Test results with stripe_cache_size=256
- Write performance: 174 MB/s

Not to good, i therefore increased it some levels, each level with result is described below:

Test results with stripe_cache_size=512
- Write performance: 212 MB/s

Test results with stripe_cache_size=1024
- Write performance: 237 MB/s

Test results with stripe_cache_size=2048
- Write performance: 254 MB/s

Test results with stripe_cache_size=4096
- Write performance: 295 MB/s

Test results with stripe_cache_size=8192
- Write performance: 362 MB/s

Test results with stripe_cache_size=16384
- Write performance: 293 MB/s

Test results with stripe_cache_size=32768
- Write performance: 326 MB/s

So, going from 256 to 32K ~doubled my write performance, not bad!

Tuning Read Ahead

Time to change a bit on read ahead, which should impact read performance. Default read ahead value is “1536″, and you can change it with the command:

blockdev --setra *number* /dev/md0

Test results with Read Ahead @ 1536
- Read performance: 717 MB/s

Test results with Read Ahead @ 4096
- Read performance: 746 MB/s

Test results with Read Ahead @ 32768
- Read performance: 731 MB/s

Test results with Read Ahead @ 262144
- Read performance: 697 MB/s

Test results with Read Ahead @ 524288
- Read performance: 630 MB/s

So oposite of the write performance tuning, this actually became worse for most of the settings. So 4096 is the best for my system.

In conclution

This is just an example on how different settings can have rather large impact on a system, both for the better and for the worse. If you are going to tune your system you have to test different setting for yourself and see what works best for your setup.  Higher values does not automaticly mean better results. I ended up with “stripe_cache_size=8192″ and “Read Ahead @ 4096″ for my system.

If you want to make sure that your changes is saved when rebooting the system, remember to add these commands (with your values) in /etc/rc.local.

The solution is to delete the file “.maintenance” in your WWW-folder/website root folder. Your blog will then again begin to work as it should.

The solution is to kindly thell DHCPCD to *not* override the hostname you have set, open /etc/default/dhcpcd and alter the following:

1

SET_HOSTNAME='yes'

to

1

SET_HOSTNAME='no'

Reboot and voila!