# kde 4.4 performance

## flammenflitzer

Bei mir ist in conky virtuoso-t immer die Nummer 1 mit 25 - 30 % CPU Last. Im Moment sogar, obwohl ich den "Datei-Indexer" ausgesetzt habe. Ich habe den Schieberegler auf 250 MB RAM gesetzt, um zu sehen, wie die Sache dann läuft. Im Moment - da ich den "Datei-Indexer" ausgesetzt habe - belegt nepomukservicestub und virtuaoso-t c.a. 800 MB RAM Und nicht die zugeteilten 250 MB.

KDE4.4 läuft bei mir so etwas von zäh, das es schon richtig nervt. Unter kde 4.3 hatte ich virtualbox an, habe Pakete kompilliert, einige Apps offen und konnte noch unter wine spielen. Ob das wieder wird? Außerdem reisst dolphin ab und an die Hufe hoch. Ich hoffe, das da noch etwas pasiert.

----------

## franzf

Wurde in letzter Zeit genügend oft diskutiert und kritisiert. Z.B. hier, selbe Symptome  :Wink: 

https://forums.gentoo.org/viewtopic-p-6175818.html#6175818

In den Settings strigi deaktivieren, dann läuft es richtig flott.

Lass mich raten, du hast auch nen Singlecore?

----------

## flammenflitzer

Dualcore. Ich habe die Desktopsuche deaktiviert. Nun beschwert sich kmail/akonadi.

----------

## franzf

 *flammenflitzer wrote:*   

> Dualcore. Ich habe die Desktopsuche deaktiviert. Nun beschwert sich kmail/akonadi.

 

Natürlich darfst du nicht Nepomuk deaktivieren  :Wink: 

Die "strigi Dateiindiziereung" musst du ausmachen.

----------

## mv

 :Evil or Very Mad:  Für alle, denen es wie mir stinkt, dass kmail sie zu Nepomuk nötigen will:

 :Twisted Evil:  Kmail deinstallieren und statt dessen claws-mail benutzen.

 :Mr. Green:  Ist für den Anwender weitgehend bediengleich und scheint bislang sogar weitaus besser zu sein.

----------

## lituxer

Beim Update von 4.3 auf 4.4 hatte ich das selbe Problem. Die Kiste lief auf gut deutsch gesagt beschi.....

Im englischen Forum habe ich gelesen (finde den Betrag aber nicht mehr) das man sein Home Verzeichnis komplett neu anlegen soll.

Also habe ich mir die Arbeit mal gemacht. Jetzt rennt die Kiste wieder.

Alles läuft tadellos.

----------

## flammenflitzer

 *mv wrote:*   

>  Für alle, denen es wie mir stinkt, dass kmail sie zu Nepomuk nötigen will:
> 
>  Kmail deinstallieren und statt dessen claws-mail benutzen.
> 
>  Ist für den Anwender weitgehend bediengleich und scheint bislang sogar weitaus besser zu sein.

 Claws Mail is an email client (and news reader), based on GTK+ - entfällt damit. Dann kann man ja auch thunderbird nehmen. Ich wollte aber etwas, das mit den anderen kde-pim Komponenten zusammenarbeitet.

----------

## franzf

 *flammenflitzer wrote:*   

> Claws Mail is an email client (and news reader), based on GTK+ - entfällt damit. Dann kann man ja auch thunderbird nehmen. Ich wollte aber etwas, das mit den anderen kde-pim Komponenten zusammenarbeitet.

 

Da wirst du Probleme bekommen...

Denn wenn kdepim, dann akonadi. Eine Alternative wäre mailody. Die verwenden aber sogar schon die akonadi_imap_resource. Also wieder nix ohne Nepomuk/Akonadi...

Einizge Option für kde4-only:

Ein Kommandozeilen-Mailapp in konsole laufen lassen  :Razz: 

----------

## flammenflitzer

....das man sein Home Verzeichnis komplett neu anlegen soll.

Da geht mir zu viel flöten. Das kann sich ja nur um einige configs handeln. Unter .config und unter .kde*

Vielleicht 

.config/akonadi/

.config/kde.org/

.config/Trolltech/

und das komplette

.kde4/

----------

## franzf

 *flammenflitzer wrote:*   

> ....das man sein Home Verzeichnis komplett neu anlegen soll.
> 
> Da geht mir zu viel flöten. Das kann sich ja nur um einige configs handeln. Unter .config und unter .kde*

 

Einerseits zerschossene Config, andererseits können lange verwendete /homes auch mal etwas (sehr) fragmentieren. Mit sys-fs/shake defragmentieren sollte auch helfen.

Wenn der indexer mehrmals pro Stunde durch deine files fetzt, kannst du dir denken wie das ausbremst, wenn fragmentiert...

Werd ich wohl auch mal testen, thx für den Tip!

Was ich auch noch im kde-forum gelesen hab: Den Regler für den Speicherverbrauch verändern. Ich kann mir vorstellen, dass der angezeigte Defualt von 50 MB nur in der Config-GUI sichtbar ist. Im Programm selber sieht man vllt. was anderes - oder gar nichts und nimmt so viele wie man grad lustig ist...

----------

## flammenflitzer

PS: Was ist denn das 

```
Shake is a defragmenter ...
```

 Ich kann mich noch an endlose, teils sehr leidenschaftliche Diskussionen erinnern, das man unter Linux so etwas nie brauchen wird. (Mein home Verzeichnis ist schon bald 10 Jahre alt.)

----------

## franzf

 *flammenflitzer wrote:*   

