Hello Anton,
thank you for reaching out to us on that matter!
SubGit is written in Java and as any other Java program it may suffer from the memory starvation if the amount of data it handles is too big and that is the exact reason for those OutOfMemory errors. By default, SubGit does not set memory size explicitly that means that the upper limit of memory is the default value for the given platform which not always big enough. This default value can be checked out with the following command:
java -XX:+PrintFlagsFinal -version | grep MaxHeapSize
or on Windows:
java -XX:+PrintFlagsFinal -version | findstr MaxHeapSize
It will print the maximum heap size in bytes; and if the value is small, it may worth setting higher memory limits by setting the Xmx JVM parameter. It can be set right in the SubGit startup script which reside in bin subdirectory in SubGit installation directory. There is a EXTRA_JVM_ARGUMENTS line in the script and the Xmx parameter can be added right in the end of that line like this:
EXTRA_JVM_ARGUMENTS="-Dsun.io.useCanonCaches=false -Djava.awt.headless=true -Djna.nosys=true -Dsvnkit.http.methods=Digest,Basic,NTLM,Negotiate -Dsvnkit.ssh.client=apache -Xmx4G"
As mentioned, the root cause of this issue usually is that SubGit tries to put all the data in memory during a revision translation and in some cases the data amount is too high. It usually does not happen when SubGit is configured to use svn, ssh, or file protocol to access the SVN repository, just because of those protocols using specifics, but often happens when the SVN repository is being accessed over http, especially with default SubGit setting – in this case SubGit tries to put all the revision data in RAM. However, it’s possible to change this behaviour by setting svn.httpSpooling configuration option in SubGit configuration file to true (default is false):
[svn]
url = …
…
httpSpooling = true
Don’t forget to run subgit install <REPO_PATH> after changing the setting to apply the changes.
When it’s set like this, SubGit stores the revision data in a disk cache instead of RAM thus reducing memory consumption. It may lead to the disk space issues, on the other hand, but helps overcoming the OOMEs errors.
From the SVN side those errors may happen not only due to drastic repository grow but also due to erroneous or not correct SVN operations. A very often example is copying repository’s root instead of a particular folder – like, in a try to create a new branch one copies the repository root instead of the trunk. Such an action does not add much data in the SVN repository, but it’s a big difference during the translation to Git since SubGit is forced to copy the whole repository data to reflect that action and this, of course, can lead to those OOME errors.
As for the process checking – I’m afraid there are no embedded facilities for that, but it’s possible whit a regular operating system’s tools and features. When a new commit come to a mirrored SubGit repository or when subgit install or subgit fetch commands are invoked, SubGit starts a daemon process which is visible in the list of system processes and thus can be monitored. The latest translated commit can be found in the daemon log or, for the Git-originated commit also in the pre-receive log, but it’s also present in the daemon log, so probably it’s betted to check the daemon log all the time.
Hope the above will help.