Startproblem

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.

Startproblem

Beitragvon henschi » Mo Jan 26, 2009 10:16 pm

Heute habe ich nun ein anderes Problem mit Yacy. :-(
Die Version 5516 fährt nicht mehr hoch und endet mit 100% CPU. Es wird nicht mehr auf der Platte gelesen oder sonst etwas.
Anbei der Stacktrace des Thrads:

"main" prio=10 tid=0x09210400 nid=0x8c2 runnable [0xb7df1000..0xb7df21f8]
java.lang.Thread.State: RUNNABLE
at java.io.RandomAccessFile.readBytes(Native Method)
at java.io.RandomAccessFile.read(RandomAccessFile.java:322)
at java.io.RandomAccessFile.readFully(RandomAccessFile.java:381)
at de.anomic.kelondro.kelondroEcoFS.fillCache(kelondroEcoFS.java:201)
at de.anomic.kelondro.kelondroEcoFS.get(kelondroEcoFS.java:246)
- locked <0x93de2ba0> (a de.anomic.kelondro.kelondroEcoFS)
at de.anomic.kelondro.kelondroBufferedEcoFS.get(kelondroBufferedEcoFS.java:89)
- locked <0x93de2b88> (a de.anomic.kelondro.kelondroBufferedEcoFS)
at de.anomic.kelondro.kelondroEcoTable.<init>(kelondroEcoTable.java:173)
at de.anomic.kelondro.kelondroCollectionIndex.openIndexFile(kelondroCollectionIndex.java:278)
at de.anomic.kelondro.kelondroCollectionIndex.<init>(kelondroCollectionIndex.java:134)
at de.anomic.index.indexCollectionRI.<init>(indexCollectionRI.java:49)
at de.anomic.plasma.plasmaWordIndex.<init>(plasmaWordIndex.java:168)
at de.anomic.plasma.plasmaSwitchboard.<init>(plasmaSwitchboard.java:311)
at yacy.startup(yacy.java:224)
at yacy.main(yacy.java:1037)
henschi
 
Beiträge: 65
Registriert: So Okt 07, 2007 6:49 pm
Wohnort: Brandenburg an der Havel

Re: Startproblem

Beitragvon henschi » Mo Jan 26, 2009 10:35 pm

Nach dem Löschen von der Datei collection.index geht es nun scheinbar weiter. puh :-)
henschi
 
Beiträge: 65
Registriert: So Okt 07, 2007 6:49 pm
Wohnort: Brandenburg an der Havel

Re: Startproblem

Beitragvon henschi » Mo Jan 26, 2009 10:48 pm

