Quote:
Originally Posted by factotum
What exactly is "standby memory"? Been using computers for years and never come across that...are you talking about a ReadyBoost cache or something?
|
Behold .
Standby memory is something new for Windows Vista and Windows 7.
Wayy back in the day, there were two kinds of memory: Used memory and free memory.
But the smart folks at Microsoft noted how much of the memory is wasted on a typical computer. If you've got 4 GB of memory but you never use more than 2GB of it, why have the chips in your computer?
So that is where the idea of standby memory comes from. Windows Vista and Windows 7 aggressively cache memory in your computer. When a program finishes with an area of memory, it doesn't go back to free memory. Instead, it goes to standby memory. Windows assumes that if you used it recently, there's a very good chance you're going to use it again in the near future. So it keeps "hot" in standby memory so that, if the program wakes up and wants a similar area of memory again, Windows can simply give it back what it was previously using instead of going through the process of reallocating memory.
In theory, this makes the process of allocating memory much faster than having to free memory and then re-allocate it from scratch.
In practice , it doesn't seem to work that way in all cases. Certain applications, such as VM ware or games or databases written for older versions of windows, do their own memory management.
Case in point
example 2 . In this case, the guys' standby memory is filled with old zip files and that standby memory is never being released, resulting in errors.
The particular system I am having the problem with is IBM's
DB2 . And yes,
database logging is fundamental to the program and to disaster recovery.
Here's the way it works: It takes time for a database to store data in the raw storage area. So in order to speed up responsiveness, whenever a transaction is completed it is written to a .log file. In its own time, the database will make the appropriate modifications to the datafile and the .log file will become unnecessary.
So the state of the database is the database state plus the log files.
In theory, this allows you to restore your database up to the exact moment a disaster occurred. You simply restore your last backup, then "roll forward" the log files from the time of the last backup to present, and presto! All data recovered, nothing lost.
This is why, when I see the end of
Star Ocean 3 (which takes place in a computer simulation), I say "Ah. The developers restored the database immediately prior to the point of Luther hitting the 'delete everything key'. This is why all the events up to that moment are preserved, but nothing before that moment is undone".
Seriously, fault-tolerant databases are constructed with disaster recovery to the second of disaster in mind in the modern world. Why would they not be in the 27th century, the time period in which that game is set?
At any rate, that is why DB2 generates lots and lots and lots of log files. It appears that Windows 7 is caching those log files in standby memory and not releasing them.
Of course, my first stop was the DB2 areas . No joy. Perhaps I'm barking up the wrong tree, or perhaps I'm one of the first people to notice this in relation to DB2.
DB2, like VMware, is essentially a virtual operating system. It performs its own memory and file management separate from the operating system and even the login permissions can be separated entirely from the OS. The root or administrator user for the computer may have no permissions whatsoever to access the database.
So it should come as no surprise that when an optimizing operating system collides with an optimizing program , errors of various kinds occur.
ETA:
there is a good tool called RAMMAP . It allows you to purge standby memory in real time. The problem is, there's no way to stop standby memory from filling up with the log files again using this tool. So it's only a bandaid, not a solution.
It is not feasible to redirect the output of the logs to /temp. In the first place, /tmp is a Linux thing, not a windows thing. There IS a temporary directory on windows but writing to it would not solve the problem for two reasons:
1) Writing a permanent database log to a temporary directory defeats the purpose of disaster recovery.
2) The mere fact of creating the file means that memory must be allocated for it, and once that memory is finished with it will be relegated to standby memory. So regardless of whether the file is written to disk or to main memory pretending to be disk (as in the case of Linux' /tmp) , the standby memory will still be filled up.
That, at any rate, is where I am. I hope this has been useful!
Respectfully,
Brian P.
RSS Feeds: 
Windows 7 standby memory question
