vogar insanely slow because of excessive fs traffic
GoogleCodeExporter opened this issue · comments
i finally thought to try ctrl-\ to diagnose my vogar slowness, and hey presto:
"runner-org.apache.harmony.nio.tests.java.nio.AllTests" daemon prio=10
tid=0x00007f1420039800 nid=0x6866 runnable [0x0000000042270000]
java.lang.Thread.State: RUNNABLE
at java.io.UnixFileSystem.list(Native Method)
at java.io.File.list(File.java:973)
at java.io.File.listFiles(File.java:1090)
at vogar.OutcomeStore.getXmlFiles(OutcomeStore.java:130)
at vogar.OutcomeStore.read(OutcomeStore.java:95)
at vogar.Driver.recordOutcome(Driver.java:271)
- locked <0x00007f14acbf0180> (a vogar.Driver)
at vogar.Driver.access$500(Driver.java:47)
at vogar.Driver$ActionRunner.outcome(Driver.java:465)
at vogar.monitor.SocketHostMonitor$ClientXmlHandler.endElement(SocketHostMonitor.java:240)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2938)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
at vogar.monitor.SocketHostMonitor.monitor(SocketHostMonitor.java:128)
at vogar.Driver$ActionRunner.execute(Driver.java:378)
at vogar.Driver$ActionRunner.run(Driver.java:343)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
another win for poor man's profiling.
the temporary work-around is to comment out --results-dir in ~/.vogarconfig.
the fix would be to check this once, at the end, not once for each outcome.
Original issue reported on code.google.com by e...@google.com
on 13 Sep 2010 at 9:48
we shouldn't be blocking on this work; we can kick these off in parallel and
have them running while we continue to run other tests.
Original comment by e...@google.com
on 17 Sep 2010 at 5:13
I changed the structure of the test history files.
Original comment by jessewil...@google.com
on 21 Feb 2011 at 1:14
- Changed state: Fixed