I did try reducing the values of those two parameters but it still
chomped all of the memory on the server.
The problem I had was with a calender of about 4000 events synchronizing
to Outlook 2013 which I doubt is particularly a corner case.
On another server with more memory the same sync did complete OK but it
seems strange to need to much memory for this operation.
The minor pool management change made such a dramatic difference to the
memory useage that I think it well worth considering the change but do
please review it carefuly - I've now got a grand total of less than a
day's experience of objective C.
I'll get the push request in later when I've worked out how to do it.
Thanks
Raph
In this corner case a three line change made a
On 02/02/2016 13:59, Ludovic Marcotte wrote:
On 2016-02-02 05:34, Raph Weyman wrote:
By adding a locally controlled auto-release pool to the inner 'for'
loop in
this function, the memory consumption of the daemon during the same
ActiveSync
calendar synchronisation stays within 50K or so.
Much saner than the multi-gigabytes it was consuming before.
If it was consuming multi-gigabytes, that's because the sync response
being generate was enormous.
A local pool might help a bit, but the root of the issue is a
misconfiguration of the SOGoMaximumSyncResponseSize and
SOGoMaximumSyncWindowSize.
For example, if you have 1000 email folders (like I do) and you launch
Outlook 2013, it'll ask for 512 messages for each folder. You can end
up initially sending back 512 000 mails.
Anyway, create the PR and we'll look at it. As I said, a local pool
might help in some corner-cases.
Thanks,
--
[email protected]
https://inverse.ca/sogo/lists
