Is Synergy 7.2 a memory hog?
Rudi
Comparing this to an old 6.5 install, I noticed that my java client's javaw.exe *32 process uses about 5 times more RAM changing from roughly 90 MB to 450+ MB memory utilization (that is idle, just showing a started client) .. half a Gig is noticeable on a 4 Gig system that is already using 60% of its memory idle.
We are also investigating other "memory" issues where some of our (huge) queries do no longer run on the new 7.2 environment due to 'out of memory' issues. I have seen a ccm_ci.exe process grow beyond 1.3 GB RAM utilization on the server .. fs_check fails on some archives that contain large ascii files where the decompression of these archives (during fs_check) fails due to 'out of memory' issues.
.. all this works fine on an old 6.5 platform, where the memory usage profile is completely different. I understand that 7.2 was pretty much rewritten, but I wonder if there are settings/limitations to do with the increased memory demand that I am not aware of? Has anyone else experienced similar issues or has some advice on how to tweak a 7.2 environment?
.. I am curious, and grateful for any advice .. -Rudi.
Hoyland, Nigel
Rudi,
We were seeing the same issues in 7.1, especially with large Sync’s and bigger project compares. Here’s what I wrote up for my lot (and seems to have helped), based on a tech note (do a Google)…
If you are experiencing "Out of Memory" pop-up messages when using Synergy (especially when doing memory-intensive actions like very large sync's and large whole-project diffs) then your Synergy installation's "Java Heap Size" settings may need tweaking. Here's how to rectify this issue...
1. Navigate to C:\Program Files (x86)\IBM\Rational\Synergy\7.1\bin and save a copy of the cmsynergy.lax file (e.g. copy file and rename to cmsynergy.lax.save).
2. Open up the cmsynergy.lax file and search for the lines starting "lax.nl.java.option.java.heap.size.max" and "lax.nl.java.option.java.heap.size.initial=256m" and change the settings as below...
a. If you have a 16Gb RAM "Developer's Laptop"...
o lax.nl.java.option.java.heap.size.max=1024m
o lax.nl.java.option.java.heap.size.initial=256m
b. If you have a standard 4Gb laptop/desktop machine...
o lax.nl.java.option.java.heap.size.max=256m
o lax.nl.java.option.java.heap.size.initial=64m
NOTE: If these values don't work for you, then experiment with different values, but bear in mind the higher you put the values, the slower the Synergy start-up times may be (according to Rational).
Obviously, you’ll need to experiment with different values depending on the available RAM you have on your machines.
Cheers,
Nige
--
You received this message because you are subscribed to the Google Groups "Synergy CM Tool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
synergy-cm-to...@googlegroups.com.
To post to this group, send email to
synergy...@googlegroups.com.
Visit this group at
http://groups.google.com/group/synergy-cm-tool?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Ruediger...@jci.com
thank you for this info .. and yes, we considered Java heap sizes and tweaked around (with very similar value pairs as you show) .. without fixing the problem. Somehow our memory problems seem to be more system (HP ProLiant G7, 12 core + HT, 32 GB RAM) or OS (Windows Server 2008 R2 SP1) related .. and I truly think the latest release might still suffer from memory leaks .. or inefficient memory utilization.
This is of course all theory .. and I have no way/time (or choice) to prove anything ;) .. which is why I was wondering if other people encountered similar issues.
Thank you for the feedback,
-Rudi.
Ps. .. one thing to keep in mind for the Java heap adjustments is the fact that Synergy still uses a 32-bit java engine so (independent of your OS) there is still a physical limitation on how much memory space can be addressed .. in this case that is somewhere around 1600 MB - if I remember right .. which is the max you could/should use for the Xmx value or things will start acting up.
cmtodd
MORGENTHALER, Peter
Hi,
I would have thought that the change in design from 6.5 to 7.X (web connect) would use more ram on the server as a lot of the processing has moved from the client machine to the server. On a default machine running 7.2 or 7.1 we get away with 512M Ram and rarely have a problem even on a big sync. Whilst 7.2.0.3.001 is far from perfect we have not had any issues re memory like you are seeing.. that said we are running on Lunix rather than windows server so it may just be a difference on that. I would try changing your JRE to the oracle (sun) version to see if you still have the same memory issues. We find some interesting performance gains (and losses) using different JRE versions.
There does appear to be an issue reported with 7.2 running on oracle not closing sessions but I believe it is isolated to just oracle users not Informix.
Peter
From: synergy...@googlegroups.com [mailto:synergy...@googlegroups.com]
On Behalf Of Rudi
Sent: Wednesday, 6 March 2013 2:10 AM
To: synergy...@googlegroups.com
Subject: Is Synergy 7.2 a memory hog?
I am starting to wonder if I have 'misconfigured' my Synergy 7.2 system as I noticed a tremendous increase in memory (RAM) utilization while running a java client or the cli.
--
You received this message because you are subscribed to the Google Groups "Synergy CM Tool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
synergy-cm-to...@googlegroups.com.
To post to this group, send email to
synergy...@googlegroups.com.
Visit this group at
http://groups.google.com/group/synergy-cm-tool?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited. If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility. It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."
MORGENTHALER, Peter
Further to that I have not noticed much memory difference between 7.1 and 7.2 on the client side. There are two operations which will always blow the memory usage of the java client out.. a large sync and a show history.. that said you should get the memory back once you close the windows as a garbage collect should occur.
Peter
Ian Wilkins
This isn't really a fix, but can be helpful. If you run the synergy client with the -debug flag (you'll most likely have to update your shortcut), you get several options
under the tool menu. These allow you to see the current heap size, force garbage collection, clean the local object cache.
This is my default mode now, and helps me manage the limited resources on my laptop.
Ian ....
Hoyland, Nigel
Thanks Ian – I’ll give that a shot!
--
Ruediger...@jci.com
.. I remember that laptop .. ;)
.. and do run that exact setting for my client (for which I just ordered another dimm of memory). Things are breaking on the server right now .. the ccm_ci.exe blows up on some queries .. the bsdco.exe blows up on some fs_check commands. I did see problems with the javaw.exe before (that's where the heap adjustments comes into the game).
When I say "blows up" I mean that those processes run and continuously increase their memory utilization .. at some point - between 1.7 and 2 GB - the processes just die with an out of memory error.
This might be a OS restriction for 32-bit apps (even though our server runs Windows Server 2008 R2 64-bit as OS) .. but nevertheless I would not have expected any process to use up that much memory to begin with. I know as a fact that the 6.5 processes don't .. which we are running on a 2003 32-bit server OS (on almost identical data). The application was designed (and compiled) for a 32-bit platform so the constraints for "available" memory address space should have been known to the developer ..
Memory profiling might be the next step to find the root cause .. unless there are settings on Windows Server 2008 R2 that would help addressing this behavior. There is a good chance that we are not running with optimized settings .. since I don't know what those would be ..
-Rudi.