FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory



  • 0_1668610388011_upload-2c359c8d-0bbc-42bb-91fd-0b7f57c2644c

    I leave here the link of my json , where you can see that I have a lot of data. And it is recurring that I have reports with this size, due to the many transactions
    https://we.tl/t-LzeybgDoSw

    My jsreport.config
    0_1668610677077_upload-e0122eb5-a07e-41d9-8955-126832720f1b

    My package
    0_1668610706580_upload-a6377b05-9252-4808-9721-96d3d6eaef2c

    0_1668610746897_upload-4a9b2bc4-90bb-491a-a8e9-66ed1737047c

    I've tried on another machine to put the latest version of jsreport but I have the same problem.

    The errors that usually appear to me are Payload to large, heap out of memory

    Any solution you recommend? Because I have several clients that need long reports, as in this case


  • administrators

    hi! yes, it is expected that by default you get out of memory errors with such long reports, after all it is node.js default not to use all memory available.

    you need to set the node.js option --max-old-space-size, which expects a value in megabytes.

    depending on how you start the jsreport you need to either pass it as a node.js option or an env var

    • node --max-old-space-size=3000 server.js
    • NODE_OPTIONS=--max-old-space-size=3000 jsreport start or NODE_OPTIONS=--max-old-space-size=3000 node server.js

    you will need to figure it out the exact megabytes value to pass, depending on the available memory you have on the machine, it is a bit of trial and error until you get right value for your reports.


  • administrators

    also, since you are on the v2 version it is likely you need to follow other configurations like the ones described in this blog post, but the --max-old-space-size node.js option is the most important



  • there is possibility to have multiple json files in a single template?


  • administrators

    no, there can be only one data entity attached to the template, but of course, you can still have many of them saved and available.

    the data entity is mostly for testing purposes and to verify that your template produces the expected output during your development. so it makes sense to have just one of them attached to a template on each render.

    what would be the use case of having multiple of them in a single template?



  • The case would be instead of sending a json with millions of lines, "split" that json into several and send these jsons through my API (C#)
    And so it would probably avoid timeout and memory errors


  • administrators

    I am afraid that such approach does not solve the issue with memory, receiving the input data is just one part of the puzzle and it becomes meaningless if the rest of the tasks (handlebars rendering, chrome rendering, etc) do not work the same way, because eventually some of these tasks will require having everything in memory.

    we have some ideas to make handlebars to work this way (for the output part, not the input), but as I said it depends on the rest of the tasks that are going to be done, and it does not work for all cases/recipes.

    because of these points, receiving the input data this way does not represent an advantage right now. in an ideal world each task supports getting input and producing output in a streaming way but this is not possible so far.


Log in to reply
 

Looks like your connection to jsreport forum was lost, please wait while we try to reconnect.