Akonadi MySQL backend: tuning for larger accounts or switching to MariaDB with a different storage engine?

[Martin Steigerwald]

Hi!

I reported

Bug 332626 - MySQL tuning: adaption of MySQL tuning options for larger
accounts
https://bugs.kde.org/show_bug.cgi?id=332626


But its somewhat arguable, I know.

I think I saw quite an improvement with raising the default low innodb buffer
pool size of Akonadi of 80 MiB, which is even below the MySQL default of 128
MiB, to 256 MiB helped with a 11 GiB large POP3 account, especially when
synchronizing linux-kernel-ml folder with about 223000 unread mails. And also
on retrieving and filtering new mails there, which can make KMail quite
unresponsive on a quite powerful machine (Sandybridge, 8 GB RAM, dual SSD
BTRFS RAID 1). I will do some testing, yet it is difficult to know for sure.
mysqltuner.pl script gave some clear recommendations tough, which are to high
for a desktop machine tough, I think (>1 GiB of innodb buffer pool size). It
seems it recommends adjusting to actual data size in database, which would
only be suitable if all of the data is accessed often.

What is the amount data Akonadi accesses frequently? Are there any experiences
with that? I bet it depends highly on how the user uses it and the amount of
mails in a single folder to be synchronized.


What do you think?

Do you have any plans to switch to MariaDB and probably investigating storage
engines which may be more suitable for tuning to desktop loads? InnoDB is
difficult as innodb_buffer_pool_size needs to take free memory into account which
can change quite rapidly on desktops or anything else than a dedicated
database server. A engine which uses Linux pagecache for most of its caching
would be interesting I think.


Just wanted to raise this topic.

Ciao,
Martin
--
Martin Steigerwald
Consultant / Trainer

teamix GmbH
Südwestpark 43
90449 Nürnberg

fon: [phone]
fax: [phone]
mail: ***@teamix.de
web: http://www.teamix.de
blog: http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320
Geschäftsführer: Oliver Kügow, Richard Müller

** Frühjahrswissenstage bei teamix - 25.03.2014 | Frankfurt/Mainz 26.03.2014 | München 27.03.2014 ** http://www.teamix.de/wissenstag

_______________________________________________
KDE PIM mailing list kde-***@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
K

[Daniel Vrátil]

Post by Martin Steigerwald
Hi!
I reported
Bug 332626 - MySQL tuning: adaption of MySQL tuning options for larger
accounts
https://bugs.kde.org/show_bug.cgi?id=332626
But its somewhat arguable, I know.

Hi,

I actually talked about optimizing mysql.conf with MariaDB people on FOSDEM in
February.

Post by Martin Steigerwald
I think I saw quite an improvement with raising the default low innodb
buffer pool size of Akonadi of 80 MiB, which is even below the MySQL
default of 128 MiB, to 256 MiB helped with a 11 GiB large POP3 account,
especially when synchronizing linux-kernel-ml folder with about 223000
unread mails. And also on retrieving and filtering new mails there, which
can make KMail quite unresponsive on a quite powerful machine (Sandybridge,
8 GB RAM, dual SSD BTRFS RAID 1). I will do some testing, yet it is
difficult to know for sure. mysqltuner.pl script gave some clear
recommendations tough, which are to high for a desktop machine tough, I
think (>1 GiB of innodb buffer pool size). It seems it recommends adjusting
to actual data size in database, which would only be suitable if all of the
data is accessed often.

...

The problem with innodb_buffer_pool_size is, that it directly impacts the
amount of RAM the mysqld process takes, which makes it difficult to find a
good compromise between what LKML subscribers need and what users with couple
of calendars and an adressbook need.

Post by Martin Steigerwald
What is the amount data Akonadi accesses frequently? Are there any
experiences with that? I bet it depends highly on how the user uses it and
the amount of mails in a single folder to be synchronized.

This is difficult to say and I don't think anyone ever tried to benchmark or
measure it. Indeed it does depend on how you use Akonadi, an

When you open a folder in KMail, we run

SELECT * FROM PartTable WHERE parentCollection = XY AND partType =
"PLD:ENVELOPE"

which will return all envelopes in the collection (that's subject, date, from,
to, cc, bcc, ...)

akonadi=# SELECT MIN(datasize), MAX(datasize), AVG(datasize) FROM PartTable
WHERE partTypeId = 3;
min | max | avg
-----+-------+----------------------
45 | 23354 | 487.8883434774372617
(1 row)

akonadi=# SELECT datasize AS median FROM PartTable WHERE partTypeId =3 ORDER
BY datasize DESC OFFSET (SELECT (COUNT(*) + 1) / 2 FROM PartTable WHERE
partTypeId = 3) LIMIT 1;
median
--------
451

(partTypeId = 3 == SELECT id FROM PartTypeTable WHERE ns = 'PLD' AND
name='ENVELOPE')

Which makes roughly 6.5MB of data in a collection of 15 000 items. I don't
think we have any application (except for the indexer) that would request the
full payload of all items in a collection of such size. I know KAddressbook
and KOrganizer do that, but the collections there are much smaller, and so are
the actual payloads.

Post by Martin Steigerwald
What do you think?

I think we can try to play with the values a bit, having some kind of
benchmark or test tool would be nice :-)

Post by Martin Steigerwald
Do you have any plans to switch to MariaDB and probably investigating
storage engines which may be more suitable for tuning to desktop loads?

MariaDB is a drop-in replacement for MySQL, so it's supported by default (I've
been using MariaDB instead of MySQL for over year before I switched to PSQL)

AFAIK the only engine that we can really use is XtraDB, which is just an
enhanced fork of InnoDb.

Post by Martin Steigerwald
InnoDB is difficult as innodb_buffer_pool_size needs to take free memory
into account which can change quite rapidly on desktops or anything else
than a dedicated database server. A engine which uses Linux pagecache for
most of its caching would be interesting I think.

Maybe we could have some kind of "initial setup" tool that would check
available memory and would update innodb_buffer_pool_size depending on that
(taking in account some max limit, min limit, max percentage, ...)


Cheers,
Dan

Post by Martin Steigerwald
Just wanted to raise this topic.
Ciao,
Martin

[GEO]

