Wenn es denn jetzt für den Moment zu funktionieren scheint, erlaube ein paar Rückfragen.
Das Verhalten mit der periodisch ungesunden Last ist seit Jahren bekannt und gut dokumentiert.
Ich kenne dieses Problem so nicht. Ich glaube auch nicht, dass dies ein zu erwartendes Verhalten ist. Könntest du bitte einen Link zur Verfügung stellen, unter dem das gut dokumentiert ist? Gibt es einen Bug?
Woher stammt die Information, dass das Heraufsetzen dieses Idle-Parameters das Problem löst?
Auf einige Punkte der Helfer bist du leider nicht eingegangen. Darunter war ein sehr wichtiger:
[...] hier wird dazu eigentlich stets nur geraten, um herauszufinden, ob ein AddOn o.ä. stört, und nicht, um dauerhaft so zu arbeiten. Dies hilft häufig, die Ursache von Probleme einzugrenzen, ist aber weniger als "work around" gedacht.
Wenn das Problem im Fehlerbehebungsmodus nicht auftritt, dann ist der Verursacher sehr wahrscheinlich eine Erweiterung etc. . Dann wäre es ratsam, nicht an irgendwelchen Parametern herumzuschrauben, sondern den wahren Verursacher zu finden.
Wenn das Problem im Fehlerbehebungsmodus nicht auftritt, dann ist der Verursacher sehr wahrscheinlich eine Erweiterung etc.
Naja, Thunderbird deaktiviert auch ein paar eigene Dinge im Fehlerbehebungsmodus, die für den Anwender (und auch für mich) undurchsichtig sind.
Das Problem bezüglich mail.db.idle_limit wurde ursprünglich hier beschrieben: https://bugzilla.mozilla.org/show_bug.cgi?id=794401
Das Problem kam wohl mit Thunderbird irgendwo bei Version 15-17 auf und wurde theoretisch für die meisten (aber nicht alle) Anwender mit Thunderbird 38 behoben.
Das Problem besteht wohl (nur?) bei Anwendern mit über 30 (?) Ordnern. Vermutlich spielt die Größe bzw. Anzahl der Mails pro Ordner auch eine Rolle. Und dann spielt sicherlich die Performance des PCs und des verwendeten Datenträgers auch eine Rolle. Es könnte beispielsweise sein, dass Anwender mit einer SSD davon viel weniger bemerken. Auswirkungen hat das Problem beispielsweise für Nutzer von Notebooks, wenn deren Akku leer gesaugt wird - ganz unabhängig davon, ob man beim Arbeiten selbst Wartezeiten bemerkt.
Es gab auch diesen Bug mit Anleitung bezüglich Debugging: https://bugzilla.mozilla.org/show_bug.cgi?id=1388696
Ich denke, der relevante offene Bug dazu ist jetzt dieser: https://bugzilla.mozilla.org/show_bug.cgi?id=1305207
As of version 38, most issues involving mail.db.idle_limit should be resolved. (This blog was published Feb 2013, roughly in the time period of Thunderbird 17.) However, as recent comments indicate, there may still be unresolved issues. We, the Thunderbird community, want to fix them.
If you did the workaround of setting mail.db.idle_limit, please reset mail.db.idle_limit to it’s default value; see if you can reproduce the problem with default settings.
Anyone having a performance issue – please file a bug report with the details at https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird Thanks for helping us improve Thunderbird.
A very breif history:
* https://bugzilla.mozilla.org/show_bug.cgi?id=723248 circa Sept 2012 delivered a method of closing “idle folders” (message databases) using mail.db.idle_limit and mail.db.max_open
* https://bugzilla.mozilla.org/show_bug.cgi?id=793455 quickly fixed a resulting bad performance issue in version 16
* Somewhat later, a remaining issue was found and fixed roughly June 2015 in version 38 https://bugzilla.mozilla.org/show_bug.cgi?id=1135310
Standard für mail.db.idle_limit ist in Thunderbird 91 derzeit 300000 Millisekunden (also 1000 * 60 * 5), was 5 Minuten entspricht.
Naja, Thunderbird deaktiviert auch ein paar eigene Dinge im Fehlerbehebungsmodus, die für den Anwender (und auch für mich) undurchsichtig sind.
Ich weiß. Deshalb mein Gebrauch von "wahrscheinlich" und "etc." 
Das Problem bezüglich mail.db.idle_limit wurde ursprünglich hier beschrieben: https://bugzilla.mozilla.org/show_bug.cgi?id=794401
Danke dafür. In den Bugs werden leider verschiedene Fehler vermischt, auch wenn schon darum gebeten wurde, ggf. neue Bugs zu eröffnen. Kommt mir irgendwie bekannt vor.
Interessant ist, dass dort berichtet wird, der safe-mode habe das Problem verschlimmert. kklepper hat die Frage danach leider unbeantwortet gelassen. Seine Formulierung gleich in #1 lässt sich aber so interpretieren, als hätte der safe-mode beim ihm geholfen.
Ich hatte 2 Links beigefügt, die aber seltsamerweise nicht mehr zu finden sind:
Ich verwalte 20 mail-Adressen, davon 6 POP, der Rest IMAP. Teilweise habe ich alte Mails archiviert. Sollte ich komprimieren? Eigenschaften zeigt jeweils Größen im 2 stelligen Bereich. Das Datenverzeichnis hat 4,7 GB, wenn ich das richtig verstehe, müssen das die POP-Daten sein.
Obwohl ich mail.db.idle_limit sehr hoch gesetzt habe, scheint mir der Prozess deutlich häufiger anzuspringen. Auf dem Notebook sind die Probleme gravierender, es ist mir nicht gelungen, den Parameter zu verändern. Demnächst werde ich alles neu spiegeln, denn ich werde nochmal operiert und muss dann wieder mit dem Noatebook arbeiten..
Was ist denn nun mit dem safe-mode? Hilft der bei dir? Oder macht er es auch schlimmer?
Seit wann bedeutet "kommt für mich nicht infrage" dasselbe wie "bringt keine Besserung"?
Dein Satz klang für mich eher nach "Das habe ich gar nicht erst ausprobiert" oder "Das hilft zwar, kommt aber nicht infrage". Auf den Hinweis von Drachen, dass das nur der Fehleranalyse dient, bist du gar nicht erst eingegangen. Und auch jetzt keine eindeutige Antwort. Sorry.
Was ist das denn wieder für eine Antwort? Offen gestanden, mir wird das zu dumm hier. Ich habe dir einen Hinweis auf einen Hinweis von Drachen gegeben, den du seit zwei Wochen ignorierst. Wie oft muss man dich denn fragen, um von dir mal eine klare und eindeutige Antwort zu bekommen? Es ist mir ein Rätsel, warum du um diese Frage so einen Eiertanz machst. Oder sind wir hier bei Comedy dot Central?
Thunderbird Menü Hilfe → Fehlerbehebungsmodus
Dieser wurde früher im Programm als "Abgesicherter Modus" bzw. im Englischen dann halt als "Safe-Mode" bezeichnet. Wenn man das Programm per Verknüpfung startet, kann man an den Pfad zur thunderbird.exe hinten noch -safe-mode dran hängen, um das Programm bewusst so zu starten.
Und zur weiteren Info:
.. auf das Notebook (4GB RAM) übertragen, [..]. Im Prinzip funktioniert Thunderbird nun dort auch gut, kein Vergleich zum Zustand, als ich den Thread startete. Allerdings habe ich den Eindruck, dass diese Spitzen häufiger auftreten.
Falls das nicht just ein neues normal-performantes Notebook ist, was bei der mageren Ausstattung mit RAM eher unwahrscheinlich ist, dann wird es daran liegen: altes Teil, schlappe CPU und vor allem *nur* 4 GB RAM für vermutlich Windows 10, möglicherweise noch nicht mal eine SSD (oder eine grausam langsame SSD) - dann sind diese Effekte ziemlich erklärlich.
Gruß
Sehvornix
Das glaube ich ehrlich gesagt nicht wirklich, denn der Thunderbird läuft selbst auf einem Raspi ohne solche Zicken. Besonders anspruchsvoll ist er nicht. Aber das ließe sich durch einen Blick in den Taskmanager leicht klären.
Hallo Susi to visit ,
tatsächlich läuft das auf einem Raspi rund (steht hier rechts neben dem Monitor 
), aber das kann man nicht wirklich miteinander vergleichen. Das habe ich aus eigener Anschauung geschrieben, da ich in den letzten Jahren diverse bis zu 12 Jahre alte Notebooks mit einer SSD aufgerüstet habe und immer wieder das gleiche Muster dabei konstatieren muss: Windows 10 und 4 GB - määh, Windows 10 und 8 GB - löpt.
Aber wir wissen beide nicht, was genau kklepper für ein Notebook hat. Es ist eine Möglichkeit, die solches Hakeln erklären könnte.
Gruß
Sehvornix
