用.NET做过企业级系统的大哥们请进

>>>>不过，这样的Server好像承受能力不强，经常莫名其妙的死掉，看看EventViewer里有什么错误信息
>>> zhehui(小慧) ....WellKnownObjectMode.Singleton那程序的scalability也完蛋了

to saucer(思归) :
主要的麻烦就是事件日志里面没有出现任何异常，哎！

to zhehui(小慧) ：
我们做的是电信的系统，代码太多了，可能拷贝不过来
但是，就Host而言，关键的代码就那么一句：
RemotingConfiguration.Configure("Host.config");
其他都是一些出错处理的代码。

what is in the Host.Config? start other objects, right? what are those objects?

Here is the Host.config:<configuration>
  <system.runtime.remoting>
    <application name="MetaDataService">
      <service>
    <wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.MetaDataService.BizMetaDataRemoting.ProdTemplatecnfgRemoting, Timeson.TOS.BuildingBlocks.MetaDataService.BizMetaDataRemoting" objectUri="ProdTemplatecnfgRemoting.rem" />
    <wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.MetaDataService.BizMetaDataRemoting.ServiceTemplateRemoting, Timeson.TOS.BuildingBlocks.MetaDataService.BizMetaDataRemoting" objectUri="ServiceTemplateRemoting.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.Common.StaticsTableRemoting, Timeson.TOS.BizFramework.COMLib.Common" objectUri="StaticsTableRemoting.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.MetaDataService.BizMetaDataRemoting.ResourceRemoting, Timeson.TOS.BuildingBlocks.MetaDataService.BizMetaDataRemoting" objectUri="ResourceRemoting.rem" />
    <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.Remoting.BizAccept.BizAcceptMgmt, Timeson.TOS.BizFramework.Remoting.BizAccept" objectUri="BizAcceptMgmt.rem" />
    <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.Remoting.BizAccept.BizAcceptQuery, Timeson.TOS.BizFramework.Remoting.BizAccept" objectUri="BizAcceptQuery.rem" />
    <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.Remoting.BizAccept.BizAcceptStatQuery, Timeson.TOS.BizFramework.Remoting.BizAccept" objectUri="BizAcceptStatQuery.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.BizObjects.OrderMgmt.AccessWorkFlowCache, Timeson.TOS.BizFramework.BizObjects.OrderMgmt" objectUri="AccessWorkFlowCache.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.OrderMgmt.WorkSheetAMgnt, Timeson.TOS.BizFramework.COMLib.OrderMgmt" objectUri="WorkSheetAMgnt.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.OrderMgmt.WorkSheetAMgntUpdate, Timeson.TOS.BizFramework.COMLib.OrderMgmt" objectUri="WorkSheetAMgntUpdate.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.OrderMgmt.BusinesOrderAMgnt, Timeson.TOS.BizFramework.COMLib.OrderMgmt" objectUri="BusinesOrderAMgnt.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.OrderMgmt.BakeNumOrderAMgnt, Timeson.TOS.BizFramework.COMLib.OrderMgmt" objectUri="BakeNumOrderAMgnt.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.OrderMgmt.AssignNumberOrderAMgnt, Timeson.TOS.BizFramework.COMLib.OrderMgmt" objectUri="AssignNumberOrderAMgnt.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.OrderMgmt.CheckOrderAMgnt, Timeson.TOS.BizFramework.COMLib.OrderMgmt" objectUri="CheckOrderAMgnt.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.OrderMgmt.PCWorkOrderAMgnt, Timeson.TOS.BizFramework.COMLib.OrderMgmt" objectUri="PCWorkOrderAMgnt.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.OrderMgmt.FinishOrderAMgnt, Timeson.TOS.BizFramework.COMLib.OrderMgmt" objectUri="FinishOrderAMgnt.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.OrderMgmt.DataCheckOrderAMgnt, Timeson.TOS.BizFramework.COMLib.OrderMgmt" objectUri="DataCheckOrderAMgnt.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.OrderMgmt.ReturnOrderAMgnt, Timeson.TOS.BizFramework.COMLib.OrderMgmt" objectUri="ReturnOrderAMgnt.rem" />
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.COMLib.TOSSWorkOrder.AutoWorkOrder, Timeson.TOS.BizFramework.COMLib.TOSSWorkOrder" objectUri="AutoWorkOrder.rem"/>
    <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.Remoting.OrderMgmt.WorkOrderRemoting,Timeson.TOS.BizFramework.Remoting.OrderMgmt" objectUri="WorkOrderRemoting.rem"/>
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.Remoting.OrderMgmt.WorkFlowRemoting, Timeson.TOS.BizFramework.Remoting.OrderMgmt" objectUri="WorkFlowRemoting.rem"/>
        <wellknown mode="SingleCall" type="Timeson.TOS.BizFramework.BizObjects.OrderMgmt.AccessWorkFlowCache, Timeson.TOS.BizFramework.BizObjects.OrderMgmt" objectUri="AccessWorkFlowCache.rem"/>

