Deployment Solution

We have recently upgraded to DS 6.9 .

At the same time, we put server on VMware ESXi and new hardware, both to improve performance and stability.

At our larger sites ( approx. 4000 workstations), we are continuing to have issues with performance and server crashes.  It appears to be a memory issue as we are running windows server standard with sql-server 2008 and can only access 4gb of real memory.

We are going to move the sql-server onto it's own windows server standard, expecting that the 1.5 gb's or so of memory used by DS 6.9 will benefit server stability.

Does anyone have experience or recommendations on scalability based on real world experience with approx. 4000 windows clients running against one DS 6.9 server?

As a secondary question, does running up the DS console, tools, options resource refresh rate from the default of 30 seconds to something large, ie 180, ease performance burden on the server?

thanks,

Parham

I know DS CAN scale up to 5K users, but we don't recommend above 2500 per server.  That alone will help.

And having SQL off-box might help, but not 100% positive.  Can't hurt though.  :D

Virtuals are wonderful little toys, but have the disadvantage of sharing resources.  Be careful.

We currently run DS 6.9 here with about 4500 computers on the server now.Database is a seperate sql 2005 server.

No slowdowns or loss in performance that I have noticed.

I am also curious about converting to a VM to see how it runs. I suspect it would be just fine provided the hardware you are running on is good enough and what kind of load other VMs on the server would demand.

I may try it in the next couple of weeks here and will let you know the results if no one else responds.

Thanks for the reply.

What's your hardware like?  Be happy to put you with one of our systems guys to talk about the vmware performance.

We particularly have problems when scheduling to several hundred or thousand computers, even when running them in space out batches.

We also run a weekly forced log off on Friday so that any WSUS approved updates can apply that won't when a user is logged in.  Similarly we run a weekly forced reboot early Monday so that any windows apps that need that to finish installation do.  Do you do any of that kind of thing?

Off the cuff sounds like you're pushing DS6.9 to its limit with 4000 clients in a virtual environment. I split off a similar setup into separate DS boxes to improve performance some time back. Performance monitor is your friend on seeing what resources your system is struggling for.

If you want to get the best performance and need to stick to a single virtualised DS, I'd try

1. Moving SQL to a 64-bit SQL Server Box (for the extra processing speed boost)
2. Ensure SQL backup and maintenance plans are in place (can make a staggering difference)
3. Ensure the SQL Server data drive is on a LUN which isn't going to be highly contended
4. Give yourself at least a dual-processor DS. Consider reserving CPU's exclusively if CPU still an issue.

Generally, when you're at the edge like this I'd probably strongly consider a physical setup to prevent resource contention as this is often where the problem lies.

Kind Regards,
Ian./ 

Hey P-Squared

I actually do have some take on this "problem" your experiencing, as thomas said the DS can handle those kind of clients, but the setup needs to be taken into considerations for this to work properly.

I have an examble on a customer who had about the same amount of clients and every day they had jobs running on all clients which did some maintenance on all of their clients. (the clients where running Steadystate, therefore they needed to do maintenance outside of work hours).
Their setup to start with was, bot DS and SQL where running virtualized, but they where struggling with their jobs couldn't finish in timely fashion.
We therefore installed a physical SQL server with 16 GB ram, and 8 disks which where setup in mirrored RAID in pair, 4 volumes:

1 for system
2 for tempdb (one per physical CPU)
3 for DB
4 for logs

By doing this "only" we did cut down the time for executing all of these jobs by 2 hours, which was acceptable by this customer, i would think that making a physical DS also would cut down some time since the "problem" you mostly experience in a vurtualized environment is I/O.

I in general say that when you have more than 3000 clients i would not make my implementation in a virtualized environment, and i would make my SQL server off-box.
This is based on earlier experiences in larger environments.

Just my 2 cents.

Kind Regards
Morten Leth

Our sql and ds/ns are their own physical boxes but the DS box is also shared with our NS which serves 10K clients. The SQL box houses the databases for the NS/DS and our DEV NS/DS. The DS its self has about 2500. We actually just have a scheduled task to restart the express engine every night. We always had issues with ds services needing to be restarted even on many of our smaller sites only hosting 150-200 clients. So we just got to the point we have scheduled DS reboots during the night once a week except at the main site which we just restart the DS services everynight. We have found it a lot more reliable that way. I would also agree I think 4000 is pushing a VMs limits especially if there are other vms using a  lot of resources, but moving the sql off would prob make the biggest difference but there is obviously a good bit of resources doing that. I mean realistically if the box is only running DS it might be hard to justify have a whole separate box to host a couple hundred MB database.