Hi all, Thank you for the feedback and parameter suggestions.
I have now submitted PR #18538, which implements the first two steps discussed in this thread: https://github.com/apache/iotdb/pull/18538 First, the PR adds an Edge-specific configuration and JVM profile targeting about 512 MiB total process RSS. I tuned and validated it on both x86 and Raspberry Pi 4B. On the Raspberry Pi, I ran 21 test groups of 30 minutes each across the aligned tree, non-aligned tree, and table models. All runs completed with zero failed points and no OOM. The results also show that workload shape matters, especially for the 10,000 × 1 case, which was throughput-limited. A concise English report for the Raspberry Pi tests is available here: https://timechor.feishu.cn/docx/Hlf0dyQ4FoQsf4xEFnSc4TTknIg Second, the PR introduces org.apache.iotdb.edge.EdgeNode, which starts the ConfigNode and DataNode in a single JVM while keeping the existing RPC communication path for now. It also adds the apache-iotdb-edge-${version}-all-bin package and a single pair of start/stop scripts. Xuan, regarding the 1 MiB sort and modification buffers: I agree that those limits would be too restrictive, so the current Edge profile does not override them to 1 MiB. Wenwei, thank you for the compaction and TsFile suggestions. The current PR uses the parameters validated in my test runs and does not yet include every proposed override. I would be happy to compare these settings further during review. Chris, regarding the previous CtrlX Edge application you mentioned: I was not able to find the earlier code. Since the bootstrap logic is relatively straightforward, I implemented a new EdgeNode instead. It starts the ConfigNode on a background thread, waits for its internal RPC endpoint to become ready, and then starts the DataNode in the same JVM. The direct in-VM communication path remains the next step after this PR. Reviews and further suggestions are very welcome. Best regards, ------------------------------- Yuan Tian
