在服务器上执行多个可执行文件 [英] Executing multiple executables on a server

查看:97
本文介绍了在服务器上执行多个可执行文件的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

你好,



我开发了一个可以处理字符串的应用程序。它唯一能做的就是从数据库处理字符串并将结果提交回来。如果我们计算CPU时间并且我正在计算cpu时间,它会在大约200ms内处理1个作业(1个字符串):

1.在作业开始前获得处理器时间

Hello there,

I have developed an app that does process strings. The only thing it does - takes the string from database processes it and submits the results back. So it processes 1 job (1 string) in about 200ms if we count CPU time and I am counting the cpu time like this:
1. get processor time before job starts

Process.GetCurrentProcess().TotalProcessorTime.TotalMilliseconds



2.作业完成后我得到相同的处理器时间并减去这些值。 />


现在 - 如果我在一台服务器上启动100个这样的可执行文件,一切都会好的。服务器(48核心机器)的总CPU消耗约为10%,单个作业的平均CPU时间(所有100个进程的平均值)约为200-300ms。



当我启动200个这样的可执行文件时,奇怪的事情开始发生(2倍以上,因此预计服务器的总体CPU使用率约为20%)。但是...... CPU使用率在服务器上开始上升到100%,单个作业的平均CPU时间变为~2000-4000 ms(10-20倍)。

知道这里发生了什么吗?可能是代码中存在缺陷吗?或者它是服务器进程管理的东西。



服务器是Windows Server 2008 R2标准。但它也似乎也发生在srv 2012上。

该应用程序是用.net 4.5编写的(但我用4.6.1构建它来测试 - 仍然是200个进程的问题)



提前感谢任何提示或建议。



br,

gii



我尝试了什么:



检查了c#代码应用程序似乎没有任何会导致CPU泄漏。在win srv 2008和2012上测试过。

向上帝祈祷......但没有回答......


2. I get the same processor time after job is complete and subtract the values.

Now - everything is fine if I start 100 of these executables on a single server. The total cpu consumption of a server (48 core machine) is about 10% and the average CPU time for single job to be processed (average through all 100 processes) is about 200-300ms.

The oddness start to happen when I start 200 of these executables (2 times more so would expect the overall CPU usage of the server to be about 20%). But... The CPU usage starts to ramp up to 100% on the server and the average CPU time for single job to be processed becomes ~2000-4000 ms (10-20 times more).
Any idea what is happening here? can it be that there is flaw in the code? Or is it something with server process management.

The server is Windows Server 2008 R2 standard. But it also seems to be happening on srv 2012 too.
The app is written with .net 4.5 (but I've build it with 4.6.1 to test too - still a prolem with 200 processes)

Thanks in advance for any hints or suggestions.

br,
gii

What I have tried:

checked the c# code of the app there seems to be nothing that would result in CPU leaking. tested on win srv 2008 and 2012.
prayed to god... but did not answer...

推荐答案

我不知道有你的代码或你的服务器,但这里有一些事情要检查根据你的帖子和我的评论回复:



1)你有很多(大概是活跃的) )进程运行。与 AppDomain 或线程相比,进程是一件昂贵的事情。当在线程之间切换时,如果新线程来自不同的进程(很可能有200个活动进程),内核也必须切换地址空间。在任务管理器中,选中查看>显示内核时间,查看该内核使用了多少处理器%。考虑使用 AppDomain 来查看您的问题是否已解决。如果没有,请考虑线程(池)方法。通常我使用规则processes< AppDomains< threads。选择符合您要求的列表中最高的,因为越低,产生的开销越大。



2)减少进程数量也可以让你捆绑SQL语句并批量执行它们。可能不是你的问题,除非你在同一台机器上运行200个进程和数据库,但仍然是一个很好的奖励。



3)调试并确定内存使用情况,确保不同的进程不会争夺资源(例如数据库访问),只需一次性地为您的代码提供一个好的衡量标准。从50%到10%,在100到100%,阈值为120-125,直到你跳到100%听起来好像你正在处理超载系统本身的某些部分,但你永远不知道。



4)字符串可以是丑陋的东西来集体处理。可能只是您的程序无效地处理它们并且咀嚼内存或强制GC频繁运行。 [ ^ ]是一个很好的基础入门字符串在C#中处理。
I don't have your code or your server but here are some things to check based on your post and response to my comment:

1) You have quite a lot of (presumably active) processes running. A process is an expensive thing compared to an AppDomain or a thread. When switching between threads the kernel also has to switch address spaces if the new thread is from a different process (highly likely with 200 active processes). In the Task Manager check "View > Show Kernel Times" and see how much of that processor % is being used for the kernel. Consider using AppDomains to see if your problem is resolved. If not, consider a threading (pool) approach. Generally I use the rule "processes < AppDomains < threads". Choose the highest on the list that meets your requirements because the lower you go the more overhead is incurred.

2) Reducing the number of processes would also allow you to bundle up SQL statements and batch execute them. Probably not your issue unless you're running the 200 processes and the DB on the same machine but a nice bonus nonetheless.

3) Debug and determine memory usage, ensure different processes aren't fighting over resources (DB access for example), and just give your code a once-over for good measure. From 5-10% at 50 to 10% at 100 with a threshold of 120-125 until you jump to 100% sounds like you're dealing with overloading some part of the system itself but you never know.

4) Strings can be ugly things to handle en masse. It may simply be that your program is handling them inefficiently and chewing up memory or forcing the GC to run frequently. This[^] is a good basic primer on how strings are handled in C#.


这篇关于在服务器上执行多个可执行文件的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