[bokeron2008]

I'm using an MSDN ISO of Vista x86, Spanish. I try every build using Virtual PC, giving the virtual computer an amount of 1gb of RAM.
I have a problem, don't know if it's related to Vista itself or to Vlite.

When lookin at the task manager info, a clean install of Vista Ultimate uses around 24-25% of RAM, about 260 mb. It also indicates a cached memory of around 450-500 mb and 450 free. 28-29 processes and about 370 subprocesses.

When I install ANY update, the memory usage goes up by quite a margin. Free (not cached) memory drops to something like 360-280 mb (or even, a couple of times, 2-7 mb) . Number of processes go from 28 to 32-34, and even kernel memory goes up by 5-10 mb.

I've tried every combination I've could think of when "vliting", I've tried installing different updates, one each time, and some of them affect the system more than others, but the end result is the same.


I don't know what's going on, or if this is happening to anyone else. Could you please help me ?

[TranceEnergy]

Sounds pretty normal to me.

[bokeron2008]

That's what I'm not sure. In everyone experience, is this normal ?

I was of the impression that "updates" or security updates at least, modified files or "behaviours", but not to the point of causing a 150 mb increase in memory usage because of it.

At least, when I was using XP, it was not the case. A few K's at most, because of new processes running, or files that got increased in size... but not this.

[arjuna07]

I'm sorry if i dont 100% understand you.

If you do talk about such a decreases of memory during the update(+/- 5minutes), absolutly normal.
If you do talk about such a decreases of memory way after the update, it is uncommen to me.

[bokeron2008]

I mean way after the update. Like rebooting, leaving the virtual PC idle for 20 minutes, rebooting again, and leaving it idle again for 10-15 minutes.

[bokeron2008]

Last example from a recent test.

I have only installed 1 update, KB938371. Available memory went down from 450mb to 389mb.

And, as I said before, this is after two reboots and 20 minutes idle after the first one, and another 20 minutes idle after the second.

So, please, can't anyone comment on the issue ? Is this the normal behaviour ? What can I do if not ?

[cluberti]

You said "number of processes goes up from 28 to 32 - 34" - what processes started? Perhaps a process explorer (sysinternals tool) monitoring the system when you install the update will give some clues as to what's firing up and not going away?

[bokeron2008]

That's what I'm trying to find right now, but PE output is difficult to understand for me.

What I can say right now is that, even when the procesess stay at 32, "used memory" increase again when I install a few updates more, and "non cached" memory decrease too.

I'll try to collect more data, but in the meanwhile, if someone has any experience like mine, or contrary to mine, I'd like to know. So far I have only two answers, one say is normal, one say it's not...


P.S. I have a question related to Process Explorer / Task Manager. In Task Manager, the available memory is 0 of 1023 mb. 864 cached. But, in Process Explorer, it shows 778mb of 1023, 850 cached.
Why this diference, 0 vs 778mb of free memory?

(In this test, the cached memory before updates was 480 in PE. Went up to 850 after installing 21 updates. Free memory went from 450 in task manager to 0 - but remained at 760 approx in Process Explorer. Number of processes remained at 33 after updates. All of this, again, after two reboots and 20 minutes idle)

This post has been edited by bokeron2008: 14 August 2008 - 08:14 PM

[bokeron2008]

Ok. I've been testing some things again, and the main problem seems to be that, even when the number of processes remain stable, the cache increase or even double, depending on the number of updates installed.

I can not find wich process is responsible, as they seem to use about the same memory after the updates.

In Process Explorer, the available memory remains quite the same, but Vista Task Manager shows less available memory, or even NO available memory.

Any comment on your own experience about Vista cache , or about this different readings given by PE / Task Manager ?

[cluberti]

Sounds like a visit to perfmon is in order - under Performance Monitor (start > perfmon > Performance Monitor), under the "Process" object, add "private bytes", "virtual bytes", and "working set" counters for the "<All Instances>" process listing. Then, you can see which memory objects go up or down, and in which process.

[bokeron2008]

I've done new tests using perfmon. Checked private & virtual bytes, working set, subprocesses, etc, for 20 minutes after boot up.


1st test : Clean install, no updates apart from those that come pre-integrated, sp1 included.
2nd test : The same install, after installing updates available thru Microsoft Update, letting the virtual machine idle for 20 minutes, and rebooting again.

Result : There are some processes that use more memory or a few more processes. But there are some more processes that use less memory or less processes.
When considering the "total" results from each indicator (private & virtual bytes, working set and subprocesses), ALL of them are lower on the 2nd test... wich contradicts the almost double cache size increase and almost zero available memory reported by Task Manager on the 2nd test.

What can this mean ? What more can I check ?

[cluberti]

Is this a machine with a NUMA architecture, by chance?

[bokeron2008]

No, it's just a single Intel core-quad, and the perfmon tests were run on a virtual pc running on top of it, as I've experienced the same issues on the 'real' machine and I was trying to solve the problem before re-installing.

[cluberti]

Honestly that doesn't make sense. The only other way to really see it would be to take a complete memory dump of the box and see where the memory has been allocated.

[bokeron2008]

Disabling Superfetch frees A LOT of memory. I suppose it is something to be expected, but is there a way to know what is superfectch doing or waht is it caching ?

[TranceEnergy]

bokeron2008, on Aug 22 2008, 11:13 PM, said:

Disabling Superfetch frees A LOT of memory. I suppose it is something to be expected, but is there a way to know what is superfectch doing or waht is it caching ?

Yes use the resource manager, umh task manager, and you can see what resources/files are being loaded and what process is doing it.

about KB938371, as i recall from my exp with vista thats the update that allows better compability with future service packs & updates. It will most likely trigger an event of backup files etc Perfectly normal.

As you may or may not know, winsxs sidebyside assembly has exploded in activity with vista which is one of the reasons why it demands so much more storage space.
Last time i had vista installed it took a whooping 25-30gb with many programs installed, usually about 10gb just after installing adobe programs, this was on x64 as well.

Personally, i'd integrate that KB938371,latest version of it, before slipstreaming servicepack 1 on vista. Then the old version of KB938371 wont be integrated,installed since the newer version takes priority.
I did this and it worked for me, saved small space on iso as well.

This post has been edited by TranceEnergy: 22 August 2008 - 03:21 PM

[bokeron2008]

Hm, I've been wondering about that, too. Right now I'm doing all this tests using an MSDN version of vista that comes with the KB938371 pre-integrated. And vista, after install, asks me to install the - I suppose - new version of this KB.

But... can I integrate the new KB938371 on my ISO, even if I use the MSDN version with preintegrated sp1+ KB938371 ?

[TranceEnergy]

bokeron2008: Vista Sp1 contains the old version of that KB. By integrating the KB before you slipstream SP1, that SP1 version of the KB isnt installed in the first place, since you already integrated the latest version of the KB before SP1. At least this was my experience.

[bokeron2008]

But what if my iso comes with sp1 AND KB938371 (I suppose is the old version) PRE INTEGRATED, can I integrate, again in this iso, KB938371 ?