Method Server Core Usage

[TomU]

Is there a way to configure a method server to use more than one CPU core? I have a 4-core environment but no matter how heavily I load the method server, or for how long, it will never exceed 25% total CPU usage, aka 1 core. Is there a way to allow this process to be multi-threaded and leverage the other cores? I have to believe this would significantly improve performance. This is for WC 9.1. Thanks.

Tom U.

[cc-2]

Hi

not sure about this one but what about having 2 method servers ? Surely they will use different cores and share the load.

We currently have 2 method servers, it has improved the performance but I cannot tell you if they share the same core or not

Best regards

[ddemay]

While the java langage supports multiple threads, current java runtime environment does not support multiple cores. Java 8 to address this but PTC plans no support until release after 10.2...X-30 I believe.

If you could use VM's (or similar like LPARS) and dedicate cores that way and then cluster windchill virtually even if same hardware. You may get something out of it. This is because you would assign multiple JRE's to isolated specific cores. This is actually why I am a fan of physical but multiple less powerful machines clustered.

The person to answer that would be Steve Dertien.




Sent from my Verizon Wireless 4G LTE Smartphone

[TomU]

We are currently running two method servers, one regular and one background, but when refreshing a large workspace or performing searches only the regular method server is affected. The background method server just sits idle.

Do you know if Windchill will split a single request across multiple method servers? Reading the documentation makes me think 'no'. If that's the case then adding more method servers probably won't help.

From the Windchill Advanced Deployment Guide:
"When a request is made on a method server, the current server checks to determine if any thresholds have been surpassed. If so, a wt.method.ServerLoadExceptions is thrown from this server and is caught by the remote method server. Within the exception is a reference to the next server. The remote method server then redirects the request to that server."

Tom U.

[BenLoosli]

Multiple method servers will help as the second one can process another person’s request while the first one is working. I have always had 2 foreground and 1 background and users ranging from 15 to 50. As for cores, when I had access to the server, I used to set the affinity of the JAVA processes, one to a core on an 8 core machine. The Java processes of multiple method servers could start on the same core so separating them helped some.

[TomU]

Similar to my other reply, will a single request be processed by more than one node in the cluster? From my limited knowledge of clusters and load balancing, it does not seem so. I am not dealing with high request volume, I am dealing with long response times for single requests. Here’s what I’m currently seeing

0:00 Refresh workspace triggered on client PC
0:01 Method server java process jumps to 25% CPU usage (full load for single core)
0:01 SQL Server process ramps up CPU usage to around 25%, then bounces up and down between 0% and 25% (full load for single core)
0:03 End of data transmission from client PC (total PC transmission time - 3 seconds)
<waiting>
0:37 SQL Server process drops back to 0% CPU usage (total SQL server processing time - 36 seconds)
0:40 Method server java process drops back to 0% CPU usage (total method server processing time - 39 seconds)
0:40 Beginning of data transmission from server back to client PC
0:40 Local PC web browser process jumps to 25% CPU usage (full load for single core)
0:42 End of data transmission from server to client PC (total server transmission time - 2 seconds)
0:48 PAGE DISPLAYS
0:49 Local PC web browser process returns to 0% CPU usage (total web browser display the data time - 9 seconds)

Basically, it takes Windchill 40 seconds to return the data requested and another 8 seconds (or so) for the web browser to format and display the information.

Tom U.

[jessh]

1 thread of execution will not use more than 1 core.

Most single-user operations are single threaded.

Thus having multiple cores primarily ensures that multiple operations
can be processed simultaneously (whether on the behalf of one user or
several) with little impact on performance (as compared to these
operations having to share 1 core).

Why are single-operations mostly single threaded?

* It takes additional thought and code to distribute an operation
across multiple threads (particularly an operation which must all be
part of one database transaction).
* It takes still more thought to do this such that a single operation
won't overtly hog resources when the server is serving multiple
requests from multiple users.

--
Jess Holle

[jessh]

The current Java environment certainly supports multiple cores. Java
and the OS certainly distribute Java threads across the available CPU cores.

It's just difficult to break a single operation up into multiple threads
of execution to make optimal use of multiple cores.

Java 8 will make this somewhat easier, but only somewhat. It will still
requires substantive thought and skill to gain substantial benefit from
multiple cores within a single operation -- without choking other
operations when the same server is asked to produces numerous operations
at once. Java 8 is also not due until 2014 at this point -- and for any
Windchill version to leverage it would require a stable Java 8 available
on all Windchill platforms very early in its development cycle.

You also mention dedicating/locking/assigning cores, which is a separate
matter to help the scheduler make better use of the cores at hand.

--
Jess Holle

[jessh]

Splitting a single request across multiple processes (and doing so such
that the result markedly improves performance) is even more difficult
than splitting it across multiple threads -- again, this is especially
so if the request is to be within a single database transaction.

Multiple method servers serve primarily to:

1. Get around any scalability barriers encountered within a single JVM
process (e.g. in locks, GC, etc).
2. Provide higher availability in the case of a method server failure
3. Allow separation of disparate types of loads, e.g. foreground
requests and background queue tasks

[jessh]

This is not to say that effort has not been made to leverage multiple
threads and thus multiple cores to process a single request.

Doing this well, i.e. so that the cores are used to good effect and
overall multi-user scalability is not adversely impacted, is
non-trivial, though.

Such parallel processing is thus rather limited in scope at this point.

I certainly can't speak for my employer [I'm just an engineer :-)], but
I have to assume that if customers emphasize their desire for more
effort in this area than other enhancement areas PTC would take note of
this.

--
Jess Holle