Post by Daniel Vrátil
MariaDB is a drop-in replacement for MySQL, so it's supported by default
(I've been using MariaDB instead of MySQL for over year before I switched
to PSQL)

Just interested: You use the akonadi postgresql backend as your default one?
_______________________________________________
KDE PIM mailing list kde-***@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Daniel Vrátil]

Post by GEO

Post by Daniel Vrátil
MariaDB is a drop-in replacement for MySQL, so it's supported by default
(I've been using MariaDB instead of MySQL for over year before I switched
to PSQL)

Just interested: You use the akonadi postgresql backend as your default one?

Yes, and I'm a happy man now :-)

Post by GEO
_______________________________________________
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Martin Steigerwald]

Post by Daniel Vrátil

Post by GEO

Post by Daniel Vrátil
MariaDB is a drop-in replacement for MySQL, so it's supported by default
(I've been using MariaDB instead of MySQL for over year before I switched
to PSQL)

Just interested: You use the akonadi postgresql backend as your default one?

Yes, and I'm a happy man now :-)

Why? What did it improve?

I used it once, but still before the pre-mail times of Akonadi, as KMail was
not using it yet. Both with Akonadi started and central PostgreSQL.

I wondered about the support in Akonadi and I wondered about upgrades between
major PostgreSQL versions

[Daniel Vrátil]

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by GEO

Post by Daniel Vrátil
MariaDB is a drop-in replacement for MySQL, so it's supported by default
(I've been using MariaDB instead of MySQL for over year before I switched
to PSQL)

Just interested: You use the akonadi postgresql backend as your default one?

Yes, and I'm a happy man now :-)

Why? What did it improve?

I was having problems with data corruption when using MariaDB. No idea why.

Post by Martin Steigerwald
I used it once, but still before the pre-mail times of Akonadi, as KMail was
not using it yet. Both with Akonadi started and central PostgreSQL.

Lot has changed since then :-)

Post by Martin Steigerwald
I wondered about the support in Akonadi and I wondered about upgrades
between major PostgreSQL versions

We now have a PostgreSQL developer on our side (klando), who has improved the
way we detect, start and stop PostgreSQL server in Akonadi in 1.12 a lot. I
don't know about upgrades between PSQL version, but I dare to assume they work
just fine :-)

Dan

[Cédric Villemain]

Post by Daniel Vrátil

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by GEO

Post by Daniel Vrátil
MariaDB is a drop-in replacement for MySQL, so it's supported
by
default
(I've been using MariaDB instead of MySQL for over year
before I
switched
to PSQL)

Just interested: You use the akonadi postgresql backend as your default one?

Yes, and I'm a happy man now :-)

Why? What did it improve?

I was having problems with data corruption when using MariaDB. No idea why.

Post by Martin Steigerwald
I used it once, but still before the pre-mail times of Akonadi, as
KMail was not using it yet. Both with Akonadi started and central
PostgreSQL.

Lot has changed since then :-)

Post by Martin Steigerwald
I wondered about the support in Akonadi and I wondered about
upgrades
between major PostgreSQL versions

We now have a PostgreSQL developer on our side (klando), who has
improved the way we detect, start and stop PostgreSQL server in
Akonadi in 1.12 a lot. I don't know about upgrades between PSQL
version, but I dare to assume they work just fine :-)

...

Major version upgrade is 1/ rare (major version of PostgreSQL are
supported 'stable' for 5 years) 2/ handled by dump/restore or pg_upgrade
binary tool for larger databases.

Some distribution packages can propose an upgrade script. Really not
something to worry for a desktop, IMHO.

[GEO]

Post by Daniel Vrátil

Post by GEO

Post by Daniel Vrátil
MariaDB is a drop-in replacement for MySQL, so it's supported by default
(I've been using MariaDB instead of MySQL for over year before I switched
to PSQL)

Just interested: You use the akonadi postgresql backend as your default one?

Yes, and I'm a happy man now :-)

