check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

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.

check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon Vega » So Mär 07, 2010 11:49 am

Nach 3 Tagen Dauerbetrieb war mein Peer plötzlich übers Webinterface nicht mehr erreichbar - SVN 94/6697 - im Log hab ich nur folgendes gefunden:

Code: Alles auswählen
2010/03/07 09:01:28 PLASMA Received 8 Entries 1 Words [y94t9qfIk3Dt .. y94t9qfIk3Dt]/-630094602492175760 from BzLmWqTgnZ__:91-89-44-70-94dpnw66/0.91006386, proc
essed in 2 milliseconds, requesting 0/8 URLs, blocked 0 RWIsI 2010/03/07 09:01:28 LOCAL_SEARCH INIT WORD SEARCH: fkk:OH7ZhAdESFjM - 10 links to be computed, 10 lines to be displayed
I 2010/03/07 09:01:28 SEARCH resultWorker thread 0 terminatedI 2010/03/07 09:01:28 LOCAL_SEARCH EXIT WORD SEARCH: fkk - 1666 links found, 256 ms
I 2010/03/07 09:01:29 LOCAL_SEARCH INIT WORD SEARCH: koloskopie durchfuehrung:i7OohjkOoqH4qYcib0KOAXWJ - 10 links to be computed, 10 lines to be displayed
I 2010/03/07 09:01:29 SEARCH resultWorker thread 0 terminated
I 2010/03/07 09:01:29 LOCAL_SEARCH EXIT WORD SEARCH: koloskopie durchfuehrung - 0 links found, 131 ms
I 2010/03/07 09:01:30 PLASMA Received 13 Entries 4 Words [keTAnfdyQCXQ .. keTFC0rdLOYx]/1458649359131379944 from IFlRzri68___:KIT01-05-checker/0.94006723, process
ed in 2 milliseconds, requesting 0/12 URLs, blocked 0 RWIs
I 2010/03/07 09:01:31 PLASMA Received 5 Entries 1 Words [AmThUnIwzReA .. AmThUnIwzReA]/-2594607068365455968 from O6ykQ9Dd5j__:KIT01-16-custom/0.94006723, processe
d in 1 milliseconds, requesting 0/5 URLs, blocked 0 RWIs
I 2010/03/07 09:01:31 PLASMA Received 1 Entries 1 Words [q6mSfMt-tRem .. q6mSfMt-tRem]/530230725353736608 from dH6KyKAkSS__:cophome/0.94006723, processed in 0 mil
liseconds, requesting 0/1 URLs, blocked 0 RWIs
I 2010/03/07 09:01:32 SERVER check for Session_88.140.143.128:55810#0: 1441917 ms alive, stopping thread
I 2010/03/07 09:01:32 SERVER Closing main socket of thread 'Session_88.140.143.128:55810#0'
I 2010/03/07 09:01:32 SERVER check for Session_88.140.143.128:55941#0: 1401368 ms alive, stopping thread
I 2010/03/07 09:01:32 SERVER Closing main socket of thread 'Session_88.140.143.128:55941#0'
I 2010/03/07 09:01:32 SERVER check for Session_78.51.16.214:44355#0: 1375833 ms alive, stopping thread
I 2010/03/07 09:01:32 SERVER Closing main socket of thread 'Session_78.51.16.214:44355#0'
I 2010/03/07 09:01:32 SERVER check for Session_88.140.143.128:56154#0: 1370598 ms alive, stopping thread
I 2010/03/07 09:01:32 SERVER Closing main socket of thread 'Session_88.140.143.128:56154#0'
I 2010/03/07 09:01:32 SERVER check for Session_78.51.16.214:39619#0: 1355790 ms alive, stopping thread
I 2010/03/07 09:01:32 SERVER Closing main socket of thread 'Session_78.51.16.214:39619#0'
I 2010/03/07 09:01:32 SERVER check for Session_88.140.143.128:56317#0: 1339765 ms alive, stopping thread
I 2010/03/07 09:01:33 SERVER Closing main socket of thread 'Session_88.140.143.128:56317#0'
I 2010/03/07 09:01:33 SERVER check for Session_78.51.16.214:40751#0: 1325860 ms alive, stopping thread
I 2010/03/07 09:01:33 SERVER Closing main socket of thread 'Session_78.51.16.214:40751#0'
I 2010/03/07 09:01:33 SERVER check for Session_78.46.71.171:40322#0: 1309769 ms alive, stopping thread
I 2010/03/07 09:01:33 SERVER Closing main socket of thread 'Session_78.46.71.171:40322#0'
I 2010/03/07 09:01:33 SERVER check for Session_78.51.16.214:33519#0: 1295924 ms alive, stopping thread
I 2010/03/07 09:01:33 SERVER Closing main socket of thread 'Session_78.51.16.214:33519#0'
I 2010/03/07 09:01:33 SERVER check for Session_78.46.71.171:57829#0: 1279646 ms alive, stopping thread
I 2010/03/07 09:01:33 SERVER Closing main socket of thread 'Session_78.46.71.171:57829#0'
I 2010/03/07 09:01:33 SERVER check for Session_85.125.223.84:59870#0: 1279134 ms alive, stopping thread
I 2010/03/07 09:01:33 SERVER Closing main socket of thread 'Session_85.125.223.84:59870#0'
I 2010/03/07 09:01:33 SERVER check for Session_213.147.1.70:55000#0: 1277139 ms alive, stopping thread
I 2010/03/07 09:01:33 SERVER Closing main socket of thread 'Session_213.147.1.70:55000#0'
I 2010/03/07 09:01:33 SERVER check for Session_78.46.71.171:35533#0: 1249727 ms alive, stopping thread
I 2010/03/07 09:01:33 SERVER Closing main socket of thread 'Session_78.46.71.171:35533#0'
I 2010/03/07 09:01:33 SERVER check for Session_213.147.1.70:33244#0: 1247049 ms alive, stopping thread
I 2010/03/07 09:01:33 SERVER Closing main socket of thread 'Session_213.147.1.70:33244#0'
I 2010/03/07 09:01:33 SERVER check for Session_85.125.223.84:55609#0: 1246404 ms alive, stopping thread
I 2010/03/07 09:01:34 SERVER Closing main socket of thread 'Session_85.125.223.84:55609#0'
I 2010/03/07 09:01:34 SERVER check for Session_78.46.71.171:38204#0: 1219583 ms alive, stopping thread
I 2010/03/07 09:01:34 SERVER Closing main socket of thread 'Session_78.46.71.171:38204#0'
I 2010/03/07 09:01:34 SERVER check for Session_213.147.1.70:42236#0: 1217136 ms alive, stopping thread
I 2010/03/07 09:01:34 SERVER Closing main socket of thread 'Session_213.147.1.70:42236#0'


