Has this billing app + RDP access been in production on a physical server prior to virtualization?
Is the VM OS still accessible when the app crashes?
Why do you think it's the VM?
Is it possible that windows RDP is causing this problem? I've seen similar problems happen with apps run over RDP before.
Yes, the app was run on an OLD physical server prior to the VM w/o problems, although, I'll have to verify if they used RDP or not. I'll have them try a different remote desktop solution and see how that works.
The VM most of the time is still accessible. Occasionally, it becomes unresponsive and the VM is rebooted via the console.
I'm leaning more toward it possibly being the host rather than VM itself, although, this app is god aweful and the multiple mdb files have to regularly compacted to avoid the Access 2GB limit. They currently have a developer redoing the whole thing using MSSQL and will dump Access, but that is months away at the earliest.
Can you post the VMX file for the guest?
You're right, Access can get pretty aweful. So the databases and the app are local to the guest OS? Can you also turn on a couple of performance counters on the guest for a period of time (cpu utilization/ page file swapping/ memory... )?
I'm going to setup some counter tomorrow and see what I get. They used to use LogMeIn on the old server, so I'm having them switch to that as well. I'll pop back in a couple days with more information.
You cannot expect to get everthing working in one slap - without having to tweak the host OS for VMWare. You need to tweak your VMWare. I had the same errors you had by the way.
Ok here we go:
By the way I use Ubuntu 8.10, but these tweaks could be valid for other Debian based systems.
You will have to create a ramdrive from fstab add the following in /etc/fstab
tmpfs /tmp/vmware tmpfs defaults,size=100% 0 0
and from a root shell create /tmp/vmware directory
Next: open and edit /etc/vmware/config
add the following entry:
tmpDirectory = "/tmp/vmware"
mainMem.useNamedFile = "FALSE"
MemTrimRate = 0
MemAllowAutoScaleDown = "FALSE"
prefvmx.useRecommendedLockedMemSize = "TRUE"
prefvmx.minVmMemPct = "100"
And lets restart your virtual machines, with the proper ramdrive installed:
We told VMWare Server to only use the .vmem files to the temp directory VMWare uses. That was done using mainMem.useNamedFile = "FALSE"
And to also told VMWare Server to specify the path to the temp directory, and that was done using tmpDirectory = "/tmp/vmware"
I saw imdiate improvements when I did this.
The rest of the config tweaks I mentionned was only to tell VMWare Server to lock the allocated memory for the VM to make it stay in the RAM. That's a good performance tweak.
There are other things worth doing if you are under a Debian based system:
vm.dirty_background_ratio = 5
vm.dirty_ratio = 100
net.core.wmem_max = 16777216
net.core.rmem_max = 16777216
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_rmem = 4096 262144 16777216
net.ipv4.tcp_wmem = 4096 262144 16777216
net.core.optmem_max = 524288
net.core.netdev_max_backlog = 200000
These are extra settings that I founded on the net, that have not done harm yet. Worth giving a shot too.
When reading vmware.log files, always read between the lines.
I will provide additional details onto extra config tweaks I am about to text this weekend, I'll keep u posted.
PS: the solution I explained works for my system, I only use one VM in this box..