When I work with MCNLive for several hours the available memory as shown in ksysguard gets less and less, even when I close all programs and windows. Eventually, ksysguard shows 1650k used and 400 or so k available (I got 2 GB). I tried clearing my temp files through the KDE settings -> privacy menu but that made no difference. What could be the reason and is there possibly something that could be odne about it? Help is much appreciated .

What version of MCNLive do you use?

I noticed a same kind of problem on VirtualCity when trying to make a remaster off of it, but I quit trying and have gone with Cherbough again.

Could you try the following and post the results. When the memory usage is high open a console and type free -m

So I am not the only one...

After 2 hours of working with various programs free -m gets this (only this Konqueror window and one Konsole was open at that stage):

total used free shared buffers cached
Mem: 2026 1283 742 0 123 959
-/+ buffers/cache: 201 1825
Swap: 0 0 0

So it seems that the cache is eating it! 1283 MB used with only two windows open is a real issue...and the system becomes much less responsive. That really affects usability. By the way, this is a remaster of several remasters.

it would be interesting to know what process is eating so much. Can you take a look at your memory use with 'top' ?

there is no proces. The real memory usage is 201 the rest of the memory is used as a buffer for writing to the hd I believe. How your pc gets so slow I don't know but wat you could try is to run a program whitch uses a lot of memory(a vmware whit 1024 mem is the most simpel way i know), see how long it takes start and how it responds. Then when you close the programe run free -m again and see if the used amount is less.

I'll give it a try. Well ,this afternoon I noticed the system getting quite slow but memory use was not dramatic, used mem at around 850K and quite a bit of free memory. But the remaster took 4 times (!!!) as long as normal. I often get this after working with MCNlive for a few hours...and I don't do anything fancy at all, not even using a virtualiser.

By default nothing is writing to the HD, it is a live system that entirely runs in RAM -
unless Adrian is running a program that is reading and writing explicitley to a mounted hard disk partition.

This is a challenge, Adrian. As Tim and davo already pointed out: your RAM usage is ok. Actually you use only 200 MB RAM out of 2 GB. That is optimal.

But why this slowing down?

Some shots in the dark:
* you have installed/added firefox, using it for several hours? With several tabs open?
Firefox is set (by default) to cache websites, 50-100 MB, look at the settings.

* You are closing applications like you do in Windows? with the (x), right top? Try to close them via the File menu.

* You have installed Open Office?

* You reconfigured the KDE desktop or some KDE settings? Esp.: have you added stuff to the systray? An applet?

* You have a remaster of a remaster of a remaster etc problem, hard to debug.

@Tim: how do you see that no proces is running?
Shouldn't he try running: top in a terminal?

Hi Kris,

Let's see:

- I have not been using Firefox but Konqueror web browser. I often delete all temp files via the KDE privacy feature. Have been using Thunderbird, Kwrite, shell, Konqueror...

- I to close applications like I do in windows. How do you close them via the file menu? You mean by right-clicking on them in the KDE task bar and choosing "close"?

- OpenOffice is not installed

- I have reconfigured KDE, not really added any applets though (when I add the CPU applet it doesn't appear when I reboot a remaster, so I gave up on that). Only added KGPG to the system tray, which boots by default. Most changes are just about looks such as background image etc.

- It is a multi-remaster. What should I watch out for to minimize the likelihood of problems cropping up in remasters? My latest remaster ISO is 511 MB in size.

-

As davo said: open a terminal, type: top
... and watch
(you come out of this process with: CTRL & c)

CPU applet? Kill this beast. Maybe it's running in the background.


Closing: just click on the File - menu in an application, --> exit

Ok.

Currently mem usage is at 1530k with 540k free, 1258k cached, but the system is fast and responsive. I ran top but I am not entirely sure what to make of it all. The last time the system was slow I used ksysguard to view processes but nothing stood out. I'll investigate this more.

Wel looking at the memory usage i concluded dat there is no program that uses a lot of memory. 200 is quite normal for mandriva.
But your right in saying that it could be a program that only uses a lot of cpu power. Because we talked about the memory i just tought there is no proces eating memory so no proces running.

This morning I used top to catch a funny process called dialog which used up lots of CPU. Whenever I killed it with ksysguard it would re-appear. Rebooting solved this and I have not had any more issues so far today. I have been using Virtualbox quite a bit but things are fine so far. I will continue to monitor the situation, it seems to be hard to nail what is going on. I know that in the past few days I opended ksysguard when the system got slow and couldn't see anything, but I will use top whenever the system slows down again.

I hope my remaster isn't a total loss...because I found that the rpms disappear from the /var/cache/urpmi/ folder once they are installed via the MCC (the partial downloads stay), so a brand new remaster means new downloads and I only got an average of 5K/s at the moment...

With 'dialog' you can create dialog boxes from shell scripts. I don't think it has to do with virtualbox.

If you remastered MCNL with newly installed software (installed by you i mean), then it should be on your remaster. What is your problem with the rpm's ?

The software will certainly be on the new remaster but if I decide to start all over again, e.g. if my remasters turn out to have issues, and I want to remaster from scratch, then if I had the downloaded rpms I could just click and install and not have to wait hours for slow downloads. That would be really nice...

just put the rpm's on a stick or cd, temporarily and copy them back to your fresh system afterwards.

In your other topic I already described how you keep the downloaded/installed rpm's. There is only one way to do this. You can't do this by using the graphical installer !!!

Steps:
1. Enable the software source 'updates' (this you can do in the MCC ...)
2. Close the MCC
3. Click up a terminal
4.
5. And now you can install software (on command line !!!), with a special switch that will keep all rpm's under /var/cache/urpmi/rpms. Example, you want to install a package with the name: abiword, you would do:

6. Before you install something you can even make a test, example:

Hi Chris,

Ok, I got it. Thanks for your patience. And it's that patience that enables newbies like me transition to Linux. Thanks again.

I think I found the culprit for slowing down the system: it is the process "dialog" and the issue comes when I experiment with my shell scripting quite a lot. So I think the problem is identified, but not solved, since the dialog process can't be killed (it immediately reappears). Well, a reboot solves it of course.

then something must be still calling the dialog. What process/script/program calls the dialog ? kill that one before trying to kill dialog.

Well, in my case all windows/opened apps were closed, and no instance of the script was (as far as I could tell) running. So how do you figure out which process called it?

Possibly the issue with the script is that it calls up itself once it is run through because I have not been able the equivalent of a "goto" command in shell scripting that would enable jumps to a prior line in the script...

Finally you are revealing that you are running your own scripts, and obviously they are the culprit.

Yes, I think we got the problem nailed down to my script! Really, my apologies if I gave you sleepless nights .

But what did get me to post here was also the high memory usage, especially the cache figures that just kept growing. But I suppose that is harmless or normal and the cache does let apps that need more memory have it?

We explained already that you don't have high memory usage .
It is 'cached' memory.

The opposite: you have a wonderful and stunning low memory usage

Azenz: what is the script about? If you want post it here, we might figure out what's wrong, and then you learn something new...

That could be nice, but it's quite long, just over 650 lines! Maybe I could email it to you? The main issue I have is that I can't find the equivalent of a "goto"-type jump command for shell scripting.

First of all: start a new topic in the applicable subforum "Documentatie en Programmeren" (even for a non-native speaker that should be clear ).

Upload the file to your webspace or whatever and put a link in the forum. Then others also can look at it.