This project has moved. For the latest updates, please go here.
1
Vote

CircularLog not working (on a specific host)

description

Hi,
We're using the PersistentDictionary for a couple of years now and so far it works great. However - we now have a single machine (Win 2012R2) were the configuration setting "CircularLog" does not work.
The configuration we apply uses a 4MB logfile and should roll over after about 6 logfiles. On this particular machine however it fills up until the disk is full.

My first guess was that a transaction of a PersistentDictionaryCursor is hung, but added diagnostic code indicates that this is not the case.

The code that reads from / writes to the dictionary is the same as everywhere else, do you have any idea what could cause the problem?
This machine itself is not that much a problem (it's an inhouse - testing vm) but history shows that problems in test usually come up in production as well...

BR, Klaus

comments

linky wrote May 2 at 11:03 AM

Sorry - I forgot about it before:
A small testapp that only updates the same 1000 values in a loop from a single thread works without any problems and suffers no problems...
So - it's definitely not just "this machine" but "this machine with our payload"

mthorp wrote May 2 at 7:04 PM

Hi Klaus,

If you can provide a bit more information on the particular VM that is hitting this problem I'll try to look into the issue. First, what version of Windows is it running and is that, by any chance, different from the version running on other test/production machines? Are you able to provide the test database? If so, please provide the database, the checkpoint (*.chk file) and the list of files that are in the log folder. Maybe also the last few log files just to check them. If you would prefer not to, can you dump the database header and checkpoint file as such:
esentutl.exe /mh <database file>
esentutl.exe /mk <checkpoint file>
Do you by any chance take regular backups of the data? What kind of payload is running on this test VM? Heavy on updates or mostly reads?

Thanks,
Michael

linky wrote May 4 at 1:56 PM

Hi Michael,
Sorry for the late reply.

Windows is in Version 2012R2 Standard, 6.3, Build 9600;
Strange thing is that we have the same application with the same PersistentDictionary assembly on pretty much the same VM (all installed with the same install guide).

In general - we're using the persistentdictionary as fast, local store before we transfer data to another db.
A single Storage consists of the following:
*PersistentDictionary<long,string> Queue
*PersistentDictionary<string,byte> Operation
*PersistentDictioanry<string,string> Data

When we add a record to our Storage we
*insert into Queue
*insert or update Operation (basically just the info if write or delete)
*insert or update Data

Some time later (a few ms to a few seconds) we get the next entries via Queue(long).Take(5000).ToArray and with this we get the values from Operation and Data. Once transfered, the records are deleted.
In a typical Storage in a typical environment we have < 100 inserts per second per dictionary (although we have some systems with high load with > 1000 inserts per second per dictionary)

As far as I know we have never taken any backups so far.

If you give me your email address (you can contact me at klaus.linzner@live.at) I'd be more than happy to provide you db and logfiles (link to onedrive).
For now, I'll attach the esentutl output.

Thanks for your support && BR, Klaus
esentutl /mh PersistentDictionary.edb

Extensible Storage Engine Utilities for Microsoft(R) Windows(R)
Version 10.0
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
         Database: PersistentDictionary.edb

DATABASE HEADER:
Checksum Information:
Expected Checksum: 0x2ff61f6d
  Actual Checksum: 0x2ff61f6d

Fields:
        File Type: Database
         Checksum: 0x2ff61f6d
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,20,0  (attached by 0)
 Engine ulVersion: 0x620,30,40  (efvCurrent = 8960)
Created ulVersion: 0x620,20
     DB Signature: Create time:04/19/2017 10:08:30.698 Rand:404286851 Computer:
         cbDbPage: 8192
           dbtime: 7221 (0x1c35)
            State: Dirty Shutdown
     Log Required: 12-110 (0xc-0x6e)
    Log Committed: 0-111 (0x0-0x6f)
   Log Recovering: 0 (0x0)
   Log Consistent: 0 (0x0)
  GenMax Creation: 04/25/2017 02:17:41.636
         Shadowed: Yes
       Last Objid: 9
     Scrub Dbtime: 0 (0x0)
       Scrub Date: 00/00/1900 00:00:00
     Repair Count: 0
      Repair Date: 00/00/1900 00:00:00.000
 Old Repair Count: 0
  Last Consistent: (0x6,A7,0)  04/19/2017 13:47:08.754
      Last Attach: (0x6,A9,268)  04/19/2017 16:46:01.086
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00.000
    Last ReAttach: (0x0,0,0)  00/00/1900 00:00:00.000
             Dbid: 1
    Log Signature: Create time:04/19/2017 10:08:30.198 Rand:632064612 Computer:
       OS Version: (6.2.9200 SP 0 NLS ffffffff.ffffffff)

Previous Full Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000

Previous Incremental Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000

Previous Copy Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000

Previous Differential Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000

Current Full Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000

Current Shadow copy backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000

     cpgUpgrade55Format: 0
    cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0

       ECC Fix Success Count: none
   Old ECC Fix Success Count: none
         ECC Fix Error Count: none
     Old ECC Fix Error Count: none
    Bad Checksum Error Count: none
Old bad Checksum Error Count: none

  Last checksum finish Date: 00/00/1900 00:00:00.000
Current checksum start Date: 00/00/1900 00:00:00.000
      Current checksum page: 0

  Database Header Flush Signature: Create time:00/00/1900 00:00:00.000 Rand:0 Computer:
 Flush Map Header Flush Signature: Create time:00/00/1900 00:00:00.000 Rand:0 Computer:


Operation completed successfully in 0.203 seconds.
esentutl /mk epc.chk

Extensible Storage Engine Utilities for Microsoft(R) Windows(R)
Version 10.0
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
      Checkpoint file: D:\CUT\BufferedOperation\epc.chk

      LastFullBackupCheckpoint: (0x0,0,0)
      Checkpoint: (0xC,A0,0)
      DbConsistency: (0xC,A0,0)
      FullBackup: (0x0,0,0)
      FullBackup time: 00/00/1900 00:00:00.000
      IncBackup: (0x0,0,0)
      IncBackup time: 00/00/1900 00:00:00.000
      Signature: Create time:04/19/2017 10:08:30.198 Rand:632064612 Computer:
      Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers)
          (     on,    250,   2048,   1024,   1024,   2048,   1024,2147483647)
      1 D:\CUT\BufferedOperation\PersistentDictionary.edb LogOff VerOn RW
        dbtime: 63262 (0-63262)
        objidLast: 9
        Signature: Create time:04/19/2017 10:08:30.698 Rand:404286851 Computer:
        MaxDbSize: 0 pages
        Last Attach: (0x6,A9,268)
        Last Consistent: (0x6,A7,0)

Operation completed successfully in 0.62 seconds.