Emerson Exchange 365

• Not Answered

Objectivity performance limitations

Hello Everyone,

 

We have quite a large database (daily export size about 900 MB). It is a new project, running v12.3.1, Dell R720 servers on 64-bit Windows. 

Configuration is class-based and when modifying certain classes, saving can take up to 10-15 minutes. I found that during big module saves the Free physical memory goes down to zero, all available RAM being listed under "cached" (see lower left corner of screenshot). To me, this would mean that Objectivity is able to make use of the 16 GB RAM we have.

However, only one CPU core is being used.

I think if Objectivity would have multi-core support, projects could benefit from faster database updates (saving time and money).

Am I correct in these assumptions?

Are there any plans to improve on this? E.g. I found (running ootidy from command prompt) that we are running Objectivity 6.1.0 while the current version is 11.2.4 (probably having multi-core support). Or is there anything we can do to improve? A workaround we are implementing is to set up a separate system for class modifications, having only the Library, no areas or controllers. Classes can then be modified faster, and we import multiple classes in one go to the live system overnight.

Istvan

• Objectivity
• x64

István Orbán

• 20 Jan 2015 1:01 AM
• Cancel

9 Replies

• AdrianOffield

  

  • 20 Jan 2015 3:38 AM

  I was pushing for this back in 2004 during a mega-project for Aramco, so given the 10 years timeframe and the fact we are still using iFix for graphics I would say that nothing will happen in backend performance any time soon.
  
  There is some reference to an attempt to improve performance in this blog http://www.emersonprocessxperts.com/2011/12/super-server-for-large-mining-automation-project/
  
  Finger crossed!

  • Cancel
• István Orbán

  

  • 20 Jan 2015 4:56 AM

  In reply to AdrianOffield:

  To be honest, 64-bit support already brought a big performance improvement. Daily export takes about 12 minutes and the extended clean 15 minutes, which is great speed for a database of this size.
  Also, we are using VCAT which is additional load.
  We are actually in the process of adding more RAM to the proplus, resulting in 32 GB, we'll see whether it improves performance.
  It is still annoying to see that one core is on 100% utilization and the others just resting, makes me wonder how fast it could be if Objectivity could use all available resources.

  • Cancel
• AdrianOffield

  

  • 20 Jan 2015 5:28 AM

  In reply to István Orbán:

  How does "User Defined" exports work now in 64bit, the biggest issue I have on 32bit is hitting the 3GB memory limit during the export and crashing the export requiring large custom exports to be broken down into chunks, very annoying. Have you noticed how large the memory creeps, can it exceed 3GB now on 64bit?
  
  Typically a single threaded app will still be confined to 32bit addressing, just because it hasn't been optimized to run on a 64bit platform.

  • Cancel
• István Orbán

  

  • 20 Jan 2015 5:40 AM

  In reply to AdrianOffield:

  For user-defined exports, you might want to check KBA AK-1400-0008. There is a special format file for exporting modules to avoid hitting this limit.
  The largest bulk export I recently did was 6000 lines of Profibus signals (using default DeltaV format file), that went without issues. I do remember having to split the control modules in two files (we have around 8000).

  • Cancel
• AdrianOffield

  

  • 20 Jan 2015 6:20 AM

  In reply to István Orbán:

  Thanks, so it is still an issue in 12.3.1 so that answers my question, DeltaV is still confined to 32bit memory even though it runs on 64bit OS. That's unfortunate, so it looks like we'll be stuck with these constraints for a long time to come :(

  • Cancel
• Steve Priest

  

  • 20 Jan 2015 10:23 AM

  In reply to AdrianOffield:

  Still using the "super server". It has all solid state drives in a RAID array for fast reads. Objectivity spends 95% of that wait time reading files and checking references. Solid state drives are fastest at reads so they make a step change in productivity using the Professional Plus. Still running as 32 bit application and single threaded. We cut the number of CPU's down and moved the memory fences around inside Windows. Not sure that is needed with a base 64 bit windows system. Version 12 counts DST's differently but we have around 6100 DST's with a lot of SCADA data from PLC's etc. Professional plus still works for us with up to 10 users.

  • Cancel
• AdrianOffield

  

  • 21 Jan 2015 8:45 AM

  In reply to Steve Priest:

  Great to hear it's still going, enterprise grade SSD I take it! Any drive replacements since? I'm surprised Emerson never offered this as an option.
  
  If you don't mind, how did you cut the number of CPU's down, do you mean you transitioned to a single socket server or disabled cores in the BIOS?

  • Cancel
• István Orbán

  

  • 26 Jan 2015 4:39 AM

  In reply to István Orbán:

  We upgraded the RAM of the proplus from 16 to 32 GB now, and it looks like it cut the time required for the daily export to less than half. I hope its effect will also be seen during class updates which take a very long time now.

  • Cancel
• Steve Priest

  

  • 3 Feb 2015 9:56 AM

  In reply to István Orbán:

  The Super server is now out of warranty so 3 years old running all SSD drives. No failures to date, that was a concern going in but DeltaV objectivity is mostly reads not writes so the drives are still going strong. We will bring a spare to site just on spec as they are over three years old on a large system. Still happy as class saves went from hours to minutes using the SSD drives.

  • Cancel