Running JUJING OBSERVE on the Xinchuang Stack: Kylin + Kunpeng + DM Database

The gap people underestimate in domestic-stack (Xinchuang) work is the one between "it installs" and "it runs in production." JUJING OBSERVE has run in production on Kylin V10 (SP3) + Kunpeng 920 + DM Database 8, and this post records the deployment and tuning process honestly.

Target environment

• OS: Kylin V10 SP3 (aarch64)
• CPU: Kunpeng 920 (64 cores)
• Database: DM8
• Middleware: TongWeb (optional; the built-in Nginx works too)

The two real differences are CPU architecture and database. Kunpeng is ARM, so a lot of third-party binaries are x86-only — verify an aarch64 build exists before you commit to a component. DM's SQL dialect differs from MySQL, so any module that touches SQL needs its own adaptation pass. Don't assume anything ports over unchanged.

Deployment steps

Install the system dependencies first:

yum install -y libaio glibc gcc-c++ make
# DM needs libaio; without it you get "error while loading shared libraries: libaio.so.1"

JUJING OBSERVE ships an aarch64 offline installer. Extract it and run the bundled script — no network access required:

tar -xzf jjhub-observe-2.3-aarch64.tar.gz
cd jjhub-observe-2.3-aarch64
./install.sh --db dm8 --db-host 192.168.1.20 --db-port 5236

The --db dm8 flag switches on the DM dialect adaptation layer. The installer creates the database, tables, and initial data automatically. Use a dedicated business account rather than running the production schema as DM's SYSDBA, and keep its privileges to the minimum.

Storage and performance tuning

Kunpeng has plenty of memory bandwidth, but DM needs tuning for high-concurrency small-transaction workloads. In DM's dm.ini:

MEMORY_POOL = 4096          # memory pool, in MB
BUFFER = 8192               # data buffer
SORT_BUF_SIZE = 64

On the write side, JUJING OBSERVE partitions logs and metrics by time by default. On DM, change the partition granularity from daily to hourly so a single partition doesn't grow large enough to force cross-partition scans and slow down queries.

One easily missed point on Kunpeng: use a Kunpeng-optimized OpenJDK (BiSheng JDK or the Kylin-bundled build). It's about 15% faster than a generic ARM build on crypto and GC, which directly affects Collector and alert-engine throughput. Don't lift JDK tuning flags from x86 and drop them onto ARM.

Verification

Push 10,000 log lines per second with a load tool while running queries, and watch three things:

1. Write latency P99 stays under 50ms.
2. A 7-day query aggregating 10 endpoints returns within 2s.
3. Memory doesn't creep up over a 24-hour soak.

Our measured result: at 10k writes/sec plus 20 concurrent queries, CPU sits around 40% with no memory leak. The one real gotcha was a cursor-leak bug in DM before 8.1.1 that caused occasional query stalls — upgrade to DM 8.1.1.128 or later if you hit it.

Recommendations

• Run a full regression on the DM + Kunpeng + Kylin combination before going live. Don't test on x86 and ship to ARM; the differences hide in edge cases.
• Back up with DM's own DMRMAN rather than third-party tools — it's the most compatible option.
• Turn the deployment into Ansible playbooks. Xinchuang environments often include offline data centers, so the playbooks must run fully offline — no sneaky external network calls.