Extrem langsamer Start von LibO 3.4.3 auf sehr alten Rechnern

Hallo!

Ich bin Administrator einer Volks-/Grundschule und wir haben nur sehr alte PCs für die Schüler. Teilweise sind es Pentium 3 Geräte mit 500-800 MHz. Wir haben eine Windows Domain mit mandatory Profiles und ich habe LO einfach per GPO verteilen können (mit Oracle Java JRE 6u27).

Nun ist das Problem aber, dass LO ewig braucht um gestartet zu werden. Wie oben erwähnt handelt es sich um (wirklich!) sehr alte Clients. Aber mit ewig meine ich 1:20 min!!! Wenn es einmal läuft, ist es relativ flott. Das Problem ist wirklich nur der Start des Programms.

Ich weiß, dass die Rechner steinalt sind. Aber ich kann nicht alle Rechner in der Schule tauschen lassen wegen LO, vor allem, weil sie für die sonstigen Anforderungen gut laufen, da die Systeme sehr gut optimiert sind.
Ein Problem ist vor allem, dass der Splashscreen erst für die letzten 10-20 Sekunden erscheint. Davor bekommt der User kein Feedback (es sei denn, der Taskmanager ist offen, was die Schüler selbst gar nicht können). Aber das müssen Entwickler ändern.

Meine eigentliche Frage: Gibt es irgendeine Möglichkeit, den Start zu beschleunigen, indem man Plugins oder Erweiterungen oder Sprachpakete deaktiviert?

Ich habe auch recherchiert und ein paar Tricks versucht (ohne Netzwerk, ohne Java), aber das brachte so gut wie nichts. Das zeigt sich auch, weil bis zum Start des Programms die CPU zu 80-100% ausgelastet wird (es ist also keine blocking I/O-Operation).

Hat irgendwer Erfahrungen mit LO auf so alten Maschinen? Gibt es eine andere, vielleicht auch ältere Version, die auf alten Geräten schneller startet?

LG,
Peter

Hallo Peter,

das Problem dürfte wohl weniger der langsame Prozessor sein, sondern der sehr knappe Arbeitsspeicher? Wieviel haben denn die Kisten?

Ich habe vor einiger Zeit auf einigen älteren Laptops Kinder-Tux (Linux auf Mandriva-Basis) installiert, dazu writer aus LO 3.0.x.
Die Rechner haben 348 MB, weniger 12 MB für den Graphik-Chip. Das geht geht gerade so, die Rechner sind aber häufig an ihrer Grenze und fangen unvermittelt an zu swappen.
Die Startzeit für LO liegt da auch knapp unter einer Minute.

Hallo,

ich habe mal von einem Projekt (der open-source Community gehört), bei dem alle Leute, alte, nicht mehr gebrauchte Hardware zu dieser Stiftung schicken können. Diese gibt diese alte Hardware dann an Schulen, arme Leute usw., die sich einfach keine bessere Hardware aus diversen Gründe beschaffen können. Dort könntest du mal anfragen... Aber ich habe gerade absolut nicht im Kopf wie das geheißen hat... google wird’s richten :slight_smile:

Nur so als Ti´pp...

Viele Grüße
Kai Klostermann

Hallo!

Ich denke nicht, dass es am Arbeitsspeicher liegt, da wie gesagt die CPU beim Start fast vollständig ausgelastet ist. Swapping würde sich ja in einer geringen CPU Auslastung zeigen und hoher Festplatten Aktivität (die natürlich beim Laden der Binaries auch gegeben ist).

Was den Schnellstarter betrifft ist mir auch aufgefallen, dass der nur etwas bringt, wenn man neue Dokumente auch über diesen erstellt. Benutzt man bei laufendem Quickstarter die Programmicons oder öffnet bestehende Dokumente aus dem Dateimanger heraus, ist das Öffnen genauso langsam, wie ohne Quickstarter, also ist der auch keine wirkliche Alternative.

