Después de un poco de análisis, resultó que este no era un comportamiento normal y, de hecho, era la fuente de muchos problemas de rendimiento.
Comprobé qué archivos mantiene calaccessd, y descubrí que la base de datos principal del calendario está ubicada en ~/Library/Calendars/Calendar.sqlitedb. Por razones desconocidas, este archivo había crecido a más de 3.5 GB, y el registro WAL justo al lado de él alcanzaba un asombroso 2.5 GB, lo cual era claramente anormal y mucho más grande de lo recomendado para una base de datos SQLite.
Mi error al diagnosticar esto fue revisar el rendimiento del disco. Era bastante bajo, unos pocos cientos de kB/s, y no habría afectado mucho al sistema. Pero había muchos eventos de E/S discretos.
Remedié el problema desactivando todas las fuentes de calendario en el panel de configuración de la aplicación Calendario. Después de cerrar Calendar, moví toda la antigua carpeta de Calendar a una ubicación de respaldo. Luego volví a abrir Calendar, añadí de nuevo las fuentes de calendario y la aplicación recreó transparentemente la carpeta ~/Library/Calendar.
Ahora mi sistema es notablemente más receptivo en general, y la actividad del disco realmente cae a 0 kB/s de lectura/escritura y 0 eventos durante los tiempos de inactividad, algo que realmente no ocurría antes.
