cgdecker / vogar

Automatically exported from code.google.com/p/vogar

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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