http-thread Pool / Anzahl Verbindungen [closed]

Hier finden YaCy User Hilfe wenn was nicht funktioniert oder anders funktioniert als man dachte. Bei offensichtlichen Fehlern diese bitte gleich in die Bugs (http://bugs.yacy.net) eintragen.
Forumsregeln
In diesem Forum geht es um Benutzungsprobleme und Anfragen für Hilfe. Wird dabei ein Bug identifiziert, wird der thread zur Bearbeitung in die Bug-Sektion verschoben. Wer hier also einen Thread eingestellt hat und ihn vermisst, wird ihn sicherlich in der Bug-Sektion wiederfinden.

http-thread Pool / Anzahl Verbindungen [closed]

Beitragvon Vega » Do Okt 29, 2009 4:22 pm

Hallo, in Version 0.92/6436 ist mir folgendes aufgefallen:

in der Status-Sidebar in der Adminconsole werden nach ca. 1/2 Tag Betrieb 170 Verbindungen angezeigt, es ist auch schon vorgekommen das dieser Wert auf über 200 gestiegen ist. Klicke ich jetzt auf in der Sidebar auf "Eingehende Verbindungen" werden mir nur 30 - 40 Verbindungen angezeigt, auf der Seite PerformanceQueues_p.html werden aber wieder die 170 Verbindungen angezeigt ? - Das finde ich etwas verwirrend, oder hab ich da einen Denkfehler - Screnshots und Threaddump hab ich mal angehängt....
Der Peer ist in Metager eingebunden, die Suma-EV Peers haben aber dieses Verhalten nicht - SVN: 0.91/6388

Code: Alles auswählen
************* Start Thread Dump Thu Oct 29 16:19:01 CET 2009 *******************

YaCy Version: 0.92/6436
Assigned   Memory = 1677721600
Used       Memory = 741135720
Available  Memory = 936585880


THREADS WITH STATES: BLOCKED


THREADS WITH STATES: RUNNABLE

Thread= Reference Handler daemon id=8 RUNNABLE
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:79)


Thread= httpd:8080 id=117 RUNNABLE
at java.net.ServerSocket.accept(ServerSocket.java:421)
at de.anomic.server.serverCore.job(serverCore.java:329)
at net.yacy.kelondro.workflow.AbstractBusyThread.run(AbstractBusyThread.java:145)


Thread= Finalizer daemon id=7 RUNNABLE
at java.lang.Thread.run(Thread.java:619)


Thread= Session_188.40.55.86:57150#0 id=97941 RUNNABLE
Thread= Session_141.52.175.11:52215#2 id=97796 RUNNABLE
Thread= Session_78.42.33.9:63672#3 id=97785 RUNNABLE
Thread= Session_85.178.114.36:46078#2 id=97786 RUNNABLE
Thread= Session_84.60.187.177:45034#3 id=97778 RUNNABLE
Thread= Session_141.52.175.32:56575#0 id=97779 RUNNABLE
Thread= Session_134.107.24.49:39752#5 id=97816 RUNNABLE
Thread= Session_152.81.11.90:41624#2 id=97797 RUNNABLE
Thread= Session_217.7.17.163:58506#2 id=97800 RUNNABLE
Thread= Session_84.63.126.126:56129#3 id=97757 RUNNABLE
Thread= Session_92.227.87.171:42104#7 id=97756 RUNNABLE
Thread= Session_217.7.17.163:60523#3 id=97755 RUNNABLE
Thread= Session_212.117.110.162:60909#0 id=97753 RUNNABLE
Thread= Session_141.52.175.15:37861#7 id=97751 RUNNABLE
Thread= Session_141.52.175.54:42744#8 id=97774 RUNNABLE
Thread= Session_217.7.17.163:64524#3 id=97764 RUNNABLE
Thread= Session_85.10.210.99:60562#3 id=97758 RUNNABLE
Thread= Session_84.60.187.177:36890#1 id=97890 RUNNABLE
Thread= Session_88.73.26.45:33849#0 id=97906 RUNNABLE
Thread= Session_141.52.175.84:60296#4 id=97840 RUNNABLE
Thread= Session_95.118.95.102:60333#3 id=97858 RUNNABLE
at jrockit.net.SocketNativeIO.readBytesPinned(Native Method)
at jrockit.net.SocketNativeIO.socketRead(SocketNativeIO.java:46)
at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.net.SocketInputStream.read(SocketInputStream.java:182)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at java.io.PushbackInputStream.read(PushbackInputStream.java:122)
at de.anomic.server.serverCore.receive(serverCore.java:831)
at de.anomic.server.serverCore$Session.readLine(serverCore.java:573)
at de.anomic.server.serverCore$Session.listen(serverCore.java:680)
at de.anomic.server.serverCore$Session.run(serverCore.java:627)


