Running JJHub on a Full Domestic Stack: ARM + Kylin + DM Database

"Domestic substitution" usually sounds like a long list of compatibility caveats. This post is the opposite: a concrete, tested path for running JJHub entirely on domestic hardware and software, from CPU to database.

Compatibility matrix

Every JJHub component has been adapted for ARM64 and mainstream domestic OSes and databases. The core list: CPUs—Kunpeng 920, Phytium S2500/FT-2000; operating systems—Kylin V10 SP2/SP3 and UOS 1050/1060 (both ARM and x86 covered); databases—DM8, openGauss 3.x, and KingbaseES V8; middleware can be swapped to TongWeb. Everything below is based on real deployments, not paper compatibility. Compatibility here means more than "it installs": every listed combination has passed the four-step acceptance (collect, search, alert, trace) plus a soak test.

Don't forget the runtime. JJHub recommends a domestic JDK such as BiSheng JDK on ARM. The stock aarch64 OpenJDK is correct but not tuned; the domestic builds are optimized for Kunpeng and Phytium chips, and that tuning shows up in garbage-collection pauses on a busy collector.

Installing on ARM64

JJHub ships both deb and rpm packages, so Kylin and UOS install directly:

# Kylin V10 (aarch64)
yum install -y ./jjhub-server-2.6.0.aarch64.rpm
# UOS (aarch64)
dpkg -i jjhub-server-2.6.0_arm64.deb

Confirm two things before installing: glibc ≥ 2.28 (satisfied by default on Kylin SP2+), and disable transparent huge pages plus raise vm.max_map_count—the storage engine is sensitive to both on ARM:

echo never > /sys/kernel/mm/transparent_hugepage/enabled
sysctl -w vm.max_map_count=262144

Put both into a boot script, or they'll revert after a reboot and queries will slow down noticeably. This is the number-one "it was fast yesterday, slow today" cause on ARM deployments. Filesystem choice matters too: use ext4 or xfs with default mount options for the data directory, and avoid network mounts for the index directory—the storage engine relies on local-disk mmap semantics that NFS does not guarantee.

Swapping the database

The built-in metadata database can be replaced with DM or openGauss smoothly. For DM8, it's three steps: create the database and user in DM, then point the JJHub datasource at it:

datasource:
  type: dm
  url: jdbc:dm://10.0.0.12:5236/JJHUB
  username: jjhub
  password: ${DB_PASSWORD}

Finally run the migration script to import the schema and existing data. Run it against a copy first and diff the row counts per table—the script is idempotent, but verifying counts catches charset or collation surprises before you point production at the new database. After restarting, the console home page shows the current database type for a quick self-check.

Choosing between DM and openGauss: pick DM if you already have a DM DBA team, openGauss if your team is more comfortable with the PostgreSQL lineage—both behave identically in JJHub, so pick the one your team can actually maintain. Don't choose a database nobody on the team knows how to operate; the database you can keep running is the better architecture.

Migration and acceptance notes

Two traps when moving from x86 to ARM: the older agent is an x86 binary and must be reinstalled with its aarch64 counterpart, or the new environment won't collect anything; and some self-developed plugins depend on x86 glibc libraries, so run ldd over dependencies in the new environment first.

Expect roughly equivalent throughput after migration, but re-baseline anyway: run the same load test on x86 and ARM side by side, and record p50/p99 query latency on both before cutting over. A practical checklist: install the aarch64 agent on every node, ldd all plugins, migrate metadata to DM/openGauss, replay a day of real traffic against the new stack, then cut over and watch the four-step acceptance.

Localization isn't about swapping one or two components; it's about the replaceability of the whole chain—JJHub has made database, middleware, OS, and CPU all pluggable, which is exactly what makes the migration stick. The end state worth aiming for is a stack with no x86-only components left anywhere in the data path; keep a running list of what's still x86 so you know exactly what would block a full cutover. After cutover, keep an eye on the collector's CPU profile: the first week is the best time to catch a plugin that compiles fine on ARM but performs poorly on a different instruction set. If throughput dips, the usual culprits are transparent huge pages re-enabled by a kernel update and a database connection pool that wasn't sized for the new driver.