[EMAIL PROTECTED] wrote:
Hi Cami
I would be willing to try, though it would require some manpower and
thus has to be planned in advance because more than one team is affected
(we do not administer the SQL server, only Postfix and relevant
processes).
As Nigel has pointed out, changing it
PM
To: policyd-users@lists.sourceforge.net
Cc: cluebringer-devel
Subject: Re: [policyd-users] cleanup performance optimization
I would be willing to try, though it would require some manpower and
thus has to be planned in advance because more than one team is
affected (we do not administer
Dominique Feyer wrote:
We use a setup with an InnoDB on our cluster (10'000 domains, 100'000
accounts). We convert MyISAM to InnoDB without problem. The only one
chage in Policyd is the INSERT DELAY - INSERT
With a policyd database size of 3.4Go on a dual xenon 2.4Ghz 6Go RAM it
] On Behalf Of Roland Rosenfeld
Sent: Tuesday, March 18, 2008 1:12 PM
To: policyd-users@lists.sourceforge.net
Subject: Re: [policyd-users] cleanup performance optimization
On Tue, 18 Mar 2008, Cami Sardinha wrote:
Policyd was test/written for MySQL 4.x. This doesn't mean it shouldn't
behave the same
Roland Rosenfeld wrote:
The triplet table currently contains 5.5M entries and every hour ~250k
entries are expired. Without maintenance this took some minutes now.
So I tried a mysqlcheck -r on the database (which took only two
minutes) and after this cleanup runs much faster.
5.5M entries
On Tue, 18 Mar 2008, Cami Sardinha wrote:
Policyd was test/written for MySQL 4.x. This doesn't mean it
shouldn't behave the same for v5. Unless i'm mistake (or things have
changed between versions), using DELETE QUICK on an
auto-incrementing row is where holes (/fragmentation) occurs. This
Roland Rosenfeld wrote:
On Tue, 18 Mar 2008, Cami Sardinha wrote:
Policyd was test/written for MySQL 4.x. This doesn't mean it
shouldn't behave the same for v5. Unless i'm mistake (or things have
changed between versions), using DELETE QUICK on an
auto-incrementing row is where holes
Hello, Roland:
You didn't mention what your retention times were for the triplets, etc.
You might try cutting the expiration limits down to be no more than
about twice the limit value (so, say, 4 hours and 2 hours). We get over
1 M messages a day and even though my DBs grow to as much as 50 MB