Thread= Session_217.7.17.163:55954#1 id=97915 RUNNABLE
at java.lang.Thread.getAllStackTraces(Thread.java:1487)
at Threaddump_p.respond(Threaddump_p.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at de.anomic.http.server.HTTPDFileHandler.invokeServlet(HTTPDFileHandler.java:1189)
at de.anomic.http.server.HTTPDFileHandler.doResponse(HTTPDFileHandler.java:756)
at de.anomic.http.server.HTTPDFileHandler.doGet(HTTPDFileHandler.java:245)
at de.anomic.http.server.HTTPDemon.GET(HTTPDemon.java:491)
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at de.anomic.server.serverCore$Session.listen(serverCore.java:736)
at de.anomic.server.serverCore$Session.run(serverCore.java:627)



THREADS WITH STATES: TIMED_WAITING

Thread= de.anomic.yacy.yacyCore.publishSeedList id=112 TIMED_WAITING
Thread= de.anomic.crawler.CrawlQueues.remoteCrawlLoaderJob id=110 TIMED_WAITING
Thread= de.anomic.search.Switchboard.surrogateProcess id=107 TIMED_WAITING
Thread= de.anomic.search.Switchboard.dhtTransferJob id=114 TIMED_WAITING
Thread= de.anomic.crawler.CrawlQueues.remoteTriggeredCrawlJob id=108 TIMED_WAITING
Thread= de.anomic.search.Switchboard.cleanupJob id=106 TIMED_WAITING
Thread= de.anomic.yacy.yacyCore.peerPing id=113 TIMED_WAITING
Thread= de.anomic.data.bookmarksDB.autoReCrawl id=65 TIMED_WAITING
at java.lang.Thread.sleep(Native Method)
at net.yacy.kelondro.workflow.AbstractBusyThread.ratz(AbstractBusyThread.java:201)
at net.yacy.kelondro.workflow.AbstractBusyThread.run(AbstractBusyThread.java:166)


Thread= de.anomic.crawler.CrawlQueues.coreCrawlJob id=111 TIMED_WAITING
at java.lang.Thread.sleep(Native Method)
at net.yacy.kelondro.workflow.AbstractBusyThread.ratz(AbstractBusyThread.java:201)
at net.yacy.kelondro.workflow.AbstractBusyThread.run(AbstractBusyThread.java:129)


Thread= Thread-1 id=12 TIMED_WAITING
at java.lang.Thread.sleep(Native Method)
at net.yacy.kelondro.util.MemoryTracker.run(MemoryTracker.java:64)



THREADS WITH STATES: WAITING

Thread= pool-662-thread-1 id=53652 WAITING
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
at net.yacy.kelondro.order.Digest$md5FilechunkConsumer.call(Digest.java:243)
at net.yacy.kelondro.order.Digest$md5FilechunkConsumer.call(Digest.java:201)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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)


Thread= MultiThreadedHttpConnectionManager cleanup daemon id=17 WAITING
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ReferenceQueueThread.run(MultiThreadedHttpConnectionManager.java:1122)


Thread= Log Runner id=11 WAITING
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
at net.yacy.kelondro.logging.Log$logRunner.run(Log.java:316)


Thread= Main Thread id=1 WAITING
at java.util.concurrent.Semaphore.acquire(Semaphore.java:286)
at de.anomic.search.Switchboard.waitForShutdown(Switchboard.java:2148)
at net.yacy.yacy.startup(yacy.java:399)
at net.yacy.yacy.main(yacy.java:1033)


Thread= Thread-3 id=16 WAITING
at java.util.concurrent.Semaphore.acquire(Semaphore.java:286)
at net.yacy.kelondro.rwi.IODispatcher.run(IODispatcher.java:145)


Thread= SplitTable-Discovery id=20 WAITING
Thread= SplitTable-Discovery id=19 WAITING
Thread= SplitTable-Discovery id=18 WAITING
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
at net.yacy.kelondro.table.SplitTable$Discovery.run(SplitTable.java:414)


Thread= text.index_pool-1-thread-441 id=13090 WAITING
Thread= Java2D Disposer daemon id=11743 WAITING
Thread= text.index_pool-1-thread-440 id=13089 WAITING
Thread= text.index_pool-1-thread-439 id=13088 WAITING
at java.lang.Thread.run(Thread.java:619)