Are you running using an internal server?
I cannot get it working :-( It cannot connect to the server :-(.
Error log is attached.

Would be a pleasure if someone could help me.

[Martin Steigerwald]

Post by Daniel Vrátil

Post by Martin Steigerwald
Hi!
I reported
Bug 332626 - MySQL tuning: adaption of MySQL tuning options for larger
accounts
https://bugs.kde.org/show_bug.cgi?id=332626
But its somewhat arguable, I know.

I actually talked about optimizing mysql.conf with MariaDB people on FOSDEM
in February.

Thanks for your prompt reply, Daniel.

What were the results of your talk? Did you receive any recommendations? I am
a Linux Performance analysis and tuning generalist, so I just have the basic
knowledge about it.

Post by Daniel Vrátil

Post by Martin Steigerwald
I think I saw quite an improvement with raising the default low innodb
buffer pool size of Akonadi of 80 MiB, which is even below the MySQL
default of 128 MiB, to 256 MiB helped with a 11 GiB large POP3 account,
especially when synchronizing linux-kernel-ml folder with about 223000
unread mails. And also on retrieving and filtering new mails there, which
can make KMail quite unresponsive on a quite powerful machine (Sandybridge,
8 GB RAM, dual SSD BTRFS RAID 1). I will do some testing, yet it is
difficult to know for sure. mysqltuner.pl script gave some clear
recommendations tough, which are to high for a desktop machine tough, I
think (>1 GiB of innodb buffer pool size). It seems it recommends adjusting
to actual data size in database, which would only be suitable if all of the
data is accessed often.

The problem with innodb_buffer_pool_size is, that it directly impacts the
amount of RAM the mysqld process takes, which makes it difficult to find a
good compromise between what LKML subscribers need and what users with
couple of calendars and an adressbook need.

...

Interestingly after moving Akonadi data to local storage (Ext4 SoftRAID1), I
did not find much difference between 80 MiB and 512 MiB of innodb buffer size.

Also as I reduced the POP3 setup account to 80 MiB default again which I am
still using now, I do not see any visible differences either. I will observe
this for a bit more, as I really had the impression that raising it on that
setup helped. Sure thing, some benchmarks make sense.

Christian Mollekopf wrote in a bug report, he is even just using 8 MiB without
issues, so…

Post by Daniel Vrátil

Post by Martin Steigerwald
What is the amount data Akonadi accesses frequently? Are there any
experiences with that? I bet it depends highly on how the user uses it and
the amount of mails in a single folder to be synchronized.

This is difficult to say and I don't think anyone ever tried to benchmark or
measure it. Indeed it does depend on how you use Akonadi, an
When you open a folder in KMail, we run
SELECT * FROM PartTable WHERE parentCollection = XY AND partType =
"PLD:ENVELOPE"
which will return all envelopes in the collection (that's subject, date,
from, to, cc, bcc, ...)
akonadi=# SELECT MIN(datasize), MAX(datasize), AVG(datasize) FROM PartTable
WHERE partTypeId = 3;
min | max | avg
-----+-------+----------------------
45 | 23354 | 487.8883434774372617
(1 row)
akonadi=# SELECT datasize AS median FROM PartTable WHERE partTypeId =3 ORDER
BY datasize DESC OFFSET (SELECT (COUNT(*) + 1) / 2 FROM PartTable WHERE
partTypeId = 3) LIMIT 1;
median
--------
451
(partTypeId = 3 == SELECT id FROM PartTypeTable WHERE ns = 'PLD' AND
name='ENVELOPE')
Which makes roughly 6.5MB of data in a collection of 15 000 items. I don't
think we have any application (except for the indexer) that would request
the full payload of all items in a collection of such size. I know
KAddressbook and KOrganizer do that, but the collections there are much
smaller, and so are the actual payloads.

...

Interesting. I think there are some MySQL status variables that may help with
estimation. Here some examples from the POP3 setup with currently 80 MiB
InnoDB buffer pool size[1]:

[1] https://dev.mysql.com/doc/refman/5.5/en/server-status-variables.html#statvar_Innodb_buffer_pool_pages_dirt

[2] https://mariadb.com/kb/en/xtradbinnodb-server-status-variables/#innodb_buffer_pool_bytes_dirty

| Innodb_buffer_pool_pages_data | 4873 |
| Innodb_buffer_pool_bytes_data | 79839232 |

Actually data in pool.

| Innodb_buffer_pool_pages_dirty | 89 |
| Innodb_buffer_pool_bytes_dirty | 1458176 |

Dirty (modified) memory in InnoDB pool.

| Innodb_buffer_pool_pages_flushed | 24448 |
| Innodb_buffer_pool_pages_free | 0 |
| Innodb_buffer_pool_pages_misc | 247 |
| Innodb_buffer_pool_pages_total | 5120 |
| Innodb_buffer_pool_read_ahead_rnd | 0 |

Well obviously, with my gigant POP3 account:

***@merkaba:~/.local/share> du -sh local-mail
11G local-mail
***@merkaba:~/.local/share> find local-mail -type f | wc -l
815046
***@merkaba:~/.local/share> find local-mail -type d | wc -l
1001

Obviously folders need to be somewhat divided as for cur / new / tmp.

| Innodb_buffer_pool_read_ahead | 698532 |
| Innodb_buffer_pool_read_ahead_evicted | 98723 |

Those are unused readaheads. Read, but evicted before use

| Innodb_buffer_pool_read_requests | 914046494 |
| Innodb_buffer_pool_reads | 15625921 |

Now this is interesting: These are the number of read requests InnoDB couldn´t
satisfy from the buffer pool. Quite low actually, only 1,7% of the total read
requests.

After clicking between some folders of 5000-30000 mails each, I get:

| Innodb_buffer_pool_read_requests | 945120475 |
| Innodb_buffer_pool_reads | 16222353 |

Now I switch between three of those for a while, ext4-ml, btrfs-ml and
fsdevel-ml and introduce a new one, xfs-ml (all between 10000-30000 unread
mails):

| Innodb_buffer_pool_read_requests | 962699391 |
| Innodb_buffer_pool_reads | 16520208 |

Hmmm, I start to doubt the usefulness of raising the buffer pool size
considerably. Maybe I am missing something here tough.

| Innodb_buffer_pool_wait_free | 0 |

Also there are no waits for free pages at all even after my quick tests above:

| Innodb_buffer_pool_write_requests | 1682523 |

I ponder whether raising buffer pool size much would really bring benefits… a
slight increase if more than 4 GB of RAM or more than 8 GB of RAM or so are
available may make sense, but even there I have no actual data to back this.
But I bet this needs a more long time observation. I restarted Akonadi today
to reduce buffer pool size to 80 MiB again, so its not running for long so far.

I will observe this a bit and also try the kernel-ml case with 220000 mails in
one folder. Thus I´d not optimize for this one by default :). Maybe it gives
an impression on a relation between folder mail count and InnoDB buffer
behavior.

Post by Daniel Vrátil

Post by Martin Steigerwald
What do you think?

I think we can try to play with the values a bit, having some kind of
benchmark or test tool would be nice :-)

I bet there are test cases for Akonadi and one could probably be used. But
would need to create an account with some mails in it first (for POP3) or use
an IMAP account with some mails in it.

Post by Daniel Vrátil

Post by Martin Steigerwald
Do you have any plans to switch to MariaDB and probably investigating
storage engines which may be more suitable for tuning to desktop loads?

MariaDB is a drop-in replacement for MySQL, so it's supported by default
(I've been using MariaDB instead of MySQL for over year before I switched
to PSQL)
AFAIK the only engine that we can really use is XtraDB, which is just an
enhanced fork of InnoDb.

I see already digged further into this.

Post by Daniel Vrátil

Post by Martin Steigerwald
InnoDB is difficult as innodb_buffer_pool_size needs to take free memory
into account which can change quite rapidly on desktops or anything else
than a dedicated database server. A engine which uses Linux pagecache for
most of its caching would be interesting I think.

Maybe we could have some kind of "initial setup" tool that would check
available memory and would update innodb_buffer_pool_size depending on that
(taking in account some max limit, min limit, max percentage, ...)

...

Well I am backing off a bit at the moment. Maybe those read bursts I observed
where not related to InnoDB buffer pool size, but to something else. If I see
it again, I try to look in Akonadiconsole as to what Akonadi is doing there.

Ciao,

