|
[
Permalink
| « Hide
]
Dmitry Yemanov added a comment - 30/Mar/12 05:48 AM
It can be reproduced with 2.5.1 as well, hence I've changed the subject to mention the already released version instead of a snapshot build.
This is a regression introduced while implementing
Usage of isc_send() instead of isc_start_and_send() forces the looper to always exit with a non-NULL node, so release_blobs() is never called and thus blobs/arrays bound to the current request are never released, at least until the transaction ends. Hence we have a transaction level memory leak.
The dumb but easiest solution could be to restart the request periodically (e.g. if (records % 1000 == 1)) to keep some kind of a balance between memory usage and performance. Or set some flag if we have blobs/arrays stored right before this record and use that flag to restart the request instead of just sending the record. Or combine these two approaches. Ideally, the engine should be fixed, but this sounds too risky for point releases. With a 32-bit FB 2.5.2 (release mode) on 64-bit Windows I see VM = 750MB after 1,000,000 records restored, 1.5GB after 2,000,000 records and the OOM error happens at 2,262,000 records. 64-bit FB consumes a bit more memory but unsurprisingly succeeds to restore.
Just for the record, I was restoring using the Services API. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||