I am running a series of tests for an implementation of a remote pager that sends page faults to other computers in a network. Long story short, I was wondering if there is an easy way to force a process to use virtual memory as oppose to physical RAM so that I can better measure the performance of my implementation against how the system would perform while swapping to the hard drive.
|
feedback
|
|
This is difficult, but what you essentially need is for a separate process to consume all of the available RAM, locking its own data into physical RAM, but leaving all of the swap available (you should be able to see the effect using the 'free' command) I think there are already tools out there to do this (I don't recall any specific examples, but there are tools to fill up memory or test memory for bit errors while the system is running... that type of thing) or something close to it. My question is ... why? Why intentionally cripple the test machine only to get number that is highly specific to your swap configuration (disk type, size, rotation rate, etc)? Also, how resource intensive is your application in the first place? If it isn't very (say a meg or two of RAM), then swapping won't hurt very badly. | |||
|
feedback
|
|
well to be clear, RAM is part of the virtual memory hierarchy it isn't possible for a process to bypass RAM...how would swapped pages re-enter the CPU cache? you can simulate something like it by having a box with ridiculously low RAM, but even then you can see from vmstat that it is still being used, and used in a nondeterministic way with regards to your test set | |||
feedback
|
|
You can limit the amount of physical RAM available to a process with
The underlying interface is | |||
|
feedback
|
|
It sounds to me like he wants to test that the pager message gets out even when the machine being monitored is bogged down with heavy swapping. This is a reasonable test case. I'd probably set up a program that allocated lots of memory and does random reads and writes throughout that memory, making sure each address is a different page. Run a few copies of this, and a few copies of a video compression job for eating up CPU cycles - that should make the machine busy. | |||
|
feedback
|