Darren D
darren at activebilling.com.au
Tue Nov 18 18:32:58 CST 2008
Hi Team Thanks for all the replies Allocated 3 gig to the VM Session and it made a world of difference. Strangely when we reverted to 2 GIG the performance did decrease but not to the point it was at the other day. Sadly in the meantime there was a re-boot of the server with MS Updates installed in the shutdown - So I have no clue what they were or what they did (If anything) - But the increase in RAM did make a big difference Bruce and Gustav I'm told that it is a 'real' VM Server not the desktop thing. Bruce I am interested in the comments about network passthroughs - Do you have any more information? It was a business decision to go with SQL server - made above my head and before my time Many thanks Darren -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan Sent: Tuesday, 18 November 2008 11:58 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] WAY OT: Brains Trust Q - Slow SQL Server 2005 First thing I'd look at is the amount of memory you have allocated for your VM. Running SQL Server on Windows Server, you'll need at least a couple of Gigs of memory dedicated to it. On 18 Nov 2008 at 11:31, Darren D wrote: > Hi All > > Please forgive the WAY OT Post but I need access to the Brains trust and I know > a lot of you are SQL/VMWare gurus > > As this is a way OT post - feel free to respond to me off line to: darren at > activebilling dot com dot au > > Moderators feel free to tell me to take it away > > > > We have a Dell server running Linux as the OS (Running Ubuntu I think) > > On this Linux server we have a VM Session running Windows Server as the OS > > On this VM Session we have our instance of SQL Server 2005 - And it is running > like a slug. > > > > For instance - We copied a live and running SQL 2000 dB onto this SQL 2005 setup > and started running comparisons against each on a large table and the results > were awful. > > We started connecting our app to it as well and the results were even worse > (About 12 minutes to open a relatively simple screen) > > Whereas the same app connected to the live and running SQL 2000 version runs as > expected > > > > Can anyone advise if this multi layer OS/VM Setup is the likely culprit for the > go slow? > > Does anyone know of sure fire things to change and even some things to try or > gotchas? > > Also do we know of any analyser tools that we could test the Linux/VM Session > config to see if that level is the culprit before we dig into the SQL 2005 > setup? > > And anything else you can recommend > > > > Many many questions - > > > > Thanks heaps in advance team - Apologies again for the OT :-) > > > > DD > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com