[Martin Steigerwald]

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by Martin Steigerwald
Hi!
I reported
Bug 332626 - MySQL tuning: adaption of MySQL tuning options for larger
accounts
https://bugs.kde.org/show_bug.cgi?id=332626
But its somewhat arguable, I know.

I actually talked about optimizing mysql.conf with MariaDB people on FOSDEM
in February.

Thanks for your prompt reply, Daniel.
What were the results of your talk? Did you receive any recommendations? I
am a Linux Performance analysis and tuning generalist, so I just have the
basic knowledge about it.

Post by Daniel Vrátil

Post by Martin Steigerwald
I think I saw quite an improvement with raising the default low innodb
buffer pool size of Akonadi of 80 MiB, which is even below the MySQL
default of 128 MiB, to 256 MiB helped with a 11 GiB large POP3 account,
especially when synchronizing linux-kernel-ml folder with about 223000
unread mails. And also on retrieving and filtering new mails there, which
can make KMail quite unresponsive on a quite powerful machine (Sandybridge,
8 GB RAM, dual SSD BTRFS RAID 1). I will do some testing, yet it is
difficult to know for sure. mysqltuner.pl script gave some clear
recommendations tough, which are to high for a desktop machine tough, I
think (>1 GiB of innodb buffer pool size). It seems it recommends adjusting
to actual data size in database, which would only be suitable if all of the
data is accessed often.

The problem with innodb_buffer_pool_size is, that it directly impacts the
amount of RAM the mysqld process takes, which makes it difficult to find a
good compromise between what LKML subscribers need and what users with
couple of calendars and an adressbook need.

Interestingly after moving Akonadi data to local storage (Ext4 SoftRAID1), I
did not find much difference between 80 MiB and 512 MiB of innodb buffer size.
Also as I reduced the POP3 setup account to 80 MiB default again which I am
still using now, I do not see any visible differences either. I will observe
this for a bit more, as I really had the impression that raising it on that
setup helped. Sure thing, some benchmarks make sense.
Christian Mollekopf wrote in a bug report, he is even just using 8 MiB
without issues, so…

Post by Daniel Vrátil

Post by Martin Steigerwald
What is the amount data Akonadi accesses frequently? Are there any
experiences with that? I bet it depends highly on how the user uses it and
the amount of mails in a single folder to be synchronized.

This is difficult to say and I don't think anyone ever tried to benchmark
or measure it. Indeed it does depend on how you use Akonadi, an
When you open a folder in KMail, we run
SELECT * FROM PartTable WHERE parentCollection = XY AND partType =
"PLD:ENVELOPE"
which will return all envelopes in the collection (that's subject, date,
from, to, cc, bcc, ...)
akonadi=# SELECT MIN(datasize), MAX(datasize), AVG(datasize) FROM PartTable
WHERE partTypeId = 3;
min | max | avg
-----+-------+----------------------
45 | 23354 | 487.8883434774372617
(1 row)
akonadi=# SELECT datasize AS median FROM PartTable WHERE partTypeId =3
ORDER BY datasize DESC OFFSET (SELECT (COUNT(*) + 1) / 2 FROM PartTable
WHERE partTypeId = 3) LIMIT 1;
median
--------
451
(partTypeId = 3 == SELECT id FROM PartTypeTable WHERE ns = 'PLD' AND
name='ENVELOPE')
Which makes roughly 6.5MB of data in a collection of 15 000 items. I don't
think we have any application (except for the indexer) that would request
the full payload of all items in a collection of such size. I know
KAddressbook and KOrganizer do that, but the collections there are much
smaller, and so are the actual payloads.

Interesting. I think there are some MySQL status variables that may help
with estimation. Here some examples from the POP3 setup with currently 80

...

Ho, there is more[1]:

SHOW ENGINE INNODB STATUS\G;

[1] http://dev.mysql.com/doc/refman/5.5/en/show-engine.html
https://mariadb.com/kb/en/show-engine/

which gives a heck of a lot of output. Browsing through it a bit to see
whether there is anything interesting.

----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 85852160; in additional pool allocated 0
Dictionary memory allocated 103892
Buffer pool size 5120
Free buffers 0
Database pages 4869
Old database pages 1777
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 19328232, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 18648345, created 2768, written 27262
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead
0.00/s
LRU len: 4869, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]


Old database pages and the young stuff may give a hint, but I didn´t find an
explaination to it in the docs. But there are some hints:

http://dba.stackexchange.com/questions/56494/making-sense-of-innodb-buffer-pool-stats

And yada: We have a buffer pool hit rate there:

Buffer pool hit rate 1000 / 1000

Well according to the stack exchange link my point is mood, cause the buffer
pool is perfectly utilized. Thus probably good to close bug report I made.

I will observe this for a bit still, cause if restarted recently, the values
are not that meaning full.

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by Martin Steigerwald
InnoDB is difficult as innodb_buffer_pool_size needs to take free memory
into account which can change quite rapidly on desktops or anything else
than a dedicated database server. A engine which uses Linux pagecache for
most of its caching would be interesting I think.

Maybe we could have some kind of "initial setup" tool that would check
available memory and would update innodb_buffer_pool_size depending on that
(taking in account some max limit, min limit, max percentage, ...)

Well I am backing off a bit at the moment. Maybe those read bursts I
observed where not related to InnoDB buffer pool size, but to something
else. If I see it again, I try to look in Akonadiconsole as to what Akonadi
is doing there.

...

I am thankful for any hints on where to look regarding Akonadi related
performance issues. I think I want to dig this a bit :).

I found information on testing framework[2], but not regarding performance
issues. I think I read through the techbase documentation to understand
Akonadi a bit better.

[2] http://techbase.kde.org/Projects/PIM/Akonadi/Testing

Ciao,

[Martin Steigerwald]

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by Martin Steigerwald
InnoDB is difficult as innodb_buffer_pool_size needs to take free memory
into account which can change quite rapidly on desktops or anything else
than a dedicated database server. A engine which uses Linux pagecache for
most of its caching would be interesting I think.

Maybe we could have some kind of "initial setup" tool that would check
available memory and would update innodb_buffer_pool_size depending on that
(taking in account some max limit, min limit, max percentage, ...)

Well I am backing off a bit at the moment. Maybe those read bursts I
observed where not related to InnoDB buffer pool size, but to something
else. If I see it again, I try to look in Akonadiconsole as to what Akonadi
is doing there.

