Bug 1396045

Description of problem:
Syncing a server using WebUI or by executing synchronisation by taskomaticd this may take over 8GiByte. Doing the same calling spacewalk-repo-sync on CLI it takes only about 3GiByte.
If the spacewalk host is equiped with 8 GiByte RAM, the process will fail with "Killed" without any error message. You'll find what has going on ONLY within system logs. Not within any logs written by spacewalk.

Version-Release number of selected component (if applicable):


How reproducible:
Always. It does not depend on repos being synchron or not. The more repositories a channel holds the more memory is used.

Steps to Reproduce:
1. Install Spacewalk 2.4, create repos, create channels, assign repos to channels, then synchronize these.
2. Watch memory used by java going up slowly while the process synching repositories goes on.
3. As soon as this process ends memory will drop to the level it started to rise from.

Actual results:
Memory may go out and kernel kills process. No error message within spacewalk. You'll only notice this looking at system logs, searching for "killed" processes.

Expected results:
Spacewalk exausting a warning, telling you about the fact memory is to low to sychronize further repositories, begging for more memory, or better using slower, but less memory hungry algorithms.

Additional info:
Since there is no error message within WebUI it is difficult to tell if "killed" process 100023 was spacewalk trying to synchronize repositories or not. This leads to repositories never updated in some cases.