> Ich kann mich noch an endlose, teils sehr leidenschaftliche Diskussionen erinnern, das man unter Linux so etwas nie brauchen wird. (Mein home Verzeichnis ist schon bald 10 Jahre alt.)

 

Dass Linux-Dateisysteme nicht fragmentieren entspricht nicht der Wahrheit. Sie tun es einfach nicht so schnell wie FAT oder NTFS. Und das Defragmentieren geht deutlich leichter: Inhalt der Platte kopieren, Dateien löschen, Dateien zurückkopieren -> fertig.

Die Algorithmen scheinen einfach durchdachter zu sein.

Aber wenn eine Partition alt ist und vor allem oft großen Veränderungen unterworfen ist, kann eine Fragmentierung schneller eintreten. Versuchs einfach mal mit shake  :Wink: 

----------

## flammenflitzer

 *franzf wrote:*   

>  *flammenflitzer wrote:*   Ich kann mich noch an endlose, teils sehr leidenschaftliche Diskussionen erinnern, das man unter Linux so etwas nie brauchen wird. (Mein home Verzeichnis ist schon bald 10 Jahre alt.) 
> 
> Dass Linux-Dateisysteme nicht fragmentieren entspricht nicht der Wahrheit. Sie tun es einfach nicht so schnell wie FAT oder NTFS. Und das Defragmentieren geht deutlich leichter: Inhalt der Platte kopieren, Dateien löschen, Dateien zurückkopieren -> fertig.
> 
> Die Algorithmen scheinen einfach durchdachter zu sein.
> ...

  Diese Meinung habe ich auch vertreten und wurde quasi als windows-freund abgekanzelt.

----------

## think4urs11

 *flammenflitzer wrote:*   

>  *franzf wrote:*   Aber wenn eine Partition alt ist und vor allem oft großen Veränderungen unterworfen ist, kann eine Fragmentierung schneller eintreten.   Diese Meinung habe ich auch vertreten und wurde quasi als windows-freund abgekanzelt.

 

Niemand hat gesagt das es leicht ist etwas zu vertreten das die Mehrheit als 'falsch' deklariert.  :Wink: 

Wenn man aber logisch an die Sache rangeht merkt man das bei regelmäßiger/intensiver Nutzung jedes FS fragmentiert (Hintergrundjobs die dies verhindern bzw. beheben sind genaugenommen keine Lösung des Problems sondern ein Workaround).

----------

## flammenflitzer

 *franzf wrote:*   

> Versuchs einfach mal mit shake 

  Hast du damit Erfahrungen gesammelt? Kannst du das Programm bewerten?

----------

## franzf

 *flammenflitzer wrote:*   

>  *franzf wrote:*   Versuchs einfach mal mit shake   Hast du damit Erfahrungen gesammelt? Kannst du das Programm bewerten?

 

Momentan kann ich nichts dazu sagen. Mein /home ist nicht wirklich stark fragmentiert (5%). Aber im Internet stößt man drauf, wenn man nach Möglichkeiten zur Defragmentierung unter linux sucht.

Das schöne an shake ist ja, dass es das gemountete FS defragmentieren kann. Du kannst auch nur einen bestimmten Ordner defragmentieren, oder nur einzelne Dateien. Zum Testen ist das sicher eine gute Möglichkeit. Ein größeres Dir wegsichern, shake drüberlaufen lassen und schauen ob alles kaputt ist  :Wink: 

Nebenbei: Die 0.3.1 ist stable im offiziellen Tree, also kann es nicht soooo schlecht sein.

----------

## mv

 *flammenflitzer wrote:*   

> Claws Mail is an email client (and news reader), based on GTK+ - entfällt damit.

 

gtk+ != GNOME; evolution z.B. würde ich deswegen nicht empfehlen, weil das gconf2 und damit wesentliche GNOME-Komponenten nach sich zieht. gtk+ hingegen ist i.W. nur eine GUI-Bibliothek, braucht nicht allzu viel Speicher und hat auch keine sicherheitsrelevanten Implikationen wie das Betreiben von GNOME. Vermutlich haben diese Bibliothek ohnehin die meisten Benutzer auf ihrer Platte - man müsste schon auf viel Sinnvolles verzichten, wenn man diese Bibliothek vermeiden will.

 *Quote:*   

> Dann kann man ja auch thunderbird nehmen.

 

Nein, erstens ist da die Bedienung ganz anders, und zweitens braucht wohl thunderbird alleine mehr Plattenplatz als gtk.

 *Quote:*   

> Ich wollte aber etwas, das mit den anderen kde-pim Komponenten zusammenarbeitet.

 

Wenn Du pim willst, führt an Nepomuk kein Weg vorbei: Gerade pim wurde ja mit Nepomuk verknüpft. Dass kmail das dann auch braucht, ist nur die Konsequenz.

----------

## mv

 *think4urs11 wrote:*   

> Wenn man aber logisch an die Sache rangeht merkt man das bei regelmäßiger/intensiver Nutzung jedes FS fragmentiert

 

Jein. Es ist eine Frage der Statistik und hat nichts mit regelmäßiger Nutzung sondern der Art der Nutzung zu tun. Man kann immer ein Filesystem so schreiben, dass es bei bestimmten Arten der Nutzung nicht fragmentiert (in dem Sinne, dass die Fragmentierung niedrig bleibt und auch nach langer Nutzung nicht ansteigt). Erst wenn die Nutzung häufig anders ist als konzeptionell statistisch erwartet wurde, wird die Fragmentierung ansteigen. Außerdem ist der absolute Prozentteil der Fragementierung weitgehend irrellevant (außer für Backups o.ä.): Wichtiger für das "normale" Arbeiten ist vielmehr, ob die zusammen benutzten Daten auch halbwegs zusammen stehen.

 *Quote:*   