...

There is indeed some stuff in Akonadiconsole there.

And now I had this long wait for KMail to do anything again. After downloading
/ filtering new mail.

According to Akonadiconsole akonadi nepomuk feeder was indexing and according
to atop akonadi maildir resource was hogging one Sandybridge core for 100% for
minutes.

Akonadiconsole Query Debugger showed queries to get payload bodies, also from
that kernel-ml folder. And I have quite some wait times in Job Tracker now,
for Akonadi::ItemFetchJob. I have wait times up to:

00:05:33.069

Five of those wait times between 5 and 6 minutes.

Four between 2-3 minutes.

Five between 10-20 seconds.

Why this time is so long, I don´t know.


Akonadi seems to block out KMail due to this mail indexing background
activity, which I reported already:

Bug 331848 - displaying, moving, deleting mails takes 10-20 seconds when
Akonadi synchronizes in background

https://bugs.kde.org/show_bug.cgi?id=331848

But at work I do not have mail indexing enabled so far, yet this was on NFS
still as I reported the bug.


I think I just disable mail indexing for now for this POP3 setup, until I can
install KDE SC 4.13 including new KDEPIM and Baloo.

Well, I learned about debugging performance issues with Akonadi.


I am inclined to close my MySQL tuning related report. I do not have the
impression anymore that it is very important at the moment. What do you think?

So finishing analysis for now.

[Martin Steigerwald]

Post by Martin Steigerwald

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by Martin Steigerwald
InnoDB is difficult as innodb_buffer_pool_size needs to take free memory
into account which can change quite rapidly on desktops or anything else
than a dedicated database server. A engine which uses Linux pagecache for
most of its caching would be interesting I think.

Maybe we could have some kind of "initial setup" tool that would check
available memory and would update innodb_buffer_pool_size depending on that
(taking in account some max limit, min limit, max percentage, ...)

Well I am backing off a bit at the moment. Maybe those read bursts I
observed where not related to InnoDB buffer pool size, but to something
else. If I see it again, I try to look in Akonadiconsole as to what Akonadi
is doing there.

There is indeed some stuff in Akonadiconsole there.
And now I had this long wait for KMail to do anything again. After
downloading / filtering new mail.
According to Akonadiconsole akonadi nepomuk feeder was indexing and
according to atop akonadi maildir resource was hogging one Sandybridge core
for 100% for minutes.
Akonadiconsole Query Debugger showed queries to get payload bodies, also
from that kernel-ml folder. And I have quite some wait times in Job Tracker
00:05:33.069
Five of those wait times between 5 and 6 minutes.
Four between 2-3 minutes.
Five between 10-20 seconds.
Why this time is so long, I don´t know.
Akonadi seems to block out KMail due to this mail indexing background
Bug 331848 - displaying, moving, deleting mails takes 10-20 seconds when
Akonadi synchronizes in background
https://bugs.kde.org/show_bug.cgi?id=331848
But at work I do not have mail indexing enabled so far, yet this was on NFS
still as I reported the bug.
I think I just disable mail indexing for now for this POP3 setup, until I
can install KDE SC 4.13 including new KDEPIM and Baloo.
Well, I learned about debugging performance issues with Akonadi.
I am inclined to close my MySQL tuning related report. I do not have the
impression anymore that it is very important at the moment. What do you think?
So finishing analysis for now.

...

I got miss rates now:


BUFFER POOL AND MEMORY
----------------------
Total memory allocated 85852160; in additional pool allocated 0
Dictionary memory allocated 103892
Buffer pool size 5120
Free buffers 0
Database pages 4871
Old database pages 1778
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 659333, not young 0
3302.78 youngs/s, 0.00 non-youngs/s
Pages read 619033, created 84, written 1204
3191.25 reads/s, 0.53 creates/s, 10.80 writes/s
Buffer pool hit rate 977 / 1000, young-making rate 24 / 1000 not 0 / 1000
Pages read ahead 79.79/s, evicted without access 21.00/s, Random read ahead
0.00/s
LRU len: 4871, unzip_LRU len: 0
I/O sum[267946]:cur[0], unzip sum[0]:cur[0]


Another example:
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 85852160; in additional pool allocated 0
Dictionary memory allocated 103892
Buffer pool size 5120
Free buffers 0
Database pages 4942
Old database pages 1804
Modified db pages 10
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 1076283, not young 0
10570.21 youngs/s, 0.00 non-youngs/s
Pages read 1015530, created 110, written 1673
10471.76 reads/s, 0.50 creates/s, 10.00 writes/s
Buffer pool hit rate 965 / 1000, young-making rate 36 / 1000 not 0 / 1000
Pages read ahead 479.76/s, evicted without access 78.46/s, Random read ahead
0.00/s
LRU len: 4942, unzip_LRU len: 0
I/O sum[88144]:cur[7656], unzip sum[0]:cur[0]

see:

Bug 332626 - MySQL tuning: adaption of MySQL tuning options for larger
accounts
https://bugs.kde.org/show_bug.cgi?id=332626#c5


And I got:

Bug 332653 - After mail receive on filtering: Unable to retrieve item from
resource: NO ImapParserException: Unable to read more data


This should have been with disabled mail indexing. I will observe further and
really close analysis for now. Need to get a clear head again, before
continuing.

Ciao,

[Daniel Vrátil]

Post by Martin Steigerwald

Post by Martin Steigerwald

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by Martin Steigerwald
InnoDB is difficult as innodb_buffer_pool_size needs to take free memory
into account which can change quite rapidly on desktops or anything else
than a dedicated database server. A engine which uses Linux
pagecache
for
most of its caching would be interesting I think.

Maybe we could have some kind of "initial setup" tool that would check
available memory and would update innodb_buffer_pool_size depending on that
(taking in account some max limit, min limit, max percentage, ...)

Well I am backing off a bit at the moment. Maybe those read bursts I
observed where not related to InnoDB buffer pool size, but to something
else. If I see it again, I try to look in Akonadiconsole as to what Akonadi
is doing there.

