Configuring the Server Memory Settings for Essential

One of the most common issues with setting up Essential is getting the memory configuration of the various components configured correctly. As the complexity of the Essential meta-model and of Essential Viewer has increased then so have the memory resources required by the server to support them.

Right now, our current recommendation for a server is a multi-core processor such as an i5/i7 or Xeon equivalent and more importantly plenty of RAM. 4GB is a minimum but 8GB is more practical. You’ll struggle to use the Import Utility and Viewer together on a system with only 4GB of RAM. Assuming you’re running all the components on the same server (which is perfectly fine and can yield great performance) then here’s how we’d allocate the RAM across the main components…

  • Tomcat running Essential Viewer – 2GB RAM
  • Tomcat running Essential Import Utility – 2GB RAM
    • We’d install the Essential Import Utility on a separate instance running on different port e.g. 9080 as it improves stability and performance
    • If running both on a single instance then allocate 4GB RAM to Tomcat
  • Protege – 1.5GB RAM
  • If running a Database configuration we’ll ensure there’s about 1GB for that
  • We need some memory for the OS to run smoothly so about 1GB for that

This adds up to about 7.5GB. In reality, you’ll rarely use all that RAM simultaneously however this configuration is one we’ve used countless times with excellent performance.

So, now you’ve got plenty of RAM then how do you configure the components to use that.

First up, make sure you’re using the 64bit versions of all your components. If you’re running 32bit versions, you’ll max out a 1.5GB which will work whilst the repository is small but will cause you problems later on.


On Windows:

  1. Start Protege. Go to File->Preferences->Protege.lax
  2. Update the row for the property ‘
  3. This is set in bytes, so set this to 2048000000 for installs with the 64-bit Java environment.
  4. Click OK
  5. Restart Protege

On Mac:
If you run Protege on a Mac by double clicking an icon, you need to edit the Info.plist file that is hidden within that icon. Right click the icon (or ^-click for one button mouses) and click “show package contents”. A new finder window will come up. Double click “Contents” and then “Info.plist”. Traverse down the tree as follows: “Root” –> “Java” –> “VMOptions”. In VMOptions edit the -Xmx line to indicate the correct memory usage, e.g. 2048M. Note that this can be specified in megabytes by using the ‘M’ value.

For example, here are my settings:

Save the changes that you’ve made and restart Protege for these to take effect.

This principle also applies to the Protege server. If you have not already, update the ‘run_protege_server.bat’ / ‘’ file to increase the maximum memory JVM option as follows by setting the -Xmx parameter:

For Unix / Mac / Linux:

MAX_MEMORY=-Xmx2048M -XX:MaxPermSize=512m

On 64-bit Windows platforms (with the 64-bit Java installation):

set MAX_MEMORY=-Xmx2048M

On 32-bit JVMs on 64/32-bit Windows, there’s a limit to how much memory can be allocated:

set MAX_MEMORY=-Xmx1536M


Tomcat / Essential Viewer / Essential Import Utility

The memory settings for the Tomcat that is running the Essential Viewer should also be set to around 2GB for 64-bit Java environments.

On Windows

If you are running Tomcat as a Windows service, you can set the upper memory limit using the tomcat8w.exe program. You’ll find this either in the start menu or in the install folder of Tomcat. This will pop-up a configuration panel.

  • Select the ‘Java’ tab and then set the parameter for the Maximum memory pool to 2048
  • Click Apply
  • restart Tomcat for these settings to take effect.

On Mac

If running the Viewer Tomcat on a Mac / Linux platform, you can set these using the ‘’ file in <TOMCAT INSTALL>/bin and set the CATALINA_OPTS variable, e.g.:

export CATALINA_OPTS=”-Xms128m -Xmx2048m -XX:MaxPermSize=512m”
export JAVA_OPTS=”-Djava.awt.headless=true”

If this file doesn’t exist then simply create a new text file and save it as with these lines in it.

Again, you must restart Tomcat for these settings to take effect.


If things aren’t working as expected, then the Log files are your friends. The Protege log is in the Protege install folder under logs and is called protege_###.log. The Tomcat log is in the Tomcat install folder under logs and is called catalina.out. What you’re looking for is anything that mention “memory” or “heap”. If you’re seeing these errors then you haven’t properly configured the settings.