> Hintergrundjobs die dies verhindern bzw. beheben sind genaugenommen keine Lösung des Problems sondern ein Workaround

 

Das ist eher eine sprachliche Haarspalterei. Wenn ein Filesystem von vornherein etwas Redundanz einbaut, um die Fragementierung gering zu halten, könnte man dies genauso als "permanenten nichtabschaltbaren Hintergrundjob" auffassen, der zudem noch schlecht scheduled ist, weil er immer dann einsetzt, wenn man sowieso schon Plattenbelastung hat. Da ist ein Hintergrundjob, dem man ggf. die Rechenzeit nach Bedarf zuordnen/entziehen kann schon eine weitaus bessere Lösung. Wichtig für die Praxis ist eher, dass dies tatsächlich im Hintergrund (also bei gemountetem aktivem Filesystem) geschehen kann. Richtig sinnvoll wird das unter Linux wohl erst mit BTRFS möglich sein.

----------

## Yamakuzure

Es werden immer wieder Dateien gelöscht. Schon entstehen Lücken. Ist dann eine neue Datei größer als die größte verfügbare Lücke, wird die Datei fragmentiert. Vollkommen egal welches FS benutzt wird.

...ich habe bei einer so einfachen Logik noch nie verstanden, warum so viele Menschen so wehement dagegen anstinken. Jedes Dateisystem fragmentiert. Wie schnell und wie stark mag ja unterschiedlich sein. Aber die Frage nach dem "ob" muss immer mit einem klaren "Ja" beantwortet werden.

----------

## mv

 *Yamakuzure wrote:*   

> Es werden immer wieder Dateien gelöscht. Schon entstehen Lücken. Ist dann eine neue Datei größer als die größte verfügbare Lücke, wird die Datei fragmentiert. Vollkommen egal welches FS benutzt wird. [...] Jedes Dateisystem fragmentiert. Wie schnell und wie stark mag ja unterschiedlich sein.

 

Du übersiehst, dass eine Lücke - insbesondere noch in einer besonders großen Datei - für die Praxis vollkommen vernachlässigbar ist; je nach Zählweise und Dateigröße ist das eine Fragmentierung im weniger-als-Promillebereich. Nun magst Du vielleicht argumentieren, dass Du Dir - in einer Art bösartigem Tetris - immer gerade ungünstige Dateibrocken ausdenken kannst, bei denen die Fragmentierung kontinuierlich ansteigt. Das ist unbestritten, ist aber ein worst-case-Szenario, das bei normaler Filesystemnutzung niemals eintritt. Vielmehr wird es bei normaler Nutzung durchaus häufig vorkommen, dass nach dem Löschen und Neuschreiben etlicher Dateien (im Zuge der normalen Nutzung) die Gesamtfragmentierung sogar leicht abnimmt. Wenn sich das auf Dauer die Waage hält, wird der Level der Fragmentierung also ungefähr unverändert bleiben - auch und gerade bei langer Nutzung; und wenn man ein paar Annahmen über die durchschnittlichen Dateigrößen und deren Varianz macht, kann man das Dateisystem eben für so etwas "justieren". Die Fragmentierung wird nur dann zunehmen, wenn über lange Zeit von den Annahmen, für die das Filesystem ausgelegt ist, abgewichen wird, und zwar in gewissem Sinne immer in die "gleiche" Richtung (z.B. bei jeder Session werden jedesmal längere Dateien geschrieben, und es gibt fast keine kurzen o.ä.); das ist aber statistisch extrem unwahrscheinlich. Deshalb schrieb ich ja: Die Fragmentierung ist eine Frage der Stochastik.

----------

## think4urs11

Erstens kommt es anders

Zweitens als man denkt

 :Wink: 

Bezogen auf ein FS das Dieter Durchschnitt (durchaus linux-affin) für z.B. sein /home einrichtet ist es aber schwer 'richtige' Annahmen über die Verwendung zu finden. Evtl. kommt er auf die Idee plötzlich MP3s zu sammeln, oder Videoschnitt zu machen, oder er fängt an zu programmieren incl. VCS usw...

Im wesentlichen wählt D.D. hier etwas wie ext3/4, reiser oder oder, aber meist mit den Defaults - weil die 'im Mittel' ganz gut sind.

Fragmentierung=ok if percentage=low kann man so generell auch nicht sagen - laut Murphy sind genau die 'nur 2% fragmentierte' Dateien genau die die einen ausbremsen.

Klar gibt es einen ganzen Ar... voll Variablen die die Fragmentierung beeinflußen wie z.B. %-belegter Platz. Wenn man es sich einfach machen will nimmt man grundsätzlich die gerade größtmöglich verfügbare Platte und wirft die auf das Problem - ein /home das zu 5% belegt ist fragmentiert nur seeehr langsam; eines das überwiegend zu 80+% belegt ist schon eher.

Letztlich ändert das aber nichts am root cause - es gibt keine garantiert nicht fragmentierenden FS (wie gesagt mit Konstrukten die im Hintergrund aufräumen und files hin- und herschieben läßt sich das sehr gut verstecken, jedenfalls sofern das System nicht ständig unter high load steht).

Auc SSDs lösen diese Problem nicht, sie verstecken es nur durch die viel schnelleren Transferraten und die extrem viel schnelleren seektimes - bedingt dadurch das hier kein mechanischer Kopf mehr bewegt werden muß.

----------

## Klaus Meier