There is indeed some stuff in Akonadiconsole there.
And now I had this long wait for KMail to do anything again. After
downloading / filtering new mail.
According to Akonadiconsole akonadi nepomuk feeder was indexing and
according to atop akonadi maildir resource was hogging one Sandybridge core
for 100% for minutes.
Akonadiconsole Query Debugger showed queries to get payload bodies, also
from that kernel-ml folder. And I have quite some wait times in Job Tracker
00:05:33.069
Five of those wait times between 5 and 6 minutes.
Four between 2-3 minutes.
Five between 10-20 seconds.
Why this time is so long, I donŽt know.
Akonadi seems to block out KMail due to this mail indexing background
Bug 331848 - displaying, moving, deleting mails takes 10-20 seconds when
Akonadi synchronizes in background
https://bugs.kde.org/show_bug.cgi?id=331848
But at work I do not have mail indexing enabled so far, yet this was on NFS
still as I reported the bug.
I think I just disable mail indexing for now for this POP3 setup, until I
can install KDE SC 4.13 including new KDEPIM and Baloo.
Well, I learned about debugging performance issues with Akonadi.
I am inclined to close my MySQL tuning related report. I do not have the
impression anymore that it is very important at the moment. What do you think?
So finishing analysis for now.

BUFFER POOL AND MEMORY
----------------------
Total memory allocated 85852160; in additional pool allocated 0
Dictionary memory allocated 103892
Buffer pool size 5120
Free buffers 0
Database pages 4871
Old database pages 1778
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 659333, not young 0
3302.78 youngs/s, 0.00 non-youngs/s
Pages read 619033, created 84, written 1204
3191.25 reads/s, 0.53 creates/s, 10.80 writes/s
Buffer pool hit rate 977 / 1000, young-making rate 24 / 1000 not 0 / 1000
Pages read ahead 79.79/s, evicted without access 21.00/s, Random read ahead
0.00/s
LRU len: 4871, unzip_LRU len: 0
I/O sum[267946]:cur[0], unzip sum[0]:cur[0]
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 85852160; in additional pool allocated 0
Dictionary memory allocated 103892
Buffer pool size 5120
Free buffers 0
Database pages 4942
Old database pages 1804
Modified db pages 10
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 1076283, not young 0
10570.21 youngs/s, 0.00 non-youngs/s
Pages read 1015530, created 110, written 1673
10471.76 reads/s, 0.50 creates/s, 10.00 writes/s
Buffer pool hit rate 965 / 1000, young-making rate 36 / 1000 not 0 / 1000
Pages read ahead 479.76/s, evicted without access 78.46/s, Random read ahead
0.00/s
LRU len: 4942, unzip_LRU len: 0
I/O sum[88144]:cur[7656], unzip sum[0]:cur[0]
Bug 332626 - MySQL tuning: adaption of MySQL tuning options for larger
accounts
https://bugs.kde.org/show_bug.cgi?id=332626#c5
Bug 332653 - After mail receive on filtering: Unable to retrieve item from
resource: NO ImapParserException: Unable to read more data
This should have been with disabled mail indexing. I will observe further
and really close analysis for now. Need to get a clear head again, before
continuing.
Ciao,

...

Hi,

thanks a lot for all the analysis. I will need to read up on this and consult
MySQL documentation first, so I'll go through it next week :-)

Dan

[Martin Steigerwald]

Hi,

Post by Daniel Vrátil

Post by Martin Steigerwald

Post by Martin Steigerwald

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by Martin Steigerwald
InnoDB is difficult as innodb_buffer_pool_size needs to take free
memory
into account which can change quite rapidly on desktops or
anything
else
than a dedicated database server. A engine which uses Linux
pagecache
for
most of its caching would be interesting I think.

Maybe we could have some kind of "initial setup" tool that would check
available memory and would update innodb_buffer_pool_size depending
on
that
(taking in account some max limit, min limit, max percentage, ...)

Well I am backing off a bit at the moment. Maybe those read bursts I
observed where not related to InnoDB buffer pool size, but to something
else. If I see it again, I try to look in Akonadiconsole as to what Akonadi
is doing there.

There is indeed some stuff in Akonadiconsole there.
And now I had this long wait for KMail to do anything again. After
downloading / filtering new mail.
According to Akonadiconsole akonadi nepomuk feeder was indexing and
according to atop akonadi maildir resource was hogging one Sandybridge core
for 100% for minutes.
Akonadiconsole Query Debugger showed queries to get payload bodies, also
from that kernel-ml folder. And I have quite some wait times in Job Tracker
00:05:33.069
Five of those wait times between 5 and 6 minutes.
Four between 2-3 minutes.
Five between 10-20 seconds.
Why this time is so long, I don´t know.
Akonadi seems to block out KMail due to this mail indexing background
Bug 331848 - displaying, moving, deleting mails takes 10-20 seconds when
Akonadi synchronizes in background
https://bugs.kde.org/show_bug.cgi?id=331848
But at work I do not have mail indexing enabled so far, yet this was on NFS
still as I reported the bug.
I think I just disable mail indexing for now for this POP3 setup, until I
can install KDE SC 4.13 including new KDEPIM and Baloo.
Well, I learned about debugging performance issues with Akonadi.
I am inclined to close my MySQL tuning related report. I do not have the
impression anymore that it is very important at the moment. What do you think?
So finishing analysis for now.

BUFFER POOL AND MEMORY
----------------------
Total memory allocated 85852160; in additional pool allocated 0
Dictionary memory allocated 103892
Buffer pool size 5120
Free buffers 0
Database pages 4871
Old database pages 1778
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 659333, not young 0
3302.78 youngs/s, 0.00 non-youngs/s
Pages read 619033, created 84, written 1204
3191.25 reads/s, 0.53 creates/s, 10.80 writes/s
Buffer pool hit rate 977 / 1000, young-making rate 24 / 1000 not 0 / 1000
Pages read ahead 79.79/s, evicted without access 21.00/s, Random read ahead
0.00/s
LRU len: 4871, unzip_LRU len: 0
I/O sum[267946]:cur[0], unzip sum[0]:cur[0]
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 85852160; in additional pool allocated 0
Dictionary memory allocated 103892
Buffer pool size 5120
Free buffers 0
Database pages 4942
Old database pages 1804
Modified db pages 10
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 1076283, not young 0
10570.21 youngs/s, 0.00 non-youngs/s
Pages read 1015530, created 110, written 1673
10471.76 reads/s, 0.50 creates/s, 10.00 writes/s
Buffer pool hit rate 965 / 1000, young-making rate 36 / 1000 not 0 / 1000
Pages read ahead 479.76/s, evicted without access 78.46/s, Random read
ahead 0.00/s
LRU len: 4942, unzip_LRU len: 0
I/O sum[88144]:cur[7656], unzip sum[0]:cur[0]
Bug 332626 - MySQL tuning: adaption of MySQL tuning options for larger
accounts
https://bugs.kde.org/show_bug.cgi?id=332626#c5
Bug 332653 - After mail receive on filtering: Unable to retrieve item from
resource: NO ImapParserException: Unable to read more data
This should have been with disabled mail indexing. I will observe further
and really close analysis for now. Need to get a clear head again, before
continuing.
Ciao,

