locked
My program hangs until SetProcessWorkingSetSize is called or app. minimized RRS feed

  • Question

  • Greetings

    Full description of the problem you can see here: http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=16535
    My program generates "phantom" thread (neither one of my threads, nor one of async completion threads) after a few hours of normal work, and that thread consumes 100% of CPU time until program window is minimized or a call landed to

    Process process = Process.GetCurrentProcess(); SetProcessWorkingSetSize(process.Handle,-1,-1);
     


    If someone knows what problem leads to this behaivor - please, help me..
    Friday, June 17, 2005 7:51 AM

Answers

  • [just linking in old threads]

    http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=16535

    http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=16564

    This problem may be a bit difficult to diagnose from the symptoms you listed.  One suggestion from the other posts was to use CLR Profiler.  You mentioned having trouble with it before, have you had any luck since?

    Have you spent time running through the app with a debugger?

    Specifically, you mentioned strange behavior:

    "While this "hang" all of server features continue to work correctly, but very slow. Strage thing happens when I minimize and then restore server's console window - in a few seconds "fantom" thread suddenly disappears and server operates normally for next several hours.."

    Have you tried running diagnostics/debugging on the app specifically at the point where that occurs?

     

     

    Tuesday, September 6, 2005 4:57 PM

All replies

  • [just linking in old threads]

    http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=16535

    http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=16564

    This problem may be a bit difficult to diagnose from the symptoms you listed.  One suggestion from the other posts was to use CLR Profiler.  You mentioned having trouble with it before, have you had any luck since?

    Have you spent time running through the app with a debugger?

    Specifically, you mentioned strange behavior:

    "While this "hang" all of server features continue to work correctly, but very slow. Strage thing happens when I minimize and then restore server's console window - in a few seconds "fantom" thread suddenly disappears and server operates normally for next several hours.."

    Have you tried running diagnostics/debugging on the app specifically at the point where that occurs?

     

     

    Tuesday, September 6, 2005 4:57 PM
  • Greetings.
    It has been a long time. Almost year has passed.

    So, the main part of my problem still actual as never. Hangups are now in past, but after some worktime, "phantom" thread is spawned across my server's threads. That thread is nor IOCP callback thread, nor managed thread. It does not affects program execution, except for CPU usage. That thread processor time is almost equal to it's execution time.
    It appears only on heavy server load (more than 200 online players) and even with 50 players server is not debuggable - it uses more than 500Mb of memory and attached debuger slows down whole app and makes it almost unplayable. But even when I attach to server, that has nasty thread spawned, I'm not able to debug it - VS says "There is no code for that location" and stack trace shows no managed entry points in that thread. Some third-party programs allowed me to get execution function name - it is ReleaseFusionInterfaces.

    Sometimes I'm able to do something, that increases or decreases normal worktime, but the problem never disappears absolutelly.
    For example, when I've created buffer pool for byte[] arrays and tried to return buffer to pool after some operations, it moved from 30-40m to 2-3h.

    It looks like that "panthom" thread is a some sort of GC memory defragmenter helper and something at allocated memory makes it mad.

    I've created simple code for enumerating my app threads. While "phantom" thread livetime it looks like that:

     Thread ID State Start Address Start Time Running Time Processor Time Cpu usage Average cpu usage
    3224Wait0x7C82B5C719:16:50.982000d 00h 45m 57s 892ms00d 00h 00m 24s 828ms0%0,9%
    1804Wait0x7C82B5BB19:16:51.044500d 00h 45m 57s 830ms00d 00h 00m 00s 000ms0%0%
    3848Wait0x7C82B5BB19:16:51.044500d 00h 45m 57s 830ms00d 00h 00m 09s 421ms0,2%0,34%
    1252Wait0x7C82B5BB19:16:51.138300d 00h 45m 57s 736ms00d 00h 00m 00s 000ms0%0%
    1856Wait0x7C82B5BB19:16:51.185200d 00h 45m 57s 689ms00d 00h 00m 00s 000ms0%0%
    1808Running0x7C82B5BB19:16:51.185200d 00h 45m 57s 689ms00d 00h 01m 21s 265ms1,76%2,95%
    1300Ready0x7C82B5BB19:16:51.200800d 00h 45m 57s 673ms00d 00h 01m 20s 453ms2,52%2,92%
    1260Ready0x7C82B5BB19:16:51.200800d 00h 45m 57s 673ms00d 00h 01m 24s 031ms1,27%3,05%
    2332Ready0x7C82B5BB19:16:51.200800d 00h 45m 57s 673ms00d 00h 01m 18s 328ms1,81%2,84%
    944Wait0x7C82B5BB19:16:51.200800d 00h 45m 57s 673ms00d 00h 01m 21s 281ms1,98%2,95%
    928Wait0x7C82B5BB19:16:55.013300d 00h 45m 53s 861ms00d 00h 00m 00s 000ms0%0%
    900Wait0x7C82B5BB19:16:55.028900d 00h 45m 53s 845ms00d 00h 00m 00s 062ms0%0%
    2408Wait0x7C82B5BB19:16:55.028900d 00h 45m 53s 845ms00d 00h 00m 00s 000ms0%0%
    2132Wait0x7C82B5BB19:18:37.201500d 00h 44m 11s 673ms00d 00h 00m 02s 562ms0%0,1%
    1200Wait0x7C82B5BB19:18:37.201500d 00h 44m 11s 673ms00d 00h 00m 05s 625ms0,02%0,21%
    2208Ready0x7C82B5BB19:18:37.217100d 00h 44m 11s 657ms00d 00h 00m 37s 875ms0,83%1,43%
    2528Ready0x7C82B5BB19:18:37.217100d 00h 44m 11s 657ms00d 00h 19m 30s 656ms18,6%44,15%
    3088Wait0x7C82B5BB19:19:30.248700d 00h 43m 18s 626ms00d 00h 00m 00s 000ms0%0%
    708Wait0x7C82B5BB19:21:32.140100d 00h 41m 16s 734ms00d 00h 00m 03s 687ms0%0,15%
    2856Wait0x7C82B5BB19:22:20.781000d 00h 40m 28s 093ms00d 00h 00m 02s 984ms0%0,12%
    3612Wait0x7C82B5BB19:22:22.890400d 00h 40m 25s 984ms00d 00h 00m 02s 375ms0,02%0,1%
    408Wait0x7C82B5BB19:22:36.234200d 00h 40m 12s 640ms00d 00h 00m 02s 890ms0%0,12%
    2188Wait0x7C82B5BB19:26:03.657400d 00h 36m 45s 217ms00d 00h 00m 02s 687ms0,05%0,12%
    3564Wait0x7C82B5BB19:26:50.439000d 00h 35m 58s 435ms00d 00h 00m 02s 796ms0,46%0,13%
    2180Wait0x7C82B5BB19:27:34.267400d 00h 35m 14s 607ms00d 00h 00m 02s 234ms0,07%0,11%
    3392Wait0x7C82B5BB19:29:31.361900d 00h 33m 17s 512ms00d 00h 00m 02s 484ms0%0,12%
    3148Wait0x7C82B5BB19:29:32.158800d 00h 33m 16s 715ms00d 00h 00m 02s 640ms0,05%0,13%
    3896Wait0x7C82B5BB19:34:14.160600d 00h 28m 34s 714ms00d 00h 00m 02s 640ms0%0,15%
    2724Wait0x7C82B5BB19:39:35.443900d 00h 23m 13s 430ms00d 00h 00m 01s 343ms0%0,1%
    1504Wait0x7C82B5BB19:40:39.553700d 00h 22m 09s 321ms00d 00h 00m 01s 890ms0,05%0,14%
    792Wait0x7C82B5BB19:40:45.897500d 00h 22m 02s 977ms00d 00h 00m 01s 656ms0,44%0,13%
    3996Wait0x7C82B5BB19:42:48.476400d 00h 20m 00s 398ms00d 00h 00m 01s 156ms0,02%0,1%
    3856Wait0x7C82B5BB19:45:55.352600d 00h 16m 53s 522ms00d 00h 00m 01s 343ms0%0,13%
    2736Wait0x7C82B5BB19:46:49.102900d 00h 15m 59s 771ms00d 00h 00m 01s 500ms0,12%0,16%
    2244Wait0x7C82B5BB19:47:01.446700d 00h 15m 47s 427ms00d 00h 00m 01s 437ms0%0,15%
    3232Wait0x7C82B5BB19:51:31.511000d 00h 11m 17s 363ms00d 00h 00m 00s 921ms0,07%0,14%
    3820Wait0x7C82B5BB19:57:03.731800d 00h 05m 45s 142ms00d 00h 00m 00s 281ms0,05%0,08%
    2392Wait0x7C82B5BB19:58:54.920100d 00h 03m 53s 954ms00d 00h 00m 00s 234ms0%0,1%
    3140Wait0x7C82B5BB20:00:59.983400d 00h 01m 48s 891ms00d 00h 01m 09s 609ms65,35%63,93%
    Hightlighted row is "phantom' thread

    I don't think it is possible to reproduce that problem in simple app. Maybe I should try to create small async socket server and simple client to jabber it with thousands of packets per second.
    Currently, I'm rewriting some parts (BufferPool, ByteQueue, etc.) to MC++ with explicit buffer creation and deletion with allocated/released counters. It does not helps to solve my problem, but at least I can be shure, that there is no memory leak at atomic operations.

    Thursday, May 4, 2006 6:06 PM