Open ByronBecker opened 2 years ago
Interesting! I wasn't aware that the Motoko team is currently developing a BTree (I'm guessing the analogue of the StableBTree written in Rust). I couldn't find mention of it in this thread...
Update: This issue will be resolved upon the release of Deterministic Time slicing. DFINITY has estimated this feature is on the order of weeks away (pending blockers), so hopefully it will be released at some point in October/November. Additionally, the Motoko team has hired a GC specialist to help resolve some of the performance issues involved with the current GC in favor of a more incremental GC.
Update: 2X DTS is currently live. After testing, one can safely insert up to 475 MB before hitting GC limitations. DFINITY is hopeful that 6-10X should fully resolve any issues related to the GC and allow canisters to store close to 4GB in heap memory without issue.
My test results of before vs. with 2X DTS - https://forum.dfinity.org/t/deterministic-time-slicing/10635/55
Update: 4X DTS has been live for some time now.
Canisters can now insert up to 900MB heap memory safely with CanDB.
Issue
When deployed to the IC main network, inserting entity records can hit the message instruction limit, causing the canister to trap and prevents further insertion.
Why is this happening
The when storing small Entity attributes & attribute values associated with keys, the Motoko Garbage Collector (GC) will eventually hit the message instruction limit at various times, on a scale between 250MB-2GB depending on the size of the attributes inserted (from Bytes - 1.5MB per entity) in my experience. The Motoko team is aware of this issue. See related issue - https://github.com/dfinity/motoko-base/issues/390
In-progress work being done to fix this issue
Recommended stop-gap measure
When testing locally, this issue does not exist.
If deployed to the IC, it is recommended to set the following
ScalingOptions
, forsizeLimit
using the#heapSize
variant with a size of less than 200MB.