[closed] lscm (scm) command line is very slow (solved)
The question has been closed for the following reason: "Duplicate Question" by krzysztofkazmierczyk Jan 19 '15, 3:15 a.m.
3 answers
Hi Brett,
Could you please try with the below details.
LSCM_USE_JAVA_FEC EV and that seems to have speed things up considerably.
Set EV to any value i.e
set LSCM_USE_JAVA_FEC=xyz.
This can be done via the windows environment variables or at the command line before running the lscm commands.
Here is an example of a batch file that you can use to start run the initial login using lscm
set LSCM_USE_JAVA_FEC=xyz
@echo %LSCM_USE_JAVA_FEC% Fec
set PATH=C:\OPT\eclipse\RTC\RTC-Client-Win-4.0.5\jazz\scmtools\eclipse;%PATH%
@echo Start Bat file: %time%
lscm login -c -n r -r https://server:9444/ccm -u user -P password
Regards,
Arun.
Arne Bister (2.1k●3●15) | answered 1 hour ago
JAZZ DEVELOPER
please cp. https://jazz.net/wiki/bin/view/Deployment/RTCClientPerformance#Command_line_interfaces_CLIs to references how to enable Metronom and additional logging for command line to pinpoint exactly what is causing the performance issue you are observing.
- Arne
Comments
Metronom doesn't appear to work on lscm (invalid option). Running on scm, produced:
Start VM: -Xmx512m -Xshareclasses:nonfatal -Xquickstart /OutOfMemoryError,request=exclusive+prepwalk -os linux -ws gtk -arch x86 -showsplash -data @noDefault -debug .debugoptions list workspaces -r local -vm /usr/java/jdk1.6.0_26/bin/../jre/lib/i386/client/libjvm.so -vmargs -Xmx512m -Xshareclasses:nonfatal -Xquickstart -Dosgi.requiredJavaVersion=1.6 -Xdump:system:events=systhrow,filter=java/lang/OutOfMemoryError,request=exclusive+prepwalk -Djava.class.path=/cots/rtc/jazz/scmtools/eclipse/plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar/org.eclipse.osgi_3.6.50.R36x_v20120315-1500.jar Splash location: null Debug options: file:/cots/rtc/jazz/scmtools/eclipse/.debugoptions loaded Time to load bundles: 4 Starting application: 558 (1000) (1033) Service Trip Statistics: Interface/method Calls Time IRepositoryRemoteService 4 212ms fetchOrRefreshItems 4 212ms IScmRestService......... 1 161ms getWorkspaces 1 161ms -- Total time in service calls: 373ms
real 0m5.602s
Just looking at the output above - are you using a Java 6 VM from the installation of RTC, or one from elsewhere? Any chance you can point to the JVM supplied with the RTC client (if you installed this part of the client) - or try a Java 7 VM.
WHY ARE COMMENTS RESTRICTED TO LIKE 300 CHARACTERS?!?!? Is this a twitter forum??
Sorry, took me while to get back to this. We are looking to just switch to git since that command line generally works. but to answer your question, I don't know how to tie to the RTC VM, as it isn't installed anywhere I can tell. I tried again with Java 7, it actually seemed slightly better.
-vm /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.25/bin/../jre/lib/i386/client/libjvm.so
-vmargs
-Xmx512m
-Xshareclasses:nonfatal
-Xquickstart
-Dosgi.requiredJavaVersion=1.6
-Xdump:system:events=systhrow,filter=java/lang/OutOfMemoryError,request=exclusive+prepwalk
Service Trip Statistics:
Interface/method Calls Time
IRepositoryRemoteService 3 20ms
fetchOrRefreshItems 3 20ms
IScmRestService......... 1 56ms
getWorkspaces 1 56ms
-- Total time in service calls: 76ms
The problem seems to largely be lscm, which doesnt support metronome.
lscm list workspaces takes 10 seconds minimum (at times closer to a minute)
scm list workspaces takes 4 seconds
Comments
Another option could be to mount NFS filesystem with -llock (Solaris/AIX/HP-UX) or -nolock (Linux) option. It would force to use local locks for the NFS filesystem. It is safe when the same build workspace is used from one UNIX/Linux host at a time.
RTC would not run at all without the -nolock option on the mount command. Added the option allowed it to run, just really, really slow. Using a local filesystem was a significant improvement (or an NFS filesystem that supported locks)
Comments
Remy Suen
Sep 30 '14, 11:18 a.m.If you use regular 'scm' instead of 'lscm' is it just as slow?
Brett Waldo
Sep 30 '14, 12:16 p.m.Remy Suen
Sep 30 '14, 2:21 p.m.Do your coworkers also have the same problem with 'lscm'?
Brett Waldo
Sep 30 '14, 2:49 p.m.I'm really the only person using it at this point. Our organization is pushing migrating to RTC and I've kind of been the guinea pig. But in talking with other people on other servers, it seems to be pretty standard that scm is really slow. I'm hoping to try GIT integration at some point so we have a command line available. Not sure what we lose in doing that however.
Donald Nong
Oct 01 '14, 1:13 a.m.The fact that even the login process took a such long time leads me to believe that the issue is network related. Looking at those numbers, I have a feeling that you hit a timeout of 15 seconds. It should be easy to capture network trace using tcpdump and analyze it with Wireshark in order to figure it out.
Brett Waldo
Oct 01 '14, 6:59 a.m.So this morning when I came in to try the tcpdump, but speeds were dramatically increased. I presume this was due to the nightly reboot of the client machine. Time to list workspaces/components/streams was < 1 sec. Logout was instant, First login was 5-10 seconds, subsequent ones were < 5 seconds.
The load command is still pretty slow. The network is GB and downloading 200MB should take much less than 4 minutes. After the load, I couldn't do a status command with the error message about another process has locked the file and could not initialize. Running a ps -aef | grep scm showed two instances of
/tcs/cots/rtc/jazz/scmtools/eclipse/scm --config /home/bwaldo/.jazz-scm daemon start --connection-timeout 120000 --inactive-timeout 7200000
I've seen the number of these grow to 4 or 5. I killed this process and then lscm got much slower.
So the question is, what is this process, should there be multiple of them? Why does killing one cause subsequent ones to be so slow?
Evan Hughes
JAZZ DEVELOPER Nov 18 '14, 11:56 a.m.Those processes are intended to speed up the operation of 'lscm', making it faster to run than 'scm'. Each one runs as a daemon and should only be associated with one sandbox at a time. The next time you see slowness or multiple 'scm' instances, could you get a listing of the daemons along with their associated sandboxes?
That shows two daemons running in Eclipse, each with a single sandbox.You do that by running 'scm list daemons', e.g:
In order of 'lscm' to find daemons, it queries directories in ~/.jazz-scm. Does your home directory exist, and is it on a filesystem that provides consisting locking behaviour? Is your sandbox on a filesystem that supports consistent locking?