Thread= job_pool-1-thread-18 id=71 WAITING
Thread= parseDocument_pool-1-thread-34 id=103 WAITING
Thread= storeDocumentIndex_pool-1-thread-16 id=46 WAITING
Thread= job_pool-1-thread-19 id=73 WAITING
Thread= storeDocumentIndex_pool-1-thread-9 id=32 WAITING
Thread= storeDocumentIndex_pool-1-thread-15 id=44 WAITING
Thread= job_pool-1-thread-21 id=77 WAITING
Thread= webStructureAnalysis_pool-1-thread-26 id=87 WAITING
Thread= parseDocument_pool-1-thread-35 id=105 WAITING
Thread= condenseDocument_pool-1-thread-30 id=95 WAITING
Thread= storeDocumentIndex_pool-1-thread-12 id=38 WAITING
Thread= storeDocumentIndex_pool-1-thread-10 id=34 WAITING
Thread= parseDocument_pool-1-thread-32 id=99 WAITING
Thread= job_pool-1-thread-20 id=75 WAITING
Thread= storeDocumentIndex_pool-1-thread-14 id=42 WAITING
Thread= job_pool-1-thread-23 id=81 WAITING
Thread= storeDocumentIndex_pool-1-thread-13 id=40 WAITING
Thread= webStructureAnalysis_pool-1-thread-25 id=85 WAITING
Thread= condenseDocument_pool-1-thread-29 id=93 WAITING
Thread= storeDocumentIndex_pool-1-thread-8 id=30 WAITING
Thread= parseDocument_pool-1-thread-33 id=101 WAITING
Thread= storeDocumentIndex_pool-1-thread-24 id=83 WAITING
Thread= webStructureAnalysis_pool-1-thread-27 id=89 WAITING
Thread= storeDocumentIndex_pool-1-thread-11 id=36 WAITING
Thread= job_pool-1-thread-17 id=69 WAITING
Thread= condenseDocument_pool-1-thread-28 id=91 WAITING
Thread= parseDocument_pool-1-thread-31 id=97 WAITING
Thread= job_pool-1-thread-22 id=79 WAITING
Thread= storeDocumentIndex_pool-1-thread-7 id=28 WAITING
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
at net.yacy.kelondro.workflow.WorkflowProcessor.take(WorkflowProcessor.java:99)
at net.yacy.kelondro.workflow.AbstractBlockingThread.run(AbstractBlockingThread.java:55)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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)



THREADS WITH STATES: NEW


THREADS WITH STATES: TERMINATED


************* End Thread Dump Thu Oct 29 16:19:01 CET 2009 *******************


Gruß,
Thomas
Dateianhänge
YacyC3.png
YacyC3.png (135.47 KiB) 1286-mal betrachtet
YacyC2.png
YacyC2.png (97.23 KiB) 1285-mal betrachtet
YacyC1.png
YacyC1.png (168.82 KiB) 1281-mal betrachtet
Zuletzt geändert von Vega am Do Nov 05, 2009 7:45 pm, insgesamt 1-mal geändert.
Vega
 
Beiträge: 824
Registriert: Mi Jun 27, 2007 3:34 pm
Wohnort: Dresden

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon Orbiter » Do Okt 29, 2009 5:31 pm

ich befürchte wir niemanden mehr, der sich richtig tief in das httpd-Thema vertiefen kann, oder? wäre sehr hilfreich. Ich habe vor das mit Hilfe von einem 'richtigen' http Server zu lösen, und dabei habe ich jetty im Auge. Da kann man den Server-Teil als library raus nehmen, das ist nicht groß, und in einen eigenen Server packen.
Ich visiere das für eine nach-1.0er Version an. Das ist mir vorher zu heftig. Damit der Übergang erleichtert wird, habe ich beim Refactoring die letzte Zeit (was noch nicht abgeschlossen ist) die Klassen aus dem Serverpackage raus genommen, so weit es ging, damit man nur noch das dann entfernen kann was zum alten Server gehörte.
Hilfe hierbei ist natürlich willkommen.
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon Vega » Do Okt 29, 2009 5:43 pm

@ Michael - Es hat ja schon einmal funktioniert, wie gesagt in SVN: 0.91/6388 tritt dieses Verhalten ja noch nicht auf, irgendwas muss also zwischendurch passiert sein. - Außer das ich die Java-VM gewechselt habe, das drehe ich heute Abend mal zurück um das ausschließen zu können.
Ich kann Dir da leider nicht wirklich helfen, meine Fähigkeiten als Programmierer sind - vorsichtig ausgedrückt - rudimentär. Wäre schön wenn jemand anderes hier mit helfen könnte... Jetty ist ok, das kenne ich :-) - zum Httpd-Server hätte ich eh noch ein paar Wünsche, es ist ja bald Weihnachten - ich mach mal eine Liste :D ....

Gruß,
Thomas
Vega
 
Beiträge: 824
Registriert: Mi Jun 27, 2007 3:34 pm
Wohnort: Dresden

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon Vega » Mo Nov 02, 2009 8:03 am

Ich habe das mal weiter beobachtet, auch ohne Metager-Einbindung steigt die Zahl der Verbindungen langsam an.
Ich denke es liegt an den ausgehenden Verbindungen, die eingehenden werden korrekt angezeigt - siehe Screenshot.
Mit täglichem Neustart könnte man das Umgehen, das ist aber keine Lösung-vor allem nicht in Verbindung mit Metager, da hägt der Peer innerhalb kurzer Zeit.
Kann das jemand von euch nachstellen, hat noch jemand diesen Effek ?


Code: Alles auswählen
************* Start Thread Dump Mon Nov 02 07:57:28 CET 2009 *******************

YaCy Version: 0.92/6441
Assigned   Memory = 1536098304
Used       Memory = 1401199536
Available  Memory = 134898768


THREADS WITH STATES: BLOCKED