<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.Remoting.UniversalAA.OrganizationManager, Timeson.TOS.BuildingBlocks.Remoting.UniversalAA" objectUri="OrganizationManager.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.Remoting.UniversalAA.UserManager, Timeson.TOS.BuildingBlocks.Remoting.UniversalAA" objectUri="UserManager.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.Remoting.UniversalAA.AuthorityAuthorization, Timeson.TOS.BuildingBlocks.Remoting.UniversalAA" objectUri="AuthorityAuthorization.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.Remoting.UniversalAA.FigureAuthorization, Timeson.TOS.BuildingBlocks.Remoting.UniversalAA" objectUri="FigureAuthorization.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.Remoting.UniversalAA.FunctionOperationManager, Timeson.TOS.BuildingBlocks.Remoting.UniversalAA" objectUri="FunctionOperationManager.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.Remoting.UniversalAA.OperationEntityAAManager, Timeson.TOS.BuildingBlocks.Remoting.UniversalAA" objectUri="OperationEntityAAManager.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.Remoting.UniversalAA.OperationEntityManager, Timeson.TOS.BuildingBlocks.Remoting.UniversalAA" objectUri="OperationEntityManager.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.Remoting.UniversalAA.RoleManager, Timeson.TOS.BuildingBlocks.Remoting.UniversalAA" objectUri="RoleManager.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.Remoting.UniversalAA.AddrUnitManager, Timeson.TOS.BuildingBlocks.Remoting.UniversalAA" objectUri="AddrUnitManager.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.Remoting.UniversalAA.TerritoryManager, Timeson.TOS.BuildingBlocks.Remoting.UniversalAA" objectUri="TerritoryManager.rem" />
<wellknown mode="SingleCall" type="Timeson.TOS.BuildingBlocks.Remoting.UniversalAA.DataAuthorization, Timeson.TOS.BuildingBlocks.Remoting.UniversalAA" objectUri="DataAuthorization.rem" />
      </service>
      <channels>
        <channel port="8008" ref="tcp">
<serverProviders>
<formatter ref="binary" typeFilterLevel="Full" />
</serverProviders>
</channel>
      </channels>
    </application>
  </system.runtime.remoting>
</configuration>

请各位老大帮忙分析。
现在同时连接的客户端数量大概在200左右。
Host Crash的频率大概是每24小时一次。请各位一定帮忙。

可以用http协议，让IIS来接收请求，毕竟IIS专业一些。库数存取用ADO吗？在COM+中能使用ADO.net吗？如果是，效率怎么样？

to pxsoftcsdn：
数据库用的是ADO.NET（Oracle），COM+当然能够使用ADO.NET，效率还不错。不过，这个跟协议相关吗？

是不是com+的问题，如事务没处理好？

由Remoting对象来处理客户端和COM+服务的连接听起来是个不错的方法
受益了

原来看过一个bug报告，说remoting+com+方式时，若传递byte数组时，会出问题（还没有补丁）。
还有一个是，server端不能用这种读config文件的方式运行，这样对象好象不能销毁（占内存越来越多）；若直接在代码中公布对象则可避免这个问题。希望对你有帮助，也希望解决后能告诉我解决方法。

不过，这样的Server好像承受能力不强，经常莫名其妙的死掉，
------------------------------------------------------是死机吗？还是其他？

to EricHxy(龙真) :
你按我的意见做过测试吗？

