You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@nutch.apache.org by Bogdan Kecman <bo...@alteray.com> on 2006/09/09 04:01:41 UTC

RE: Nutch fetcher "waiting" inbetween fetch

> > Here we're using one machine for fetching (exclusive at the moment) 
> > with about 50 fetchers and a local Bind-resolver in 
> caching-nameserver setup.
> > Bandwidth of the fetchers is 5 to 10mbit inbound roughly.
> >
> > What I see is that during fetching java is taking 99.9% cpu (all 
> > userland). At the point where the server "stalls" this changes to 
> > 99.9% on system-usage (writing something  to disc?). It stalls for 
> > about 30 seconds or a bit more.
> This sounds suspiciously like a pagedaemon - what's the swap usage?
 
             total       used       free     shared    buffers     cached
Mem:       2074736    1376656     698080          0      31460     866320
-/+ buffers/cache:     478876    1595860
Swap:      1052248          0    1052248

Looks pretty free to me

> Get a thread dump (kill -SIGQUIT) from that java process. 

I have no idea how to interpret this but here it is (running 500 fetcher threads 1 thread per site, 1500 sites)


Full thread dump Java HotSpot(TM) Server VM (1.5.0_07-b03 mixed mode):
"DestroyJavaVM" prio=1 tid=0x6c2467b0 nid=0x2b10 waiting on condition [0x00000000..0xbfffcdb0]

"fetcher499" prio=1 tid=0x6c29d8e0 nid=0x2f23 waiting for monitor entry [0x5bed6000..0x5bed6f30]
        at org.apache.nutch.fetcher.Fetcher$FetcherThread.outputPage(Fetcher.java:277)
        - waiting to lock <0x73054438> (a org.apache.nutch.io.ArrayFile$Writer)
        at org.apache.nutch.fetcher.Fetcher$FetcherThread.handleFetch(Fetcher.java:261)
        at org.apache.nutch.fetcher.Fetcher$FetcherThread.run(Fetcher.java:193)
...
Same for all 500 fetchers
...
"fetcher0" prio=1 tid=0x6c243170 nid=0x2d2e waiting for monitor entry [0x5c2df000..0x5c2df1b0]
        at org.apache.nutch.fetcher.Fetcher$FetcherThread.outputPage(Fetcher.java:277)
        - waiting to lock <0x73054438> (a org.apache.nutch.io.ArrayFile$Writer)
        at org.apache.nutch.fetcher.Fetcher$FetcherThread.handleFetch(Fetcher.java:261)
        at org.apache.nutch.fetcher.Fetcher$FetcherThread.run(Fetcher.java:148)

"MultiThreadedHttpConnectionManager cleanup" daemon prio=1 tid=0x6d4736b8 nid=0x2c94 in Object.wait() [0x60c73000..0x60c73f30]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x72e776a0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x72e776a0> (a java.lang.ref.ReferenceQueue$Lock)
        at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ReferenceQueueThread.run(MultiThreadedHttpConnectionManager.java:1082)

"Low Memory Detector" daemon prio=1 tid=0x6e100af0 nid=0x2b20 runnable [0x00000000..0x00000000]
"CompilerThread1" daemon prio=1 tid=0x08120068 nid=0x2b1f waiting on condition [0x00000000..0x6e2822d8]
"CompilerThread0" daemon prio=1 tid=0x0811eff8 nid=0x2b1e waiting on condition [0x00000000..0x6e303358]
"AdapterThread" daemon prio=1 tid=0x0811df20 nid=0x2b1d waiting on condition [0x00000000..0x00000000]
"Signal Dispatcher" daemon prio=1 tid=0x0811d020 nid=0x2b1c waiting on condition [0x00000000..0x00000000]
"Finalizer" daemon prio=1 tid=0x081137a8 nid=0x2b1b in Object.wait() [0x6e686000..0x6e686eb0]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x72db4438> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x72db4438> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=1 tid=0x08112100 nid=0x2b1a in Object.wait() [0x6e707000..0x6e707f30]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x72d99e78> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:474)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x72d99e78> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=1 tid=0x0810fc30 nid=0x2b19 runnable
"GC task thread#0 (ParallelGC)" prio=1 tid=0x08076fb0 nid=0x2b15 runnable
"GC task thread#1 (ParallelGC)" prio=1 tid=0x08077c00 nid=0x2b16 runnable
"GC task thread#2 (ParallelGC)" prio=1 tid=0x08078838 nid=0x2b17 runnable
"GC task thread#3 (ParallelGC)" prio=1 tid=0x08079470 nid=0x2b18 runnable
"VM Periodic Task Thread" prio=1 tid=0x6e1020a0 nid=0x2b21 waiting on condition



> When you look at top(1), which of the pid states is the most 
> common? R (runnable) or D (disk-wait)? And check the swap 
> usage, as mentioned above.

top - 20:53:48 up 2 days,  9:57,  1 user,  load average: 3.94, 3.63, 2.82
Tasks:  88 total,   1 running,  87 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.5% us,  0.7% sy,  0.0% ni, 98.8% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:   2074736k total,  1516564k used,   558172k free,    31636k buffers
Swap:  1052248k total,        0k used,  1052248k free,   937644k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
12254 work      16   0 1537m 376m  13m S  123 18.6  10:15.01 java