THREADS WITH STATES: RUNNABLE

Thread= Session_141.52.175.62:43715#3 id=76043 RUNNABLE
Thread= Session_141.52.175.15:36297#1 id=76046 RUNNABLE
Thread= Session_141.52.175.52:56794#3 id=76050 RUNNABLE
Thread= Session_131.246.103.128:36450#1 id=76015 RUNNABLE
Thread= Session_85.214.147.140:48599#11 id=76018 RUNNABLE
Thread= Session_141.52.175.32:50188#3 id=76017 RUNNABLE
Thread= Session_141.52.175.46:38308#1 id=76002 RUNNABLE
Thread= Session_87.155.251.149:43132#3 id=76011 RUNNABLE
Thread= Session_85.178.101.81:40805#12 id=76008 RUNNABLE
Thread= Session_78.34.171.147:55188#1 id=76036 RUNNABLE
Thread= Session_141.52.175.16:40492#1 id=76030 RUNNABLE
Thread= Session_129.69.141.78:55101#0 id=76042 RUNNABLE
Thread= Session_141.52.175.54:59070#7 id=76024 RUNNABLE
Thread= Session_85.178.108.171:49038#19 id=76020 RUNNABLE
Thread= Session_79.195.175.97:1583#1 id=76029 RUNNABLE
Thread= Session_85.25.150.190:35127#5 id=76025 RUNNABLE
at java.io.PushbackInputStream.read(Unknown Source)
at de.anomic.server.serverCore.receive(serverCore.java:831)
at de.anomic.server.serverCore$Session.readLine(serverCore.java:573)
at de.anomic.server.serverCore$Session.listen(serverCore.java:680)
at de.anomic.server.serverCore$Session.run(serverCore.java:627)


Thread= httpd:8080 id=116 RUNNABLE
at java.net.ServerSocket.accept(Unknown Source)
at de.anomic.server.serverCore.job(serverCore.java:329)
at net.yacy.kelondro.workflow.AbstractBusyThread.run(AbstractBusyThread.java:145)


Thread= Session_84.179.83.176:49897#12 id=76041 RUNNABLE
at java.lang.Thread.getAllStackTraces(Unknown Source)
at Threaddump_p.respond(Threaddump_p.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at de.anomic.http.server.HTTPDFileHandler.invokeServlet(HTTPDFileHandler.java:1189)
at de.anomic.http.server.HTTPDFileHandler.doResponse(HTTPDFileHandler.java:756)
at de.anomic.http.server.HTTPDFileHandler.doGet(HTTPDFileHandler.java:245)
at de.anomic.http.server.HTTPDemon.GET(HTTPDemon.java:491)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at de.anomic.server.serverCore$Session.listen(serverCore.java:736)
at de.anomic.server.serverCore$Session.run(serverCore.java:627)



THREADS WITH STATES: TIMED_WAITING

Thread= de.anomic.search.Switchboard.cleanupJob id=105 TIMED_WAITING
Thread= de.anomic.crawler.CrawlQueues.remoteCrawlLoaderJob id=108 TIMED_WAITING
Thread= de.anomic.crawler.CrawlQueues.coreCrawlJob id=109 TIMED_WAITING
Thread= de.anomic.search.Switchboard.surrogateProcess id=106 TIMED_WAITING
Thread= de.anomic.data.bookmarksDB.autoReCrawl id=63 TIMED_WAITING
Thread= de.anomic.yacy.yacyCore.publishSeedList id=110 TIMED_WAITING
Thread= de.anomic.crawler.CrawlQueues.remoteTriggeredCrawlJob id=107 TIMED_WAITING
Thread= de.anomic.yacy.yacyCore.peerPing id=111 TIMED_WAITING
Thread= de.anomic.search.Switchboard.dhtTransferJob id=112 TIMED_WAITING
at java.lang.Thread.sleep(Native Method)
at net.yacy.kelondro.workflow.AbstractBusyThread.ratz(AbstractBusyThread.java:201)
at net.yacy.kelondro.workflow.AbstractBusyThread.run(AbstractBusyThread.java:166)


Thread= partition_pool-1-thread-643 id=76003 TIMED_WAITING
Thread= partition_pool-1-thread-641 id=75948 TIMED_WAITING
Thread= sorting_pool-1-thread-634 id=75663 TIMED_WAITING
Thread= sorting_pool-1-thread-642 id=75969 TIMED_WAITING
at java.lang.Thread.run(Unknown Source)


Thread= Thread-1 id=10 TIMED_WAITING
at java.lang.Thread.sleep(Native Method)
at net.yacy.kelondro.util.MemoryTracker.run(MemoryTracker.java:64)



THREADS WITH STATES: WAITING

Thread= main id=1 WAITING
at java.util.concurrent.Semaphore.acquire(Unknown Source)
at de.anomic.search.Switchboard.waitForShutdown(Switchboard.java:2141)
at net.yacy.yacy.startup(yacy.java:399)
at net.yacy.yacy.main(yacy.java:1033)


Thread= MultiThreadedHttpConnectionManager cleanup daemon id=15 WAITING
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ReferenceQueueThread.run(MultiThreadedHttpConnectionManager.java:1122)


Thread= Finalizer daemon id=3 WAITING
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)


