I've been using Sage 300 with every version of VMware vSphere esxi since around esxi version 4.0 ish. It works great!

Arch

Arch,

Thanks for the reply...

What does your infrastructure consist of, servers, switches, storage arrays. 

How is the speed of Sage in the virtual environment? 

Was hoping to gain some speed since we find Sage 300 CRE to be a bit slow on even a high end server running nothing but Sage.

Vince

The Sage 300 CRE VM also serves as a file server and the speed is fine. The server is nothing fancy (I bought it used super cheap). 
1. The host in an older Dell PowerEdge R520 with dual Intel(R) Xeon(R) CPU E5-2450 0 @ 2.10GHz processors. 
2. The data sits on DAS (direct attached storage) which is nothing but a pair of 2tb SSD in a RAID1 configuration.
3. The Sage 300 CRE VM has 25 GB of RAM and two virtual CPUs allocated to it. 
4. The switch is just 32 port switch with 1GB ports. 

Again...nothing complicated or high end.....I've used it this way for years. 

Arch

Arch C. Willingham IV
President
T.U. Parks Construction
1207 East 23rd Street
Chattanooga, TN 37408-2304
Direct dial: 423-648-3813 (use my cell if you have it…I’m never at this number)
email: [email protected]

Arch Willingham  I'm looking at doing the same thing here.  I have an R620 I have set up as a virtualization server.  

I'm currently running my sage off a standard Win10 box acting as the "server".  It's not a true server software, just Win10 Pro.  What operating system are you running inside your virtual machine?

Thank you in advance

Guy

Hi Vince, 

I virtualised by conversion of a physical box to a virtual server using VMware converter to try and improve the speed.  While everything was smooth & successful and upgraded the hardware spec of the machine to now 8 cores, 32GB memory, and 1TB SSD raid 1 I did not find the speed increase to that noticable if at all. 

It is certainly useful to have it virtualised as you can snapshot on upgrades and other normal virtual server benefits but if I had my time again which will be over the xmas holidys I would start a new virtual machine from scratch and make your self a new Sage virtual server. After some reading, a converted physical machine will never perform as well as freshly installed native virtual machine due to (in very simple terms) leftover software drivers and configurations that want to do stuff but cant any more.

I would also try to have more than a raid 1 (2 disks mirrored) setup on your disks as well as the more disks that have data accross them the quicker the machine will be able to return your data and is it safer for disk failure too.

The VM is Server 2019.

We're a Hyper-V shop, but regardless Sage CRE runs fine virtualized. We started with 9.8 in 2013, having tested in 2012, and every version since has been installed to a new server and the data migrated over. 

A clean OS install (with UEFI BIOS) is very much preferred to a P2V of an existing server. 

Hopefully you have vSphere Essentials or better, so your backup API is enabled and you can automate the backup of the entire VM. I do a local Sage backup to a separate virtual disk and then back that up as well. We use Veeam.

There are things you can do to improve performance of Sage but it is hamstrung by the legacy Pervasive database. I've hosted the server VM on SSD's since 2013, first on a RAID10 of four SSD's and since 2015 on a RAID5 of 8 SSD's. Mechanical drives should be avoided for database applications and anything that is latency sensitive.

So much of what happens on the server side is single threaded, I've moved to buying the highest clock speed Xeons I can afford (Gold in the current model lineup). Windows Server licensing favors 16 cores or less, and with two 8 core Xeons that turbo to 3.7 GHz, we've found 4 vCPU's to be as much can be used.

32GB of RAM seems to be OK as there is a "60% of RAM but don't go over 18GB in use" rule I have in my notes from going to Pervasive 12 64-bit. You'll see a lot of unused RAM, it's really frustrating.

JClayton,

I agree, we will be setting up a new Sage server as a VM on VMware as a Win Server 2019, and not converting over from an old Sage server. Also a new disk array in a Raid 10, new switches, to try and gain as much speed from Sage 300 CRE, which we have found very laggy due to the underlying technology still being used. It is difficult to get a 32bit app to perform like a 64bit app and going the VM route seems to be one of the only ways to do it.

Brian,

We will be going with vSphere Essentials Plus, and I agree that the underlying Pervasive database is the core of the speed issues with CRE as it is difficult to get 64bit performance from a 32bit app, and going the virtual route seemed to be one options to improve the performance. Thanks for your insight i will keep all of it in mind during this process.

Well, the current server side Pervasive install is 64-bit, but the engine doesn't seem to make very good use of the resources available. One performance hack support had me try was installing the 64-bit engine on our RDS server. If there was any positive impact, it was very hard to discern.

Vince,

My response won't be so much related to running Sage 300 CRE in a Virtual Environment as it is to performance in general - especially since reviewing the responses you've had so far don't seem to offer a lot of hope.

There are a number of issues that can slow the overall performance of Sage 300 CRE and I hope you have also addressed these (in order of impact):

• Size of your Log Viewer file.  Sage confirms this is an issue when it reaches 2GB (when it iterates itself), but I find it has a large impact on performance between 1.5 and 2GB.  To check the size of this file, browse to the Timberline Office folder/share on your server then to 9.5\Accounting\Global\PVData\Master_QLM and look at the size of the QLM_R1.mkd file (or see if it has already been iterated).  This file can cause slowness across the board in Sage.  It can be archived from within Sage while looking at your Log Viewer.
• Large datasets in your current/active files.  e.g. 10 years worth of payroll checks in current.prt.  The amount of historical data should vary from application to application, but I recommend archiving as much as possible where possible.  This greatly impacts performance of reports, but also impacts time to open a Task window or process tasks (e.g. Enter Invoices, Enter Direct Costs, etc.).  I've seen a report go from over 3 hours to 30 seconds after archiving 10 years of data.  I've also seen a Task window take 30-60 seconds to open, but open instantly after archiving data.
• Security tables.  This might take more discussion, but to try to simplify - if you have an Employee assigned to more than one Role, no two or more Roles should provide access to the same object (Task, Report, Inquiry, etc.).  If you have an Employee assigned to the Application Administrator Role, they should not be assigned to any other Role (with the exception of the Security Administrator Role - if applicable).  It is better to create more Roles to reduce overlap of assignments than to generalize the Roles and provide multiple assignments to the same object.
• Reports Manager organization.  The previous three items will impact overall performance while this one would initially only impact report performance/access, but if left unmanaged could corrupt all of Security.  Within each application, access your Report Manager and be sure to Arrange your reports by Sub-menu.  There is more maintenance that can be performed here, but this one item is/could be the most critical.  I've seen mismanaged Reports Managers that started as corruption in access to reports in that application get to the point, it corrupted Security in general requiring either restoring Security and Reports Manager files from a backup prior to the corruption (very difficult to determine) or creating new Security and User menu files from scratch.

I commonly find these issues in the environments I've worked in and hope this helps resolve some of your performance pains.

Todd Baker
Sage Consultant