Zwei Dinge dazu. Ob ein FS fragmentiert oder nicht ist scheiß egal. Ich habe festgestellt, dass das Arbeiten wesentlich schneller geht, wenn man es einmal alle 6 Monate umkopiert. Außerdem hat man dann mal wieder ein Backup. Und das, obwohl fsck mir angezeigt hat, es wäre zu 0,1% defragmentiert. Außerdem, beiext3 sind die Werte doch gestiegen, ext4 bekomme ich einfach nicht über diese 0,1. Und es ist mir echt egal, an was es liegt. Der Effekt ist spürbar. Jeder, der auf ein andere FS gewechselt ist, war der Meinung, das das Neue viel schneller ist als das alte. Einer wechselt von etx3 auf reiser: Viel schneller. Der nächste wechslet von reiser auf ext3: Viel schneller.  Liegt halt nicht am FS sondern an der neuen Ordnung der Dateien. Also einfach mal das home Verzeichnis auf ein neues kopieren, das alte löschen und dann umbenennen. Aber ich glaube nicht, dass dies das Problem löst.

Beim Wechsel von 4.3 auf 4.4 waren bei mir so gut wie alle Einstellungen weg. Da haben die kräftig durchgerührt. Ist dafür aber auch deutlich übersichtlicher geworden als vorher. Und dabei wurde dann wohl ein größeres Konfusium angerichtet, was das lesen der Dateien sehr verzögert. Also eventuell nur den .kde4 Ordner löschen. Oder erst mal nur den config Teil.

----------

## Yamakuzure

@mv: Genau das meinte ich mit dem "Gegenanstinken". Jedes FS fragmentiert. Punkt. Wann, wie stark, wie schnell, ist egal. Ob die Rate relevant ist, war nicht die Frage. Sondern nur ob ein FS unter Linux fragmentiert. Egal ob 0,000001% oder 50%. Die Antwort lautet: ja

----------

## mv

 *Klaus Meier wrote:*   

> Zwei Dinge dazu. Ob ein FS fragmentiert oder nicht ist scheiß egal. Ich habe festgestellt, dass das Arbeiten wesentlich schneller geht, wenn man es einmal alle 6 Monate umkopiert.

 

Ich vermute, der Effekt, der sich da bei Dir hauptsächlich bemerkbar gemacht hat, ist das Directory Hashing. Von ext4 auf ext4 wird Dir das dann in 6 Monaten keinen Vorteil mehr verschaffen. Bei btfrs schon gleich gar nicht.

----------

## mv

 *Yamakuzure wrote:*   

> Wann, wie stark, wie schnell, ist egal. Ob die Rate relevant ist, war nicht die Frage. [...] Die Antwort lautet: ja

 

Diese Frage interessiert aber keine Sau: Dies ist ganz bestimmt nicht die Frage, die man meint, wenn man über Defragmentierung spricht, denn 0% Fragmentierung erwartet ja kein vernünftiger Mensch. Die Frage, die tatsächlich dabei interessiert, ist, ob Defragmentierung einen echten Vorteil bringt. Und hier fällt die Antwort eben viel differenzierter aus (ich wiederhole jetzt nicht alles nochmals).

----------

## mrsteven

Zum Thema Fragmentierung noch eine Kleinigkeit: Es ist ja bei den meisten Unix-/Linuxprogrammen so, dass diese ziemlich viele kleinere Dateien installieren. Diese können ja theoretisch auf der Platte ziemlich weit auseinander liegen, der Kernel weiß ja nicht, welches Programm welche Dateien benutzt. Das heißt, dass auch bei wenig fragmentierten Dateien der Festplattenkopf ziemlich viel hin und her springen muss, weil die kleinen Dateien eben alle erst mal einzeln geladen werden müssen.

----------

## Klaus Meier

 *mv wrote:*   

>  *Klaus Meier wrote:*   Zwei Dinge dazu. Ob ein FS fragmentiert oder nicht ist scheiß egal. Ich habe festgestellt, dass das Arbeiten wesentlich schneller geht, wenn man es einmal alle 6 Monate umkopiert. 
> 
> Ich vermute, der Effekt, der sich da bei Dir hauptsächlich bemerkbar gemacht hat, ist das Directory Hashing. Von ext4 auf ext4 wird Dir das dann in 6 Monaten keinen Vorteil mehr verschaffen. Bei btfrs schon gleich gar nicht.

 

Dieses Thema hatten wir ja schon mal. Entschuldige meine Frage, aber was genau ist jetzt Directory Hashing? Ich denke, es gibt dabei drei Punkte.

Punkt eins: Fragmentierung: Wird religiös diskutiert, bringt eher Null, warum, dazu später.

Punkt zwei: Verhalten beim Löschen von Dateien. War bei ext3 so, alter Eintrag wurde gelöscht, aber nicht überschrieben. Neue Datei, neuer Eintrag. Also ein Ordner, in dem jeden Tag 100 Dateien gelöscht werden und 100 hinzugefügt werden hat ganz schnell mal 100 000 Einträge. Das dies nicht gerade förderlich ist, ist wohl klar. Dies kann man aber durch fsck -fD beheben. Mache ich so einmal die Woche. Ist es das, auf was sich das Hashing bezieht? Vielleicht erinnert sich noch jemand an einen alten Beitrag von mir, war ja recht heftig wegen: "Sehr geehrte Damen und Herren, liebe Neger...." wo ich der Meinung war, dass ext4 deutlich schneller als ext3 ist, bis ich dann festgestellt habe, dass ich mein ext3 mit besagten fsck -fD auf das gleiche Niveau heben konnte.

