Somewhere in the documentation there's some note about LMTPD not being
designed to be run in multiple instances at the same time.
In my experience that is not exactly true. It *CAN* create some unusual
but pretty innocent situations, caused by multiple transactions running
at the same time.
You
Andrea,
My postfix lmtp usually has a delay of 2.2 (delays=0.01/0.01/0/2.2) but
when it gets busy they can be higher, but they are never lower then 2.
table rows
dbmail_users 2246
dbmail_header 135684624
dbmail_phymessage 6315243
I don't know if those are big numbers or not. It seems like I have
Let's got in order:
* Slow insert. It's not "normal". You'd better check what you have in
the dbmail_headername tables, clean it up, and probabily disable the
dbmail_headername auto-insert. Can you give a few information on the DB
size as well? I'm not using pgsql but probably checking th
Am 24.06.2012 04:56, schrieb remy:
> I have a fresh installation of dbmail 3.0.2. (mysql 5.1.46; postfix
> 2.7.1 in a openSuSE 11.3 everthing in the same server).
update to MySQl 5.5 if possible
> (some supposedly relevant parameters from supposedly relevant config files:)
they most interesti
On Donnerstag, 23. August 2007 Jesse Norell wrote:
> try inserting the
> value of either message-id or resent-message-id into it and if it's
> already there the insert will fail (of course it could fail for other
> reasons too..). That ought to be much quicker than a 75 second
> SELECT.
No, no,
On Thu, 2007-08-23 at 12:26 +0200, Paul J Stevens wrote:
>
> > I have loads of these in my slow query log and the box is suffering.
> >
> > # Query_time: 75 Lock_time: 0 Rows_sent: 0 Rows_examined: 225432
> > SET timestamp=1187861236;
> > SELECT message_idnr FROM dbmail_messages m JOIN dbmail_
Aleksander Kamenik wrote:
> I have loads of these in my slow query log and the box is suffering.
>
> # Query_time: 75 Lock_time: 0 Rows_sent: 0 Rows_examined: 225432
> SET timestamp=1187861236;
> SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON
> m.physmessage_id=p.id JOI
Jorge Bastos wrote:
Hum, that must be something with your configuration in particular.
I have about 1GB of emails and about 4000 mails now in my INBOX, and
it's fast on a P4 3.2 with HT with only 512MB RAM
do you have "skip-name-resolve" in my.ini?
yes, in my.cf=). and I have 3 vcpu xen machin
Hum, that must be something with your configuration in particular.
I have about 1GB of emails and about 4000 mails now in my INBOX, and it's
fast on a P4 3.2 with HT with only 512MB RAM
do you have "skip-name-resolve" in my.ini?
- Original Message -
From: "Alexander Benaguev" <[EMAIL
Jon Duggan wrote:
Unfortunately, running imapd from inetd doesn't seem to help with this.
That actually *great*. No really! If you can reproduce this in inetd mode, you
can provide me with a backtrace.
Could you:
a) rebuild dbmail with debugging symbols? (CFLAGS=+-g)
b) run the commands ag
> (just double checked before sending the email and this is the error im
> getting )
> ERROR : Connection dropped by imap-server.
> Query: SEARCH CHARSET ISO-8859-1 ALL Subject {13}
ok, so *that* is bug #579
I've a feeling this may be a bug manifesting itself behind another problem.
>
> I'll
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of zamri
Sent: 28 June 2007 02:30
To: DBMail mailinglist
Subject: Re: [Dbmail] slow squirrelmail queries
On 6/28/07, Jon Duggan <[EMAIL PROTECTED]> wrote:
Thanks for the reply Paul
The imapdproxy seemed to help with an imap
Jon Duggan wrote:
(just double checked before sending the email and this is the error im
getting )
ERROR : Connection dropped by imap-server.
Query: SEARCH CHARSET ISO-8859-1 ALL Subject {13}
ok, so *that* is bug #579
I'll try and get some further info regarding the mysql slow query logs.
On 6/28/07, Jon Duggan <[EMAIL PROTECTED]> wrote:
Thanks for the reply Paul
The imapdproxy seemed to help with an imap fetch problem (iirc) we were
having when we first went to 2.2.5. Although that may be a coincidence - i
haven't figured that one out yet
I have tested without it in equation a
to 'other'
Thanks for all your help as always
Jon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Paul J Stevens
Sent: 27 June 2007 21:04
To: DBMail mailinglist
Subject: Re: [Dbmail] slow squirrelmail queries
Jon Duggan wrote:
> Hi Guys
Jon Duggan wrote:
> Hi Guys
>
> Still having an issue with slow imap queries via overlook (its a
> squirrelmail base with changes in gui, we've also tested squirrelmail with
> same results),
>
> We're getting *very* slow queries on some mailboxes below ive provided a
> level 5 trace log
No slow
On Mittwoch, 20. Juni 2007 Paul J Stevens wrote:
> There is no direct relation between headernames and physmessages. So
> no, I don't see how that could be changed easily. If you can whip up
> a query that improves the situation please share it.
I've tried around, but postgres kept insisting on th
Michael Monnerie wrote:
>
> Seems to me the problem is the relation of physmessage -> headervalue ->
> headername
> If that would be physmessage -> headername -> headervalue, there would
> be a dramatic speedup, because the planner could lookup all
> headername='message-id' before having to look
On Dienstag, 19. Juni 2007 Paul J Stevens wrote:
> Maybe because you were doing running the analysis queries on the
> headervalue table at the time?
I thought you might answer this, but forgot to mention in the previous mail
that those lines were before my analysis. :-)
But no, even running it t
Michael Monnerie wrote:
> I've got postgres with slow query logging on, and got some logs today:
>
> Jun 19 11:18:20 db.zmi.at postgres[8035]: [2-1] 2007-06-19 11:18:20 CEST
> DB=dbmail HOST=212.69.162.198(49440) SESSTRT=2007-06-19 10:30:01 CEST LOG:
> Dauer: 14147.986 ms
> Jun 19 11:18:20 db.z
Kell Jemison wrote:
Hi,
We have a basic LAMP setup on RH9. We are using MySQL version 4.2.2-17, PHP
4 and Apache 2.0.40-21 We are using your product to manipulate the email
from a program embedded into PHP Groupware (Anglemail). We can experience
very quick page transitions going through the PHP
Roel Rozendaal - IC&S ([EMAIL PROTECTED]) écrivait:
>
>Could you verify the performance by opening a telnet session to the
>IMAP server and issue some commands (SELECT, FETCH, STORE etc.) ?
I will do that and tell you more later, thanks for your help.
Sam.
Could you verify the performance by opening a telnet session to the
IMAP server and issue some commands (SELECT, FETCH, STORE etc.) ?
Sam Przyswa heeft op maandag, 27 jan 2003 om 11:09 (Europe/Amsterdam)
het volgende geschreven:
Eelco van Beek - IC&S ([EMAIL PROTECTED]) écrivait:
Well, th
Eelco van Beek - IC&S ([EMAIL PROTECTED]) écrivait:
>
>Well, this sounds very weird. How exactly are you testing? How many
>users? How many messages and mailboxes per user?
We have 296 users with a total of 62400 messages and with a PHP Webmail it's too
slow, we have tested direct SQL queries on t
Well, this sounds very weird. How exactly are you testing? How many
users? How many messages and mailboxes per user?
Regards,
Eelco
On zondag, jan 26, 2003, at 21:53 Europe/Amsterdam, Sam Przyswa wrote:
Sam Przyswa ([EMAIL PROTECTED]) écrivait:
Hi,
We have installed DBmail CVS on a machin
Sam Przyswa ([EMAIL PROTECTED]) écrivait:
>
>Hi,
>
>We have installed DBmail CVS on a machine 2 X 1.3Ghz with 1.5Go RAM on MySQL
>and
>it's two time slower than an old P233 with Courier-IMAP. We use a Webmail in
>PHP4
>(PHPgroupWare).
>
>Have you an idea to optimize the IMAP logic or SQL queries
26 matches
Mail list logo
