jwcolby
jwcolby at colbyconsulting.com
Thu Mar 4 19:33:57 CST 2010
Jurgen, I think Drew might be right in that Access is supposed to sense "other applications" wanting the processor and releasing the cycles. If Access is all that is running inside of that VM, then it never senses "other applications" wanting the cycles because those other applications are isolated by the walls of the VM. Thus the VM ends up requesting real cpu cycles to service the Access FE and essentially tying up an entire core per FE. As for whether Access still does this anymore, I have not seen it continuously do this, however I have seen it do this for a "long period" where long period is 30 seconds or more, and then eventually stop. I have three virtual machines running on a quad core "server". I quote the server simply because it is just a reasonably powerful quad core AMD, NOT a true SERVER machine. After much research I discovered that VMs are not all they appear. For example the recommendation is NEVER give a single VM multiple "CPUs" even though it is possible to do so. Likewise the recommendation is to always leave a core not assigned to a VM, iow if it is a quad core machine, only run three VMs and leave the fourth core to run the VMWare host software (and Windows of course). I have a third party application which is written in Foxpro for Windows. It runs well in the VM however... it eventually locks up the VM. No idea why, but if I allow it to do its processing for 24 or 48 hours it will eventually lock up the VM. The VM responds, but "responds" as in 2 minutes to respond to a mouse click and so forth. Once this happens, it is damned difficult and sometimes impossible to regain control of the VM. I end up just "removing power" to the VM (the equivalent of hitting the power button). I have seen it do something to the VMWare host software such that a reboot of the actual server was required to get the VMs working again. SOMETIMES I can simply close VMWare and restart it, sometimes that doesn't work and a reboot of the physical machine is required. All of this happens with an application other than Access, so that indicates that application software running in a VM is quite capable of bringing the entire server to its knees. In my mind that should not be possible and VMWare needs to figure this out and fix it from their side. So far they have not, and there are complaints about this on their forums. I have just fired up my server and will do a little testing. I do not have office installed on the VMs but I will install Office 2003, and then get a simple FE running talking to a BE up on the VMWare server machine. I will then be able to tell you if I see anything like what you are seeing. I suspect that I will not however. John W. Colby www.ColbyConsulting.com Drew Wutka wrote: > 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