Punkt drei: Und ich denke das, ist der wichtigste, weil er weder durch fsck noch durch defragmentieren  bearbeitet werden kann. Ich starte ein Programm. Und das liest dann Dateien aus .kde4/share/config. Diese Dateien sind nicht fragmentiert und das Directory ist auch auf der Höhe. Aber trotzdem können sie vollständig über die ganze Platte verteilt sein. Kommen sie zusammen, wenn ich diesen Ordner umkopiere? Eher nicht, da wo gerade frei ist wird hingeschrieben. Wenn ich aber eine komplett freie Partition habe, dann wird durch das rekursive kopieren alles direkt zusammen geschrieben.

Sollte da durch ext4 einiges besser geworden sein als bei ext3 und meine Ausführungen damit nicht so ganz auf der Höhe, dann bitte ich das zu entschuldigen.

Bei den alten Griechen gab es mal so einen Satz: Was die Natur deinem Geist nicht offenbart, das zwingst du ihr auch nicht mit Hebeln und Schrauben ab. Daran erinnert mich das ganze manchmal. Statt 30 Minuten probieren wird drei Tage diskutiert.... Also jetzt kein Vorwurf gegen direkt anwesende, aber hier schrieb doch gerade jemand, wie man auf ihn reagiert hat, als er das Wort "Fragmentieren" in den Mund genommen hat.Last edited by Klaus Meier on Fri Feb 26, 2010 5:09 pm; edited 1 time in total

----------

## Klaus Meier

 *mrsteven wrote:*   

> Zum Thema Fragmentierung noch eine Kleinigkeit: Es ist ja bei den meisten Unix-/Linuxprogrammen so, dass diese ziemlich viele kleinere Dateien installieren. Diese können ja theoretisch auf der Platte ziemlich weit auseinander liegen, der Kernel weiß ja nicht, welches Programm welche Dateien benutzt. Das heißt, dass auch bei wenig fragmentierten Dateien der Festplattenkopf ziemlich viel hin und her springen muss, weil die kleinen Dateien eben alle erst mal einzeln geladen werden müssen.

 Hast wohl das gleiche gedacht wie ich, während ich geschrieben habe....

----------

## toralf

 *Klaus Meier wrote:*   

> Dies kann man aber durch fsck -fD beheben.

 Darf ich fragen, wie ? Bootest Du dazu von CD oder kann man diesen Parameter einem reboot "mitgeben" ? Anbei meinst Du "fsck.ext3fs -fD", oder ?

----------

## Klaus Meier

 *toralf wrote:*   

>  *Klaus Meier wrote:*   Dies kann man aber durch fsck -fD beheben. Darf ich fragen, wie ? Bootest Du dazu von CD oder kann man diesen Parameter einem reboot "mitgeben" ? Anbei meinst Du "fsck.ext3fs -fD", oder ?

 

Ich habe zweimal Gentoo auf meiner Platte. Kann da eins booten um dann das andere zu bearbeiten. Bin halt ein Bastler, da ist das schon eine sichere Sache. Aber normal musst du das von einer InstallationsCD oder einer RescueCD machen. Bin da zur Zeit mit der SystemRescueCd am glücklichsten, kannst du dir auf einen USB Stick packen, recht flexibel konfigurieren, das Teil baseirt auf Gentoo, und ist so aufgebaut, dass du dir da auch einen KDE Desktop zubauen kannst, wenn du willst.

http://www.sysresccd.org/Main_Page

fsck reicht, was für ein FS das ist, findet es alleine raus. Ansonsten kenne ich shutdown -F, aber ob man da ein D anhängen kann? Steht jedenfalls nicht in der Doku. Werde ich aber bei Gelegenheit mal austesten.

----------

## toralf

Ok, danke. Ich probier's mal mit GRML auf einem Stick.

----------

## mv

 *Klaus Meier wrote:*   

> Entschuldige meine Frage, aber was genau ist jetzt Directory Hashing?

 

Ohne Directory Hashing stehen die Dateien in irgendeiner Reihenfolge (meist in der Reihenfolge, in der sie erzeugt wurden) hintereinander im Directory. Möchte man also Datei "z" öffnen und ist diese Datei zufälligerweise die letzte Datei im Directory, so müssen vorher trotzdem alle 27346 Directory einträge gelesen und auf den Namen "z" überprüft werden. Mit Directory-Hashing wird diese lineare Laufzeit durch (zumindest in gewissem Sinne) konstante Laufzeit ersetzt - auf Kosten von Plattenplatz. Die Reihenfolge, in der die Dateien geschrieben werden spielt diesbezüglich keine Rolle mehr.

 *Quote:*   

> Fragmentierung: Wird religiös diskutiert, bringt eher Null, warum, dazu später.

 

Reiser4 soll sich bzgl. Fragmentierung bei längerer Nutzung extrem ungünstig verhalten. Ob dies allerdings den Tatsachen entspricht oder nur aus "ideologischen" Gründen behauptet wurde, weiß ich nicht.

 *Quote:*   

> Punkt drei: Und ich denke das, ist der wichtigste, weil er weder durch fsck noch durch defragmentieren  bearbeitet werden kann. Ich starte ein Programm. Und das liest dann Dateien aus .kde4/share/config. Diese Dateien sind nicht fragmentiert und das Directory ist auch auf der Höhe. Aber trotzdem können sie vollständig über die ganze Platte verteilt sein. Kommen sie zusammen, wenn ich diesen Ordner umkopiere? Eher nicht, da wo gerade frei ist wird hingeschrieben. Wenn ich aber eine komplett freie Partition habe, dann wird durch das rekursive kopieren alles direkt zusammen geschrieben.

 

