locked
VB.Net Service uses excessive CPU Time RRS feed

  • Question

  • I am using VB.Net 2008. I created an application that I want to be able to run stand-alone or as a service. This works fine. I used the "Service" project in VB to create the service. However, when I launch the application as a service, it takes a huge amount of CPU as compared to when I launch it standalone. The stand-alone version and Service version run the same code. The statistics from Task Manager are:

    Metric                Stand-Alone             Service
    CPU Time                0:00:34              0:03:01
    Mem Usage               26,244               32,952
    Page Faults               98,711               89,691
    Handles                         100                  136
    Threads                           5                       9
    GDI Ojbects                    43                     41
    I/O Reads                   1,146                1,161
    I/O Writes                     594                   758
    I/O Other                    6,089                6,148
    I/O Reads Bytes    5,794,083          5,790,634
    I/O Writes Bytes        24,807              28,833
    I/O Other Bytes       387,720             349,606

    As you can see the only metric really out of sync is the CPU time. Does anyone have any idea why this is happening or give me the correct search keywords to find answers on the web?
    Thursday, June 4, 2009 5:35 PM

Answers

  • Hello Rick,

     

    Thank you for your post!  I would suggest posting your question in the '.NET Framework Developer Center > .NET Development Forums' located here:  http://social.msdn.microsoft.com/Forums/en-US/category/netdevelopment


    Have a great day!

    Thanks!


    SachinW Tier 2 Application Support Server and Tools Online Engineering Live Services Team
    • Proposed as answer by SachinW Thursday, June 4, 2009 8:18 PM
    • Marked as answer by SachinW Friday, September 4, 2009 8:10 AM
    Thursday, June 4, 2009 8:18 PM

All replies

  • Hello Rick,

     

    Thank you for your post!  I would suggest posting your question in the '.NET Framework Developer Center > .NET Development Forums' located here:  http://social.msdn.microsoft.com/Forums/en-US/category/netdevelopment


    Have a great day!

    Thanks!


    SachinW Tier 2 Application Support Server and Tools Online Engineering Live Services Team
    • Proposed as answer by SachinW Thursday, June 4, 2009 8:18 PM
    • Marked as answer by SachinW Friday, September 4, 2009 8:10 AM
    Thursday, June 4, 2009 8:18 PM
  • Net services though appearing the same are not run the same by the OS. Usually as a service they are throttled so to speak. But you say, wait, throttled, its using more. Well kind of, there is the wrapper used by the service to behave as a service and that adds to it and the OS is going to set it at a different memory high water mark. Let me explain: 

    In general when the OS runs an application it tries to determine how much memory is being used. It will allocate more memory for the application that what the application currently needs. The reason for that is, to allocate/deallocate memory is a cpu intensive operation. Why parallel what the app needs when it can reside in a pool of memory which will allow it, the app, to expand and contract with no interference from the operating system. Saves on cycles.

    What the developer sees is a high water mark for memory. If the system is not stressed, the system will not reclaim any memory and keep the high water mark. There are many posts in this forum where the users say, processing done, memory cleaned up but the OS still shows my app at memory point X, when it should be memory point M (lower). Winform users report the same but if one minimizes the app, suddenly the mem usage reported drops to that M level. That is done by design. Minimizing suggests that an app doesn't need the memory for it will not be interacting with the user and the OS will reclaim the point. If its not a winform and the OS is not stressed, the app stays at the high water mark of X.

    I believe you get the idea. By your list I surmise you are using the taskmanager to report this which is fine, but to really examine in perfmon the "Private Bytes" of an application, that is a true indicator of actual memory used and not what the OS has allocated. If that value steadly increases, one has a memory leak.

    Read up on it here for Private Bytes and others on memory managagement, yes I know you are not reporting a leak, but just for reporting.

    CLR Inside Out: Investigating Memory Issues -- MSDN Magazine, November 2006
    Debug Leaky Apps: Identify And Prevent Memory Leaks In Managed Code -- MSDN Magazine, January 2007
    Download details: Debug Diagnostic Tool v1.1
    Joe Duffy's Weblog (Dispose, Finalization, and Resource Management)

    HTH GL
    William Wegerson (www.OmegaCoder.Com)
    Friday, June 5, 2009 11:51 AM