TO junqiang(上帝，宽恕我吧) :
如果“直接在代码中公布对象”，那么我们的端口变化就要改程序了？而且，如果增加什么组件，那么HOST程序就要修改了！而且，现在也不允许我们这个大规模的改动，因为我们的系统已经上线了。非常感谢你的关心。

to EricHxy(龙真) :
如果你的程序是因为内存耗尽而死的话，我估计可能是由于在配置文件中公布的原因。如果你没有别的方法的话，改为直接在程序中公布对象也不是不可行。端口变化或增减组件就重新编译程序好的，因为代码很少，所有修改和维护也很方便，不会引入bug。当然若能通过别的更的方法解决当然更好。祝你好运，现在你先要定位是remoting server的问题或是com+的问题。

看了你的配置文件，应该没有什么问题
但是SingleCall调用过多（真的有必要？），那么请问所有的远程对象涉及到调用非托管资源的有多少？有没有手动释放非托管资源？？？（文件或者数据库的访问？）
死机是因为内存消耗太大吗？做一下24h测试,观测内存变化。再请问一下，你在Remoting里是如何调用COM+服务器上的组件的？调用过后有没有释放资源，COM+客户端对于.NET来说也是非托管资源。或者你的Remotint Server是做到COM+里的？
把你的系统架构详细的说一下

to qimini(循序渐进)：
非常感谢。不过，我要问一个菜鸟问题：我如何判断是内存耗尽而死？
还有，托管资源、非托管资源又是什么含义？

我们程序的基本架构是这样的：
客户端（包括WinForm和ASP.NET）调用Remoting，Remoting调用底层的COM+组件，以支持事务。然后COM+会调用一些一般的DLL来实现。数据库的访问没有直接调用ADO.NET，而是自己实现了一个简单的数据访问层，以实现对Oracle数据库（表、存储过程等）的一致访问。

按照你的说法，数据连接是封装在COM+中的?
那么现在你的Remote Server和COM+ Server是同一台机器吗？还有COM+是用什么语言写的---.NET吗？* 关于托管和非托管资源见timmy的解释http://expert.csdn.net/Expert/TopicView1.asp?id=2214138* 关于内存。你可以监测在不同数量的用户做不同动作时内存的变化,COM+组件管理器有对事务执行情况实行监测的功能 '开始/管理工具/组件服务/事务统计‘ 结合‘任务管理器’

to qimini(循序渐进):
没错，我们的数据访问层是作为一个COM+组件在被调用，他的每一个方法都会跟数据库建立连接，然后调用完成之后释放连接，以防止程序员忘记释放数据库的连接。所有代码都是用C#写的。非常感谢您的帮忙。

你的先确定问题的所在。监测服务器性能确定瓶口（当然如果你的代码没错的话），修改方式就行了。
你给的问题太粗了，网上很难判断。看你的回答，你对Net不熟，你这么问问题是解决不了问题的。你的找个懂的人，现场测试才行。

那么在Remoting 中是如何调用COM+的？贴段代码出来,以确定问题是出在COM+上还是Remoting上

我们的系统开始是用COM＋的，性能测试时，发现缓冲池满了COM＋服务器就死掉了，于是我们改造，Remoting做分布式计算，MTS或者数据库事务保证分布式事务，性能能有2－4倍的提高，从不停服务。COM＋就是垃圾

TO qimini(循序渐进) :下面是我们Remotinig组件的一个方法，而
SaveHelper是一个COM+组件。
public int SaveTerritory(ref Territory oTerritory)
{
#if DEBUG
SecurityHelper.DebugMessage("TerritoryManager.SaveTerritory Invoked");
#endif
Init(false);
SaveHelper saveProxy = new SaveHelper();
return saveProxy.SaveTerritory(sh,ref oTerritory);
}

to iamafrog(我是青蛙) ：
我接触.NET确实不久，从5月份才开始学习.NET，所以对很多东西都不了解。但是，这是一个跟Microsoft合作的项目，所以我们学习得还是比较快。但是，这段时间Mircosoft的工程师不在，才想到让大家帮忙解决问题的。
希望各位尽量帮忙分析，谢谢大家。

TO EricHxy(龙真) :
你的问题我也爱莫能助了，建议自己再检查检查。

调试易

用.NET做过企业级系统的大哥们请进

解决方案 »