Thread= text.index_pool-1-thread-199 id=14837 WAITING
Thread= text.index_pool-1-thread-200 id=14838 WAITING
Thread= text.index_pool-1-thread-201 id=14839 WAITING
Thread= Java2D Disposer daemon id=144 WAITING
at java.lang.Thread.run(Unknown Source)


Thread= Reference Handler daemon id=2 WAITING
at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)


Thread= storeDocumentIndex_pool-1-thread-16 id=44 WAITING
Thread= job_pool-1-thread-18 id=69 WAITING
Thread= job_pool-1-thread-20 id=73 WAITING
Thread= storeDocumentIndex_pool-1-thread-10 id=32 WAITING
Thread= parseDocument_pool-1-thread-33 id=100 WAITING
Thread= webStructureAnalysis_pool-1-thread-26 id=86 WAITING
Thread= parseDocument_pool-1-thread-34 id=102 WAITING
Thread= storeDocumentIndex_pool-1-thread-12 id=36 WAITING
Thread= storeDocumentIndex_pool-1-thread-8 id=28 WAITING
Thread= parseDocument_pool-1-thread-35 id=104 WAITING
Thread= webStructureAnalysis_pool-1-thread-25 id=84 WAITING
Thread= storeDocumentIndex_pool-1-thread-14 id=40 WAITING
Thread= parseDocument_pool-1-thread-32 id=98 WAITING
Thread= job_pool-1-thread-21 id=75 WAITING
Thread= storeDocumentIndex_pool-1-thread-24 id=81 WAITING
Thread= job_pool-1-thread-19 id=71 WAITING
Thread= storeDocumentIndex_pool-1-thread-11 id=34 WAITING
Thread= condenseDocument_pool-1-thread-29 id=92 WAITING
Thread= condenseDocument_pool-1-thread-30 id=94 WAITING
Thread= storeDocumentIndex_pool-1-thread-13 id=38 WAITING
Thread= condenseDocument_pool-1-thread-28 id=90 WAITING
Thread= storeDocumentIndex_pool-1-thread-9 id=30 WAITING
Thread= storeDocumentIndex_pool-1-thread-15 id=42 WAITING
Thread= parseDocument_pool-1-thread-31 id=96 WAITING
Thread= job_pool-1-thread-17 id=67 WAITING
Thread= storeDocumentIndex_pool-1-thread-7 id=26 WAITING
Thread= job_pool-1-thread-22 id=77 WAITING
Thread= webStructureAnalysis_pool-1-thread-27 id=88 WAITING
Thread= job_pool-1-thread-23 id=79 WAITING
at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source)
at net.yacy.kelondro.workflow.WorkflowProcessor.take(WorkflowProcessor.java:99)
at net.yacy.kelondro.workflow.AbstractBlockingThread.run(AbstractBlockingThread.java:55)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)


Thread= Log Runner id=9 WAITING
at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source)
at net.yacy.kelondro.logging.Log$logRunner.run(Log.java:316)


Thread= Thread-3 id=14 WAITING
at java.util.concurrent.Semaphore.acquire(Unknown Source)
at net.yacy.kelondro.rwi.IODispatcher.run(IODispatcher.java:145)


Thread= SplitTable-Discovery id=17 WAITING
Thread= SplitTable-Discovery id=16 WAITING
Thread= SplitTable-Discovery id=18 WAITING
at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source)
at net.yacy.kelondro.table.SplitTable$Discovery.run(SplitTable.java:414)



THREADS WITH STATES: NEW


THREADS WITH STATES: TERMINATED


************* End Thread Dump Mon Nov 02 07:57:28 CET 2009 *******************


Verbindung.png
Verbindung.png (33.38 KiB) 1199-mal betrachtet


Gruß,
Thomas
Vega
 
Beiträge: 824
Registriert: Mi Jun 27, 2007 3:34 pm
Wohnort: Dresden

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon dulcedo » Mo Nov 02, 2009 12:14 pm

Es sind definitiv die Verbindungen (mit) Schuld. Das merke ich daran dass er selbst keine mehr aufbauen kann oder keine eingehenden mehr zulässt. Der Peer an sich arbeitet weiter. Wo sind die denn "hart" limitiert, im apache, dem BS oder dem Router?
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon Vega » Mo Nov 02, 2009 1:02 pm

Danke für das Gegentesten - @Michael - kannst Du da nochmal drauf schauen ?

@dulecedo - Hart Limitiert ? In Yacy gibt es eine Einstellung dazu, und viele Router haben mit zu vielen offenen Verbindungen Probleme, das äußert sich dann in Neustarts des Routers, das Internet ist langsam etc.... - die Grenze ist aber je nach Router-Modell verschieden.

Gruß,
Thomas

