如何在选定的计算机上查找 .NET 远程处理内存泄漏?
内存泄漏并不是在每台机器上都会发生,但在我工作的几台机器上确实发生过,并且在现场看起来接近 10%。
我有一个产品,它使用 Windows 服务来监视用户输入以启动警报,并与仅位于系统托盘中的可视应用程序配对,并允许用户进行配置更改。
我选择使用远程对象在两个进程之间共享配置信息。在服务中称为serviceConfig,在可视化应用中称为configData。该对象首先在服务器上创建,然后按如下方式进行远程处理:
try
{
InitializeComponent();
setAppInitDLL(thisDirectory);
serviceConfig = new serviceConfigData();
Regex getVersion = new Regex("Version=(?<ver>[^,]*)");
if (getVersion.IsMatch(Assembly.GetExecutingAssembly().FullName))
{
serviceConfig.Version = new Version(getVersion.Match(Assembly.GetExecutingAssembly().FullName).Result("${ver}").ToString());
}
// Create the server channel for remoting serviceConfig.
serverChannel = new TcpServerChannel(9090);
ChannelServices.RegisterChannel(serverChannel, false);
RemotingServices.Marshal(this.serviceConfig, "ServiceConfigData");
baseLease = (ILease)RemotingServices.GetLifetimeService(serviceConfig);
lock (Logger) { Logger.Write(String.Format("The name of the channel is {0}", serverChannel.ChannelName)); }
lock (Logger) { Logger.Write("Exiting Constructor"); }
}
catch (Exception ex)
{
lock (Logger) { Logger.Write(String.Format("Error in Constructor:{0}", ex.Message)); }
}
然后在可视应用程序中,我有一个连接使用的私有对象:
configData = (serviceConfigData)Activator.GetObject(typeof(serviceConfigData), "tcp://localhost:9090/ServiceConfigData");
在读取或写入该对象时,我有用于套接字异常和远程处理异常的 catch 语句,然后称此为同一个声明。
在大多数机器上,这不会泄漏内存,但在某些机器上,它泄漏得很快。工作中的所有机器都装有 .NET 3.5,其中一些是 XP,一些是 Vista。该问题只在XP机器上出现过,现场机器都是XP的。
我应该在哪里寻找任何想法,作为次要问题,我应该使用与此完全不同的东西吗?
The memory leak is not happening on every machine, but reliably on a couple at my work, and it's looking like close to 10% in the field.
I have a product that uses a Windows service to monitor user input to launch alerts, paired with a visual application that serves only to sit in the system tray, and allow the user to make configuration changes.
I chose to use a remoted object to share the configuration information between the two processes. In the service it is called serviceConfig, and in the visual application it is called configData. The object is created on the server first, and then remoted as follows:
try
{
InitializeComponent();
setAppInitDLL(thisDirectory);
serviceConfig = new serviceConfigData();
Regex getVersion = new Regex("Version=(?<ver>[^,]*)");
if (getVersion.IsMatch(Assembly.GetExecutingAssembly().FullName))
{
serviceConfig.Version = new Version(getVersion.Match(Assembly.GetExecutingAssembly().FullName).Result("${ver}").ToString());
}
// Create the server channel for remoting serviceConfig.
serverChannel = new TcpServerChannel(9090);
ChannelServices.RegisterChannel(serverChannel, false);
RemotingServices.Marshal(this.serviceConfig, "ServiceConfigData");
baseLease = (ILease)RemotingServices.GetLifetimeService(serviceConfig);
lock (Logger) { Logger.Write(String.Format("The name of the channel is {0}", serverChannel.ChannelName)); }
lock (Logger) { Logger.Write("Exiting Constructor"); }
}
catch (Exception ex)
{
lock (Logger) { Logger.Write(String.Format("Error in Constructor:{0}", ex.Message)); }
}
Then in the visual application I have a private object that I connect using:
configData = (serviceConfigData)Activator.GetObject(typeof(serviceConfigData), "tcp://localhost:9090/ServiceConfigData");
When reading or writing to this object, I have catch statements for Socket Exceptions and Remoting Exceptions which then call this same statement.
On most machines this works without leaking memory, but on some it leaks very quickly. All machines at work have .NET 3.5, some are XP, a couple are Vista. The problem has only been seen on XP machines, and the machines in the field are all XP.
Any ideas where I should be looking, and as a secondary question, should I be using something completely different from this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我的第一个想法是在您看到泄漏的机器上分析应用程序,例如 Red Gate 的内存分析器。
这比尝试猜测泄漏可能要可靠得多。
至于选择正确的技术,如果您的所有计算机都安装了 .NET 3.5,您可能需要考虑迁移到 WCF(主要是命名管道)来进行进程间通信。查看这篇 SO 帖子了解更多详细信息。 ..
My first thought would be to profile the application on the machines you're seeing the leak with something like Red Gate's Memory Profiler.
It'll be a lot more reliable than attempting to guess what the leak might be.
As for chosing the right technology, if all your machines will have .NET 3.5 installed you might want to consider migrating to WCF (primarily Named Pipes) for your inter-process communication. Check this SO post for more detail...