Hier liegst Du vollkommen falsch und zwar gleich aus mehreren Gründen:

Erstens ist es in den seltensten Fällen so, dass Daten, die hintereinander benötigt werden typischerweise "nahe" im Directory-Baum stehen. Das Beispiel .kde/share/config ist hier eine seltene Ausnahme; typischer ist: Es wird etwas aus /usr/bin aus /usr/lib aus /usr/share und aus /home/user/.bla benötigt. Umkopieren bringt da gar nichts. Was man in dem Fall bräuchte wäre eine Statistik, in welcher Reihenfolge welche Dateien typischerweise gelesen werden und müsste dann das Dateisystem entsprechend umorganisieren. Ich glaube mich zu erinnern, dass so etwas in BTRFS oder Reiser4 geplant war; was daraus geworden ist, habe ich nicht weiter verfolgt.

Selbst das Beispiel .kde/share/config ist sehr schlecht, denn schon beim nächsten Herunterfahren von KDE werden alle diese Dateien neu geschrieben. Der Effekt für dieses Directory beim Umkopieren ist also quasi garantiert gleich null.

Drittens ist es auch nicht so, dass die Dateien, die hintereinander geschrieben werden auch tatsächlich hintereinander auf der Platte landen. Tatsächlich besteht ja in den meisten Dateisysteen die Strategie zur Vermeidung von Fragmentierungsanstieg darin, gerade große Lücken zwischen zeitnah geschriebenen Dateien zu lassen. In ext4 mag das vielleicht durch extents und delayed allocation etwas abgemildert werden, aber prinzipiell ist auch hier die Strategie die selbe.

 *Quote:*   

> Bei den alten Griechen gab es mal so einen Satz: Was die Natur deinem Geist nicht offenbart, das zwingst du ihr auch nicht mit Hebeln und Schrauben ab. Daran erinnert mich das ganze manchmal. Statt 30 Minuten probieren wird drei Tage diskutiert...

 

Ich würde das Zitat gerade umgekehrt deuten: Man sollte nicht ziellos an irgendewelchen Schrauben drehen (und vielleicht mit Glück Erfolg haben), sondern mit dem Geist erfassen, was man tun will...

----------

## mv

 *Klaus Meier wrote:*   

> Aber normal musst du das von einer InstallationsCD oder einer RescueCD machen.

 

Keineswegs: Mit openrc geht es so:  */etc/conf.d/fsck wrote:*   

> fsck_args="-A -p -D"

 

----------

## Klaus Meier

@mv: fsck_args="-A -p -D" geht voll in die Hose. Ich habe es gesetzt und dann ein shutdown -F now gemacht. -D verändert die Partition immer und erzwingt einen Neustart. Ohne die Partition vorher als auber zu markieren. Ergebnis:Endlosschleife.

Konfigurationsdateien? Werden die jedes mal neu geschrieben, auch wenn sie nicht geändert werden? Alleine diese Tatsache wäre ja schon tödlich.

Aber jetzt noch mal zum eigentlichen Thema, Performance. Ich bin tatsächlich seit einiger Zeit bei KDE. 2 Kern CPU mit 2GB Speicher. gentoo-sources, voll  auf Desktop optimiert. Was mir da aufgefallen ist. Der Start, bis der Desktop benutzbar ist, nach dem einloggen, ist ewig lang. Und wenn man dann noch Programme startet, dann schaut man erst mal ewig auf drehende Kreise. Erinnert schon irgendwie an Vista. Dann hängen manche Programme irgendwie, wenn sie minimiert in der Taskleiste sind. Muss man dreimal draufklicken oder nach dem ersten Klick warten, hab das noch nicht eingrenzen können, aber irgendwie klemmt da was. Bei 4.3 war das nicht so.

Aber irgendwie alles nicht konkret eingrenzbar. Zur Zeit läuft es wesentlich besser als noch vor einer Woche. keine Ahnung, warum.

Aber nun der Hammer: Ist das die "Desktopsuche"? Ich habe sie nicht abgestellt. Aber so ab und an rattert die Kiste los und ist für einige Zeit unbedienbar. Also keine Chance, da so etwas wie top oder Systemmonitor zu starten. slocate habe ich schon seit Ewigkeiten, das hat meine Kiste noch nie in die Knie gezwungen. Also seit 4.4 ist die Performance voll in den Keller gegangen.

Und dann noch ein Schmakerl....  Hab so per Zufall mal gesehen, was ich in .kde4 habe....

```
drwxr-xr-x 2 rmx rmx 4096 23. Feb 02:04 Autostart

lrwxrwxrwx 1 rmx rmx   21 23. Feb 13:03 cache-airwolf -> /var/tmp/kdecache-rmx

lrwxrwxrwx 1 rmx rmx   21 23. Feb 02:04 cache-sirwolf -> /var/tmp/kdecache-rmx

drwxr-xr-x 2 rmx rmx 4096 23. Feb 20:09 env

drwx------ 6 rmx rmx 4096 23. Feb 20:09 share

drwxr-xr-x 2 rmx rmx 4096 23. Feb 20:09 shutdown

lrwxrwxrwx 1 rmx rmx   16 23. Feb 13:03 socket-airwolf -> /tmp/ksocket-rmx

lrwxrwxrwx 1 rmx rmx   16 23. Feb 02:04 socket-sirwolf -> /tmp/ksocket-rmx

lrwxrwxrwx 1 rmx rmx   12 23. Feb 13:03 tmp-airwolf -> /tmp/kde-rmx

lrwxrwxrwx 1 rmx rmx   12 23. Feb 02:04 tmp-sirwolf -> /tmp/kde-rmx
```