Tja, zu früh gefreut. :-(
Nach einem erneuten Shutdown Test, hängt Yacy beim Start wieder an der gleichen Stelle.
henschi
 
Beiträge: 65
Registriert: So Okt 07, 2007 6:49 pm
Wohnort: Brandenburg an der Havel

Re: Startproblem

Beitragvon Orbiter » Mo Jan 26, 2009 10:51 pm

probier mal den collection.index neu aufzubauen.
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Startproblem

Beitragvon miTreD » Mo Jan 26, 2009 11:06 pm

Ich denke hier besteht das gleiche Problem.
collection.index gelöscht, Peer gestartet und läuft. Peer beendet und wieder gestartet - YaCy läuft in 100% CPU. Hier das Log mit dem thread dump:
Code: Alles auswählen
[ YaCy v0.71, build 20090126 by Michael Christen / www.yacy.net ]
-------------------------------------------------------------------------------
STARTUP: Trying to load logging configuration from file /yacy/DATA/LOG/yacy.logging
S 2009/01/26 22:49:12 STARTUP Java version: 1.6.0_10
S 2009/01/26 22:49:13 STARTUP Operation system: Linux
S 2009/01/26 22:49:13 STARTUP Application root-path: /yacy
S 2009/01/26 22:49:13 STARTUP Time zone: UTC+0100; UTC+0000 is 1233006553253
S 2009/01/26 22:49:13 STARTUP Maximum file system path length: 65535
I 2009/01/26 22:49:13 PLASMA This is the pro-version of YaCy
I 2009/01/26 22:49:14 indexContainerRAMHeap restoring rwi blob dump 'index.dhtout.blob'
I 2009/01/26 22:49:14 indexContainerRAMHeap finished rwi blob restore: 166 words, 3153 word/URL relations in 117 milliseconds
D 2009/01/26 22:49:14 STARTUP OPENING COLLECTION INDEX
I 2009/01/26 22:49:14 ECOTABLE initialization of /yacy/DATA/INDEX/freeworld/TEXT/RICOLLECTION/collection.index: available RAM: 878MB, allocating space for 6259083 entries
I 2009/01/26 22:49:14 ECOTABLE /yacy/DATA/INDEX/freeworld/TEXT/RICOLLECTION/collection.index: EcoTable /yacy/DATA/INDEX/freeworld/TEXT/RICOLLECTION/collection.index has table copy DISABLED
I 2009/01/26 22:49:14 ECOTABLE initializing RAM index for EcoTable collection.index, please wait.
I 2009/01/26 22:49:50 ECOTABLE /yacy/DATA/INDEX/freeworld/TEXT/RICOLLECTION/collection.index: WARNING - EcoTable /yacy/DATA/INDEX/freeworld/TEXT/RICOLLECTION/collection.index has 110268 doubles
2009-01-26 23:05:38
Full thread dump Java HotSpot(TM) Server VM (11.0-b15 mixed mode):

"Thread-1" prio=10 tid=0x0853a400 nid=0x10fd waiting on condition [0x77e3a000..0x77e3afb0]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at de.anomic.server.serverProfiling.run(serverProfiling.java:61)

"Low Memory Detector" daemon prio=10 tid=0x0841d000 nid=0x10fb runnable [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread1" daemon prio=10 tid=0x0841b800 nid=0x10fa waiting on condition [0x00000000..0x77fa12a8]
   java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=10 tid=0x08418c00 nid=0x10f9 waiting on condition [0x00000000..0x780221a8]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x08417000 nid=0x10f8 runnable [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x08407000 nid=0x10f7 in Object.wait() [0x782c4000..0x782c50b0]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x7ecf0a70> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x7ecf0a70> (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=10 tid=0x08402400 nid=0x10f6 in Object.wait() [0x78315000..0x78316030]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x7ecf0978> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x7ecf0978> (a java.lang.ref.Reference$Lock)

"main" prio=10 tid=0x083b1000 nid=0x10f4 runnable [0xb7e93000..0xb7e941f8]
   java.lang.Thread.State: RUNNABLE
        at de.anomic.kelondro.kelondroBase64Order.compare0(kelondroBase64Order.java:297)
        at de.anomic.kelondro.kelondroBase64Order.compare(kelondroBase64Order.java:293)
        at de.anomic.kelondro.kelondroRowCollection.compare(kelondroRowCollection.java:862)
        at de.anomic.kelondro.kelondroRowCollection.isort(kelondroRowCollection.java:746)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:584)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:592)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:591)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:591)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:592)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:592)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:591)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:592)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:592)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:591)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:592)
        at de.anomic.kelondro.kelondroRowCollection.qsort(kelondroRowCollection.java:592)
        at de.anomic.kelondro.kelondroRowCollection.sort(kelondroRowCollection.java:523)
        - locked <0x85491fa0> (a de.anomic.kelondro.kelondroRowSet)
        at de.anomic.kelondro.kelondroRowSet.put(kelondroRowSet.java:132)
        - locked <0x85491fa0> (a de.anomic.kelondro.kelondroRowSet)
        at de.anomic.kelondro.kelondroRAMIndex.put(kelondroRAMIndex.java:97)
        - locked <0x85491fc8> (a de.anomic.kelondro.kelondroRAMIndex)
        at de.anomic.kelondro.kelondroBytesIntMap.puti(kelondroBytesIntMap.java:73)
        - locked <0x85491fe0> (a de.anomic.kelondro.kelondroBytesIntMap)
        at de.anomic.kelondro.kelondroEcoTable.removeInFile(kelondroEcoTable.java:428)
        at de.anomic.kelondro.kelondroEcoTable.<init>(kelondroEcoTable.java:188)
        at de.anomic.kelondro.kelondroCollectionIndex.openIndexFile(kelondroCollectionIndex.java:278)
        at de.anomic.kelondro.kelondroCollectionIndex.<init>(kelondroCollectionIndex.java:134)
        at de.anomic.index.indexCollectionRI.<init>(indexCollectionRI.java:49)
        at de.anomic.plasma.plasmaWordIndex.<init>(plasmaWordIndex.java:168)
        at de.anomic.plasma.plasmaSwitchboard.<init>(plasmaSwitchboard.java:311)
        at yacy.startup(yacy.java:224)
        at yacy.main(yacy.java:1037)

"VM Thread" prio=10 tid=0x083fec00 nid=0x10f5 runnable

"VM Periodic Task Thread" prio=10 tid=0x0841f000 nid=0x10fc waiting on condition

JNI global references: 825

Heap
def new generation   total 66624K, used 59614K [0x788f0000, 0x7d130000, 0x7ecf0000)
  eden space 59264K,  96% used [0x788f0000, 0x7c0aea08, 0x7c2d0000)
  from space 7360K,  34% used [0x7ca00000, 0x7cc78e80, 0x7d130000)
  to   space 7360K,   0% used [0x7c2d0000, 0x7c2d0000, 0x7ca00000)