Über Tipps und Tricks um den Programmstart zu beschleunigen wäre ich also sehr dankbar (oder alternative, ältere Versionen eventuell).

LG, Peter

Hallo Peter,

doch - genau der Arbeitsspeicher ist der Punkt!
Beispiel, die Werte nehme ich jetzt aus dem Kopf, da ich im Moment keinen passenden Rechner greifbar habe:

Auf meinem Arbeits-Rechner (Debian Squeeze, Xfce) nimmt die graphische Oberfläche und die Hintergrundprogramme im Ruhezustand rund 200 MB Arbeitsspeicher in Anspruch. Starte ich ein LO-Dokument, dann kommen dadurch, je nach dem wie groß und komplex dieses Dokument ist, noch mal 50-150 MB (evtl. auch noch mehr) dazu. Macht Summa 350 MB im Arbeitsspeicher. Bei 8 GB RAM ist das nicht weiter wild - bei nur 256 MB ist der aber schon ohne LO praktisch voll ausgenutzt. Für jede weitere Anwendung beginnt das System nun belegten RAM auf die Festplatte auszulagern, unter Linux in die swap-Partition, unter $MS in die swap-Datei (pagefile.sys heißt die glaube ich). Dieser swap-Bereich ist aber um einen vielfachen Faktor langsamer als der direkte Zugriff im RAM und bremst das System dann aus, u.U. bis zum Stillstand.
Die von mir heute morgen geschilderte Konfiguration (384 MB RAM, minus 12 MB für die Graphik) dürfte so ziemlich das unterste sein, was ein Rechner an RAM haben sollte, um einigermaßen damit arbeiten zu können.
Das ist eine Erfahrung aus der Praxis, in der Theorie und in den Versprechungen sieht das meist etwas anders aus.

Ich würde an Deiner Stelle also wirklich zu allererst mal den RAM-Ausbau der Rechner prüfen - ihn gegebenenfalls versuchen aufzustocken. Allerdings kann das vor allem bei älteren Rechnern dann schon wieder erheblich ins Geld gehen.

Hallo Stefan!

Danke, das mit dem RAM und Swap Zugriffen ist mir bewusst. Leider hab ich die Werte jetzt nicht im Kopf, bilde mir aber ein, dass es 512 MB waren. Ein paar RAM-Steine kugeln sicher auch noch wo rum (da schon ein paar Netzteile den Geist aufgegeben haben, hab ich immerwieder Ersatzteile aus den "Leichen" gehortet).

Ich werde das mit dem RAM am Montag einmal prüfen. Vielleicht können wir so ein paar Sekunden herausholen.

In jedem Fall ist es vor allem nervig, dass der Splashscreen erst so extrem spät kommt, wodurch dann immer die Frage/das Problem kommt: "Hab ich jetzt schon das Icon geklickt? Ach, ich drücks nochmal..."

Wir bekommen auch bald ein paar neue Rechner. Vielleicht werde ich der einen Klasse, die in nächster Zeit mit Office arbeiten will, auch die neuen Geräte geben. Dadurch gewinnen wir etwas Zeit, bis wir eine vernünftige Lösung gefunden haben.
Notfalls baue ich auch eine Batch Datei für den Programmstart, die den Kids ein früheres Feedback gibt... mal sehen.

LG und Danke

Peter

Hallo wieder!

Also es hat sich bestätigt: es sind 512 MB RAM mit eigener Grafikkarte, also wird da auch nichts abgezogen.
Sonst rennen keine nennenswerten Prozesse, also sollte der RAM eigentlich reichen.

Ich habe jetzt aber beschlossen das als "won't fix" zu betrachten, da wir hoffentlich bald ein paar neue Geräte bekommen. Dann werden diese Methusalem-P3-500MHz-Geräte ausgetauscht.

Ein paar Dinge sind mir trotzdem aufgefallen, aber das fällt wohl eher unter Bug-Report und Feature-Request, also bedanke ich mich an dieser Stelle erst einmal für euren Beistand.

LG, Peter