On Xinchuang, observability systems often install but run slow. This gives a repeatable tuning path — ARM page size and NUMA, key DM/Kingbase parameters, storage tiering, and a load-testing method to close the gap with x86.
Deploying an observability system on Xinchuang is only the first step. Many teams bring it up on Kunpeng or Phytium servers, find query latency noticeably worse than their old x86 setup and collection throughput lacking, and conclude "domestic hardware is slow." Most of the time the hardware isn't the problem — parameters weren't tuned and the architecture wasn't adapted. Here's a four-part path, each with a measurable signal. The rule of thumb underneath all of it: on ARM you tune for memory access patterns first and CPU clock second, which is the opposite of what most x86-era habits assume.
Kunpeng and Phytium are ARM. The first thing to check is page size. Some Kunpeng servers default to 64KB pages while most storage engines compile for 4KB; a mismatch inflates memory-mapping overhead and slows queries. Run getconf PAGESIZE — if it returns 65536, either switch to a 4KB-page kernel or use the vendor's dedicated 64KB package. Don't force it. The mismatch is silent: nothing errors out, your queries just run 20–40% slower than they should, which is why it's the first thing to verify.
Second is NUMA affinity. Cross-NUMA access on multi-socket ARM is more punishing than on x86, so bind collector and storage processes to local NUMA nodes with numactl --cpunodebind, or let the scheduler pin by CPU affinity. In our testing, NUMA binding on dual-socket Kunpeng cut query P99 latency by 20–30%. Also check that the JDK or runtime you bundle is itself an aarch64 build — an x86 JVM running under emulation will quietly destroy throughput, and it's an easy thing to miss.
Metadata and alert rules live in the database, and database parameters directly affect console responsiveness. For DM8, the key knobs:
-- size the buffer pool to 40–60% of physical memory
ALTER SYSTEM SET 'BUFFER' = 8192;
-- disable direct IO for higher write throughput
ALTER SYSTEM SET 'DIRECT_IO' = 0;
-- enlarge the redo log buffer to cut frequent flushes
ALTER SYSTEM SET 'RLOG_BUF_SIZE' = 128;For KingbaseES, the equivalents are shared_buffers (~25% of RAM), effective_cache_size, and checkpoint_completion_target = 0.9. Restart to apply, then re-run the platform's precheck.sh. A word on the buffer-pool sizes: these are starting points, not laws — size them against the memory you can actually spare after the observability services themselves, and measure before trusting anyone's rule of thumb.
With heavy log volume, storage dominates performance. Keep the last 7 days on the hot tier (SSD, full field indexing), 7–30 days warm, and 30+ days archived cold. The hot window is what day-to-day triage feels like — don't shorten it to save a buck. Equally overlooked is index pruning: partition logs by service and namespace, and always include a time range and service name in queries so the engine scans only the necessary shards instead of the whole store. On ARM, storage throughput is usually the ceiling, so tiering buys you more than CPU tuning once log volume crosses a few terabytes a day.
Tune with data, not vibes. Use the bundled load tool or wrk/vegeta to simulate production traffic across three groups: first, collection throughput — simulate N nodes reporting logs and metrics, watch agent CPU and queue depth; second, query latency — run a fixed set of real queries and measure P50/P95/P99; third, alert latency — fire a rule and time data-arrival to alert-delivery.
Re-run all three after each parameter change and record before/after. One customer's tuning on dual-socket Kunpeng 920: after NUMA binding plus 4KB pages plus DM parameter changes, query P99 dropped from 3.1s to 1.4s and collection throughput rose from 28k to 55k events/s — roughly on par with an equivalent x86 box. The takeaway isn't that domestic hardware is slow — it's that domestic hardware has to be tuned on its own terms.