dulcedo hat geschrieben:Es sind definitiv die Verbindungen (mit) Schuld. Das merke ich daran dass er selbst keine mehr aufbauen kann oder keine eingehenden mehr zulässt. Der Peer an sich arbeitet weiter. Wo sind die denn "hart" limitiert, im apache, dem BS oder dem Router?
Vega
 
Beiträge: 824
Registriert: Mi Jun 27, 2007 3:34 pm
Wohnort: Dresden

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon Lotus » Mo Nov 02, 2009 1:10 pm

Ich habe im cleanupJob gesehen, dass dort alte Verbindungen geschlossen werden. Könnte vielleicht Beobachtungen erklären, ich bin dort aber nicht weiter eingestiegen.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon dulcedo » Mo Nov 02, 2009 2:52 pm

Vega hat geschrieben:@dulecedo - Hart Limitiert ? In Yacy gibt es eine Einstellung dazu, und viele Router haben mit zu vielen offenen Verbindungen Probleme, das äußert sich dann in Neustarts des Routers, das Internet ist langsam etc.... - die Grenze ist aber je nach Router-Modell verschieden.


Der Router kann definitv mehr, auch die Verbindung dahinter. YaCY meldet aber doch dass er keine mehr verwalten oder öffnen kann. Wodurch stellt er das fest?
Meine Vermutung ist dass Apache ihm nicht genügend zur Verfügung stellt und er daher auch nicht mehr auf dem Port reagieren kann.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon Vega » Mo Nov 02, 2009 2:58 pm

Yacy - es gibt eine Einstellung in Yacy, in der wird festgelegt wieviele Verbindungen Yacy gleichzeitig halten kann - Du findest das auf der Seite: http://localhost:8080/PerformanceQueues_p.html ganz unten (httpd Session Pool) . - Yacy verwendet übrigens keinen Apache, sondern einen selbst entwickelten Webserver.

Gruß,
Thomas


dulcedo hat geschrieben:
Vega hat geschrieben:@dulecedo - Hart Limitiert ? In Yacy gibt es eine Einstellung dazu, und viele Router haben mit zu vielen offenen Verbindungen Probleme, das äußert sich dann in Neustarts des Routers, das Internet ist langsam etc.... - die Grenze ist aber je nach Router-Modell verschieden.


Der Router kann definitv mehr, auch die Verbindung dahinter. YaCY meldet aber doch dass er keine mehr verwalten oder öffnen kann. Wodurch stellt er das fest?
Meine Vermutung ist dass Apache ihm nicht genügend zur Verfügung stellt und er daher auch nicht mehr auf dem Port reagieren kann.
Vega
 
Beiträge: 824
Registriert: Mi Jun 27, 2007 3:34 pm
Wohnort: Dresden

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon dulcedo » Mo Nov 02, 2009 3:24 pm

Das ist mir klar, aber warum überschreitet YaCY dann diese Anzahl, beziehungsweise wird unerreichbar wenn erreicht.Dieses Limit doch da damit das nicht passiert. Das WAN kann die Verbindungwn verwalten, das BS kann es und YaCy beschränkt auf den eingestellten Wert. Also muss es der YaCy-Webserver sein der nicht genug davon zur Verfügung stellen kann. Oder YaCy beachtet das Limit eingehend nicht und sperrt sich selbst dann aus.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon Vega » Di Nov 03, 2009 3:54 pm

Die http-Verbindungen werden von einer Software verwaltet, DanielR hatte das implementiert bzw. umgestellt auf den Apache-HttpClient, version 3.1 wird momentan verwendet. Es gibt jedoch auch neuere Versionen, allerdings wurden da größere Änderungen vorgenommen, so das eine Implementierung dieser Versionen erheblichen Aufwand bedeutet. Es musste sich jemand einlesen und mit dem Thema grundlegend auseinandersetzen, DanielR scheint leider nicht mehr aktiv zu sein. Doc's etc. findest Du unter: http://hc.apache.org/httpclient-3.x/ .

Gruß,
Thomas

dulcedo hat geschrieben:Das ist mir klar, aber warum überschreitet YaCY dann diese Anzahl, beziehungsweise wird unerreichbar wenn erreicht.Dieses Limit doch da damit das nicht passiert. Das WAN kann die Verbindungwn verwalten, das BS kann es und YaCy beschränkt auf den eingestellten Wert. Also muss es der YaCy-Webserver sein der nicht genug davon zur Verfügung stellen kann. Oder YaCy beachtet das Limit eingehend nicht und sperrt sich selbst dann aus.
Vega
 
Beiträge: 824
Registriert: Mi Jun 27, 2007 3:34 pm
Wohnort: Dresden

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon DanielR » Di Nov 03, 2009 6:32 pm

Hi, bin nicht so richtig im Thema, aber man muss grundsätzlich die eingehenden und ausgehenden Verbindungen unterscheiden!