tenured generation   total 591680K, used 114316K [0x7ecf0000, 0xa2ec0000, 0xb0cf0000)
   the space 591680K,  19% used [0x7ecf0000, 0x85c93190, 0x85c93200, 0xa2ec0000)
compacting perm gen  total 16384K, used 4175K [0xb0cf0000, 0xb1cf0000, 0xb4cf0000)
   the space 16384K,  25% used [0xb0cf0000, 0xb1103c30, 0xb1103e00, 0xb1cf0000)
No shared spaces configured.
miTreD
 
Beiträge: 1241
Registriert: Mi Jun 27, 2007 11:35 am
Wohnort: /home

Re: Startproblem

Beitragvon henschi » Mo Jan 26, 2009 11:25 pm

Yacy meldet beim zweiten Starten doppelte Einträge in den collection.index . Es waren nach dem Rebuild 900000 RWI mehr.
henschi
 
Beiträge: 65
Registriert: So Okt 07, 2007 6:49 pm
Wohnort: Brandenburg an der Havel

Re: Startproblem

Beitragvon celle » Mi Jan 28, 2009 7:26 pm

Hallo,

ich habe auch das Problem. Ich habe mal etwas gedebuggt und folgendes festgestellt.

Das Problem scheint zu sein das bei jedem Entfernen eines doppelten Eintrags der RAM Index einmal sortiert wird. Damit ist das System nur noch mit sortieren beschäftigt. Das Problem tritt durch das "set(..) auf"

