Is there such a thing as "Dedicated Cores" within a VM environment?

[christian_jone1]

Hello Community,

We're planning on migrating our MS SQL Server 2008 physical machine to MS SQL Server 2014 virtual machine.

I know the OnBase Database Reference guide is grey when it comes to how robust a database server should be as it is dependent on the number of users (200+) and how much processing is being done on a daily process. I know from my Support years, no two OnBase environments are alike (...even Prod and Test sometimes 😉

Current physical machine has 49 GB RAM and running on Intel Xeon CPU E5640 @ 2.67 GHz (2 processors = 16 cores / CPUs)

Is there such a thing as "Dedicated Cores" within a virtual machine environment?

Does anyone have any suggestions or might be able to point to already asked Community Content?

Best regards,

Christian

[Ryan_Coyne]

Hello Christian,

Thank you for using Community.  I would definitely agree that the amount of resources needed by any given database server for an OnBase system depends on the workload and processing needs of each environment, and can vary drastically between systems in the same business vertical.

As far as direct documentation regarding virtualization, the best resource that I can think of would be the Virtualization Whitepaper v3.0, available here: https://www.onbase.com/community/technical_communities/virtualization/m/resources/15513

Although this guide is dated 2014 (and OnBase 14 specifically), the information covered is still very applicable today as the concepts are more focused on virtualization at a high level than they are OnBase specific.  The guide does touch on CPU allocation strategies (“Consider Dedicating Resources”), though it does not mention any specific features or virtualization platforms by name.

From my own experience in working with VMware ESXi (primarily in a home lab environment), the closest functionality that comes to mind regarding “Dedicated Cores” would be CPU Affinity, which allows you to assign specific resources to a given VM.  Reading through the VMware documentation (Resource Management Guide, ESXi 5.1) this feature does have a few caveats, notably that the affinity settings are not guaranteed to apply if the VM is transferred to another host (e.g. VMotion).  Unfortunately, I’m not sure if there is a complementary feature for other platforms like Microsoft Hyper-V or Citrix XenServer.

Is there a particular reason that you're looking to assign dedicated cores to the SQL Server VM?  If you are concerned with pre-sizing the virtual system for CPU/RAM, I've typically found that performing baseline analysis on the existing system will help to get an idea of the resources that are being consumed on a day-to-day basis.  We commonly recommend using a tool like the Windows built-in Performance Monitor, with a SQL Server-specific template available here: https://www.onbase.com/community/technical_communities/databases/m/scripts_and_templates/17986

Upon evaluating at least a day or two worth of results from good representations of a Production business day, you should have a pretty good idea on the actual amount of resources being used by your OnBase database for a rough estimate on how to pre-size your virtualized system. 

If you have any other specific questions regarding VM sizing and/or CPU allocation, please let me know and I’d be happy to address them.

[christian_jone1]

Hi Ryan,

When I used to work for an OnBase Reseller, I was supporting an issue with a customer whose Database Server was a VM and I recall from a Hyland Support team member that I was working with at the time that they had recommended "dedicated cores" to assist with a performance issue that was being experienced. Unfortunately, I do not recall their name, or the version of OnBase at that time.

Now that I am at the customer level as an OnBase Application Analyst and we're planning to migrate from physical to virtual, I have been proactively researching to authenticate what I recall from that support call to get ahead of any potential issues with performance down the line.

I appreciate your response. We are currently, as you stated, "performing baseline analysis on the existing system..." and have reviewed / passed along the Virtualization Whitepaper v3.0.

Thank you,
Christian

[Kristin_Young]

Christian,

We have been experiencing 'performance' issues as well for quite some time....I've been working with Hyland and our reseller, ImageSoft, since September 2015 to figure out the issue. Users will be in workflow and freeze at random when clicking between queues (note we also use workview and workflow pulls in workview objects). Sometimes just one staff member freezes, sometimes all of the staff freezes at the same time. They also report slowness opening documents. We've encapsulated the freezing/slowness as 'performance' issues.

I'm curious what 'performance issue' the client you're referring to was. Any input would be super appreciated! Thanks in advance!

Kristin Young

[christian_jone1]

Hi Kristin,

I'm sorry I didn't see your reply from 4 months ago until now.

Wow, Sept 2015... that is a long time. I'm assuming that Hyland and your reseller already went through just about everything with you. We recently moved to a VM environment and that resolved some of the odd workflow queue slow downs/onbase crashing that we were experiencing. Also moved to SQL Server 2014, disabling CE.

(See www.onbase.com/.../any-known-issues-with-sql-server-2014-sp1-or-sql-server-2016-and-onbase-15-0-2-12... for more info.)

I know that it was mentioned previously elsewhere that WF Eforms may have too much work / sql query in the background that may cause performance issues.

I'm assuming that Parallelism is disabled, database stats are at 100%, and that all of your workstations are Windows 7 64-bit with at least 8 GB RAM. 8 GB may seem like a lot, but when you take into account the OS needs 2 GB, Office needs 1-2 GB, couple with all of the other programs, or multiple instances of programs being opened for a user's workstation, RAM gets used up.

You could also have some performance issues if you're not using the correct version of the Database ODBC connection from workstation to app server... if you're using the OnBase Thick Client, that is.

Then there's the network traffic at the workstation level, possibly bad NIC or router/switch or network cabling... or...

Oh! Magnets! ... While investigating an issue, checking the physical environment of the surrounding cubicles, I found a user with multiple magnets attached to metal piping (not the typical work environment here) where network cabling ran through... And there were some pretty small and powerful magnets that created an ElectroMagnetic (EM) fields which don't play well with Network Cables... once removed, this resolved a few open tickets with issues printing, workflows freezing, etc.

Never hurts to look around a user's cubicle, or adjacent cubicles, or follow where the Network cables run to/from.