As always, you can post your questions on the Essential Forums at and we’ll answer as quickly as we can. Don’t forget to use the search too as there are over five years of posts and there’s a good chance your question has been answered before.

Once you’ve got these settings right, you should have many years of stability and performance from your Essential Install. If you’re still having problems though and would like some professional support then contact EAS via the Services menu for more information on how we can help.

What about OWL?

OWL is W3C standard for defining ontologies for the Semantic Web. When people find out that we’re using Protege in Essential Architecture Manager, they often ask why we haven’t used OWL. So, what about OWL?

When people find out that we’re using Protege as a part of Essential Architecture Manager, a common question is whether we will, or why we don’t currently, use OWL.

OWL is an open-standard language from W3C for describing ontologies – the Web Ontology Language. This uses RDF (another XML language for describing resources that is often used to capture the contents of a repository) to store the Protege repository – both classes and individuals (as instances are known in Protege OWL).

There’s a lot of work currently going on in the OWL space, developing standard ontologies for particular domains, producing advanced reasoners to use the ontologies and so on.

The Protege Project is heavily involved in supporting these ontology initiatives and indeed, currently Protege 4 only supports OWL ontologies. I had some concerns about this but have been assured by the Protege Team that Protege Frames is still very much part of the Protege roadmap and the continued development of Protege 3 demonstrates this.

So, why not use OWL for Essential Architecture Manager?

This is a question we asked ourselves several years ago and we took some time to understand which approach best supported our requirements. The advice on the Protege Project website was a key part of making this decision – our requirements very neatly matched the description of the Frames-based ontology.

Some seem to contend that unless you are using OWL, you are not working on an ontology. This is not the case. It’s the semantics, the types (classes) of things, the actual things and the relationships between the classes and things that are what makes an ontology.

With Essential Architecture Manager, we are not trying to create a universal or standard ontology for the Enterprise Architecture of all organisations. Rather, by using Essential Architecture Manager, you are building an ontology about your organisation. We find it helpful to think about the Essential Meta Model as a partially-populated ontology, like the trunk and branches of a tree, and by modelling your enterprise in Essential, you are adding the leaves to the tree.

In this way, everyone who uses Essential is creating a different ontology. However, they are using the same language to build or complete that ontology. The Essential Meta Model provides a Domain Specific Language for Enterprise Architecture that users of Essential are able to use to build the ontology of their enterprise architecture.

Using the same DSL means that details of these ontologies can be shared, exchanged, reasoned on, etc. using a shared set of tools and shared semantics.

It’s the instances of the ontology that are specific to each ‘enterprise’ but the classes and types – the meta model – that are ‘standard’ across all Essential deployments.

We realise that many existing users of Protege are getting great benefits from using OWL but in addition to the better ‘fit’ of Frames to our knowledge base requirements, the simplicity and ease of use of Protege Frames is very important to the Essential Project.

By supplying an extensive class hierarchy in the Essential Meta Model, users of the Essential Project are somewhat different from many typical Protege users in that they do not need to start with Class modelling. Rather, they pick up the Class hierarchy and start creating instances. The Protege Forms make this very clear and straight-forward, so users are able to get on with ‘adding the leaves’ to the ontology. There is no need to know anything about ontologies or ontology development to use and get the benefits of Essential Architecture Manager.

This also means that we can clearly and easily separate the development of the Essential Meta Model class-hierarchy from the modelling activity – creating instances of those classes. Indeed, we normally hide the Classes tab in a multi-user configuration to reinforce this separation. The main activities in using Essential are about creating and relating instances. Designing and creating new classes is something to be approached when the out-of-the-box meta model needs to be extended – not as part of the day-to-day use of Essential.

By focussing on describing the details (the Instances) of the organisation – current, planned or future – rather than on how to describe (the Classes) the organisation, the benefits of enterprise architecture can be realised very quickly. During our consulting engagements, we’ve seen clients spend months defining their own detailed meta model before getting started on using this meta model. By picking up the Essential Meta Model – and extending it where and when required – we’ve seen clients gain real benefits of EA and EA tools in the same timeframe that others are still defining their meta model.

For those who are interested in OWL and Essential, Protege provides the capability to export the Essential Architecture Manager repositories in OWL format, preserving the class-hierarchy and the properties of these classes. This export could provide a starting point for those who are interested in using the Essential Meta Model ontology as a starting point for OWL-based activities.

I’d be really interested to hear about anyone’s experience doing just this.