这个devnev.exe好像是VS的进程吧,不是单纯的wcf的进程,这个占用100+MB我觉得很正常啊

解决方案 »

  1.   

    第一个是宿主进程,传输100000条数据会增加200+的开销,5000000的数据有1.多G的开销,而且不会自动释放,继续调用wcf会报内存泄漏的异常。
      

  2.   

    第一个是宿主进程,传输100000条数据会增加200+的开销,5000000的数据有1.多G的开销,而且不会自动释放,继续调用wcf会报内存泄漏的异常。
    那就是你WCF的程序写的有问题.
    WCF没释放你得去找WCF的原因啊
    想在外部解决,除非你每次调用完WCF将它关掉,下次调用的时候再启动.
      

  3.   

    "如果用DataTable就不会发生这种问题,怎么回事呢?"
    说明再将DataTable改成byte[ ]的过程中哪里没处理好
      

  4.   

    第一个是宿主进程,传输100000条数据会增加200+的开销,5000000的数据有1.多G的开销,而且不会自动释放,继续调用wcf会报内存泄漏的异常。
    那就是你WCF的程序写的有问题.
    WCF没释放你得去找WCF的原因啊
    想在外部解决,除非你每次调用完WCF将它关掉,下次调用的时候再启动.
    每次调用完之后是有关闭的,如果是wcf自己测试序列化之后,内存有关闭的,不知道为什么调用之后关闭了,但是还保持着连接
      

  5.   

    你确定是因为保持着连接,而不是你获取到的数据一直在内存里没有释放?
    查看一下WCF是以什么方式获取数据的,获取到的数据存放在哪里了,处理完数据又干什么了?
      

  6.   

    wcf return 回数据之后,不会自己释放占用着内存的byte[]吗
      

  7.   

     closeTimeout="00:00:10" receiveTimeout="00:00:10"   刚增加该配置,以为10秒超时,强制断开,没效果,出现的情况是
    宿主进程自己调用方法进行序列化成byte[]内存可以自己释放,但是给winformn调用有开始returne byte[]的话,winform接收完byte[]处理完成之后有关闭对wcf的调用,但是宿主进程还是一直站着几百M的内存,所以wcf本身的序列化可能是不存在问题,推测是出在传输时占用内存进行传输,但是传输后内存又不释放
      

  8.   

    传送完大数据,你自己加上GC.Collect(),回收内存试试。
      

  9.   

    我尝试下调用完之后提供接口对服务器进行system.gc.collect();
      

  10.   

    增加了对外释放内存接口,确实可以释放宿主进程的内存,只是不知道为什么会内存泄漏,wcf有这么弱吗?
      

  11.   

    缓存池并不是内存泄漏,是为了内存的复用而常驻内存。
    是否释放?何时释放?如何释放?都是一些扩展策略。至于WCF是否支持某些释放策略我就不清楚了。