Hi all. We are running a mac server 10.7.4 with caldav 3 in a commercial environment. We have the behavior that from time to time the spawned processes from caldavd (Python /usr/bin/twistd -f /etc/caldavd/caldavd.plist) will use memory up to 3GB. because of that our server is running out of memory and the processes will create very big swap files. and our server will getting slower and slower. How we can change the process count? we figured out we can do this via the caldavd.plist file. we want to change the xml tag MultiProcess/ProcessCount. is that right? The important question is how we can restrict the memory usage for every caldav process? What does "ProcessType" mean? There are 3 values: master,slave,combined Thanks a lot for your help. Marko
On Jun 6, 2012, at 4:04 AM, Marko Bauhardt wrote:
Hi all.
We are running a mac server 10.7.4 with caldav 3 in a commercial environment. We have the behavior that from time to time the spawned processes from caldavd (Python /usr/bin/twistd -f /etc/caldavd/caldavd.plist) will use memory up to 3GB. because of that our server is running out of memory and the processes will create very big swap files. and our server will getting slower and slower.
This should go without saying, but the server is not supposed to do this. Do you know what causes its memory to grow? We're working on addressing a similar condition and the more data we can get, the better. Are you scheduling meetings with large numbers of people? Do you have a lot of events that repeat very frequently? Thanks for any information you can give us.
How we can change the process count? we figured out we can do this via the caldavd.plist file. we want to change the xml tag MultiProcess/ProcessCount. is that right?
Yep, that's the idea.
The important question is how we can restrict the memory usage for every caldav process?
You can't, really; sorry. It's a bug that it takes so much memory.
What does "ProcessType" mean? There are 3 values: master,slave,combined
You probably don't care about this. You may notice (if you look at 'ps') that there are many caldavd processes. The master process is the first one that starts up, to take care of certain kinds of bookkeeping. It then starts a bunch of slave processses to do the real work of processing multiple requests. "combined" is a configuration, mostly for development, which allows you to run the logic for the master and the slave in the same process, so that only one process starts up.
On Jun 8, 2012, at 10:16 PM, Glyph wrote: Hey Glyph. thanks for your comments.
Do you know what causes its memory to grow? We're working on addressing a similar condition and the more data we can get, the better. Are you scheduling meetings with large numbers of people? Do you have a lot of events that repeat very frequently?
Yes we are around 70 users in caldav. i would say around 30 users has a lot of events every day. we also have scheduled events that repeats for example every week. These events contains a lot of attendees, more than 30. i will ask our administrator what we have configured to attend more users than the default is. (not sure if we changed something in a plist file to attend a lot of users, or if we use groups for that..) some more information: before some days our error.log file was growing vey fast. It looked like there was a kind of loop-logging with this reoccurring lines. 2012-05-31 16:12:00+0200 [-] [caldav-6] BEGIN:VALARM 2012-05-31 16:12:00+0200 [-] [caldav-6] ACTION:AUDIO 2012-05-31 16:12:00+0200 [-] [caldav-6] ATTACH:Basso 2012-05-31 16:12:00+0200 [-] [caldav-6] TRIGGER:-PT15M 2012-05-31 16:12:00+0200 [-] [caldav-6] X-WR-ALARMUID:E73FEE8D-B0E0-4F97-A3BA-DEDBB950054F 2012-05-31 16:12:00+0200 [-] [caldav-6] END:VALARM In 14 seconds we had 28.493 repeating errors, thats around 2035 6-liners per second we thought that this error log was related to the out of memory. but now we have the out of memory without these error log lines.
The important question is how we can restrict the memory usage for every caldav process?
You can't, really; sorry. It's a bug that it takes so much memory.
Ok. we killed those processes manually (our administrator had funny nights ;)) but yesterday we starts to write a script that monitor the caldav workers and kill those processes when they running out of memory. Many thanks for your comments! Would be great when you have more informations or hints what we can do to avoid this. Marko
participants (2)
-
Glyph
-
Marko Bauhardt