Links mit absolut gleichem Namen, die auf das Gleiche zeigen doppelt? Wie geht das und was soll das?

----------

## franzf

 *Klaus Meier wrote:*   

> Links mit absolut gleichem Namen, die auf das Gleiche zeigen doppelt? Wie geht das und was soll das?

 

Ich seh dsa nix doppelt, muss an deinem Font liegen  :Razz: 

Hast du irgendwann am 23.02. deinen hostname von sirwolf in airwolf geändert?

----------

## Klaus Meier

Ups, da muss man mal genau hinsehen.... Nö habe ich eigentlich nicht. Wo kommt das denn her? Vor allem, ich finde da auch nichts mit sirwolf.... na egal, mal wieder gepennt.

----------

## mv

 *Klaus Meier wrote:*   

> @mv: fsck_args="-A -p -D" geht voll in die Hose. Ich habe es gesetzt und dann ein shutdown -F now gemacht. -D verändert die Partition immer und erzwingt einen Neustart.

 

Bei mir funktioniert das bislang einwandfrei. Aber ich setze auch nie shutdown -F ein sondern übergebe statt dessen mit Grub den Kernel-Parameter "gentoo=forcefsck", falls ich mal ein fsck erzwingen will. Da der Kernel-Parameter nur einmalig übergeben wird, steht auf der Partition nicht, dass er gleich wieder überprüfen soll, und somit gerate ich nie in die Gefahr von solchen Loops. Möglicherweise hast Du das damals aber auch nur mit einer kaputten Version von openrc getestet: Ich habe in Erinnerung, dass in einer der letzten Versionen ein Bug bzgl. des Löschens der entsprechenden "Marker"-Datei (/tmp/forcefsck oder so ähnlich) gefixt wurde.

 *Quote:*   

> Konfigurationsdateien? Werden die jedes mal neu geschrieben, auch wenn sie nicht geändert werden?

 

KDE schon (zumindest sehr viele). Das hat ja damals für die große Empörungswelle bzgl. ext4 gesorgt: Weil kde alle Dateien neu geschrieben hat, waren im Falle eines Crashs beim Herunterfahren dann alle Konfigurationsdateien weg.

 *Quote:*   

> Aber irgendwie alles nicht konkret eingrenzbar. Zur Zeit läuft es wesentlich besser als noch vor einer Woche. keine Ahnung, warum.

 

Für Programmstarts kann es vielleicht nützen, LD_BIND_NOW=1 zu exportieren oder mit LDFLAGS="-Wl,-z,now" zu übersetzen (ich tue das ohnehin, weil es in Verbindung mit LDFLAGS="-Wl,-z,relro" vom Sicherheitsaspekt her sinnvoll ist); vorsicht aber: xorg und seine Treiber brauchen lazy linking! Ist -Wl,--as-needed inzwischen schon der Default? Ansonsten könnte auch das die Startzeit noch beschleunigen.

Ich weigere mich, mir KDE selbst genauer anzuschauen, aber es könnte sein, dass die Sachen in /var/tmp/kdecache-* irgendwelche Bäume enthalten, die vielleicht nich genug durchgeschüttelt wurden - möglicherweise kann das Löschen dieser Ordner die Sache beschleunigen (beim ersten Neustart geht es natürlich deutlich langsamer, weil da diese Dateien wieder erstellt werden müssen).

 *Quote:*   

> Aber nun der Hammer: Ist das die "Desktopsuche"? Ich habe sie nicht abgestellt.

 

Du hast nicht USE=-semantik-desktop? Ja, das ist der sichere Untergang jedes effizienten Systems. [RANT] Der Hauptzweck von Nepomuk ist es, Rechenzeit und Plattenplatz in riesigen Mengen zu schlucken und ständig Kopien Deiner Daten für Einbrüche in den Webbrowser vorzuhalten. Aber dafür kannst Du es dann ca. einmal pro Quartal nutzen - mehr Bedarf hat man dafür meist nicht. [/RANT]

----------

## Klaus Meier

Das mit dem shutdown -F habe ich gemacht, um es mal zu testen. Finde das Verhalten auch nicht in Ordnung Die Partition sollte vor dem Neustart als sauber gekennzeichnet werden. Die Gefahr bei dir ist, falls du mal ein defektes FS hast, dann kommst du aus der Schleife nicht mehr raus. Ansonsten nutze ich Testing und das ist aktuell. Also wenn es da einen Fehler gibt, was für mich so aussieht, dann wurde der noch nicht gefixt.

Ich habe USE=semantik-desktop. Wurde durch 4.4 dazu gezwungen, ist jetzt Pflicht.

Und mit dem ersten Programmstart, wo es so lange gedauert hat, eventuell ist mir da was mit den Variablen durcheinander gegangen, das mit airwolf und sirwolf... Keine Ahnung wo das herkommt, aber so um das Datum ist es mir nicht mehr so extrem langsam aufgefallen. Momentan geht es eigentlich. Bis auf dieser Komplettausfälle so ab und an mal. Hab das mal komplett gelöscht.

Und alle Konfigurationsdateien zu schreiben, auch wenn sich nichts geändert hat ist ja wohl ein absolutes Unding. Na dass dann die Performance in den Keller geht ist ja wohl normal.

Zur Zeit läuft gerade das Update auf 4.4.1. Dann mal weiter sehen. Edit: Es geht jetzt auch wieder ohne semantic-desktop.

----------

## mv

 *Klaus Meier wrote:*   

