- This topic has 3 replies, 1 voice, and was last updated 6 years, 11 months ago by
.
-
Posts
-
-
I guess the \”problem\” is that you’ve got everything on a single machine. Pipelines and orchestrations are often very CPU hungry, and so the behavior you’re seeing is to be expected. You’re debatching a huge file (lots of CPU), spawning many orchestrations (lots of CPU) and have the database working overtime to keep up (lots of CPU). So, there’s not really a registry tweak where you can say \”use less processing power\”, and you might have to accept the machine running hot during the 10-20 minutes or so of processing if you can’t segment out your processes a bit onto separate machines.
-
Good afternoon:
I have a process in BizTalk Server 2006 that consists of two orchestrations and a complex transform map that does many queries to my application database. Also, one of these orchestration is a little complex since it uses some expression shapes calling some external libraries written in C# and makes some calls to an FTP to download some files.
In fact, this process receives an XML file with over 16.000 items and by means of an XML disassembler into a custom pipeline, it makes over 16.000 instances of messages that will be processed by the orchestration I speak above. One of these libraries use
As this orchestration is running, the CPU usage reaches the 100% (really the values are between the 90 – 100 percent) until it finishes. I don’t know how to solve this problem since I’ve had a look at the SQL Server agents jobs, code utilized by the external libraries, databases, etc…, but with no success.
About the architecture BizTalk Server 2006 runs on, I must say that we have in the same machine (a Intel Xeon 3,20 GHZ with 3 GB RAM) all the BizTak Server databases, my application database (it’s not very heavy).
Have somebody ever had a problem like this? And if somebody has, how was it solved?
Thank you.
-
Thank you for your answer, rseroter, but my company wants to use this machine for running several processes simultaneously. So, if I have a process running on this machine that uses the whole CPU, BizTalk server probably has got some problem to run the second process, hasn’t it?
In fact, I don’t know what to do because I don’t think my company provides me another server to use for BizTalk, thus I have to be concentrated in solving this problem.
What do you think I could test?
-
-
-
acaf3h,
I would first try to find out where this utilization is coming, your xml disassembling or your C# assemblies or your sql server that is on the box.
First, take a look at your sql server. disregarding which databases you are using, go ahead and have your DBA make sure that the sql server is using a good amount of memory so that it doesnt choke with these large trasactions. I am no DBA but i do know that there is a specific switch in the ini file that allows sql server to use more memory that default. This may relieve your database and lower cpu and memory management.
Second, try creating a testing application that calls your C# assemblies and mimics the calls taken by the orchestration. If you do find that these applications are the problem, make sure that your orchestrations are long running, which will allow them to dehydrate while the assemblies are running, once again, freeing up some CPU. but all in all, spending a few hours optimizing that code may result in the best performance boost. make sure you arent using heavy data structures or really really big strings.
Third, capture one of those large XMLs and try manipulating it in your code. basically, get the file, invoke the disassembler and stress test it. I doubt this is the problem as ive had to deal with edi XML files which were 50M+ in size and hundreds of thousands of nodes deep. Biztalk 06 handles these quite well as they had an issue with this problem in 04
if the XML is the issue, give this a shot, create a third orchestration that recieves the xml and disassembles it into the individual instances. Im assuming you are invoking the disassembler in your orchestration since you are refering to it as a single instance. Anyway, have the \”disassembling\” orchestration push the results to the message box via a direct send port. Your processing orchestration will then subscribe to these and process them individually. Now, set each of these orchestrations on a seperate host and then fine tune the hosts to not over utilize your CPU.( they shouldnt by default, but you have a heavily loaded machine) this way, your processing orch will only spin up as many instances as allowed and start going through the \”smaller\” xml files. This will slow down through-put *in-theory* but if you are experiencing a slow down because of over utilization, it will be eliminated.But, in the end, i have to agree with rseroter, the box you are running on is over utilized. The best practice is to have your MSGbox and other db on another machine, because in consideration, you are running two seperate sever products on the same box. In the end, this may be the most cost-effective and quickest solution considering the amount of time needed to debug this issue. All in all, i hope you can find your culprit and i hope this insight will prove helpful.
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.