Hat das jemand eine Idee/Vermutung dazu ?

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

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon jdelmour » So Mär 07, 2010 4:09 pm

The same here!
Siehe auch mein Posting dazu von heute vormittag http://forum.yacy-websuche.de/viewtopic.php?f=5&t=2719
jdelmour
 
Beiträge: 8
Registriert: Sa Mär 06, 2010 5:44 pm

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon dulcedo » Mo Mär 08, 2010 8:03 pm

Das tritt schon mindestens seit Herbst letzten Jahres auf und zwar vermutlich immer dann wenn der httpd aufgrund vorangegangener OOMs keine Portanfragen mehr beantwortet. Eigentlich noch das einzige ernsthafte Problem betreff Laufzeitstabilität. So wie ich es verstehe eine Schutzfunkton um blockierende Sessions zu beenden, der httpd bauf aber trotdem keine neuen auf, also auch nicht für die Bedienung des Webinterface.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon jdelmour » Mo Mär 08, 2010 11:26 pm

Das klingt jetzt wenig befriedigend.... Bei mir läuft yacy seit dem definitiv nicht mehr, weil es eben nicht vernünftig startet und ich Angst um die Server habe.

Ich betreibe etliche Root-Server und wollte eigentlich das Projekt rund um die Uhr unterstützen. Am WE hatte ich Yacy zunächst auf 2 Servern gestartet. Nachdem aber der 1. nicht mehr hochfährt, habe ich den 2. auch ausgeknipst, aufgrund der Chronik des "Aufschaukelns" eigener Yacy-Threads im wiederholten Masse, ähnlich zu dem von dir beschriebenen Problem.
Ich möchte erst das Problem geklärt wissen (wohl stets in der Annahme, das der Fehler zunächst bei MIR liegt!), bevor ich da fortfahre.

