Memory effects by (K)Ubuntu upgrade

ript>

A few days after upgrading KUbuntu on my laptop (from version 6.10 to 7.04), I noticed that the free memory indication decreased rapidly when I was loading some applications, much faster than before. Additionally, when it was reaching the amount of 50-60 megabytes left, the whole system went to a situation of continuous hard disk writing/swapping which left no other option for me than to power-cycle it the hard way! 🙁

At first, I thought it was something with the new kernel (2.6.20, in place of 2.6.17 I was using until then), so I made the change to my GRUB menu.lst file to load by default the 2.6.17 kernel. Nevertheless, although the situation got a little better, the problem remained and I had to close Firefox in order to be able to run Opera and vice versa (one very annoying situation for someone who must test his LAMP projects with the most popular browsers).

Today I made another change to my system by purging the mdadm package (responsible for software RAID arrays, which I don’t use in this computer) and, so far, the system is more stable; at least I can use 2-3 browsers (don’t forget Konqueror) simultaneously.

The next days will show if the mdadm package was the culprit!

UPDATE:
I think I found it (finally)… my swap partition was disabled!!!
The upgrade process changed the relevant line in /etc/fstab file from

/dev/sda5 none swap sw 0 0

to

UUID=fac6f2c3-34a6-48c6-83f2-eb59c90cb944 none swap sw 0 0

which didn’t worked as expected. After I restored the first line in place of the second, I got back my 500 MB swap space.

Furthermore, in order to be consistent with the new UUID method, by using the blkid command I found that the correct UUID for the swap partition was “1e93c994-8da0-4666-838f-4dd1452f9a15”, so I changed the above line to be:

UUID=1e93c994-8da0-4666-838f-4dd1452f9a15 none swap sw 0 0

The problem now is that the free command shows that I have 1 GB swap space, whereas with the first method I had 500 MB. I have to investigate this further (hoping that there will be no data corruption in the meantime)…


Visit The Light of the LAMP blog for more…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.