derbe performance probleme (vor allem beim export)

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.

derbe performance probleme (vor allem beim export)

Beitragvon protocols » Mo Mai 11, 2009 8:27 pm

hardware: AMD 2600+, 2GB RAM (128MB reserviert für yacy), 160GB HDD

crawlen/indexieren/suchanfragen läuft problemlos. Sobald ich aber die URLs/Domains exportieren will, stirbt yacy (via web nicht mehr erreichbar), nicht mehr stoppbar, selbst nach einem "kill" und neustart läufts schnell wird "aus" (d.h. nicht mehr erreichbar).
Last auf dem Server ist jetzt utopisch höher gegangen (kein swapping, festplatten io ist nicht ungewöhnlich höher).

woran liegt das?
protocols
 
Beiträge: 15
Registriert: Sa Mai 09, 2009 5:25 pm

Re: derbe performance probleme (vor allem beim export)

Beitragvon Orbiter » Mo Mai 11, 2009 10:10 pm

bitte in so einem Fall einen Thread dump machen, sonst kann man nur Vermutungen anstellen.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: derbe performance probleme (vor allem beim export)

Beitragvon Huppi » Mo Mai 11, 2009 10:25 pm

128MB für YaCy ist nicht gerade üppig. Kannst Du mehr Speicher zuweisen?
Huppi
 
Beiträge: 898
Registriert: Fr Jun 29, 2007 9:49 am
Wohnort: Kürten

Re: derbe performance probleme (vor allem beim export)

Beitragvon protocols » Mo Mai 11, 2009 10:48 pm

Orbiter hat geschrieben:bitte in so einem Fall einen Thread dump machen, sonst kann man nur Vermutungen anstellen.

wie geht das? :roll:

Huppi hat geschrieben:128MB für YaCy ist nicht gerade üppig. Kannst Du mehr Speicher zuweisen?

Das Problem hatte ich auch als ich yacy 512MB zugewiesen habe - die Frage ist eher: wie skaliert yacy? D.h. wie genau werden diese Listen exportiert? Und wieviel RAM brauche ich dann erfahrungsgemäß um extrem viele Links (10-100 Millionen) zu exportieren.

