On Friday 04 February 2005 05:00 am, Hylton Conacher (ZR1HPC) wrote:
I have over the last few days noticed that a particular OOo Spreadsheet(70k) and Writer(1.2Mb) document I work on daily, is opening up slower and slower. Whilst I realize that it may be because I am using an older version (1.1.0) of OOo, it does not seem to explain why it has suddenly got slower over the last week.
The box is a 1Ghz AMD with 256Mb of RAM and a 256MB swap partition.
I have not done any SuSE updates when it started going slow, nor have I done any since. I opened another terminal and top'd to see what the CPU usage was whilst opening one of them and noted that, whilst it was opening the sxc file, it had idle time of between 1.8 and 0.00 and yet the 250MB swap was being minimally used ie 4-8Mb. I normally do not have any other apps open at the same time, although as the spreadsheet helps me monitor my net usage, I might have Mozilla 1.4 open. Normally though the swap space usage increases. The file takes approx 5 minutes to load to edit and its size is as mentioned above(as per konqueror file manager).
Any ideas about why so little swap is being used when opening either of these files? Is it possible the swap partition has become corrupted and needs to be 'reinitialized'? How can I clear it out, perhaps daily and revitalize it?
Over the weekend I am going to try and update OOo via Yast to 1.1.3 as that is what I have on the 9.2 CD's? But still why suddenly get slower? Both files reside on my /home partition and the system on boot hasn't needed to fsck the partition.
Look at top again while doing the OO open and report what the line Cpu(s) says. Quite often there is a process that is soaking up a lot of system (sy) time. I also know that opening Acroread in a mozilla session can soak up the entire machine. There is a bug there somewhere because it doesn't happen when opening a PDF outside of moz. If you really want a test, reboot and do your OO open first thing. My guess is that it will go quickly but that won't tell you where the problem lies.