altes Thema! Lösung?

[kmeyster]

Hallo, Frage an die, die die Übersicht haben:
gibt es zu diesem Thema vom letzten Jahr eine Lösung?:

Obskur: JVerein sehr langsam an nur einem PC
von b.funk » Mi 20. Nov 2013, 18:18

Nochmal zur Erinerung:
qüalend langsame Performance (z.T. Stunden) und CPU bzw. Java auf Vollanschlag.....
Meine Version verhält sich genau so und ich sehe mit Grausen dem Jahresende mit seinen zig Spendenbescheinigungen entgegen.....

Kleiner Nachtrag:
PC Ubuntu
Jameica 2.7.0 nightly
Java version: java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.1) (7u65-2.5.1-4ubuntu1~0.12.04.2)
OpenJDK Client VM (build 24.65-b04, mixed mode, sharing)


Hoffe hier werden sie geholfen

Beste Grüße, Matthias

[matthias]

Ohne nähere Eingrenzung wird das "spannend" zu prüfen. Einfachster erster Schritt: Ein Runtime-Profiling. Bei dem sollte dann rauskommen wo die Zeit eigentlich verbraten wird - im besten Fall wird das sofort sichtbar - im schlimmsten hat man nichts verloren...

1. Installiere visualvm (Annahme: Ubuntu 14.04)
2. Starte Jameica und benutze es, bis es langsam ist/wird
3. Starte jvisualvm
4. In jvisualvm findet sich auf der linken Seite unter den Knoten "Local" ein Knoten, der mit "jameica" beginnt mit einem Doppelklick kann die Detailansicht geöffnet werden
5. Die erste Prüfung: Reiterkarte: "Monitor", CPU-Benutzung: wie ist die CPU Usage und wie hoch ist davon die GC activity?, Heap: Wie groß sind Size, Max und Used, PermGen: das gleiche wie bei Heap
6. Zweite Prüfung: Reiterkarte "Sampler", bei Sample "CPU" auswählen und für einige Minuten laufen lassen - ein Java Programmierer kann dann oft schon in der Übersicht sehen wo das Problem liegt, für die Nichtprogrammierer: Button "Snapshot" klicken. Es öffnet sich dann eine Detailanalyse als eigene Reiterkarte. Auf der Reiterkarte das erste "Speichern"-Symbol (Mouse-Over: "Export to") benutzen um den Snapshot zu exportieren.
7. Den erzeugten Profiler Snapshot hier hinterlegen.

[b.funk]

Hallo,

habe durch Zufall gesehen, dass hier ein altes Problem von uns aufgegriffen wurde.
Wir haben es letztlich nicht gelöst bekommen.
Nach einer kompletten Neuinstallation des Rechners mit Ubuntu 14.04 (war eh mal nötig) funktioniert alles wieder wie es soll. Leider kein besonders praktischer Lösungsansatz, fürchte ich .

Viele Grüße,
Florian

[kmeyster]

Ich hoffe ihr könnt damit was anfangen!
Die xml Datei, die man von dem zweiten Test bekommt kann ich hier aufgrund der Größe nicht ablegen.
Vielen Dank für die Hülfe!
Matthias

Snapshot Monitor1.jpg (98.96 KiB) 7361 mal betrachtet

CPU Snapshot.jpg (114.47 KiB) 7361 mal betrachtet

[matthias]

Danke.

Auf Basis der Bilder läßt sich schonmal sagen: Es ist kein Speicherproblem - der Speicherverbrauch ist i.O., in der CPU Übersicht sieht man gut, dass kaum GC (Garbadge collection) Zeit vebraucht wird.

Die Methode, die als Hotspot identifiziert wird (vgl. letztes Bild) zeigt das ein großer Teil (wie groß ist ohne gesamt Übersicht schwer zu sagen) in einer nativen Methode (d.h. außerhalb der Kontrolle von java/der Anwendung) verbraucht wird.

Das passt dann auch zu den ersten beiden Treffern bei Google:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=384315
https://code.google.com/p/android/issue ... l?id=34641

Beide Artikel zeigen, dass dieses Problem (hohe CPU Belastung) sowohl bei Eclipse, wie auch in den Android Tools festgestellt wurde. Die Ursache wurde jeweils in SWT (der Grafik-/Komponentenbibliothek) gefunden.

In dem zweiten Artikel der letzte Kommentar bringt mich zu zwei Punkten:

1. Welche Ubuntu Version wird eingesetzt?
2. Der Workaround kann eingesetzt werden, wenn die Accessibility-Funktionen (Unterstützung bei Behinderungen) nicht benötigt werden.

Zu den Profiling Daten (soweit noch notwendig): XML würde ich ggfs. einmal durch gzip/bzip2/lzma jagen (ich habe das @work regelmäßig Kompressionsraten > Faktor 10), ggfs. auch bitte mal schaun wie groß das als NPS (kann im Dialog auch exportiert werden) ist.

[kmeyster]

Danke für die ausführliche Antwort!!
Ich benutze 12.04 LTS
und der Ordner /usr/lib/x86_64-linux-gnu/ aus dem Workaround ist bei mir leer?!
Ich suche gleich mal nach der Bibliothek.
Die komprimierte xml habe ich nochmal angehangen. Vielleicht nützt die ja doch noch was.
Vielen Vielen Dank für die Hilfe, Grüße, Matthias

[matthias]

Ok - die XML Datei gibt so ziemlich wenig her - visualvm kann nur die NPS Dateien wieder öffnen *arg*

Zu deinem leeren Ordner: Hast du vielleicht die 32Bit Version von Ubuntu installiert? Das wäre dann ein anderer Ordner:

/usr/lib/i386-linux-gnu/gtk-2.0/modules/libgail.so

Es sieht aber aus, als wäre das ein uraltes Problem - ich würde zumindest mal überlegen ob Ubuntu 14.04 (die aktuelle LTS) nicht eine Überlegung wäre.

[kmeyster]

ICH WERD NICHTMEHR!!!!
Nach jetzigem Stand sieht es so aus als, wäre das des Rätsels Lösung gewesen!!!!!!!!!!!!!!!
TAUSEND DANK!!!!
Wie soll einer darauf kommen??
Dann kann der Jahresabschluss ja kommen, sofern nicht ein neues Problem auftaucht!!

Zur 14.04 LTS.....natürlich denk ich drüber nach, aber jedesmal hatte ich nach einer Aktualisierung irgendwelche gravierenden Probleme. Ich habe nämlich eine ziemlich alte Kiste, ein Compaq TC1100, der Vorläufer aller modernen Tablets quasi.
Na werd sehen, irgendwann in einem hoffnungsfrohen Augenblick drücke ich sowieso auf den OK-Button bei der Frage nach der Aktualisierung...

Alsdann, schöne Woche noch!
Grüße, Matthias