Deploying OBSERVE on Phytium FT-2000/64 + UOS V20 + KingbaseES V8: ARM binaries, Kingbase dialect differences, parameter tuning, and the gotchas that actually bit us.
We've written before about deploying on Kunpeng + Kylin + Dameng. This time it's the other common combination: a Phytium FT-2000/64 processor, UnionTech UOS V20, and KingbaseES V8. Swap the CPU, OS, and database and the pitfalls swap along with them. Domestic-stack adaptation has no “tune it once and it works everywhere” — every combination earns its own pass.
Phytium is ARM, so first confirm the package is an aarch64 build. OBSERVE ships an aarch64 offline bundle; extract it and run the installer, pointing at Kingbase:
tar -xzf jjhub-observe-2.4-aarch64.tar.gz
cd jjhub-observe-2.4-aarch64
./install.sh --db kingbase --db-host 10.0.0.21 --db-port 54321Kingbase listens on 54321 by default (PostgreSQL-compatible protocol) — not Dameng's 5236, and definitely not MySQL's 3306. The installer creates the schema and tables automatically; use a dedicated business account rather than the default SYSTEM account.
Kingbase supports both PostgreSQL and Oracle compatibility modes; this deployment uses PG mode. OBSERVE's metadata layer emits SQL in the PG dialect, but a few differences still need handling:
LIMIT ... OFFSET, unlike MySQL's LIMIT a,b, so the ORM layer has to follow the PG dialect.TEXT for large fields (log metadata) rather than VARCHAR, to avoid length limits.In Kingbase's kingbase.conf, we recommend:
shared_buffers = 4GB # roughly 25% of physical RAM
max_connections = 300 # enough headroom for the metadata pool
effective_cache_size = 12GBIngestion is write-heavy, so relax the WAL-related settings and the checkpoint interval to reduce write stalls from frequent flushes. In our testing, the default config pushed write latency to 300ms at 10k lines/sec whenever a checkpoint fired; after raising checkpoint_timeout, P99 settled under 60ms. This is the kind of thing that looks fine in a 10-minute smoke test and only shows up under a sustained soak.
The installer drops a systemd unit that starts OBSERVE on boot and restarts it on failure. Two settings matter in an offline environment: set RestartSec=5 so a crash doesn't loop the box, and run the service as a dedicated non-root user — the UOS default account often holds more privilege than a daemon should. Also pin the service to the ARM build's bundled JVM; using the system JDK has caused version skew on several sites we've visited.
On this FT-2000/64 with UOS, a single ingester sustained about 18k log lines/sec, with query P99 around 210ms under 20 concurrent queries — within 15% of a comparable x86 node, the gap coming from single-core performance. A 72-hour soak showed no memory growth and GC pause P99 around 28ms. The one real issue was the Kingbase checkpoint stall described above, fixed by tuning rather than by throwing hardware at it.
One more thing worth stating outright: budget for the regression pass. On paper, ARM plus PG-mode Kingbase should behave like any x86 plus PostgreSQL, but the differences surface in collation, in timestamp precision across the UOS/PG boundary, and in how the ARM build's numerics round. Those don't show up in a smoke test; they show up in the third week of production. Run the full regression on the real stack and don't cut that corner.