How to solve "GC overhead limit exceeded" error

[Anonymous]

We have recently migrated to 64bit java, and for some reason, we have immediately hit GC overhead limit exceeded for some of our transformation. After a little debugging, it was clear that the default way how Talend handles Garbage Collection is not viable. There's simply too much objects being created too fast, and the standard Java GC mechanism (on 1.6 at least) is not able to handle it.
I recommend to add following parameters to the "JVM Parameters" tab of the job:
-Xms500m -Xmx2048m -XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX urvivorRatio=16
Of course the Xmx and Xms amount should conform to your situation, and the XX urvivorRatio is just an enhancement telling GC that there's a lot of objects with short-live period.
We also believe that this should be default Talend settings, due to its nature (memory being filled with a lot of data quickly).
Martin

[alevy]

Hi martinhapl
We're having a problem compiling the "master" job that runs our whole project. We keep getting the "GC overhead limit exceeded" error. We tried adding the JVM arguments you suggested and that allowed the compilation to get further but it still did not complete successfully. Even though we bumped up the Xmx setting to 3072m, TIS does not seem to be using all the physical memory available on the PC, topping out with around 750Mb still free.
Can you please explain more what your suggested parameters are supposed to achieve and are there any other changes you can suggest?
We would have thought the JVM parameters would affect the actual running of the job rather than the compilation...

[Anonymous]

Hello alevy, my parameters are really more for the run-time of the transformation, as they affect how Garbage Collector removes unused objects. I guess that they won't have so big effect during the compilation. "GC overhead limit exceeded" message is something which cannot be truly removed by increasing the available memory. Rather GC should be put into a different mode (perhaps event different than suggested by me) to handle the situation properly. I would actually expect that people from Talend will tell us what CG configuration is the best, as they know what their application is doing internally. The line I'm using is based on some profiling we did here and is probably far from perfect, unfortunately...

[Anonymous]

Hi alevy,
Configuration of jobs JVM parameters is different from studio jvm startup parameters
In your case, you have to add/customize the JVM parameters to your binary.ini file in <TIS Install> directory
martinhapl,
I appreciate your proposal, but it's a little bit heavy for smaller environment or 32 bits users.
HTH,

[Anonymous]

Hello Michael,
It is true that the setup proposed by me is resource intensive, on the other hand it is easy to lower the amount of memory for 32bit machines. The rest solves the way how GC is cleaning up the memory, which shouldn't be that affected by the amount of available memory, but rather by what the code is really doing. By looking at some traces (jstat), we found out that the default GC setup is unable to handle what jobs generated by Talend does (more specifically complicated jobs generated by Talend). And this setups is the best we've been able to come up with.
It would be definitely helpfull to have some guidelines from Talend how to set GC for different kinds of jobs, and perhaps some reasonable default settings.
Martin

[alevy]

Thanks, mhirt. I'd managed to locate that setting and bump it up, eliminating our problem if using 64-bit, by the time I read your note.
Note, however, that we still could not compile the "master" job using 32-bit TIS, instead receiving the new error "Execution failed: No more handles".

[Anonymous]

Hi
Talend Version: 5.2.1
I have same error when processing big CSV files using tFileinput
Doest i t mean I should try change parameters in
TOS_DI-win32-x86.ini
if I run TOS_DI-win-x86_64.exe ?
My file :
-vmargs
-Xms64m
-Xmx1536m
-XX:MaxPermSize=512m
-Dfile.encoding=UTF-8
and I have no
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX urvivorRatio=16
parameters
Should I add them ?

[alevy]

The .ini files affect the studio (including compilation of jobs) but not the running of jobs.
For the studio memory, if you run TOS_DI-win-x86_64.exe then you need to modify TOS_DI-win-x86_64.ini.
For the job memory, you need to modify the Advanced Settings on the Run tab. That is where Martin was suggesting to put his extra JVM arguments but probably increasing the Xmx will be sufficient for you.

[Anonymous]

For the job memory, you need to modify the Advanced Settings on the Run tab. That is where Martin was suggesting to put his extra JVM arguments but probably increasing the Xmx will be sufficient for you.

Thanks
Yes - I found it
and increase in 2 times values
It helps
but is there any general desciption of using these parameters ?