Operating XWiki on PaaS: JVM Heap in Cloudlets, the Solr Index, Attachment Storage and LTS Upgrades on a Clone

A wiki is the one system a company notices the moment it slows down, because everyone is in it. XWiki is a Java web application with a database, a Solr search index and a permanent directory full of attachments, and operating it well means understanding each of those three. This post is a DevOps engineer's runbook for XWiki on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.

The wiki belongs to a medical-devices manufacturer we will call Corran Instruments: 600 users, 20,000 pages, tens of thousands of PDF attachments that regulators expect to be findable. It runs the XWiki package: Tomcat on a Java node, a PostgreSQL database, and the permanent directory with attachments and the Solr index on persistent storage.

Heap: let the cloudlets set it

XWiki's memory need is dominated by the JVM heap and the Solr index's memory-mapped files. The platform's Java containers derive the JVM's memory options from the container's cloudlet allocation, so the engineer does not hand-set -Xmx; he sets the node's cloudlet limit and lets vertical scaling give Tomcat what it uses. For 20,000 pages and heavy attachment indexing he sets 64 cloudlets (a cloudlet is 128 MiB of RAM plus 400 MHz of CPU), which allows an 8 GiB ceiling, and watches the platform's per-minute statistics for a month. The node sits at 30 to 36 cloudlets during working hours and drops to 12 overnight; the only excursions to the ceiling are during Solr re-indexing. A load alert at 85% for 15 minutes is the signal to raise the limit, and it has fired once, during a bulk import.

The Solr index lives on disk, and disk has a limit

XWiki's embedded Solr indexes page content and extracts text from attachments, which is why the regulators' PDFs are searchable. The index lives in the permanent directory alongside the attachments, on the node's persistent storage. Attachments are the disk consumers: Corran's grew by about 40 GB a year. The engineer sets the disk limit with three years of headroom, adds a disk load alert at 80%, and notes the platform's storage can be enlarged from the dashboard without moving anything. A full Solr re-index after an upgrade takes about ninety minutes for this wiki and is scheduled for a Saturday, because it saturates the CPU cloudlets while it runs.

Backups: three things, consistently

An XWiki backup is the database (pages, history, rights, object data), the permanent directory (attachments, index, extensions) and the configuration files. The engineer's schedule:

• Database nightly with the Database Backup/Restore add-on to a Backup Storage node, 30 days' retention.
• Permanent directory nightly by an rsync job on the Tomcat node to the same storage node, excluding the Solr index, which is rebuilt rather than restored.
• Configuration (xwiki.cfg, xwiki.properties, Tomcat's server.xml) committed to a Git repository whenever changed.

The restore drill is a clone of the environment, the database restored into it, the permanent directory copied in, and a Solr re-index. It runs quarterly and takes an afternoon, most of it waiting for the index.

Upgrades: LTS to LTS, on a clone, twice a year

XWiki publishes monthly releases and a yearly long-term-support line, and Corran's policy is to stay on LTS and move to the next one within a quarter of its release. The upgrade path on the platform:

1. Clone production. The clone has the same Tomcat, database, attachments and extensions.
2. Redeploy the clone's Tomcat container with the new XWiki WAR, or deploy the WAR through the Deployment Manager, preserving the permanent directory.
3. Open the clone; XWiki's distribution wizard runs, upgrades the core pages and offers to upgrade each extension. The engineer accepts, then checks the three extensions Corran depends on (LDAP, a document-control application built in-house, a PDF export template).
4. Run a Solr re-index on the clone and time it. Ask two power users to spend an hour in the clone.
5. On Saturday, repeat steps 2 to 4 on production, with a fresh clone taken first as the rollback and the domain ready to swap to it if needed.

Access and audit

Medical-device documentation has audit requirements, and XWiki's page history, with every version and author retained, is most of the answer. The rest is platform: the environment in an isolated group in the Frankfurt region, the container firewall exposing only 443, LDAP authentication with the company directory, and collaboration roles that let the quality team see the environment's region, backup schedule and statistics without being able to change anything. The engineer exports the backup add-on's run log monthly for the quality file.

What it costs to run well

The Java node averages about 26 cloudlets an hour across the month, the PostgreSQL node about 8, and the backup storage node is disk. At MassiveGRID's published $0.003372 per cloudlet-hour that is roughly $83 a month before discounts, plus the attachment disk. The two upgrade clones a year add a few dollars each. For a system 600 people open every day and a regulator inspects every two years, the engineer's view is that the runbook above is the cost, and the invoice is a rounding error on it.

Frequently Asked Questions

Can I put the Solr index on its own node?

Yes. XWiki supports an external Solr server, and a dedicated node lets search scale separately from Tomcat. For most wikis under 100,000 pages the embedded Solr on a well-sized node is simpler; move it out when re-indexing or search load starts competing with editing.

PostgreSQL or MariaDB for XWiki?

Both are supported and the package offers either. PostgreSQL is a common choice for larger wikis; MariaDB is fine and familiar to many teams. Whichever you pick, the Database Backup/Restore add-on supports it.

How do I move the wiki to a bigger node without downtime?

You do not need to move it. Raise the node's cloudlet limit and vertical scaling gives Tomcat more memory and CPU in place, with no restart for CPU and a JVM restart only if the heap ceiling changes. Live migration handles the case where the host itself lacks capacity.