Hi again,
Yes, running out of available memory is one possible reason this could be happening. It's also possible that you are hitting memory limits defined by the PHP execution limits. You can read more about this, and how to change some parameters, in this documentation page:
You can also run the command with no default memory limit in place, like so:
- php -d memory_limit=-1 symfony digitalobject:load /path/to/import-file.csv
If it is actually exhausting all available memory on your system, I would probably expect to see an out of memory error message in the terminal, from the task output. Do you see anything like that?
Another thing you could try is running the task again, while using htop to monitor your active processes and see how the system memory is being used. See:
You'll probably need to open 2 separate terminal windows so you can execute the load task command in one, and monitor in the other one.
Finally, it could also be that there are some unexpected results because of the matching criteria used - for example, if you are using the description identifier in your load CSV for matching, but your identifiers are not unique throughout the application, this could cause some digital objects to end up in unexpected places. If you are using 2.6 or later, I strongly recommend that you use the target description slug as your matching row in the CSV, as this is guaranteed to be unique. Ideally, you will not try to add more than 1 digital object to a single description either - while there is fallback behavior when this happens, the purpose of the task is to link digital objects to existing descriptions (with a 1:1 relationship!), not create new descriptions on the fly. A description CSV import, using the digitalObjectPath column to link your objects, would be better for adding new child descriptions with digital objects.