cyrus-imap-Server - MailDB reorganisieren
Hallo Leute, kann/muß ich die MailDB von meinem cyrus-Server gelegentlich reorganisieren oder komprimieren? Wenn ja, wie muß ich das anstellen? Danke für Eure Hilfe Christoph -- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Christoph Knauer wrote:
Hallo Leute,
kann/muß ich die MailDB von meinem cyrus-Server gelegentlich reorganisieren oder komprimieren? Wenn ja, wie muß ich das anstellen?
Welches Problem möchtest du lösen? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Wenn ich mit KMail meine Mails lesen möchte, ist die Übertragung teilweise sehr langsam ("Denkpausen"), d.h. KMail ist zeitweise nicht wirklich zu benutzen. Da ich einige Mailinglisten aboniert habe (u.a. hier ;) ), ist meine Vermutung, daß es dabei vielleicht vom Server ausgeht, zumal es bei verschiedenen SuSE-Versionen das gleiche ist (Client von 9.3 bis 10.2 getestet, jeweils die aktuellste KDE/KMail-Version von SUSE) auf einem P4-1,4GHz mit 1,5GB Ram Auf dem Server lief erst 9.3 auf einem P1-233 (256MB Ram), jetzt 10.1-x64 auf AMD Duron (1GB Ram). Alle Systeme werden / wurden jeweils aktuell gehalten. Christoph Am Dienstag, 2. Januar 2007 12:43 schrieb Sandy Drobic:
Christoph Knauer wrote:
Hallo Leute,
kann/muß ich die MailDB von meinem cyrus-Server gelegentlich reorganisieren oder komprimieren? Wenn ja, wie muß ich das anstellen?
Welches Problem möchtest du lösen?
Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
-- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Christoph Knauer wrote:
Wenn ich mit KMail meine Mails lesen möchte, ist die Übertragung teilweise sehr langsam ("Denkpausen"), d.h. KMail ist zeitweise nicht wirklich zu benutzen.
Da ich einige Mailinglisten aboniert habe (u.a. hier ;) ), ist meine Vermutung, daß es dabei vielleicht vom Server ausgeht, zumal es bei verschiedenen SuSE-Versionen das gleiche ist (Client von 9.3 bis 10.2 getestet, jeweils die aktuellste KDE/KMail-Version von SUSE) auf einem P4-1,4GHz mit 1,5GB Ram
Auf dem Server lief erst 9.3 auf einem P1-233 (256MB Ram), jetzt 10.1-x64 auf AMD Duron (1GB Ram). Alle Systeme werden / wurden jeweils aktuell gehalten.
Das sagt noch nicht wirklich viel. Ich gehe jetzt mal davon aus, dass dein Server nicht am Swappen ist. Versuchen wir doch erst einmal, das Problem einzugrenzen. Wann genau kommt diese Verzögerung? - Beim Öffnen des Ordners - Beim Öffnen der Mail - Kommt die Verzögerung IMMER oder nur beim ersten Öffnen von Mail/Ordner Hast du schon einmal getestet, ob ein anderer Client dabei keine Probleme hat? Ich würde Mulberry ausprobieren, der liest die Verzeichnisse auf dem Server wirklich RASEND schnell ein. (^-^) Steht vielleicht irgendetwas in /var/log/messages dazu? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Kmail schaut alle 10min nach neuen Nachrichten. Meist geht es "normal" schnell, d.h. in wenigen Augenblicken ist ein Ordner eingelesen. Manchmal ist aber der Activity-Indicator (unten rechts) für mehere Minuten an, und dann ist KMail in dieser Zeit äußerst langsam, bereits beim Bildschirmaufbau, oder beim öffnen eines Ordners, sogar lokal ... Wenn dann irgentwann die Anzeige verschwunden ist, gehts erstmal wieder normal. In /var/log/messages habe ich keinen Hinweis finden können, nur die Festplattenaktivität auf dem Server ist dann meist auch recht hoch ... Ich meine, daß mir dieses Phänomen mit Thundermail noch nicht aufgefallen ist ... möglicherweise ein Zusammenhang vom KMail-Imapdienst und Cyrrus? Das Problem tritt auch nicht immer auf, heute hab ich z.B. noch keinerlei Probleme gehabt. Christoph Am Dienstag, 2. Januar 2007 21:06 schrieb Sandy Drobic:
Das sagt noch nicht wirklich viel. Ich gehe jetzt mal davon aus, dass dein Server nicht am Swappen ist. Versuchen wir doch erst einmal, das Problem einzugrenzen.
Wann genau kommt diese Verzögerung? - Beim Öffnen des Ordners - Beim Öffnen der Mail - Kommt die Verzögerung IMMER oder nur beim ersten Öffnen von Mail/Ordner
Hast du schon einmal getestet, ob ein anderer Client dabei keine Probleme hat? Ich würde Mulberry ausprobieren, der liest die Verzeichnisse auf dem Server wirklich RASEND schnell ein. (^-^)
Steht vielleicht irgendetwas in /var/log/messages dazu?
Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
-- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Christoph Knauer wrote: Hallo Christoph, ich habe deinen Text mal Inline eingefügt, damit es etwas einfacher ist, den Überblick zu behalten.
Am Dienstag, 2. Januar 2007 21:06 schrieb Sandy Drobic:
Das sagt noch nicht wirklich viel. Ich gehe jetzt mal davon aus, dass dein Server nicht am Swappen ist. Versuchen wir doch erst einmal, das Problem einzugrenzen.
Wann genau kommt diese Verzögerung? - Beim Öffnen des Ordners - Beim Öffnen der Mail - Kommt die Verzögerung IMMER oder nur beim ersten Öffnen von Mail/Ordner
Kmail schaut alle 10min nach neuen Nachrichten. Meist geht es "normal" schnell, d.h. in wenigen Augenblicken ist ein Ordner eingelesen. Manchmal ist aber der Activity-Indicator (unten rechts) für mehere Minuten an, und dann ist KMail in dieser Zeit äußerst langsam, bereits beim Bildschirmaufbau, oder beim öffnen eines Ordners, sogar lokal ... Wenn dann irgentwann die Anzeige verschwunden ist, gehts erstmal wieder normal.
Das deutet darauf hin, dass der lokale Cache von KMail manchmal neu aufgebaut werden muss und dann das Programm erst einmal beschäftigt ist.
Hast du schon einmal getestet, ob ein anderer Client dabei keine Probleme hat? Ich würde Mulberry ausprobieren, der liest die Verzeichnisse auf dem Server wirklich RASEND schnell ein. (^-^)
In /var/log/messages habe ich keinen Hinweis finden können, nur die Festplattenaktivität auf dem Server ist dann meist auch recht hoch ...
Das wird vermutlich das Einlesen der Header aller Mails sein, wenn der Client einen Ordner öffnet und der lokale Cache aufgebaut wird.
Ich meine, daß mir dieses Phänomen mit Thundermail noch nicht aufgefallen ist ... möglicherweise ein Zusammenhang vom KMail-Imapdienst und Cyrrus?
Ich benutze Thunderbird (manchmal auch Mulberry), und da habe ich in der Tat keine Probleme, auch mit Ordnern von vielen Tausend Mails. Lege doch mal einen neuen User an auf deinem Client und lasse ihn mit KMail auf deinen Imap-Account zugreifen. Kommt dann auch beim ersten Öffnen der Ordner immer das Sperren auf Server und Client? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, 2. Januar 2007 23:58 schrieb Sandy Drobic:
Das deutet darauf hin, dass der lokale Cache von KMail manchmal neu aufgebaut werden muss und dann das Programm erst einmal beschäftigt ist.
Ich habe heute erstmalig auf der Serverseite ein paar Einträge gefunden ... julia2006:/home/christoph # tail -f /var/log/messages Jan 6 09:57:58 julia2006 imap[4540]: SQUAT failed to open index file Jan 6 09:57:58 julia2006 imap[4540]: SQUAT failed Jan 6 09:57:58 julia2006 imap[4540]: SQUAT failed to open index file Jan 6 09:57:58 julia2006 imap[4540]: SQUAT failed Jan 6 09:57:59 julia2006 imap[4540]: SQUAT failed to open index file Jan 6 09:57:59 julia2006 imap[4540]: SQUAT failed Jan 6 09:58:30 julia2006 imap[4540]: SQUAT failed to open index file Jan 6 09:58:30 julia2006 imap[4540]: SQUAT failed Jan 6 10:00:01 julia2006 su: (to root) christoph on /dev/pts/0 Jan 6 10:00:02 julia2006 imap[4540]: open: user christoph opened INBOX Danach geht wieder (erstmal) alles ganz normal.
Lege doch mal einen neuen User an auf deinem Client und lasse ihn mit KMail auf deinen Imap-Account zugreifen. Kommt dann auch beim ersten Öffnen der Ordner immer das Sperren auf Server und Client?
werde ich bei Gelegenheit auch mal versuchen ... Christoph
Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
-- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Christoph Knauer wrote:
Am Dienstag, 2. Januar 2007 23:58 schrieb Sandy Drobic:
Das deutet darauf hin, dass der lokale Cache von KMail manchmal neu aufgebaut werden muss und dann das Programm erst einmal beschäftigt ist.
Ich habe heute erstmalig auf der Serverseite ein paar Einträge gefunden ...
julia2006:/home/christoph # tail -f /var/log/messages Jan 6 09:57:58 julia2006 imap[4540]: SQUAT failed to open index file Jan 6 09:57:58 julia2006 imap[4540]: SQUAT failed Jan 6 09:57:58 julia2006 imap[4540]: SQUAT failed to open index file Jan 6 09:57:58 julia2006 imap[4540]: SQUAT failed Jan 6 09:57:59 julia2006 imap[4540]: SQUAT failed to open index file Jan 6 09:57:59 julia2006 imap[4540]: SQUAT failed Jan 6 09:58:30 julia2006 imap[4540]: SQUAT failed to open index file Jan 6 09:58:30 julia2006 imap[4540]: SQUAT failed Jan 6 10:00:01 julia2006 su: (to root) christoph on /dev/pts/0 Jan 6 10:00:02 julia2006 imap[4540]: open: user christoph opened INBOX
Danach geht wieder (erstmal) alles ganz normal.
SQUAT ist der Such-Index, den Cyrus anlegt. Hatte es mal einen Index gegeben, der nicht mehr aktualisiert wird? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Samstag, 6. Januar 2007 11:20 schrieb Sandy Drobic:
Christoph Knauer wrote: SQUAT ist der Such-Index, den Cyrus anlegt. Hatte es mal einen Index gegeben, der nicht mehr aktualisiert wird?
Was für einen Suchindex bitte? Dieser Fehler scheint ja auch nur von Zeit zu Zeit aufzutreten. Ich gehe meist, wenn länger nicht am Rechner gewesen, zuerst in meine persönlichen Mails im Posteingang. Ein Großteil der Mails (z.B. diese Liste) wird bereits im Vorfeld per Sieve-Script in div. Unterordner verschoben. Christoph
Sandy
-- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
-- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Christoph Knauer wrote:
Am Samstag, 6. Januar 2007 11:20 schrieb Sandy Drobic:
Christoph Knauer wrote: SQUAT ist der Such-Index, den Cyrus anlegt. Hatte es mal einen Index gegeben, der nicht mehr aktualisiert wird?
Was für einen Suchindex bitte? Dieser Fehler scheint ja auch nur von Zeit zu Zeit aufzutreten. Ich gehe meist, wenn länger nicht am Rechner gewesen, zuerst in meine persönlichen Mails im Posteingang. Ein Großteil der Mails (z.B. diese Liste) wird bereits im Vorfeld per Sieve-Script in div. Unterordner verschoben.
Christoph
Sandy
-- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Auszug aus meiner /etc/cyrus.conf: EVENTS { [...] # calling squatter to index all changed mailboxes daily squatter cmd="/usr/lib/cyrus/bin/squatter -r -s user" at=0430 [...] } squatter legt einen Volltextindex der Mailboxen an. Wenn du mal versucht hast, ein paar Jahre suse-linux nach einer Kombination von Begriffen zu durchsuchen, wirst du die Geschwindigkeit zu schätzen wissen. (^-^) Auf meiner alten Primergy bekomme ich innerhalb von einer Sekunde die Ergebnisse, selbst bei Ordnern mit 100.000 Mails. Ohne squatter brauche ich dafür einige Minuten für jeden Suchlauf. Weiteres unter "man squatter". Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sandy, wo liegt denn diese Index-Datei? Ich könnte mir vorstellen, daß da evtl. ein Rechte-Problem vorliegt - mein Sieve wollte aus einem solchen Grund auch erst nicht laufen bzw. sich über KMail fernsteuern lassen. Christoph Am Samstag, 6. Januar 2007 22:07 schrieb Sandy Drobic:
Christoph Knauer wrote:
Am Samstag, 6. Januar 2007 11:20 schrieb Sandy Drobic:
Christoph Knauer wrote: SQUAT ist der Such-Index, den Cyrus anlegt. Hatte es mal einen Index gegeben, der nicht mehr aktualisiert wird?
Was für einen Suchindex bitte? Dieser Fehler scheint ja auch nur von Zeit zu Zeit aufzutreten. Ich gehe meist, wenn länger nicht am Rechner gewesen, zuerst in meine persönlichen Mails im Posteingang. Ein Großteil der Mails (z.B. diese Liste) wird bereits im Vorfeld per Sieve-Script in div. Unterordner verschoben.
Christoph
Sandy
-- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Auszug aus meiner /etc/cyrus.conf:
EVENTS {
[...]
# calling squatter to index all changed mailboxes daily squatter cmd="/usr/lib/cyrus/bin/squatter -r -s user" at=0430
[...] }
squatter legt einen Volltextindex der Mailboxen an. Wenn du mal versucht hast, ein paar Jahre suse-linux nach einer Kombination von Begriffen zu durchsuchen, wirst du die Geschwindigkeit zu schätzen wissen. (^-^)
Auf meiner alten Primergy bekomme ich innerhalb von einer Sekunde die Ergebnisse, selbst bei Ordnern mit 100.000 Mails. Ohne squatter brauche ich dafür einige Minuten für jeden Suchlauf.
Weiteres unter "man squatter".
Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
-- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Christoph Knauer wrote:
Hallo Sandy,
wo liegt denn diese Index-Datei? Ich könnte mir vorstellen, daß da evtl. ein Rechte-Problem vorliegt - mein Sieve wollte aus einem solchen Grund auch erst nicht laufen bzw. sich über KMail fernsteuern lassen.
Wenn du nicht manuell gefummelt hast, sollten die Rechte eigentlich auf cyrus:mail lauten. Der User cyrus führt squatter aus. In jedem Ordner jeder Mailbox wird so ein Index angelegt, wenn du squatter den gesamten Pfad freigibst. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sandy, ich habe da nichts dran gemacht, Ich habe damals bei der Installation einzig an den Rechten für Sieve etwas gestrickt, und seither kann ich auch die Sieve-Regeln wieder mit KMail bearbeiten, und sie werden akzeptiert. Im Verzeichnis /var/spool/imap ist, soweit ich das gesehen habe, alles auf cyrus:mail. Im übrigen habe ich mir die cyrus.conf noch einmal angeschaut, bei mir steht kein Eintrag für den squatter, hier der Auszug: EVENTS { # this is required checkpoint cmd="ctl_cyrusdb -c" period=30 # this is only necessary if using duplicate delivery suppression delprune cmd="cyr_expire -E 3" at=0400 # this is only necessary if caching TLS sessions tlsprune cmd="tls_prune" at=0400 # Uncomment the next entry, if you want to automatically remove # old messages of EVERY user. # This example calls ipurge every 60 minutes and ipurge will delete # ALL messages older then 30 days. # enter 'man 8 ipurge' for more details # cleanup cmd="ipurge -d 30 -f" period=60 } Das ist aus der von Yast bei der Installation angelegten original cyrus.conf, da habe ich nichts dran geändert. Liegt da vielleicht der Hund begraben? Christoph Am Montag, 8. Januar 2007 10:46 schrieb Sandy Drobic:
Wenn du nicht manuell gefummelt hast, sollten die Rechte eigentlich auf cyrus:mail lauten. Der User cyrus führt squatter aus. In jedem Ordner jeder Mailbox wird so ein Index angelegt, wenn du squatter den gesamten Pfad freigibst.
-- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Christoph Knauer wrote:
Hallo Sandy,
ich habe da nichts dran gemacht, Ich habe damals bei der Installation einzig an den Rechten für Sieve etwas gestrickt, und seither kann ich auch die Sieve-Regeln wieder mit KMail bearbeiten, und sie werden akzeptiert.
Im Verzeichnis /var/spool/imap ist, soweit ich das gesehen habe, alles auf cyrus:mail.
Im übrigen habe ich mir die cyrus.conf noch einmal angeschaut, bei mir steht kein Eintrag für den squatter, hier der Auszug:
EVENTS { # this is required checkpoint cmd="ctl_cyrusdb -c" period=30
# this is only necessary if using duplicate delivery suppression delprune cmd="cyr_expire -E 3" at=0400
# this is only necessary if caching TLS sessions tlsprune cmd="tls_prune" at=0400
# Uncomment the next entry, if you want to automatically remove # old messages of EVERY user. # This example calls ipurge every 60 minutes and ipurge will delete # ALL messages older then 30 days. # enter 'man 8 ipurge' for more details
# cleanup cmd="ipurge -d 30 -f" period=60 }
Das ist aus der von Yast bei der Installation angelegten original cyrus.conf, da habe ich nichts dran geändert. Liegt da vielleicht der Hund begraben?
Nein, wenn squatter noch nie lief, sollte das keinen Fehler verursachen. Teilweise ist es auch so, dass der Loglevel Meldungen anzeigt, die eigentlich keine Fehler sind und nur Info-Character haben. Aber dann sollte auch der Client nicht so ausgebremst werden. squatter läuft nicht automatisch, man muss ihn manuell einfügen. Zudem sollte man beachten, dass der Volltext-Index eine Menge Platz frisst, squatter ist nicht gerade sparsam! Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Sandy, ich habe mal versucht, diesen Eintrag auch bei mir entsprechend einzupflegen. Nach einem Neustart kam ich dann gar nicht mehr an meinen imap-Server, und in der /var/log/messages standen folgende Meldungen: Jan 9 08:23:51 julia2006 sshd[10138]: Accepted keyboard-interactive/pam for root from 192.168.1.2 port 21109 ssh2 Jan 9 08:25:17 julia2006 master[2677]: SLPderegister [service:imap://julia2006.:143] Jan 9 08:25:17 julia2006 master[2677]: SLPderegister [service:sieve://julia2006.:2000] Jan 9 08:25:17 julia2006 master[2677]: exiting on SIGTERM/SIGINT Jan 9 08:25:17 julia2006 master[10213]: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted Jan 9 08:25:17 julia2006 master[10213]: retrying with 8192 (current max) Jan 9 08:25:18 julia2006 master[10213]: process started Jan 9 08:25:18 julia2006 master[10214]: about to exec /usr/lib/cyrus/bin/ctl_cyrusdb Jan 9 08:25:18 julia2006 ctl_cyrusdb[10214]: recovering cyrus databases Jan 9 08:25:18 julia2006 ctl_cyrusdb[10214]: skiplist: recovered /var/lib/imap/mailboxes.db (93 records, 11508 bytes) in 0 seconds Jan 9 08:25:18 julia2006 ctl_cyrusdb[10214]: skiplist: recovered /var/lib/imap/annotations.db (0 records, 144 bytes) in 0 seconds Jan 9 08:25:18 julia2006 ctl_cyrusdb[10214]: done recovering cyrus databases Jan 9 08:25:18 julia2006 master[10215]: about to exec /usr/lib/cyrus/bin/idled Jan 9 08:25:18 julia2006 kernel: master[10213]: segfault at 0000000000000000 rip 00002b50bb3c36b0 rsp 00007fffeff26f08 error 4 Gruß, Christoph Am Samstag, 6. Januar 2007 22:07 schrieb Sandy Drobic:
Auszug aus meiner /etc/cyrus.conf:
EVENTS {
[...]
# calling squatter to index all changed mailboxes daily squatter cmd="/usr/lib/cyrus/bin/squatter -r -s user" at=0430
[...] }
squatter legt einen Volltextindex der Mailboxen an. Wenn du mal versucht hast, ein paar Jahre suse-linux nach einer Kombination von Begriffen zu durchsuchen, wirst du die Geschwindigkeit zu schätzen wissen. (^-^)
Auf meiner alten Primergy bekomme ich innerhalb von einer Sekunde die Ergebnisse, selbst bei Ordnern mit 100.000 Mails. Ohne squatter brauche ich dafür einige Minuten für jeden Suchlauf.
Weiteres unter "man squatter".
Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
-- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Christoph Knauer wrote:
Hi Sandy,
ich habe mal versucht, diesen Eintrag auch bei mir entsprechend einzupflegen. Nach einem Neustart kam ich dann gar nicht mehr an meinen imap-Server, und in der /var/log/messages standen folgende Meldungen:
Jan 9 08:23:51 julia2006 sshd[10138]: Accepted keyboard-interactive/pam for root from 192.168.1.2 port 21109 ssh2 Jan 9 08:25:17 julia2006 master[2677]: SLPderegister [service:imap://julia2006.:143] Jan 9 08:25:17 julia2006 master[2677]: SLPderegister [service:sieve://julia2006.:2000] Jan 9 08:25:17 julia2006 master[2677]: exiting on SIGTERM/SIGINT Jan 9 08:25:17 julia2006 master[10213]: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted Jan 9 08:25:17 julia2006 master[10213]: retrying with 8192 (current max) Jan 9 08:25:18 julia2006 master[10213]: process started Jan 9 08:25:18 julia2006 master[10214]: about to exec /usr/lib/cyrus/bin/ctl_cyrusdb Jan 9 08:25:18 julia2006 ctl_cyrusdb[10214]: recovering cyrus databases Jan 9 08:25:18 julia2006 ctl_cyrusdb[10214]: skiplist: recovered /var/lib/imap/mailboxes.db (93 records, 11508 bytes) in 0 seconds Jan 9 08:25:18 julia2006 ctl_cyrusdb[10214]: skiplist: recovered /var/lib/imap/annotations.db (0 records, 144 bytes) in 0 seconds Jan 9 08:25:18 julia2006 ctl_cyrusdb[10214]: done recovering cyrus databases Jan 9 08:25:18 julia2006 master[10215]: about to exec /usr/lib/cyrus/bin/idled
Bis hierhin völlig normal, auch die Meldung mit dem setrlimit.
Jan 9 08:25:18 julia2006 kernel: master[10213]: segfault at 0000000000000000 rip 00002b50bb3c36b0 rsp 00007fffeff26f08 error 4
Aber das ist ein kleiner Hammer. Ich teste mal, ob das bei meiner Suse 10.2 auch passiert. Was passiert bei dir, wenn du squatter manuell aufrufst als User cyrus? su - cyrus /usr/lib/cyrus/bin/squatter -r -s -v user Liegen denn die Maildaten im Oberverzeichnis user bei dir? Liegt es wirklich an dem neuen Eintrag oder gibt es ein unsichtbares Steuerzeichen/Zeilenende, was Cyrus abwürgt? Bei mir läuft er völlig normal durch. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, 9. Januar 2007 18:00 schrieb Sandy Drobic:
Aber das ist ein kleiner Hammer. Ich teste mal, ob das bei meiner Suse 10.2 auch passiert. Was passiert bei dir, wenn du squatter manuell aufrufst als User cyrus?
Da ist er bei mir sauber durchgelaufen - 5213 Mails in 37s kommt als Ergebnis
su - cyrus /usr/lib/cyrus/bin/squatter -r -s -v user
Liegen denn die Maildaten im Oberverzeichnis user bei dir?
Liegt alles in user.christoph oder deren Unterordnern
Liegt es wirklich an dem neuen Eintrag oder gibt es ein unsichtbares Steuerzeichen/Zeilenende, was Cyrus abwürgt?
Bei mir läuft er völlig normal durch.
Werde den Eintrag nochmal mit Kate vornehmen - da sieht man wenigstens, wenn da Sonderzeichen auftauchen - aber erst morgen ... Obgleich ich diesen Eintrag aus Deiner Mail via Paste'n'copy in den mc-Editor übernommen habe, nur eine weitere #-Zeile dazu, um als Testeintrag zu kennzeichnen ... Christoph -- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Am Dienstag, 9. Januar 2007 21:27 schrieb Christoph Knauer:
Liegt es wirklich an dem neuen Eintrag oder gibt es ein unsichtbares Steuerzeichen/Zeilenende, was Cyrus abwürgt?
Bei mir läuft er völlig normal durch.
Werde den Eintrag nochmal mit Kate vornehmen - da sieht man wenigstens, wenn da Sonderzeichen auftauchen - aber erst morgen ... Obgleich ich diesen Eintrag aus Deiner Mail via Paste'n'copy in den mc-Editor übernommen habe, nur eine weitere #-Zeile dazu, um als Testeintrag zu kennzeichnen ...
Christoph Habe es jetzt dann doch noch schnell probiert, und jetzt scheit es zu tun. Bis auf die erwartete Fehlermeldung, daß das Imap-Protokoll unerwartet beendet wurde, kann ich trotzdem weiter auf meinen Server zugreifen. Hatte sich dann wohl tatsächlich ein "valscher vehler" eingeschlichen :D
Schauen wir mal, ob sich das Verhalten von KMail damit dann auch bessert ... Christoph -- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Hallo Sandy, zumindest teilweise ist es offenbar besser geworden, KMail legt nicht mehr ganz so lange "Denkpausen" ein. Danke für die Unterstüzung Christoph
Habe es jetzt dann doch noch schnell probiert, und jetzt scheit es zu tun. Bis auf die erwartete Fehlermeldung, daß das Imap-Protokoll unerwartet beendet wurde, kann ich trotzdem weiter auf meinen Server zugreifen. Hatte sich dann wohl tatsächlich ein "valscher vehler" eingeschlichen :D
Schauen wir mal, ob sich das Verhalten von KMail damit dann auch bessert ...
Christoph
-- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Schade, das war es leider doch nicht. Ein weiteres Phänomen, was dann auftritt, wenn KMail so langsam ist, wenn ich ein Mail lösche, dauert es "ewig", bis das Mail auch tatsächlich aus der Übersicht verschwindet (wird verschoben aus dem Imap-Folder in den lokalen Mülleimer) Nachrichten habe ich keine gefunden in /var/log/messages, weder auf dem Server noch auf dem Client. Gruß, Christoph Am Mittwoch, 10. Januar 2007 13:27 schrieb Christoph Knauer:
Hallo Sandy,
zumindest teilweise ist es offenbar besser geworden, KMail legt nicht mehr ganz so lange "Denkpausen" ein.
Danke für die Unterstüzung
Christoph
-- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261
Christoph Knauer wrote:
Schade, das war es leider doch nicht.
Ein weiteres Phänomen, was dann auftritt, wenn KMail so langsam ist, wenn ich ein Mail lösche, dauert es "ewig", bis das Mail auch tatsächlich aus der Übersicht verschwindet (wird verschoben aus dem Imap-Folder in den lokalen Mülleimer)
Nachrichten habe ich keine gefunden in /var/log/messages, weder auf dem Server noch auf dem Client.
Dann würde ich langsam anfangen, mich mit dem Paket iostat/sar zu befassen. sar bzw. iostat kann einige wichtige Kenndaten des Systems alle paar Minuten erfassen und so helfen, Ursachen für quälend langsame Server zu finden. Mir ist es z.B. passiert in Suse 10.2, dass Imap plötzlich sehr langsam wurde, weil zmd lief. Du musst herausfinden, welche Resourcen deines Server gefressen werden und welcher Prozess sie in Anspruch nimmt. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sandy, ich bin etwas anders zu einer Lösung gekommen: ich habe die kmail-Configdateien umbenannt, und nach Start von KMail mußte ich zwar alles wieder anlegen, aber es scheint jetzt so zu laufen, wie ich mir das vorstelle. Einzig beim Löschen (move in lokalen trash) brauchts einen Moment. Danke. Am Freitag, 12. Januar 2007 23:02:39 schrieb Sandy Drobic:
Christoph Knauer wrote:
Schade, das war es leider doch nicht.
Ein weiteres Phänomen, was dann auftritt, wenn KMail so langsam ist, wenn ich ein Mail lösche, dauert es "ewig", bis das Mail auch tatsächlich aus der Übersicht verschwindet (wird verschoben aus dem Imap-Folder in den lokalen Mülleimer)
Nachrichten habe ich keine gefunden in /var/log/messages, weder auf dem Server noch auf dem Client.
Dann würde ich langsam anfangen, mich mit dem Paket iostat/sar zu befassen. sar bzw. iostat kann einige wichtige Kenndaten des Systems alle paar Minuten erfassen und so helfen, Ursachen für quälend langsame Server zu finden. Mir ist es z.B. passiert in Suse 10.2, dass Imap plötzlich sehr langsam wurde, weil zmd lief.
Du musst herausfinden, welche Resourcen deines Server gefressen werden und welcher Prozess sie in Anspruch nimmt.
Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
-- GPG-Fingerprint: 171A 6F66 52E5 A6CE D664 2427 832F E711 7442 8261 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (3)
-
Christoph Knauer -
cool.chris65＠web.de
-
Sandy Drobic