Ich finde es schade, das bisher von Entwickler-Seite noch kein Statement dazu kam. Es gibt schließlich 2 fast zeitgleich gestartete Threads mit der gleichen Thematik dazu.
Okay, vielleicht bin ich zu voreilig. Es war Wochenende, und heute ist erst Montag :) Aber das Projekt als solches begeistert mich einfach, daher auch diese Ungeduld.

PS: habe inzwischen auch den anderen Thread vom "letzten Herbst" gelesen, da scheint ja das gleiche passiert zu sein. Allerdings dauerte es bei mir keine Minuten, sondern durchaus Stunden.
jdelmour
 
Beiträge: 8
Registriert: Sa Mär 06, 2010 5:44 pm

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon dulcedo » Di Mär 09, 2010 2:12 am

Um deine Server musst du dir in dem Fall keine Gedanken machen, YaCy belegt dann lediglich den der Java-Machine zugewiesenen Speicher und kann auch jederzeit beendet werden.
Manchmal allerding nur per KILL und das betrifft eben das Laufverhalten über längere Zeit. Wenn du vor einem START prüfst ob der YaCy-Prozess bereits läuft dann kann auch kein Speicherproblem auftreten.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon Vega » Di Mär 09, 2010 4:58 pm

@jdelmour - Ich kann Dich beruhigen, um Deine Rootserver musst Du Dir keine Sorgen machen. Ich betreibe seit längerer Zeit die beiden SUMA-EV Peers http://78.46.76.144:8080/ und http://78.46.76.146:8080/ - und diesen Fehler hatte ich auf beiden Peers noch nie. Welche Ressourcen kannst Du YACY zur Verfügung stellen (Ram + HD ? ) - Du kannst das je begrenzen, indem Du YACY auf eine (kleine) eigene Partition legst, und denn Ressourcen-Observer so einstellst das er bevor die Partition voll läuft DHT+Craweling ausschaltet. Damit durfte die Kiste auch nicht ins Speicherlimit rennen. ist zwar ein wenig "von hinten durchs Auge" - dürfte aber funktionieren. Wenn Du fragen hast - einfach hier stellen.

Ach ja, die Suma-EV Peers starte ich jede Nacht neu, das ist auch kein Fehler....

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

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon dulcedo » Di Mär 09, 2010 6:15 pm

Thomas, deswegen hast du diese Fehler auch nie, sie treten erst nach einer gewissen Laufzeit auf. Als wenn dem httpd oder was auch immer für die Bearbeitung von portanfragen zuständig ist die Luft ausgeht. Ausgehnde Verbindungen laufen weiter aber das nutzt nix ohne mögliche Anfragen.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon jdelmour » Di Mär 09, 2010 9:00 pm

Hallo

die Server sind mit 8-12 GB DDR3-RAM ausgestattet, Plattenplatz beträgt jeweils 1 Terrabyte stationär und via S3 weitere Terrabytes auf Bedarf (an beidem liegt es aber nicht). Wenn ich die Kisten täglich neustarten würde, würde dieses Problem fast nicht auftreten oder zumindest nicht auffallen.... Allerdings ist eine permanente Verfügbarkeit der Rechner durchaus erwünscht und erbeten, geradezu notwendig! Einige unserer Rechner haben eine Uptime von über 100 Tagen. Und wenn ein Reboot erfolgte, dann aufgrund eines Kernelupdates, das tatsächlich einen kompletten Reboot erforderte.

Für mich ist eine Software u.a. dann webtauglich, wenn sie sich auch nach einer Betriebszeit von 3 Monaten genauso verhält wie nach 1 Tag. Die von mir und meinen Leuten entwickelten Web-Applications kommen erst gar nicht zum Einsatz, solange sie nicht diesen Zweck erfüllen. Da schaukelt sich nichts hoch. Und wenn doch, dann fliegt der Code umgehend runter und muss zwingend überarbeitet werden.

Daher kann ich Yacy so auf diese Art und Weise gegenwärtig nicht laufen lassen, da der aktuelle Stand nicht unsere Richtlinien erfüllt. Unabhängig davon, das ein Neustart der Anwendung gar nicht mehr möglich ist, wie bereits oben beschrieben.

