Community
Participate
Working Groups
Build Identifier: A project with more than 15.000 files in the svn repo. I did an update with tortoiseSVN. Before I tried to use subversive to update svn, but that produces a similar failure. Starting eclipse and refreshed the workspace. Eclipse starts working and 10 hours later it is still running an 100% CPU. Java VisualVM shows some lock's in the SVN code happen all the time: - locked <0x21d86b58> (a org.eclipse.team.svn.core.svnstorage.SVNRemoteStorage) Reproducible: Always Steps to Reproduce: 1. svn repo with more than 15.000 files and folders. doing an update outside (svn up). around 1,3MB of changes, according to tortoisesvn. 2. starting eclipse und refresh. 3. eclipse uses 100% of one CPU core, even after 10 hours, it doesn't complete.
Created attachment 160850 [details] threaddump 1
Created attachment 160852 [details] threaddump 2
Created attachment 160859 [details] threaddump 3
Created attachment 160860 [details] threaddump 4
Created attachment 160862 [details] threaddump 5
Created attachment 160864 [details] threaddump 6 - 10 hours later, after the first 4 and 5 threaddump 4 short after eclipse uses 100% CUP threaddump 5 20 minutes later threaddump 6 10 hours later
As a workaround you can tune performance preferences: Window/Preferences/Team/SVN/Performance and unselect 'Compute deep outgoing state' option. This should significantly increase performance; this option is made for such cases. There can be some reasons why performance is so slow: 1. other programs monitor or lock files in SVN administrative folders (.svn), e.g. AntiVirus software. So please try to disable such programs (or try to configure your virus scanner so that it ignores .svn directories) during project refresh. 2. there can be problem because of you have slow computer or you have programs which intensively work with your hard drive in parallel. 3. there are known problems with SVN itself if there are more 1000 files in a folder. Also if it's possible please provide a profiling snapshot, e.g. by using Java VisualVM. Please, try it with JavaHL connector.
(In reply to comment #7) > As a workaround you can tune performance preferences: > Window/Preferences/Team/SVN/Performance and unselect 'Compute deep outgoing > state' option. This should significantly increase performance; this option is > made for such cases. This option is already disabled. > There can be some reasons why performance is so slow: > 1. other programs monitor or lock files in SVN administrative folders (.svn), > e.g. AntiVirus software. So please try to disable such programs (or try to > configure your virus scanner so that it ignores .svn directories) during > project refresh. Symantec Antivirus is aktiv. I will do a test without it. But that take some time. > 2. there can be problem because of you have slow computer or you have programs > which intensively work with your hard drive in parallel. There was no other programm running this hard. I'm aware that this task uses a lot file IO and other systems resources. > 3. there are known problems with SVN itself if there are more 1000 files in a > folder. I'm not aware of any folder that has that much files. > Also if it's possible please provide a profiling snapshot, e.g. by using Java > VisualVM. > Please, try it with JavaHL connector. I did some tests: Subversive (with all options in the performance tab disabled): 1. Subversive with SVNKit 1.3.2: Eclipse starts, after e.g. 1 minute there is _no_ process in the "Process" Tab of Eclipse, but still is uses a lot of file IO, CPU 100% and a lot of GC activity. 2. Subversive with Native Java HL (Subversion 1.6.6): Eclipse starts, after e.g. 1 minute there is _no_ process in the "Process" Tab of Eclipse, no further file IO or CPU usage. Now with Subclipse (Not Subversive!) 3. Subclipse with SVNKit 1.3.2: Eclipse starts, after e.g. 1 minute there is _no_ process in the "Process" Tab of Eclipse, no further file IO or CPU usage. end of the current tests. Summary: subversive with Native Java HL is working as well as Subclipse with SVNKit.
While I did the test with subversive and SVNKit I got one threaddump with one thread in the state of "waiting for monitor entry" for "0x1e0211a8": "Worker-9" prio=6 tid=0x4db59400 nid=0x1040 waiting for monitor entry [0x5394f000] java.lang.Thread.State: BLOCKED (on object monitor) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber.getSyncInfo(AbstractSVNSubscriber.java:145) - waiting to lock <0x1e0211a8> (a java.util.HashSet) at org.eclipse.team.core.subscribers.Subscriber.getDiff(Subscriber.java:370) at org.eclipse.team.internal.core.subscribers.SubscriberChangeSetManager.getDiff(SubscriberChangeSetManager.java:302) at org.eclipse.team.internal.core.subscribers.SubscriberChangeSetManager$EventHandler.handleChange(SubscriberChangeSetManager.java:183) at org.eclipse.team.internal.core.subscribers.SubscriberChangeSetManager$EventHandler.doDispatchEvents(SubscriberChangeSetManager.java:80) at org.eclipse.team.internal.core.BackgroundEventHandler.dispatchEvents(BackgroundEventHandler.java:394) at org.eclipse.team.internal.core.BackgroundEventHandler.processEvents(BackgroundEventHandler.java:374) at org.eclipse.team.internal.core.BackgroundEventHandler$1.run(BackgroundEventHandler.java:203) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Locked ownable synchronizers: - None #################### The same Hashmap is also locked in this Thread: "SVN-PJLQ1" prio=6 tid=0x4d41e400 nid=0x11a8 runnable [0x4fd9f000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:106) at java.io.FileReader.<init>(FileReader.java:55) at org.tmatesoft.svn.core.internal.wc.SVNConfigFile.doLoad(SVNConfigFile.java:254) at org.tmatesoft.svn.core.internal.wc.SVNConfigFile.load(SVNConfigFile.java:223) at org.tmatesoft.svn.core.internal.wc.SVNConfigFile.getPropertyValue(SVNConfigFile.java:73) at org.tmatesoft.svn.core.internal.wc.SVNCompositeConfigFile.getPropertyValue(SVNCompositeConfigFile.java:64) at org.tmatesoft.svn.core.internal.wc.DefaultSVNOptions.getIgnorePatterns(DefaultSVNOptions.java:236) at org.tmatesoft.svn.core.internal.wc.SVNStatusEditor.getGlobalIgnores(SVNStatusEditor.java:371) at org.tmatesoft.svn.core.internal.wc.SVNStatusEditor.<init>(SVNStatusEditor.java:74) at org.tmatesoft.svn.core.wc.SVNStatusClient.doStatus(SVNStatusClient.java:375) at org.tmatesoft.svn.core.javahl.SVNClientImpl.status(SVNClientImpl.java:300) at org.tmatesoft.svn.core.javahl.SVNClientImpl.status(SVNClientImpl.java:282) at org.polarion.team.svn.connector.svnkit.SVNKitConnector.status(SVNKitConnector.java:336) at org.eclipse.team.svn.core.extension.factory.ThreadNameModifier.status(ThreadNameModifier.java:608) at org.eclipse.team.svn.core.utility.SVNUtility.status(SVNUtility.java:297) at org.eclipse.team.svn.core.utility.SVNUtility.getSVNInfoForNotConnected(SVNUtility.java:865) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber.resourcesStateChangedImpl(AbstractSVNSubscriber.java:243) - locked <0x1e0211a8> (a java.util.HashSet) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber.resourcesStateChanged(AbstractSVNSubscriber.java:201) at org.eclipse.team.svn.core.svnstorage.SVNRemoteStorage$3.runImpl(SVNRemoteStorage.java:184) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:77) at org.eclipse.team.svn.core.operation.LoggedOperation.run(LoggedOperation.java:38) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility$1$1.run(ProgressMonitorUtility.java:60) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility$1.run(ProgressMonitorUtility.java:58) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Is it correct that the thread both access that HashSet? Has this something to do with the Team Synchronizing View?
Jochen, thanks for your tests. As I can see that after disabling 'Compute deep outgoing state' option, you have acceptable performance, processing takes about a minute, I think it's ok. As for comment# 9: this comment talks about different problem which doesn't relate to original one provided in description. It's better to create a new task for it and discuss it there, because it's not very good to mix different things. Anyway: what exact problem do you have, e.g. deadlock (or you just asking about Subversive code: why we made synchronized block there)?
Close the bug as Subversive has tuning options specifically created for these kinds of problems which resolve current problem.
Created attachment 248652 [details] threaddump Worker-83 SVNRemoteStorage.refreshLocalResourceImpl I can confirm this behaviour. After opening a multi-module reactor project with 94501 files eclipse become unusable due refreshing local resources blocks all subsequent operations. Worker-83 of attached thread dump takes 2 hours to complete. 'Compute deep outgoing state' is disabled too. SVNRemoteStorage.refreshLocalResourceImpl should perform much better. Eclipse Luna SR1 Subversive SVN Team Provider: 2.0.1.I20140907-1700 Native JavaHL 1.8 Implementation (Optional): 4.1.0.I20140907-1700 Native Library: Collabenet Subversion 1.8.10 (Windows 64-bit) binaries In order to avoid killing eclipse each time 'refreshLocalResourceImpl' freaks out I sometimes kill this Refreshing Worker Thread described here http://stackoverflow.com/questions/11610902/how-to-kill-a-java-thread-using-visualvm-or-using-a-unix-command but this isn't satisfiable.
