0 Replies Latest reply on Mar 15, 2013 12:08 PM by diesmo

    Calendar 6.3 - Logging region out of memory ?


      We are using Calendar 6.3-32.01 (32bits) on Linux.

      The administrative commands cscal, csexport, etc. do not work anymore, we only get "Cannot open database".

      We get this message in admin.log
      [15/Mar/2013:10:38:42 +0100] cal6 csdb[31743]: General Error: caldb: Error with calendar database: Logging region out of memory; you may need to increase its size
      [15/Mar/2013:10:38:42 +0100] cal6 csdb[31743]: Store Error: Unable to open ics50events.db database: No such file or directory

      We did a csdb check and csdb rebuild, the problem was back after 2 days.
      Second rebuilt, problem back after 1 day.

      Now, csdb check did not find any error after i removed the __db.* on a copy of the production database.

      The Berkeley database is 3.8GB.

      Currently, db_stat -h csdb -l gives me this :

      40988 Log magic number.
      8 Log version number.
      32KB Log record cache size.
      0660 Log file mode.
      10Mb Current log file size.
      769MB 357KB 206B Log bytes written.
      Log bytes written since last checkpoint.
      35592 Total log file writes.
      21083 Total log file write due to overflow.
      19026 Total log file flushes.
      475 Current log file number.
      8677091 Current log file offset.
      475 On-disk log file number.
      8677091 On-disk log file offset.
      27 Max commits in a log flush.
      0 Min commits in a log flush.
      *96KB Log region size.*
      9731 The number of region locks granted after waiting.
      2476390 The number of region locks granted without waiting.

      Do you think it's a good idea to increase the logging region ? To do so, i would :
      - stop the calendar server
      - get rid of the __db.*
      - make a copy of the database
      - create a DB_CONFIG file in the csdb folder with (256KB):
      set_lg_regionmax 262144
      - restart the server

      Do i need to increase other settings, like the size of the cache ?

      Any advice is appreciated.


      Similar problem with Messaging's berkeley dbs :

      Would using a DB_CONFIG file be the "definitive solution for this kind of issue" ?

      Edited by: diesmo on 15 mars 2013 05:04