Pervasive
Sign in | Join | Help
in

Strange performance problem

Last post 07-14-2008 10:14 AM by Gordon. 4 replies.
Page 1 of 1 (5 items)
Sort Posts: Previous Next
  • 07-03-2008 4:23 AM

    Strange performance problem

    Hello,

    I'm investigating slowness of our application on a customer. Occasionally performance goes down and I have now made some analysis.

    When I was checking system file activity with filemonitor I noticed something strange.

    Filemonitor shows lines like this:

    0.00438503 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 602902528 Length: 4096
    0.00434042 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 602902528 Length: 4096
    0.00003010 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 601206784 Length: 4096
    0.00240580 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 599670784 Length: 4096
    0.00236809 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 599670784 Length: 4096
    0.00002494 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 597405696 Length: 4096
    0.00462524 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 600039424 Length: 4096
    0.00457764 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 600039424 Length: 4096
    0.00549872 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 263618560 Length: 4096
    0.00546089 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 263618560 Length: 4096
    0.00720133 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 110686208 Length: 4096
    0.00715204 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 110686208 Length: 4096
    0.00293421 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 593862656 Length: 4096
    0.00289351 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 593862656 Length: 4096
    0.00271713 ntdbsmgr.exe:9944 READ D:\Liinos6\Db\KH\VOSAL.DB SUCCESS Offset: 418287616 Length: 4096


    Why there is this double reading with the same filename and same offset sometimes? It seems that if there is only single read that it is up to 200 times faster than the double read. When this appears then the system is slow.

    This environment has the system cache on, if that matters.

    Client is using 9.1.20 version of Pervasive, I know that we might have to upgrade to 9.52.62.

    Or is this a file system issue?

    Pervasive settings are checked quite a few times and they are ok.

    All help would be greatly appreciated!

    Timo
  • 07-06-2008 3:09 AM In reply to

    Re: Strange performance problem

    I have now tested so far that in 9.1 when I turn on the system cache there will start to appear. Next I will upgrade to 9.52.62 to see if these are still there. Maybe this is just the way Pervasive works with the cache. Timo
  • 07-07-2008 10:05 AM In reply to

    Re: Strange performance problem

    When you turn on System Cache, do you turn off the PSQL engine's L2 cache by setting Max Microkernel Memory Usage to 0?  Typically, you only use one or the other of these settings.

    Linda

    Linda Anderson
    Pervasive Software, Support
  • 07-09-2008 12:03 AM In reply to

    Re: Strange performance problem

    Yes, I turn off the L2 cache. What is by the way difference between L1 and L2 cache, aren't they both in the same address space of the mtdbsmgr process and limited by 2G limit in Windows? Does it hurt if I for example define L1 cache to be 1350MB and leave L2 cache off and turn system cache on to use for example other 2G if there is for example 4G RAM on the server? I have seen on some servers that system cache is rather small and that there is lots of RAM free. Is there anything I could do to max out the windows system cache? Timo
  • 07-14-2008 10:14 AM In reply to

    • Gordon
    • Top 50 Contributor
    • Joined on 08-30-2007
    • Delft, The Netherlands
    • Posts 93

    Re: Strange performance problem

    On a dedicated PSQL server you will typically see low system cache usage when using default settings for PSQL. That's because you're bypassing it.

    Yes, L2 cache operates in user space and so the sum of PSQL + L1 + L2 + resources cannot exceed 2Gb. The difference between the two caches is that the engine will only work with pages stored in L1. With L2 enabled the cache mechanism will compress and push a "Least Recently Used" (LRU) page from L1 to the L2 cache where it may either be recovered to L1 or dropped entirely. Because L2 is in a compressed format it becomes very unlikely that System Cache could hold pages that are not readily available to PSQL already. It therefore just adds to overhead; i.e. less performance.

    Without L2 the LRU page will be dropped directly by L1 which will then revert to disk I/O if the page needs to be accessed again. In this case you do want System Cache to reduce actual disk access. You should see rapid increment of System Cache using this setting.

    1350Mb may be a bit over the top. This is because L1 may actually waste memory by holding multiple instances of the same page (shadow paging). Other issues may also rise with Windows memory management. There is no single optimum setting since this depends on too many variables, but commonly 800Mb would be a good starting point.

Page 1 of 1 (5 items)
© 2008 Pervasive Software Inc. All Rights Reserved.