Are your workers multi-core systems using the default settings for jobslots?
For example, do you have 4-core machines with the default "worker cpus" setting, so that they can each run 4 subjobs at a time? If that's the case, it may actually be the case that your workers are being oversubscribed, in terms of memory resource.
Ideally, your users should all estimate, as accurately as possible, the amount of RAM that each job needs, and then add it to the "reservation" field of each job at submission, as in "host.memory=1024" (which means 1024MB), so that their jobs won't step on each other's toes-- i.e., that way, each job will "reserve" the eccessary amount of RAM to run smoothly, without some other large jobs running on the same worker, fighting for limited RAM.
If that's not possible, you may want to limit your workers to only run 1 subjob at a time, per worker, by setting their worker_cpus to 1. That way, you'll know for sure that each worker will only run 1 instance of XSI at a time, and that should alleviate memory issues caused by running multiple subjobs at once.
By default, workers can run up to N subjobs at a time, where N = number of cores on the system.
Optionally, you can submit jobs with "host.processors=1+" (yes, that's the digit ONE, followed by a PLUS sign), so that each subjob from those jobs will occupy all jobslots on each worker, thereby preventing other jobs from running on the worker until they're done.
