;-) of course you only need to reboot (maybe log off / log on is enough) if the memory goes up again more than normal ...
and remember: only a CRAY can run an endless loop in just three seconds.
196,053 users have contributed to 43,014 threads and 258,388 posts.
In the past 24 hours, we have 2 new thread(s), 18 new post(s) and 144 new user(s).
Hi cm,
Here is my feedback:
I cleaned out the DM and rebooted. Checked my Committed RAM in TM with nothing launched, its 225mb. Opened the DM, FireFox so I can type this, and the TM. Lastly I open the Windows Explorer. My Committed RAM at this point is 253mb.
Now, I drag and drop the VSL Percussion data folder of the Cube into the DM from Explorer. This folder is 51.3gb. My Committed RAM jumps to 357mb, thats 104mb. Normal?
Now, I will reboot and re-open the DM and do a scan and see what happens.
I will edit this post when I'm back up...be back in 2 minutes.
Ok, I'm back.
Launched TM, DM, and Firefox. Committed RAM is at 257mb. Only Percussion data is in DM. Clicking Rescan...Commited RAM jumps up to 358mb, pretty much the same as before.
I'll add another data folder to the DM with the Percussion already there, this time Brass II which is 39gb. Committed RAM goes up to 441mb, thats a rise of another 83mb.
Adding Orch Strings II 18.9gb, now RAM jumps to 473mb, another 32mb.
I'll finish off this drive and add the WoodWinds II which is 44.8gb, now RAM is at 546mb, a rise of 73mb.
So I started with 225mb with nothing launched. Added Percussion, Brass II, Orch Str II, and WW II to the DM. Total of 154gb of data and my Committed RAM rose to 563mb, thats rise of 338mb. That can't be normal, right?
If we minus the RAM it takes to run the DM we wind up with a Commintted RAM of 554 so its 329mb of vanished RAM.
When I close DM the RAM is not released. I have to reboot to get it all back.
One thing I did not mention is that I have previously loaded only one volume at a time into the DM and rebooted to see if one of the volumes was the problem. After checking and noticing the RAM was still jumping up is when I decided to write this.
This is driving me nuts!
Any ideas?
Like I said, the data files were copied from another computer to this one via ethernet. My other computer is a WinXP32 system that is now no longer used. I guess all my data could be corrupted from the copying but I bought the Vienna Bosendorfer recently and installed directly to this machineand I have the same problem with that as well.
All my VSL data is spread across 3 internal seagate drives and no matter which drive I use to drop data folders in the DM the RAM goes up like this.
What should I do?
I'll try anything.
David
keep in mind i only proceeded as described above to return to *normal behavior* ..
although before i uninstalled LCC, VI, VE because i assumed the problem here.
uninstall always means here a clean uninstall from control panel - add/remove software making sure no processes are running followed by a reboot.
bad RAM is no probable reason IMO, you would rather get *could not read* or *could not write* at adress 0x1234567 or something similar.
a failing harddrive (loosing and incompletely re-assigning sectors) would be a possible reason though.
christian
I hope no one forgot about me.I'm still having this vansihing RAM problem.
I installed Vista-64 thinking it would show some more info than XP64
or it would behave differently but its the same with one change.
It does the DM scan once the system has booted to the desktop!
Why in the world would it do that?
Weird thing is that if I turn virtual memory on it does it when I run
the DM but when I turn VM off then the RAM vanishes right after
bootup, within a minute.
Is there some sort of Indexing or database being built?
David
david, unfortunately i don't even understand this statement
@DM33 said:
It does the DM scan once the system has booted to the desktop!
earlier i reported that i don't like VISTA because it starts with 680 MB memory usage on a *naked* system, which goes down after some minutes to ~ 320 MB (VISTA 32 on a 2 GB machine here) - on the same machine XP32 with an unhealthy amount of applications installed starts with ~ 260 MB memory usage.
i'd assume VISTA 64 behaves similar and moves some of the memory used at startup to the virtual memory area (if activated only of course)
btw: have you already found which collection has been responsible for the excessive comit charge? here it have been the solo strings ...
christian
ps: i just noticed the ADD FOLDER in the Directory Manager is working recursive now on XP64
Hi cm,
Sorry, that statement was meant to say "Does the DM do a scan once the system has booted up to the desktop?".
On Vista64 it was doing just that but it was the Vista SuperFetch function. I disabled it and that issue went away.
Unfortunately my vanishing RAM problem has not gone away.
I have done a reinstall of WinXp64, hated Vista. I have also chk dsk'ed all my drives and tested my RAM chips for errors and found no problems, everything is fine.
For testing I rebooted the system, launched the TM and VI, and the RAM shot up just like before. It did not go up as much as before but I only
have 1 volume installed with 12 to go.
Copying Orch Str I as I write this and will install that ASAP.
Will report back to you.
BTW, I have optimized this machine as I do all my machines but this is the first time I'm using WinXP64. Do you think the optimizations have anything to do with my problem?
Here is the list of optimizations:
http://www.musicxp.net/tuning_tips.php
Let me know what you think or what I could try next.
Can you explain what SHOULD be happening in regards to RAM when I launch the VI?
How much RAM should the VI take when it launches and does a data scan for on an Extended Cube system?
Mine seems to take a GB of RAM. It did not do this on my WinXP32 system.
David
P.S. - Just finished installing the Orch Str I volume. Rebooted. Only have 2 volumes installed: Chamber Strings and Orch Str I.
On bootup Commit Charge was at 210mb, after launching VI, not VE, my Commit Charge went upto 416mb. When I close VI
it only comes back down to 370mb. Why not back to 210mb?
david, reading you mentioned optimization according to musicXP i decided to not continue because of lack of time.
however i just ha´d a look on their reworked site and found many of the tweaks i thought to remember (a series of registry hacks) have luckily disappeared.
as a sidenote: i don't understand *Turn off System Restore on all Drives* - i would rather be happy if system restore is active on my system drive, although i also switch it off on all audio drives ... anyway
we can't get the few XP64 systems we currently have available to behave as you describe, so there is nothing to investigate and report unfortunately .... the short intermezzo as mentioned above was immediately gone after removing the corrupt sample data.
if you find the time please check out the famous sysinternal tools and keep us updated if you notice something suspicious
http://www.microsoft.com/technet/sysinternals/Processesandthreadsutilities.mspx
christian
@ktnujynisis said:
Im still having the exact same issue. Mine is pretty severe. Sometimes I'll can start off with 1gb missing before I touch anything. Give me a week, I'm gonna show the screen shots. And I am using a Mac Pro
So what does that have to do with XP64?
DG
@ktnujynisis said:
same problem... different OS. Which obviously disconnects the problem to the operating systems or he OS's type.................??????????????!!!!!!!!!!!!!!!!??????????!!!!!!!!!!!!!!!!
Memory handling is so different for XP and OSX that you cannot deduce a connection I'm afraid. Mind you, you did say disconnect, thereby stating that the problem is not connected to the OS. [6]
DG
Just to let you know: I´m having the same problem on a G5 2 GHz Dual with Mac OS 10.4.1 and Vienna Ensemble. I hope the support is working on this, since adressing more Ram was one of the new features of Vienna Ensemble!@DM33 said:
I'm wondering why its only happening on so few systems.
Only a couple of people have mentioned the problem.
I would think it would be a bigger problem. It must be something
wrong with our specific systems. May RAM type or bad RAM or errors
on the hard drives.
David