Bitte nicht falsch verstehen! Ich finde dieses Projekt geradezu großartig, einfach nur umwerfend! Mir ist auch absolut klar, das ein Projekt dieser Dimension nicht mehr als One-Man-Show gepflegt werden kann. Es bedarf zwingender Unterstützung durch andere. Wenn ich den Anforderungen gerecht werden könnte, würde ich dies tun. Aber weder ich noch meine Leute sprechen ausführlich Java. Alles, was ich derzeit anbieten kann, ist ausführliches Testing und das Posten von Erfahrungswerten.

Grüße, jdelmour

PS: Nachtrag für Thomas: an den Resourcen RAM + HD liegt es nicht. Das Problem ist irgendwie ein klassisches Multithreading-Problem, auch "Philosophen-Problem" genannt. Irgendwann rennen da ganz viele Threads und warten gegenwärtig auf einander. Da alle auf die anderen warten, entsteht eine klassische Deadlock-Situation. Die CPU rennt volle Kanne und muss die ganzen Threads verwalten, welche aber wiederum überhaupt nicht arbeiten können, da sie auf den Nachbarn warten, sinnbildlich gesprochen.... Zumindest geht meine bisherige Diagnose "von außen" in diese Richtung.
jdelmour
 
Beiträge: 8
Registriert: Sa Mär 06, 2010 5:44 pm

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon Vega » Di Mär 09, 2010 10:32 pm

@ dulcedo - Hallo Lukas, ist gut möglich das dadurch der Fehler an den beiden SUMA-EV Peers nicht auftritt, hier muss man aber klar und eindeutig feststellen, das diese beiden Peers hautsächlich dazu da sind Metager zu feeden und natürlich das Freeworld Yacy Netz zu stützen. Daher lege ich dort großen Wert auf die Verfügbarkeit - deshalb der tägliche Neustart.

@ jdelmour
Die Server sind ja recht ordentlich, die würden gute YACY Peers abgeben :D - uns allen wäre ein Stück Software, was 3 Monate am Stück läuft ohne Zicken zu machen lieber, aber davon ist Yacy noch ein Stückchen weg, ist aber trotzdem Praxistauglich, wie ja die YACY Sciencenet Search engine (http://en.wikipedia.org/wiki/Sciencenet) beweist, schreib doch mal liebel-lab an, wie die das machen.

Ihr müsst kein Java sprechen um YACY zu helfen, HTML+CSS+JAVASCRIPT würden uns auch helfen, oder jemand für Design, oder jemand der Pyhton richtig gut kann - wobei das eher dem SUMA-EV und mir helfen würde......etc..etc... Du siehst, mir fällt genug ein :-)

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

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon jdelmour » Do Mär 11, 2010 7:52 pm

Hallo Thomas

Liebel-Net anzusprechen ist eine gute Variante, das werde ich versuchen. Fällt dir ein konkreter Ansprechpartner ein? Ansonsten suche ich mir selbst einen.
Ja, die Server sind ganz ordentlich :) Zumal mit Intel i7 920 ausgestattet, macht auch noch mal ne nette Performance.

Ich bleib dran!

Grüße, jdelmour
jdelmour
 
Beiträge: 8
Registriert: Sa Mär 06, 2010 5:44 pm

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon Vega » Do Mär 11, 2010 9:56 pm

@jdelmour - auf jeden Fall dran bleiben, das lohnt sich.....Wenn ich irgendwie helfen kann - einfach bei mir melden. Ich weis das die Core I920 ganz ordentlich Dampf haben - ich betreue ja 2 von diesen Kisten: http://www.hetzner.de/de/hosting/produkte_rootserver/eq4/.....


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

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon dulcedo » Mi Mär 17, 2010 10:11 am

Hier habe ich den threaddump (kill -3) einer solchen Situation. Es ist 1GB Speicher frei, object-space wird aber zu 99% belegt gemeldet.
Dateianhänge
yacy.log.pt31.zip
(15.74 KiB) 10-mal heruntergeladen
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: check for Session_xx.xx.xx.xx:55810#0: 1441917 ms alive, sto

Beitragvon Orbiter » Fr Mär 19, 2010 3:29 pm

hier ist der DNS lookup auffällig. De wird hier dummerweise unnötig gemacht, daher sollte hier ein fix helfen und ordentlich den httpd boosten:
SVN 6750
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main


Zurück zu Fragen und Antworten

Wer ist online?

Mitglieder in diesem Forum: Exabot [Bot] und 3 Gäste

cron