-> Wird der komplette Index/*.db in den RAM geladen -> daraus eine txt Datei
-> Wird via "buffer" nur eine begrenzte Menge immer in den RAM geladen und die txt Datei entsprechend "zeilenweise" geschrieben.
protocols
 
Beiträge: 15
Registriert: Sa Mai 09, 2009 5:25 pm

Re: derbe performance probleme (vor allem beim export)

Beitragvon bluumi » Mo Mai 11, 2009 10:59 pm

protocols hat geschrieben:
Orbiter hat geschrieben:Thread dump machen

wie geht das? :roll:
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: derbe performance probleme (vor allem beim export)

Beitragvon protocols » Di Mai 12, 2009 9:08 am

hmm ok komisch.. sobald man ihn droht tut er seine Arbeit ;)

also ich habe diesmal gewartet bis der crawl vorgang komplett fertig war und habe dann erst exportiert.. der server lastet, aber dafür werden die urls richtig gespeichert.

kann es also daran liegen dass während eines crawl vorgangs keine export aufträge bearbeitet werden? d.h. man muss erst alle crawl-vorgänge stoppen?

ansonsten probiere ich es nochmal auf dem anderen server mit thread dump.
protocols
 
Beiträge: 15
Registriert: Sa Mai 09, 2009 5:25 pm

Re: derbe performance probleme (vor allem beim export)

Beitragvon Orbiter » Di Mai 12, 2009 10:00 am

crawls und Indexierung sind IO-lastig, der Export auch. Beides zusammen wird sich dann wohl nicht so gut vertragen.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: derbe performance probleme (vor allem beim export)

Beitragvon protocols » Fr Mai 15, 2009 12:20 pm

ok, wass ist wenn er sich so nicht mehr beenden lässt (via kill -3)?
Code: Alles auswählen
2009/05/15 13:18:45 YACY rulebasedUpdateInfo: not an automatic update selected
I 2009/05/15 13:18:46 PLASMA dhtTransferJob: no selection, too many entries in transmission cloud: 70
I 2009/05/15 13:18:46 PLASMA dhtTransferJob: result from dequeueing: true
I 2009/05/15 13:18:52 PLASMA dhtTransferJob: no selection, too many entries in transmission cloud: 69
I 2009/05/15 13:18:52 PLASMA dhtTransferJob: result from dequeueing: true
E 2009/05/15 13:18:58 YACY yacyClient.transferRWI error:The host did not accept the connection within timeout of 30000 ms
I 2009/05/15 13:18:58 PLASMA dhtTransferJob: no selection, too many entries in transmission cloud: 68
I 2009/05/15 13:18:58 PLASMA dhtTransferJob: result from dequeueing: true
I 2009/05/15 13:19:04 PLASMA dhtTransferJob: no selection, too many entries in transmission cloud: 67
I 2009/05/15 13:19:04 PLASMA dhtTransferJob: result from dequeueing: true


die letzten zeilen aus dem yacy00.log die sich auch wiederholen.
protocols
 
Beiträge: 15
Registriert: Sa Mai 09, 2009 5:25 pm

Re: derbe performance probleme (vor allem beim export)

Beitragvon Orbiter » Fr Mai 15, 2009 12:21 pm

kill -3 beendet den Prozess ja auch nicht, das läßt nur einen Thread Dump produzieren. Das muss ein kill -9 sein.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: derbe performance probleme (vor allem beim export)

Beitragvon protocols » Fr Mai 15, 2009 3:16 pm

ah ok danke..

also, problem: webinterface kommt nicht mehr hoch nach neustart - nachdem der webinterface nicht mehr ging (liegt wohl nicht an einem export, habe da aktuell keinen gemacht)

Code: Alles auswählen
2009-05-15 16:12:07
Full thread dump Java HotSpot(TM) Server VM (11.2-b01 mixed mode):

"DestroyJavaVM" prio=10 tid=0xa0419800 nid=0x14fe waiting on condition [0x00000000..0xb7f2b070]
   java.lang.Thread.State: RUNNABLE

"Thread-2" prio=10 tid=0xa041a400 nid=0x150c waiting on condition [0xa059e000..0xa059ef30]
   java.lang.Thread.State: WAITING (parking)
   at sun.misc.Unsafe.park(Native Method)
   - parking to wait for  <0xa2a0ead0> (a java.util.concurrent.Semaphore$NonfairSync)
   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
   at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
   at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905)
   at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217)
   at java.util.concurrent.Semaphore.acquire(Semaphore.java:286)
   at de.anomic.kelondro.text.IODispatcher.run(IODispatcher.java:133)

"Thread-1" prio=10 tid=0x09b5fc00 nid=0x150b waiting on condition [0xa0603000..0xa0603eb0]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
   at java.lang.Thread.sleep(Native Method)
   at de.anomic.server.serverProfiling.run(serverProfiling.java:64)

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

"CompilerThread1" daemon prio=10 tid=0x09b0b800 nid=0x1507 waiting on condition [0x00000000..0xa07565e8]
   java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=10 tid=0x09b08c00 nid=0x1506 waiting on condition [0x00000000..0xa07d7568]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x09b07000 nid=0x1505 waiting on condition [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x09af7000 nid=0x1501 in Object.wait() [0xa09b3000..0xa09b3db0]
   java.lang.Thread.State: WAITING (on object monitor)
   at java.lang.Object.wait(Native Method)
   - waiting on <0xa29f0a70> (a java.lang.ref.ReferenceQueue$Lock)
   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
   - locked <0xa29f0a70> (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=0x09af2400 nid=0x1500 in Object.wait() [0xa0a04000..0xa0a04f30]
   java.lang.Thread.State: WAITING (on object monitor)
   at java.lang.Object.wait(Native Method)
   - waiting on <0xa29f0978> (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 <0xa29f0978> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x09aeec00 nid=0x14ff runnable

"VM Periodic Task Thread" prio=10 tid=0x09b0f000 nid=0x1509 waiting on condition

JNI global references: 966

Heap
def new generation   total 26240K, used 13908K [0xa0d80000, 0xa29f0000, 0xa29f0000)
  eden space 23360K,  50% used [0xa0d80000, 0xa18f0ba0, 0xa2450000)
  from space 2880K,  76% used [0xa2720000, 0xa2944630, 0xa29f0000)
  to   space 2880K,   0% used [0xa2450000, 0xa2450000, 0xa2720000)
tenured generation   total 233024K, used 209611K [0xa29f0000, 0xb0d80000, 0xb0d80000)
   the space 233024K,  89% used [0xa29f0000, 0xaf6a2ce0, 0xaf6a2e00, 0xb0d80000)
compacting perm gen  total 16384K, used 4601K [0xb0d80000, 0xb1d80000, 0xb4d80000)
   the space 16384K,  28% used [0xb0d80000, 0xb11fe5b8, 0xb11fe600, 0xb1d80000)
No shared spaces configured.
protocols
 
Beiträge: 15
Registriert: Sa Mai 09, 2009 5:25 pm


Zurück zu Fragen und Antworten

Wer ist online?

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