Drew Wutka
DWUTKA at Marlow.com
Thu Mar 4 16:38:57 CST 2010
Jurgen, I am no expert in VMWare. I use Virtual PC and Virtual Server, both MS based systems. And for 'remote clients' that want to use a 'desktop' here, they use Remote Desktop (it used to be MS's Terminal Server), so if you are using Citrix for that, I don't have much experience there either. HOWEVER, I think I may know where your problem lies...at least the direction it's in. I think the problem is two fold. First, Access 97 used to use up CPU processing during idle time, and MS swears that went away with Access 2000, but I've seen A2k and up do that 'maxing the CPU' thing. Now, on a normal machine, it's no big deal, because Access is willing and ready to give up the processing time. But, in a virtual machine, you have to realize that your VM programs aren't getting direct processor time. Instead, they are getting 'virtual processor' time. On top of that, in a Citrix/Terminal Server setting, you are practically running a virtual machine, inside a virtual machine. So with all of those lines getting tangled, Access may not be releasing the 'virtual CPU time' as readily as it should. http://insights.oetiker.ch/linux/vmware.html That is a link to a google search about terminal services inside a VM. Try those pointers, see if that helps. Personally,.... <soap box> Virtual machines are great. It's a great way to have multiple 'computers' running without having to have hardware for each one. HOWEVER, a virtual machine is going to inherently run slower then it's host, even with just one VM running on the host. Each VM added to the host is going to divvy up the already 'limited' resources. For single purpose machines, this isn't a problem, on hefty hardware. But the key is 'single purpose'. Terminal services, by their very nature are not 'single purpose'. And even some items that may seem single purposes, are really too large and complex to truly host inside a VM. Exchange servers, DB servers, etc, all can require massive resources, so putting them on anything but a capable box by themselves can be detrimental. The real confusion lies in the lack of understanding of what many 'server' roles require. Plus there is the inherent 'coolness' of virtualization. But there has to be some common sense applied. I'd say the best rule of thumb would be to ask yourself if what you want to do would work with a server that is 5 years old. If not, it won't work well in a virtual environment, and should be put on it's own server. </soap box> ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Thursday, March 04, 2010 9:47 AM To: accessd at databaseadvisors.com Subject: [AccessD] A 2003 on VM Ware I have recently assisted our parent company head office in updating my application to work with a newly deployed environment. in the past, we had 4 separate regional servers and a number of shared application and file servers supporting 65 concurrent users. Just over a year ago we switched from an mdb backend to a straight ODBC linked Sql Server setup because of 'disk or network' errors that continued after the switch to Sql Server. It turns out there was a problem on the file server hosting the front end. The new deployment is hosted on some serious hardware with 14 virtual machines run in 2 switchable banks and a pair of test servers for trying out service packs and new software installs. A set of emergency backup servers is housed across the street in a separate buildings. Additional servers can be built and deployed by scripts in a matter of an hour and a half. There are huge permanent Cat diesel backup generators in place. We now have 5 time zones set up on the servers based on the IP of the thin clients and several of the offices are moving up to fiber optic connections to the virtual servers. The problem is that the system is slower than it has ever been. We were trouble shooting some complaints yesterday and in my thin client session on one of the machines and another users session on the same machine, an inactive instance of my frontend on those sessions was sharing 100% of the cpu between the two Access applications. I deployed an older version of the front end that predated the change in environment and things are not improving. While the older environment was occasionally overwhelmed by resource demands, the problem arises far more frequently now despite the fact that we have provided significant increases to the hardware and the load balancer does a great job of ensuring that the number of users on any one server is well below the prior spec. When Access pins the processor at 100%, every other persons session on that VM essentially freezes. Ciao Jürgen Welz Edmonton, Alberta jwelz at hotmail.com _________________________________________________________________ Live connected with Messenger on your phone http://go.microsoft.com/?linkid=9712958 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.