...

[…]

Post by Daniel Vrátil
thanks a lot for all the analysis. I will need to read up on this and
consult MySQL documentation first, so I'll go through it next week :-)

Yeah, me too.

The buffer pool hit rate appears still quite good and I never have seen
anything below 950/1000 so far, so I think its no real big issue. But I also
need to understand this better :)

I enjoyed digging a bit deeper and learning more about Akonadi and what is
possible in Akonadiconsole. I think Akonadiconsole is a good place to test
basic operations.

I am still trying to find my way to analyse why KMail doesn´t respond for some
minutes for example in order to at least provide more useful bug reports. So
on how to get from an application bug to analyse what really is happening on
the surface below. I have some ideas meanwhile and I think my issues are more
with payload handling than the actual database operations. Especially
synchronizing folders seem to be expensive. Especially if they have tens of
thousands mails in it. Not talking about that kernel-ml folder with 200000
mails.

In KMail 1 I archived folders via having it move old mails to mbox folders via
folder archiving. I used a mixed maildir resource for that. Which I still did
not dare to integrate back into Akonadi. I am fine with splitting folders,
using mbox archive folder, but doing one mbox resource for each mbox folder I
want to have for archiving, does not seem to make good sense to me. So I
really like that mixedmaildir thing. Folder archive agent may be an
alternative, but I´d like to have the old mails read-accessible still and
searchable, which would only work by zgrep´ing through the archive files Folder
Archive Agent creates.

Starting with KDE SC 4.13 I may try to add back that old mixedmaildir resource
and setup archiving to it again. Well I may just try before, but *without*
mail indexing via Nepomuk :)

[Martin Steigerwald]

Post by Daniel Vrátil
Hi,
thanks a lot for all the analysis. I will need to read up on this and
consult MySQL documentation first, so I'll go through it next week

Gee, I now had it again with my POP3 setup. KMail blocked for minutes. akonadi
maildir resource 100% CPU bound. And I think I found part of the reason why:

70% of all stat calls, about 100000 of them during that strace, were to stat
/etc/localtime.

Bug 332684 - [Maildir] lots of stats calls to /etc/localtime on synchronizing
folders
https://bugs.kde.org/show_bug.cgi?id=332684


Not to blame on MySQL tough. :)

I might look into the code for that as that might be quite easy to fix.

Ciao,

[Torsten Grote]

Hey Martin,

Post by Martin Steigerwald
Bug 332684 - [Maildir] lots of stats calls to /etc/localtime on
synchronizing folders
https://bugs.kde.org/show_bug.cgi?id=332684
I might look into the code for that as that might be quite easy to fix.

Thanks for your investigation and your bug report! It would be awesome if you
could fix this POP3 issue as many non-developers still seem to use POP3 and
are seeing those issues.

Kind Regards,
Torsten
--
Torsten Grote, Kolab Evangelist

Kolab Systems AG, Zürich, Switzerland

e: ***@kolabsys.com
t: [phone]
w: http://kolabsys.com

pgp: 274D 4F97 Torsten Grote
_______________________________________________
KDE PIM mailing list kde-***@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Daniel Vrátil]

Post by Martin Steigerwald

Post by Daniel Vrátil
Hi,
thanks a lot for all the analysis. I will need to read up on this and
consult MySQL documentation first, so I'll go through it next week

Gee, I now had it again with my POP3 setup. KMail blocked for minutes.
akonadi maildir resource 100% CPU bound. And I think I found part of the
70% of all stat calls, about 100000 of them during that strace, were to stat
/etc/localtime.

Is your TZ env variable set? If not set it to TZ="Europe/XX" (whatever your TZ
is) and try again, it might reduce the amount of stats.

Dan

Post by Martin Steigerwald
Bug 332684 - [Maildir] lots of stats calls to /etc/localtime on
synchronizing folders
https://bugs.kde.org/show_bug.cgi?id=332684
Not to blame on MySQL tough. :)
I might look into the code for that as that might be quite easy to fix.
Ciao,

[Martin Steigerwald]

Post by Daniel Vrátil

Post by Martin Steigerwald

Post by Daniel Vrátil
Hi,
thanks a lot for all the analysis. I will need to read up on this and
consult MySQL documentation first, so I'll go through it next week

Gee, I now had it again with my POP3 setup. KMail blocked for minutes.
akonadi maildir resource 100% CPU bound. And I think I found part of the
70% of all stat calls, about 100000 of them during that strace, were to
stat /etc/localtime.

Is your TZ env variable set? If not set it to TZ="Europe/XX" (whatever your
TZ is) and try again, it might reduce the amount of stats.

...

Seems to help:

merkaba:/tmp> grep -c "stat(\"/etc/localtime" strace-blub.txt
0
merkaba:/tmp#1> grep -c "stat(" strace-blub.txt
998

Still KMail was blocked for some time, but appeared to be shorter, definately
wasn´t a minute, but this was also during KDE session startup with Akonadi
starting and MySQL was using 120% CPU (possibly due to other initialization
reasons).

I wait for some bigger mail batch to arrive and retest then and add comment to
bug.

Post by Daniel Vrátil

Post by Martin Steigerwald
Bug 332684 - [Maildir] lots of stats calls to /etc/localtime on
synchronizing folders
https://bugs.kde.org/show_bug.cgi?id=332684

[…]