Im ersten Post ging es wohl um eingehende Verbindungen und Orbiter hat auch geschrieben, dass er den Server umstellen will. Da kann es imho durchaus zu Problemen kommen. An dem Yacy Http-Server habe ich damals soweit es ging nichts gemacht! Ich habe wie bereits erwähnt nur an dem Client gebastelt. Dieser wird hauptsächlich zum crawlen verwendet, grundsätzlich halt für ausgehende Verbindungen.

Wenn yacy nicht erreichbar ist, liegt das definitiv an dem Server und nicht an dem Apache httpClient. Ich habe momentan leider nicht die Zeit mich intensiv damit zu beschäftigen. Deshalb nur mal dieses Statement.

Werde die nächsten Tage nochmal vorbei gucken.
DanielR
 
Beiträge: 395
Registriert: Di Feb 12, 2008 2:22 pm

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon bluumi » Di Nov 03, 2009 8:36 pm

Klar sind mit den httpd - incomming Verbindungen gemeint, aber irgendwo macht mein Yacy auch den Schirm zu durch die Outgoing Verbindungen ...
connection.JPG
connection.JPG (113.23 KiB) 1056-mal betrachtet

Jedenfalls habe ich mal testweise die httpd - incomming auf 300 gesetzt und konnte live verfolgen wie die Incomming bei 20-30 rum "dümpelten" aber die outgoing innerhalb 5 min. auf 128 anstiegen .. und dies war dann auch das letzte "bild" was ich sah, nach dem konnte ich keine Verbindung mehr zum Peer herstellen.
"Positiv" ist, dass der Peer wenigstens noch etwas macht, DHT :)
Code: Alles auswählen
I 2009/11/03 20:28:25 INDEX-TRANSFER-DISPATCHER selectContainersToCache: selectedContainerCache was filled with 65 entries
I 2009/11/03 20:28:25 INDEX-TRANSFER-DISPATCHER splitContainersFromCache: splittedContainerCache filled with 16 partitions, deleting selectedContainerCache
I 2009/11/03 20:28:25 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key CkmYyWb9ZB__/0 with 65 index containers.
I 2009/11/03 20:28:25 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key GkmYyWb9ZB__/1 with 65 index containers.
.......
I 2009/11/03 20:28:38 INDEX-TRANSFER-DISPATCHER Index transfer of 11 words [CkmG5XEiRmFm .. akmYyWb9ZB__] and 16 URLs to peer sixcooler:bAQ1k6PNpagJ in 0 seconds successful (26 words/s)
I 2009/11/03 20:28:38 INDEX-TRANSFER-DISPATCHER Transfer finished of chunk to target bAQ1k6PNpagJ/sixcooler
I 2009/11/03 20:28:38 INDEX-TRANSFER-DISPATCHER starting new index transmission request to akmYyWb9ZB__
I 2009/11/03 20:28:39 INDEX-TRANSFER-DISPATCHER Index transfer of 11 words [CkmG5XEiRmFm .. akmYyWb9ZB__] and 16 URLs to peer vdbweb:muN6u_nxZq__ in 0 seconds successful (45 words/s)
I 2009/11/03 20:28:39 INDEX-TRANSFER-DISPATCHER Transfer finished of chunk to target muN6u_nxZq__/vdbweb
I 2009/11/03 20:28:39 INDEX-TRANSFER-DISPATCHER starting new index transmission request to akmYyWb9ZB__
I 2009/11/03 20:28:39 INDEX-TRANSFER-DISPATCHER Index transfer of 11 words [CkmG5XEiRmFm .. akmYyWb9ZB__] and 16 URLs to peer KIT-liebel-20091015:p28ATFwX88__ in 0 seconds successful (47 words/s)
I 2009/11/03 20:28:39 INDEX-TRANSFER-DISPATCHER Transfer finished of chunk to target p28ATFwX88__/KIT-liebel-20091015
I 2009/11/03 20:28:39 INDEX-TRANSFER-DISPATCHER STORE: Chunk akmYyWb9ZB__ has FINISHED all transmissions!


Diese Verbindungen nach draussen, da ich Crawl und Index aus habe, müssten also alles DHT sein. Verwendet es dazu auch den "Appache-Http Client" ?
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon DanielR » Di Nov 03, 2009 9:52 pm

Ja, der Peer schickt die Daten per httpClient weg. Allerdings nimmt er sie von anderen Peers am httpd entgegen! Ich weiß auch nicht so genau, wie präzise die Anzeige ist (in und out)!
DanielR
 
Beiträge: 395
Registriert: Di Feb 12, 2008 2:22 pm

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon Orbiter » Mi Nov 04, 2009 12:04 pm

Bei 'nicht-Erreichbarkeit' kann es eigentlich nur um die 'Incomming Connections' und den http Server gehen, nicht um den apache http client. Ich hab mir nochmal den Code vom Server angeschaut: hier gibt es die Möglichkeit dass wirklich sehr viele eingehende Verbindungen ein 'keep-Alive' fordern, und regelmäßig den Server anpingen was den dazu veranlasst irgendwo dicht zu machen und der clean-up Prozess kommt dann zu spät.
Dagegen habe ich nun ein dynamisches keep-alive eingebaut, dass bei zu vielen bestehenden Verbindungen die Möglichkeit des Clients, ein keep-alive zu fordern unterbindet. SVN 6454
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon bluumi » Mi Nov 04, 2009 8:11 pm