> Das mit dem shutdown -F habe ich gemacht, um es mal zu testen. Finde das Verhalten auch nicht in Ordnung Die Partition sollte vor dem Neustart als sauber gekennzeichnet werden.

 

Die Partition ist schon als sauber gekennzeichnet, aber die Existenz der Datei /forcefsck bewirkt halt auch bei einer sauberen Partition einen fsck - das ist ja gerade ihr Zweck. Diese Datei wird aber von openrc verwaltet, nicht von fsck. Deshalb meine ich ja, dass Du einem Bug von openrc aufsitzt. (Oder bootet fsck selbständig? Das wäre natürlich ein Bug in fsck.) Im Moment habe ich aber weder Lust noch Zeit, da herumzuprobieren.

 *Quote:*   

> Die Gefahr bei dir ist, falls du mal ein defektes FS hast, dann kommst du aus der Schleife nicht mehr raus.

 

Wenn ein Filesystem so defekt ist, dass es sich nicht selbst reparieren kann, muss man sowieso mit "i" (interactive) bei openrc eingreifen und fsck von Hand aufrufen. Falls nicht einmal das möglich ist, ist ohnehin eine Rettungs-CD angesagt.

 *Quote:*   

> Ich habe USE=semantik-desktop. Wurde durch 4.4 dazu gezwungen, ist jetzt Pflicht.

 

Bei mir hat Löschen von kmail (und statt dessen Installation von claws-mail) ausgereicht, ein brauchbares kde-4.4 (sprich: Ohne nepomuk, mysql, akonadi, strigi, soprano) zu haben: 2-3 überaufgeblasene Datenbankserver plus viel Frontend-Quatsch plus ein Haufen überflüssige Dämonen nur für das Speichern von ein paar Email-Adressen - nein danke.   :Evil or Very Mad: 

Und da sich claws-mail auch deutlich besser konfigurieren lässt, und sich eher wie kmail-3.5 verhält statt kmail-4.* (mit dessen Oberfläche die Benutzer ohnehin Probleme hatten), hat der Wechsel sogar viel gebracht: Anders wäre ich gar nicht auf die Idee gekommen, claws-mail zu probieren.

Leider ist zu befürchten, dass einem mit kde-4.5 der Nepomuk-Quatsch mit noch anderen Sachen aufs Auge gedrückt wird; spätestens dann wird kde bei mir in der Tonne landen.

----------

## Klaus Meier

So, nun habe ich den Totalzusammenbruch mal etwas analysieren können. Ich habe 2GB Speicher, von denen normalerweise so zwischen 600 MB und 1GB belegt sind. Nun habe ich eine Datei (800MB) mittels Dolphin von einer Partition auf eine andere verschoben. Ergebnis: Speicher voll und 1,4 GB Swapspeicher belegt. Damit ist ja auch klar, warum das System so losrattert. Nix Desktopsuche. Genaueres festzustellen war nicht möglich, während des Swappens geht ja nicht viel. Und hinterher hatte ich dreimal den Prozess kio_thumbnail als gößten Speicherfresser,  zusammen über 300 MB Speicher.

----------

## Josef.95

@klaus Meier

Dann schau mal ob dir https://forums.gentoo.org/viewtopic-t-812042-start-0-postdays-0-postorder-asc-highlight-kiothumbnail.html

weiterhilft.

----------

## Klaus Meier

 *Josef.95 wrote:*   

> @klaus Meier
> 
> Dann schau mal ob dir https://forums.gentoo.org/viewtopic-t-812042-start-0-postdays-0-postorder-asc-highlight-kiothumbnail.html
> 
> weiterhilft.

 

Hat wohl erst mal geholfen. Ich habe mplayerthumbsconfig auf mplayer umgestellt, jetzt habe ich 30% Speicherverbrauch weniger. Und es wird sogar eine Vorschau von Videodateien angezeigt. Mal sehen, ob das jetzt stabil durchläuft.

----------

## franzf

Der mplayerthumnailer hat bei mir eh noch nie richtig funktioniert.

Hab dann für mich den kffmpegthumbnailer entdeckt, der sofort funktioniert hat, schnell fertig war (auch in nem test-Dir mit richtig vielen Videos).

Ohne groß das System lahm zu legen.

----------

## Klaus Meier

Also, mit dem mplayerthumbsconfig auf mplayer läuft meine Kiste (bis jetzt) wieder so, wie ich mir das vorstelle. Probleme mit den Vorschauen gibt es keine mehr. Ist ja beim Dolphin auf 100MB begrenzt, aber das interessiert wohl nur Phonon. Jetzt funktioiert die Vorschau von allen Dateien. Ich habe eine Ordneransicht auf dem Desktop, das hat vorher immer ewig gedauert, bis die Vorschau da, jetzt innerhalb kürzester Zeit. Aber immer noch zuerst ohne Vorschau.

Performance und Speicherverbrauch sind jetzt voll im grünen Bereich. Hab Firefox, Thunderbird und Kaffeine laufen, 480 MB. Gehört zwar nicht zu KDE, aber die r4 vom Firefox 3.6 scheint nur noch die Hälfte Speicher zu benötigen wie die erste Version.

So eine Einstellung macht aus einer lahmenden Gurke wieder einen geilen Rechner. Und der Bugreport dazu ist schon von Dezember, deshalb hab ich den nicht weiter beachtet.

Wie ich schon sagte, früher habe ich Larry gespielt, jetzt KDE. So nach drei Monaten habe ich es so weit, dass ich damit leben kann. Ich bereue nichts, aber man sollte es schon etwas DAU-Tauglicher machen. Hei, ich klicke wo drauf und es reagiert ohne Verzögerung.....

----------

