Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Performance - understanding the innards! 1

Status
Not open for further replies.

beleyrs

IS-IT--Management
Nov 22, 2004
28
US
Looking for suggestions on diving in on the workings of great plains. we recently upgrade a 6.0 version to 8.0 sp2, we also upgraded and moved the server from nt4 to win2003, double the amount of ram, double the processor speed (at least), but are getting performance on par with the old system.

I'd like to understand why this might be. Performace is ok when i run processes on the sql server, but when running for a client machine with terminal services, performance is "tough" to imagine.

In both cases I have monitored the memory and cpu usage levels. I notice that SQL server is using about as much memory as it wants, and the dynamics process is usually only using 18-33MB. The CPU hums along at 30-40%.

Seems as though dynamics is lazy! Why won't it use more memory if it is available? These are fast machines, but there is a lot of saved resources on the server. Why would the CPU be screaming along? Is something limiting how much memory adn cpu the dynamics and sql processes are using? Is there a tweak that I am missing?

Thanks for any insight (which might even include showing me where i might find more information).

 
age old question.

It's been said that Dynamics is not a true sql application, yes there are stored procedure calls but a lot of the processing still happens at the local machine.

What's your network infrastructure? 10baset/100?/Gig?

upgraded a few machines to gigabit ethernet a while ago and that dramatically improved the speed of Dynamics.

Client machine ram also helps a certain amount. As does their processor.

-----------
and they wonder why they call it Great Pains!

jaz
 
We have the same issues when running Great Plains on our citrix servers. If you run the same processes on a regular workstation, the processes seem to run much faster (especially with project accounting where citrix takes over 5 minutes to complete one transaction and workstation under a minute). I found through support that GP does a LOT of its processing using local temp files as well, instead of sending the request to the server via sp. I also found many of the sp's setup in Great Plains to be poorly optimized in a client/server environment.

Our citrix servers are all setup with a 1Gb ethernet to our Extremely powerful Win 2003 cluster server. Didn't help much with the performance.
 
We also have 1GB ethernet too. Its funny you mention teh temp file, which means lots of disk I/O right?

We are running our client machine on VMWare, so i imagine that will add some overhead. Whenever we have an issue, VM is always blamed by our consults...but nothing has proven a real issue because of VM yet.

this may be the one. vm is managing file systems for itself, and for the vm's on the machine. doubling overhead on each one...
 
I did find that when a 5400rpm drive died in one of my workstations and I replaced it with a 7200, it was noticeably faster in transaction processing.

-----------
and they wonder why they call it Great Pains!

jaz
 
Bumping this post.

Wondering if anyone else out there has had any more experience with running on VM? SQL server on VM and terminal server client on VM.

 
For what it's worth, I don't think Microsoft will support GP running on VMWare. they won't even support it on Virtual PC, which is a Microsoft product. Some other things that we have seen cause issues with GP in the past, not in any particular order:

- Poor network wiring/equipment
- Security related issues: check event logs for Group Policy and other security related errors
- Size of the paging file
- ODBC connection setup: make sure to follow the manual on this, it needs to be a system DSN and have all the check boxes unchecked

We usually run our development and testing machines on Virtual PC (and recently on Virtual Server which is MUCH faster) and have not had any operational issues on it, but it is noticeably slower than doing it on a non-virtual machine.
 
This last post worries me. We are currently running GP 7.5 on 4 citrix blade servers, but are planning on moving to VMWare (still running citrix) to better manage the citrix farm.

Can anyone confirm whether GP will be supported on VMWare? This could put us up the proverbial creek without a MS Paddle (c).
 
Your last post confuses me!! :)

I thought that VMWare was a remote access technology. If you have a Citrix server there is no need to have a second remote access technology as you can just connect with an ICA client. I don't see why you would need both.

That said VMWare is not supported with Great Plains. Please see the page below:


Point 6 in the additional notes states:

"Microsoft Business Solutions-Great Plains has not been tested with VMWare, Virtual Server or any virtual machine technology; therefore, Microsoft Business Solutions-Great Plains is not supported in any virtual machine environment"

Note that use of Terminal Server or Citrix is tested and supported, and discussed in the page below:


David Musgrave [MSFT]
Senior Development Consultant
Escalation Engineer
MBS Support - Asia Pacific

Microsoft Business Solutions

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.
 
VMWare allows you to run multiple virtual machines simultaneously on a single box. VM Ware would be running on a Linux platform, but we could publish desktops with all 10 major versions of Windows (3.1-2003 Server including variants) as well as a linux desktop just for fun. If the Win98 instance blue screens, the rest just keep on humming along and the Win98 instance 'reboots'.

We are looking at it to make our citrix farm into a larger number of 'servers' with fewer users on each, so if one bails, 5 users go down, not 35 like now. If an instance gets corrupted, you copy a good instance (a single large file to be exact) and republish it within 10 minutes.

It's very cool, but if it is not supported we would be out of luck, support wise.
 
we have vmware gsx servers but i deployed it on our web servers since Microsoft said they won't support GP in virtual environment.

back to the topic, what i did was create a template for minimum requirements on workstations that would use GP in citrix(4.2) then compare them to specs from Track-IT. Any PC that goes below the min. req. was upgraded.

we tested 2 workstations(P4,512mb vs P3,128mb) then process Manufacturing Order Receipts. The 512mb took about 30-40 seconds including posting inventory & GL entries while the 128mb tooks 3-4 minutes. Our BOM have around 25-35 components.

this just proves that a lot of issues with performance can be resolve by looking at workstations.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top