Code: Alles auswählen
kelendroRowSet.java
public synchronized kelondroRow.Entry put(final kelondroRow.Entry entry) {
        assert (entry != null);
        assert (entry.getPrimaryKeyBytes() != null);
        int index = -1;
        kelondroRow.Entry oldentry = null;
        // when reaching a specific amount of un-sorted entries, re-sort all
        if ((this.chunkcount - this.sortBound) > collectionReSortLimit) {
            sort();
        }
        index = find(entry.bytes(), (rowdef.primaryKeyIndex < 0) ? 0 :super.rowdef.colstart[rowdef.primaryKeyIndex], super.rowdef.primaryKeyLength);
        //System.out.println("index: " + index);
        if (index < 0) {
            super.addUnique(entry);
        } else {
            oldentry = get(index, true);
            set(index, entry);
        }
        return oldentry;


Code: Alles auswählen
kelendroRowCollection.java
public synchronized final void set(final int index, final kelondroRow.Entry a) {
        assert (index >= 0) : "set: access with index " + index + " is below zero";
        ensureSize(index + 1);
        a.writeToArray(chunkcache, index * rowdef.objectsize);
        if (index >= this.chunkcount) this.chunkcount = index + 1;
        if (index < this.sortBound) this.sortBound = index;
        this.lastTimeWrote = System.currentTimeMillis();
    }


Bei dem Vorgang werden die als doppelt erkannten Elemente wieder zusammengeführt. Das heißt, dass der Schlüssel vom neuen und alten Entry gleich ist. Trotzdem wird das Array nach dem Einfügen des neuen Elementes das Array neu sortiert, da das set() nicht wissen kann, dass das Element an diese Stelle passt.

Ich habe für das Problem bei mir folgenden Patch geschrieben.

Code: Alles auswählen
kelendroRowSet.java
public synchronized kelondroRow.Entry put(final kelondroRow.Entry entry) {
        assert (entry != null);
        assert (entry.getPrimaryKeyBytes() != null);
        int index = -1;
        kelondroRow.Entry oldentry = null;
        // when reaching a specific amount of un-sorted entries, re-sort all
        if ((this.chunkcount - this.sortBound) > collectionReSortLimit) {
            sort();
        }
        index = find(entry.bytes(), (rowdef.primaryKeyIndex < 0) ? 0 :super.rowdef.colstart[rowdef.primaryKeyIndex], super.rowdef.primaryKeyLength);
        //System.out.println("index: " + index);
        if (index < 0) {
            super.addUnique(entry);
        } else {
            oldentry = get(index, true);
            byte alt[] = oldentry.getPrimaryKeyBytes();
            byte neu[] = entry.getPrimaryKeyBytes();
            if (java.util.Arrays.equals(alt, neu))
               entry.writeToArray(chunkcache, index * rowdef.objectsize);
            else
               set(index, entry);
        }
        return oldentry;
    }


Das macht eine Sicherheitsabfrage und schreibt dann die Werte direkt in den Index ohne Neusortierung. Das scheint zu funktionieren, dauert jedoch immer noch eine ganze Weile (bei mir läuft es noch und arbeitet in 10 Sekunden 1000 doppelte Elemente ab mit viele IOs)

tschüss

celle
celle
 
Beiträge: 47
Registriert: Mi Jun 27, 2007 11:52 am

Re: Startproblem

Beitragvon miTreD » Do Jan 29, 2009 3:04 pm

Das mit dem Sortieren könnte hinkommen. Hab' meinen Peer heute Morgen angeschmissen und einfach mal laufen lassen. Jetzt ist er up und verrichtet gant normal seinen Dienst. Wie lange er gebraucht hat, hab' ich jetzt noch nicht überprüft.
miTreD
 
Beiträge: 1241
Registriert: Mi Jun 27, 2007 11:35 am
Wohnort: /home

Re: Startproblem

Beitragvon Orbiter » Do Jan 29, 2009 5:09 pm

celle: super Analyse!
Ich bin deinem Rat gefolgt, hab es dann aber doch ein klein wenig anders implementiert, drin in SVN 5532
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Startproblem

Beitragvon henschi » Do Jan 29, 2009 11:19 pm

Für 540000 doppelte Einträge braucht mein Rechner schon 95 Minuten eine volle CPU :-( und ist noch nicht fertig. Aber ich sehe die collection.index wird kleiner.
henschi
 
Beiträge: 65
Registriert: So Okt 07, 2007 6:49 pm
Wohnort: Brandenburg an der Havel

Re: Startproblem

Beitragvon thq » Do Jan 29, 2009 11:38 pm

Bei 540000 doppelte Einträge sollten wir besser den BUG finden, darf ja eigentlich nicht sein.

Vielleicht fehlen noch ein paar synchronized beim löschen und hinzufügen von Daten. Ist es sicher das ein löschen oder hinzufügen sich nicht gegenseitig stören und sei es nur bei einen Zähler ... ?
Zuletzt geändert von thq am Fr Jan 30, 2009 9:37 am, insgesamt 1-mal geändert.
thq
 
Beiträge: 651
Registriert: So Jul 08, 2007 12:23 pm

Re: Startproblem

Beitragvon celle » Do Jan 29, 2009 11:43 pm

Hallo,

bei mir hat es mit auch etwa einer halben Million Doubles auch etwa 3 Stunden gebraucht, also Geduld.
Trotzdem sollte da noch etwas geloggt werden, damit man weis wie viel noch zu tun ist. Ich hatte das bei meinem Test auch sicherheitshalber gemacht.

Code: Alles auswählen
kelendroEcoTable.java ab etwa Zeile 183
// now remove the entries in a sorted way (top-down)
serverLog.logInfo("ECOTABLE", delpos.size() + " doubles remaining");
Integer top;
while (delpos.size() > 0) {
  if (delpos.size()%1000 == 0)
    serverLog.logInfo("ECOTABLE", delpos.size() + " doubles remaining");
  top = delpos.last();
  delpos.remove(top);
  removeInFile(top.intValue());
}


tschüss

celle
celle
 
Beiträge: 47
Registriert: Mi Jun 27, 2007 11:52 am

Re: Startproblem

Beitragvon henschi » Do Jan 29, 2009 11:49 pm

Wo sind eigentlich die doppelten Einträge drin?
Wenn die in der collection.index drin sind, dürfte das ja eigentlich nicht gehen, da die in einem Rutsch nach dem letzten Löschen erstellt worden ist.
henschi
 
Beiträge: 65
Registriert: So Okt 07, 2007 6:49 pm
Wohnort: Brandenburg an der Havel

Re: Startproblem

Beitragvon Orbiter » Fr Jan 30, 2009 10:01 am

ich hab das noch nie gehabt, macht ihr irgend etwas besonderes?
Ich hab auch nix spezielles geändert, was das provoziert haben könnte, oder wüsste jemand an welchem SVN commit das zusammen hängt?
Ab wann genau ist das aufgetreten?
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Startproblem

Beitragvon celle » Fr Jan 30, 2009 5:09 pm

Hallo,

ich weiß nicht, seit wann das passiert. Doubles habe ich schon ziemlich lange (Jahre?), wenn ich die collection.index neu aufbaue. Vielleicht war da mal nen Bug drin vor langer Zeit. Ich musste meinen Index neu aufbauen, da die YaCy Platte über USB dran hängt und da nen Problem war.

tschüss

celle
celle
 
Beiträge: 47
Registriert: Mi Jun 27, 2007 11:52 am

Re: Startproblem

Beitragvon botec » Fr Jan 30, 2009 8:21 pm

Hallo,
das Problem gab es aber schon öfter...

Z.B. in diesem Thread Yacy Probleme beim Betrieb... #5433

Oder über die Suche...
botec
 
Beiträge: 32
Registriert: Fr Jun 13, 2008 9:20 pm


Zurück zu Fragen und Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

cron