Known issues

Processing parameters in a model class

When creating your own model class to merge content and templates for rendering, take care when populating the model with request attributes.

Populating the rendering model with request attributes impacts performance. The rendering calculation takes about 8% longer when population is enabled. Enable it only for templates where it is really needed.

Collecting referencing nodes is slow

When deleting nodes, the content dependencies module checks for references to them. These checks result in a query for each node. Lucene must allocate memory to process the queries' indexes, which causes a lot of GC pressure.

For more, see MGNLCDEP-138.

Too many same-level JCR entries

In JCR (Java Content Repository) and the Jackrabbit implementation of JCR, there’s no hard limit on the number of items that can exist at one level. However, the performance of the repository may degrade as the number of child items at a particular level increases.

The optimal number of child nodes per level depends on many factors, including the specific use case and the performance characteristics of the underlying storage system.

In general, for smooth performance, it’s recommended to limit the number of child nodes to a few hundred or less at each level.

For more, see JCR workspace: Best practices.

  • You can still retrieve the tree structure as a list through, for example, search templating functions.

  • Using a balanced tree structure, you can mitigate performance issues when publishing hundreds of items at once. See the itemsPerRequest property of the publish command.
See also Q. I have too many child nodes and performance goes down (Apache Jackrabbit Wiki).

High memory usage when bootstrapping content on first startup

When importing content on first startup or installation, you may experience high memory usage or even an OutOfMemoryError (OOME) exception. The reason is that Jackrabbit keeps all changes in a transient space (and hence in memory) until the session is saved.

If the Unable to complete bootstrapping: out of memory. message is displayed, try to increase the maximum Java heap size with the -Xmx parameter in the server startup script.

You can also alleviate the issue by disabling the Jackrabbit search index for the import (commenting out the Magnolia index configuration in the workspace.xml configuration file(s)).

Although Magnolia provides generic indexing capabilities for the content data under JCR, you may need to modify the different namespaces with custom configurations. To configure specific indexing capabilities for your JCR content types, you can follow the guidelines on index rules to generate custom index rules.

DirectoryWatcher overflow

A DirectoryWatcher overflow warning can help you pinpoint the roots of an overflow. It is logged when there are more than 500 configured virtual URI mappings in light modules.

If a DirectoryWatcher overflow error occurs (MAGNOLIA-7762), try to:

  • Keep the number of files in a single folder below 100.

  • Use folder hierarchies whenever possible.

Too many open files

The embedded Derby database, which can be used instead of the H2 database, opens several file handles and may run over the maximum limit set by the system. This issue can occur on some Linux and OS X systems such as Macbook Air.

The solution is to increase the system-wide limit on the number of open files. The exact procedure, however, varies from one OS to another.

Ubuntu Linux

  1. Find the current maximum number of open files per user in a single session:

    ulimit -n

    The number is 1024 by default, which is too small.

    A value higher than 1048576 (from Ubuntu LTS 24.01) is recommended.

  2. Edit the limits.conf file:

    sudo gedit /etc/security/limits.conf

  3. Add the following lines to the file:

    * soft nofile 10000
* hard nofile 50000

    This sets for all users a soft limit of 10000 open files and a hard limit of 50000. These are just examples. Set the limit according to your needs.

    The wildcard option applies only to regular users, not to superuser. If you run Magnolia as superuser, replace the asterisk with root.

  4. Save the file.

  5. Edit the configuration file for session-related modules:

    sudo gedit /etc/pam.d/common-session

  6. Add the following line to the file:

    session required pam_limits.so

    You may need to add the following line to /etc/systemd/system.conf and /etc/systemd/user.conf:

    DefaultLimitNOFILE=65535

  7. Save the file.

  8. Restart Ubuntu.

  9. Verify the new maximum number of open files:

    ulimit -n

    The command should now return 10000.

See Cannot Increase open file limit past 4096 (Ubuntu).

OS X 14.x

  1. Find the current maximum number of open files per user in a single session:

    ulimit -n

    The number is 256 by default, which is too small.

    To check the current limits on your Mac OS X system, run the following:

    launchctl limit maxfiles

    The last two columns are the soft and hard limits, respectively.

  2. Add ulimit -n 65536 to your ~/.profile file. This increases the limit for the shell.

  3. Create a /etc/sysctl.conf file if it does not exist.

  4. Add the following lines to /etc/sysctl.conf:

    kern.maxfiles=65536
kern.maxfilesperproc=65536

    This increases the limit for the kernel.

  5. Open a terminal and type:

    sudo sysctl -w kern.maxfiles=65536
sudo sysctl -w kern.maxfilesperproc=65536
sudo ulimit -n 65536

    Or restart your system to read the settings from the files you edited.

  6. Type ulimit -n. The response should be 65536 (if not, restart your system).

  7. Install Magnolia

See Shell session limit and this thread for information on previous Mac OS versions.

The instructions above apply to Bash shell, not Zsh.

Slow AdminCentral with many tasks and notifications

AdminCentral might get slow over time. One of the possible causes – especially when there’s no log indication of any specific issue – is a high number of tasks and notifications stored in the user profile.

You can check the total number of tasks and notifications using the Tasks and Notifications apps, respectively.

You should not experience performance issues unless more than several thousand items are stored in your profile.

Tasks and notifications are aggregated by group. If a person belonging to the editors group deletes all items, this action will impact all others in that group.

Finally, remember to check all author instances for a high number of items (production, UAT/QA, development and others).

If multiple users are experiencing performance issues, each should check the number of tasks and notifications and resolve or delete all non-essential items.

Slow AdminCentral with multiple editors

Concurrent access to the JCR might require a bigger Jackrabbit cache size. To adjust the default 16 MB, add the following parameters to your JVM configuration. They will increase the cache size to 256 MB:

-Dorg.apache.jackrabbit.maxCacheMemory=268435456
-Dorg.apache.jackrabbit.minMemoryPerCache=1048576
-Dorg.apache.jackrabbit.maxMemoryPerCache=67108864
Memory is allocated from the Java heap.

Find Bar filtering slows down instances with a large number of registered users

When the filter icon is clicked in the Find Bar, the Find Bar queries the repository for all users including public users. This may lead to a performance degradation for clients with a huge number of (public) users.

You can configure the editorRoles property to limit the range of user roles allowed in the Last editor Find Bar search filter. For more details, see the Admincentral module.

Slow browser subapp due to multiple operations triggering workspace observation

Many users creating many items in a workspace concurrently causes many observation events. Too many observation events in a short period of time could make the grid in the browser subapp nearly unusable. Configuring the observation mechanism is possible by changing delays for processing events or even disabling it completely.

Turning the automatic observation property off would mean no automatic browser subapp refreshing, but only when a user performs some action. Reducing the number of observation events reduces the number of updates to the grid, making it more reactive. At the same time, the grid will be less up-to-date with changes made by other users.

See JCR observation definition for more information.

Feedback

DX Core

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the Performance tuning guide docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules
6.3 beta
X

Magnolia 6.3 beta

Magnolia 6.3 is in beta. We are updating docs based on development and feedback. Consider the 6.3 docs currently in a state of progress and not final.

We are working on some 6.3-beta known issues during this phase.