Hyland Connect

resplin · ‎06-05-2015

The official documentation is at: http://docs.alfresco.com

Configuration Performance
Back to Server Configuration

The official documentation on this topic is here: http://docs.alfresco.com/4.1/topic/com.alfresco.enterprise.doc/concepts/jvm-tuning.html

Introduction

The Alfresco Repository and web-client hardware requirements are variable and depend significantly on the number of concurrent users that will be accessing the system. You should tune the memory and garbage collection parameters for the JVM as appropriate for your use-case. The metrics and estimates below are only a suggestion and your system may vary .

Hardware

Alfresco degrades gracefully on low powered hardware, and small installations can run well on any modern server. However, to get optimum performance, we recommend the following:

Avoid 32 bit systems. Our benchmarks show a significant performance gain when using 64 bit hardware and a 64 bit JRE.
Use a system with a clock speed above 2.5 GHz.
Reserve enough RAM for your operating system beyond the memory required for your JVM.
Keep search indexes on your local disk instead of on network storage.

Disk Space Usage

The size of your Alfresco repository defines how much disk space you will need and is a very simple calculation. Content in Alfresco is by default stored directly on disk, therefore to hold 1000 documents of 1MB in size will require 1000MB of disk space. You should also make sure there is sufficient space overhead for temporary files and versions - each version of a file (whether in DM or WCM) is stored on disk as a separate copy of that file, so make sure you allow for that in your disk size calculations (and, for DM, use versioning judiciously).

It is highly recommended that a server class machine with SCSI RAID disk array is used. The performance of reading/writing content is almost solely dependent on the speed of your network and the speed of your disk array. The overhead of the Alfresco server itself for reading content is very low as content is streamed directly from the disks to the output stream. The overhead of writing content is also low but depending on the indexing options (e.g. atomic or background indexing) there may be some additional overhead as the content is indexed or meta-data extracted from the content in each file.

Virtualization

Alfresco runs well when virtualized, but you should expect a reduction in performance. When using the rough sizing requirements below, it might be necessary to allocate twice as many resources for a given number of users when those resources are virtual. Para-virtualization, or virtualized accesses to native host volumes will not require as many resources. Benchmarking your environment is necessary to get a precise understanding of what resources will be required.

JVM Memory and CPU Hardware for multiple users

The Repository L2 Cache plus initial VM overhead plus basic Alfresco system memory is setup with a default installation to require a maximum of approximately 1024MB. This means you can run the Alfresco repository and web-client with many users accessing the system with a basic single CPU server and only 1024MB of memory assigned to the Alfresco JVM. However - you will need to add additional memory as your user base grows. You will need to add CPUs depending on the complexity of the tasks you expect your users to perform and how many concurrent users are accessing the client.

Note that for these metrics, N concurrent users is considered equivalent to 10xN casual users that the server could support.

Suggested memory+CPU settings per server:

For 50 concurrent or up to 500 casual users:

1,5 GB JVM RAM

2x server CPU (or 1xDual-core)

For 100 concurrent users or up to 1000 casual users:

1,5 GB JVM RAM

4x server CPU (or 2xDual-core)

For 200 concurrent users or up to 2000 casual users:

2,5 GB JVM RAM

8x server CPU (or 4xDual-core)

For the tests providing these metrics, a Dell Poweredge Server 2600 dual Xeon CPU 32bit machine was used:

2x Intel Xeon 2.8GHz (533Mhz FSB, single-core)

3GB RAM

3x 36GB Ultra320 SCSI Raid 0

Alfresco Enterprise 2.1 and MySQL 5 on Windows 2000 with Tomcat was deployed onto the server. Approximately 100,000 documents and 1000 user instances were imported into the system (Note that over 5 million documents have been successfully loaded into a similarly configured Alfresco repository).

Similar tests were performed on an equivalently configured Linux box running Fedora core 4 (also Suse and Ubuntu have been tested).

Recently tests have been run using Alfresco Enterprise 1.3 and MySQL 5 on Windows Server 2003 with TomCat on a dual CPU, Opteron Server machine:

2x AMD Operaton 285 2.6GHz (dual-core)

4GB RAM

3x 36GB Ultra320 SCSI Raid 0

Concurrent users are considered to be users constantly accessing the system through the Alfresco web-client with only a small pause between requests (3-10 seconds maximum) - with continuous access 24/7. Casual users are considered to be users occasionally accessing the system through the Alfresco web-client or webdav/CIFS interfaces with a large gap between requests (e.g. occasional document access during the working day).

JVM Settings

General Case

For most cases, tuning the JVM is done in three steps:

Throw as much RAM as possible at the JVM (-Xmx32G),
Set the perm gen to 256M (-XX:MaxPermSize:256m),
Don't add any other configuration settings.

Use M or m for MB and G or g for GB.

Be aware that to avoid memory swapping, -Xmx should never exceed the available RAM in the system. Remember to leave room for memory used by the OS and other applications like OpenOffice via JOD (JOD often uses 1GB of RAM per OO instance).

In general, if you don't give the JVM enough heap, playing with other JVM settings will not help. Once the JVM has enough heap, playing with other JVM settings won't make much of a difference. The 1.6 JVM is generally excellent at memory optimization and should be allowed to function.

The remaining information on this page might help in exceptional circumstances. It is unlikely to apply to your use case, and we advise against JVM tuning beyond what has already been discussed in this section.

Permanent Generation (PermGen) Size

The default PermGen size in Sun JVMs is 64M, which is very close to the total size of permanent objects (Spring beans, caches, etc.) that Alfresco creates. For this reason it's quite easy to overflow the PermGen via configuration changes or with the addition of custom extensions, and so it's recommended to increase the PermGen to avoid OutOfMemory errors eg. -XX:MaxPermSize=160M is a good starting point. Note that as of Alfresco v3.0, we've increased the size of the PermGen in the alfresco startup scripts, so provided you're using those scripts no changes should be necessary.

Maximum JVM Heap Size 32/64bit

An important calculation to keep in mind is:

  (Managed Heap + native heap + (thread stack size * number of threads)) cannot exceed 2GB on 32bit x86 Windows or Linux systems.

This is a limitation of the Sun Java VM. It means that even if you install 4GB of RAM into your server, a single instance of the Java Virtual Machine cannot grow beyond 2GB on a 32bit server machine.

Note that a 64 bit OS/JVM has much bigger values! It is recommended that a 64bit OS with large memory hardware (>2GB assigned to the JVM) is used for deployments of >250 concurrent or >2500 casual users.

You can also setup you machine to cluster if you would prefer to solve multi-user access performance issues with additional machines rather than a single powerful server.

Real-World Example

The following settings are used on a high-volume clustered 64-bit, dual 2.6GHz Xeon / dual-core per CPU , 8GB RAM environment. Note the different memory ratios and try to preserve them on different environments. A minimum MaxPermSize of 128M is recommended but may sometimes require 256M.


-Xmx3G -XX:MaxPermSize=256M