Thanks,

[Jos Poortvliet]

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by Martin Steigerwald

Post by Daniel Vrátil
Hi,
thanks a lot for all the analysis. I will need to read up on this and
consult MySQL documentation first, so I'll go through it next week

Gee, I now had it again with my POP3 setup. KMail blocked for minutes.
akonadi maildir resource 100% CPU bound. And I think I found part of the
70% of all stat calls, about 100000 of them during that strace, were to
stat /etc/localtime.

Is your TZ env variable set? If not set it to TZ="Europe/XX" (whatever your
TZ is) and try again, it might reduce the amount of stats.

merkaba:/tmp> grep -c "stat(\"/etc/localtime" strace-blub.txt
0
merkaba:/tmp#1> grep -c "stat(" strace-blub.txt
998
Still KMail was blocked for some time, but appeared to be shorter,
definately wasn´t a minute, but this was also during KDE session startup
with Akonadi starting and MySQL was using 120% CPU (possibly due to other
initialization reasons).
I wait for some bigger mail batch to arrive and retest then and add comment
to bug.

...

You want everybody on this list to send you a mail to help you test it?

:P

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by Martin Steigerwald
Bug 332684 - [Maildir] lots of stats calls to /etc/localtime on
synchronizing folders
https://bugs.kde.org/show_bug.cgi?id=332684

[…]
Thanks,

_______________________________________________
KDE PIM mailing list kde-***@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM hom

[Mark Gaiser]

Post by Jos Poortvliet

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by Martin Steigerwald

Post by Daniel Vrátil
Hi,
thanks a lot for all the analysis. I will need to read up on this and
consult MySQL documentation first, so I'll go through it next week

Gee, I now had it again with my POP3 setup. KMail blocked for minutes.
akonadi maildir resource 100% CPU bound. And I think I found part of the
70% of all stat calls, about 100000 of them during that strace, were to
stat /etc/localtime.

Is your TZ env variable set? If not set it to TZ="Europe/XX" (whatever your
TZ is) and try again, it might reduce the amount of stats.

merkaba:/tmp> grep -c "stat(\"/etc/localtime" strace-blub.txt
0
merkaba:/tmp#1> grep -c "stat(" strace-blub.txt
998
Still KMail was blocked for some time, but appeared to be shorter,
definately wasn´t a minute, but this was also during KDE session startup
with Akonadi starting and MySQL was using 120% CPU (possibly due to other
initialization reasons).
I wait for some bigger mail batch to arrive and retest then and add comment
to bug.

You want everybody on this list to send you a mail to help you test it?
:P

...

Ohh, i can help with that.
A simple for loop in PHP. Something like:
for($i = 0; i < 10000; $i++)
{ mail() }

Will give you "just" 10000 mails :)
_______________________________________________
KDE PIM mailing list kde-***@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Martin Steigerwald]

Post by Jos Poortvliet

Post by Martin Steigerwald

Post by Daniel Vrátil

Post by Martin Steigerwald

Post by Daniel Vrátil
Hi,
thanks a lot for all the analysis. I will need to read up on this and
consult MySQL documentation first, so I'll go through it next week

Gee, I now had it again with my POP3 setup. KMail blocked for minutes.
akonadi maildir resource 100% CPU bound. And I think I found part of the
70% of all stat calls, about 100000 of them during that strace, were to
stat /etc/localtime.

Is your TZ env variable set? If not set it to TZ="Europe/XX" (whatever your
TZ is) and try again, it might reduce the amount of stats.

merkaba:/tmp> grep -c "stat(\"/etc/localtime" strace-blub.txt
0
merkaba:/tmp#1> grep -c "stat(" strace-blub.txt
998
Still KMail was blocked for some time, but appeared to be shorter,
definately wasn´t a minute, but this was also during KDE session startup
with Akonadi starting and MySQL was using 120% CPU (possibly due to other
initialization reasons).
I wait for some bigger mail batch to arrive and retest then and add comment
to bug.

You want everybody on this list to send you a mail to help you test it?
:P

...

No need to.

1) I get enough mails as is. :)

2) I still get minute long CPU bursts on *filtering* about 150 mails.

The stat()´s on /etc/localtime are gone.

I ask myself why it actually tries to synchronize folders at all.

I have all mails which are to be filtered in a folder _Inbox and I press Ctrl
A, Ctrl J there. Then KMail not usable for 5-10 minutes or so and Akonadi
maildir resource synchronizing folders like mad.

For example on synchronizing kernel-ml it stat()s each of the 220000+ files in
there. Why? I moves a mail from _Inbox to kernel-ml. For me that would
include:

1. Change metadata in database.
2. Move the file from _Inbox to kernel-ml
3. Be done with it.


I already disabled synchronizing mail folders on start and on manually
checking for mails.

I usually do not put mails manually in any of the maildir folders. It has
inotify watches anyway on the folders. So the only scan that would make *some*
sense would be the one on start.

Why does it synchronize folders? I don´t get it.

[Andras Mantia]

Post by Martin Steigerwald
I already disabled synchronizing mail folders on start and on manually
checking for mails.
I usually do not put mails manually in any of the maildir folders. It has
inotify watches anyway on the folders. So the only scan that would make
*some* sense would be the one on start.
Why does it synchronize folders? I don´t get it.

Good question. Maybe the new mail in a folder triggers it in the maildir
resource? Maildir is monitoring its folders for new mails and adds
automatically to the collection when a new mail appears. It shouldn't
trigger a full sync though.

Andras
_______________________________________________
KDE PIM mailing list kde-***@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org

[Martin Steigerwald]

Post by Andras Mantia

Post by Martin Steigerwald
I already disabled synchronizing mail folders on start and on manually
checking for mails.
I usually do not put mails manually in any of the maildir folders. It has
inotify watches anyway on the folders. So the only scan that would make
*some* sense would be the one on start.
Why does it synchronize folders? I don´t get it.

Good question. Maybe the new mail in a folder triggers it in the maildir
resource? Maildir is monitoring its folders for new mails and adds
automatically to the collection when a new mail appears. It shouldn't
trigger a full sync though.

...

Well inotify would trigger a notification on every file added to a monitored
directory… but… well… thanks thats a good hint to watch out for.