Has anyone experience initial GP client launch slowdown on Windows Server 2012 ?

(0) Share

Report

Posted on by Beat Bucher GP Gee...

28,058 Moderator

Hi everyone,

We're running GP2013R2 since last November 2015 on Windows 2012 Servers (6.2.9200). The main GP server only holds the databases (SQL 2012 11.0.5058). I also have a Windows Terminal Server RDS that runs on Win2012 too, as well as GP test servers (both 2012 systems) that run respectively a clone of my prod 2013R2 and a Test bed for 2015R2.

All the servers have plenty of RAM & CPU, and all the systems are VM's hosted on VMWare ESX 5.5.0. I still do have also my two older GP2010R2 servers (1 Test & 1 Prod) that are waiting to be decommissioned, but still run some older web apps on it. My old GP servers are Windows 2008R2 systems and I never had any performance issues with them.

Recently I started to get complains from users that GP is very slow in the morning when the login the first time.. Couldn't really a faulty apps or culprit, since most of the users are running GP 2013R2 off the TS/RDS server, Today it was particularly acute and myself experienced over 5 minutes login time to get into GP.. whereas if I ran my local GP client, I was able to start working within less then a minute..

I checked my process monitor on the GP 2013R2 server, but there was nothing noticeable.. Nor was there any special resource hogger on the RDS server. That led me to some testing I decided to run on all my GP servers, prod & test, since I had myself realized a few times in the recent past that my GP client startup was taking unusually long on the server itself.

Now I hope you're sitting well ? I've timed the initial launch of my GP2013R2 client at 15min 32 secs on my Test bed server (which means no one is connected nor is the SQL server in any ways solicited). For the GP2015R2 client, it was 11 min and 47 secs.. I ran the same test on my production system and it took almost 13 minutes to start the GP client from there... Houston we have a problem !!!

Hold you breath : after closing all of those GP clients, the 2nd & 3rd launch attempt all finished within under one minute (the fastest was ready in 34 secs, and we have a total of 28 modules loaded in the DYNAMICS.SET file.. This is the kind of startup time that I expect from a GP client (less then a minute) and able to achieve constantly on my local client (more or less, depending on the current network load). On the server there is no network latency, so this should be as fast as it could, but clearly there is a problem.

Now my suspicion turns towards some Windows patches & updates that have massively been pushed down to the server in February by our IT Department.. I recall very clearly that when those system were setup last year, I never had such problems..

This is were I'm asking the community if someone else has come across a similar story where the GP client takes extremely long to start the first time in the day.. I need to do more testing with my systems, and I'm even going to ask IT to setup a new Windows 2012 VM from scratch an replay the scenario by starting with the initial upgrade of GP and then monitor the system after patches get applied from Windows Update, with the option of rolling back the snapshots. I have the feeling that since GP relies on .NET 4.x and C++ libraries, that some of them got updated and are now causing an issue.

Thanks in advance for all your comments and hints.

*This post is locked for comments

I have the same question (0)

All responses (18)

Answers (2)

Richard Wheeler 75,848 Moderator on at

Like (0)

Report

Beat, I occassionally have seen issue like this for years with GP. When I do I check the version of the ODBC SQL drivers. Sometimes I have found using an older version work better than a newer version. I am currently using the SQL Server Native Client 10.0 for GP 2013 R2 with no issues. I would compare what you see on machines that are working properly versus those that are not.

Was this reply helpful? Yes No
EaglesForLife15 on at

Like (0)

Report

We are experiencing slow downs in the afternoon, not at launch. It is around the same time every day and ALL users experience frozen screens where nothing happens.

Initially it was a couple of minutes, max. Now, the freezes last as much as 10-15 minutes.

We have a VAR monitoring this for us (we're cloud hosted), but they cannot find anything at this point and it's been over a month.

Was this reply helpful? Yes No
Richard Wheeler 75,848 Moderator on at

Like (0)

Report

Is this a public or private cloud? I would ask your cloud provider if other companies are experiencing this sluggishness at the same time. Usually disk I/O is the issue and/or lack of RAM or CPU. You will most likely find the source is due to hardware insufficiencies but you must find isolate the cause. If that does not resolve the issue it would be best to bring in a SQL guru and perform SQL monitoring which will lead to SQL performance tuning.

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Thanks Richard,

I'm going to check the sql client version tomorrow.. My IT department has built a new VM with the same OS and I'm going to install the same Sql and GP release.

Was this reply helpful? Yes No
EaglesForLife15 on at

Like (0)

Report

We have private cloud. We moved from Citrix to RDS server a few months ago. We went from drops to freezes.

Was this reply helpful? Yes No
Richard Wheeler 75,848 Moderator on at

Like (0)

Report

Do you know the specifications of that servers? What types drives and how are they configured? If you watch the performance monitor is the CPU maxed out?

Was this reply helpful? Yes No
Tim Wappat 5,711 on at

Like (1)

Report

Beat,

Although not everything you describe ties in with the cause I posted about, it might be worth excluding it as a possibility. See my post here: http://www.timwappat.info/post/2009/03/13/Dynamics-GP-slow-to-open-forms-other-users-ok

This was slowing down login, and also launching individual forms. The morning factor was for us on this issue was the contention for disk I/O and memory caused by multiple users all trying to login around similar time and then trying to all parse these files from disk.

If your test is a clone of production then you will have brought over the index files from production, so the problem should show there too. Although obviously it doesn't logically explain all the combinations of symptoms you describe between the environments.

Give it a try and report back.

Tim.

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Thanks Richard for this tip... Checked all my ODBC connexions and they are based on the SQL Native Client 10.0..

long shot :-)

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Nope, the CPU is not maxed out at all, and that's what is really strange... neither on the GP SQL server, nor on the TS/RDP server are the resource much used... neither CPU, disk I/O or RAM.. of course on VM systems, this may not say a lot.

But I've monitored the underlying VMWare hosts, and aside a some CPU / RAM spikes, can't really say it's terribly busy.

The VMWare host that manages my RDS & GP server is also host of a dozen other VM's.. and they are not even hosted on the same ESX server.. Average our ESX servers are hosting 12-15 VM's, have 12 physical CPU's (makes 24 logical ones) and 148GB or RAM.. Disk storage is spread across traditional SAN disks (of 1 or 2TB) for a total of 75TB.

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Thank you Tim for chiming in..

I've checked the post from Ian, and no I don't think it applies in my case... otherwise if the auto-completion cache would be the root cause, I'd always have problems, but this doens't seems to be the case.

Just launched my GP 2015R2 client on my TEST system, nothing else running, fully alone, and it took over 8,5 minutes to get into GP... 2nd run took 35 secs... absolutely puzzling..

Was this reply helpful? Yes No