Orbiter hat geschrieben:ein dynamisches keep-alive eingebaut. SVN 6454

Ich glaube das hat nun Wunder gewirkt. Denn auch nach über 70 Minuten ist der Peer jetzt noch zu erreichen. Und die Out's gehen nun nicht höher als "nötig". 45 In / 55 Out. :!: Thanks
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon bluumi » Do Nov 05, 2009 9:45 am

[Next Morning] da es über 70 min. gut lief, hatte ich dann DHT-In wieder aktiviert, worauf er nach "vielleicht einer stunde" wieder unerreichbar wurde. Versuche es jetzt nochmals ohne DHT-in. DHT habe ich bereits auf 10% gedrosselt, Eigentlich möchte ich gerne dass der Peer weiterhin als Such(t)einstieg verwendet werden kann und er auch bei anderen suchen darf, also deaktiviere ich DHT ungerne. Gibt es einen Wert, welchen man in Sachen DHT-IN beeinflussen kann?
20_dhtdistribution_busysleep hat ja wohl nur auf DHT-OUT eine Wirkung.
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: http-thread Pool / Anzahl Verbindungen

Beitragvon Vega » Do Nov 05, 2009 7:44 pm

@Michael - Treffer, mit 0.92/6454 läuft der Peer seit 21 Stunden stabil - inklusive Einbindung in Metager, denke das Problem ist damit erledigt.

Gruß,
Thomas
Vega
 
Beiträge: 824
Registriert: Mi Jun 27, 2007 3:34 pm
Wohnort: Dresden

Re: http-thread Pool / Anzahl Verbindungen [closed]

Beitragvon Orbiter » Do Nov 05, 2009 8:17 pm

puh, super, in SVN 6456 gibts dazu nochmal eine 'Verschärfung' der keep-alive Bedingung.

Ich glaube ich habe nun verstanden was das Problem ausgelöst hat: es war im Prinzip der verbesserte http client, da die apache http client library nun ein anständiges keep-alive beherrschte, hat dieses die YaCy http Server Sessions auf Dauer blockiert. Die Lösung dazu sieht dann eigentlich so aus, das man für die YaCy http Verbindungen kein keep-Alive mehr anfordern darf. Ein Quick-Patch wäre es, die keep-alive Wünsche der Clients bei Resourcenknappheit zu ignorieren. Letzteres ist nun implementiert, aber besser wäre es noch, mal genau zu sehen was der apache http client genau beim Verbindungsaufbau macht.
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: http-thread Pool / Anzahl Verbindungen [closed]

Beitragvon DanielR » Fr Nov 06, 2009 10:26 am

Bei dem HttpClient-Nachfolger HttpComponents kann man die keep-alive Dauer begrenzen.
Auf der Homepage findet sich auch folgender Hinweis:
Commons HttpClient 3.x codeline is nearing the end of life. All users of Commons HttpClient 3.x are strongly encouraged to upgrade to HttpClient 4.0.
DanielR
 
Beiträge: 395
Registriert: Di Feb 12, 2008 2:22 pm

Re: http-thread Pool / Anzahl Verbindungen [closed]

Beitragvon Vega » Fr Nov 06, 2009 12:50 pm

@DanielR - hättest/oder jemand anderes Zeit die neue Version zu Implementieren ? (Die Frage musste ja jetzt kommen....)

Gruß,
Thomas
Vega
 
Beiträge: 824
Registriert: Mi Jun 27, 2007 3:34 pm
Wohnort: Dresden

Re: http-thread Pool / Anzahl Verbindungen [closed]

Beitragvon Orbiter » Fr Nov 06, 2009 2:51 pm

ich will jetzt nicht zersetzend wirken, aber ich bin mit dem 3er ganz zufrieden. Auch deswegen weil ich den 4er mal für ein anderes Projekt (beruflich) ausprobiert habe und es nichts ans laufen bekomme habe. Das kann natürlich auch an mir gelegen haben, aber eine einfache Änderung am Code um das Keep-Alive setzen zu können wäre mir lieber als der große Hauruck auf was neues.
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: http-thread Pool / Anzahl Verbindungen [closed]

Beitragvon bluumi » Fr Nov 06, 2009 8:07 pm

:P - btw. mit SVN 6458 drauf habe ist nun zum ersten Mal seit Wochen der grossen Linux Peer auch nach einem Arbeits Tag (ü. 8 Std.) noch lauffähig. was auch immer Du zwischen SVN 6456 und 6458 richtig gemacht hast, ich danke.
:roll: nun hoffe ich Morgen ist er auch noch am rennen. (falle er Morgen noch läuft, teste ich ob er auch DHT-In aushalten würde)
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am


Zurück zu Fragen und Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast