Unix TOP in Windows Servers?

[patrickchin2000]

Hi All,

I have a very easy time showing Windchill performance issueson unix/linux OS systems with multiple method servers (foreground and background). We have a Windows 2008 R2 server and I can't show CPU core # to process id (java process). With TOP in unix/linux, its pretty easy generate performance charts against process id to CPU core. We are having a tough time getting/find a monitor with the same simple mapping for our current Windows 2008 R2 64bit Windchill server. If we had this, it would be easy like Linux/unix, to show the business why there are performance issues with our Windows Windchill Server. PTC points me to their PTC dynatrace monitoring tool which does not have this basic functionailty mapping the java process id to CPU core and it's performance.

Everyone knows who has ever have any experience in Windchill that a java process can only run against 1 CPU core. If that process peaks at 100% CPU core #, Windchill has issues. It can be a single foreground or worse background method server. At the same time the overallCPU utilization is only 10% because the rest of the cores are not maxed at 100%.

Does anyone have a Unix Top monitor for Windows that monitors process id to a cpu core #? We tried the basic Windowstask manager and performance monitor. We even triedour ITtool called What's Up Gold. I haven't tried Appdynamics yet, but I'm open to options.

I know it would be so simple to move to Redhat linux, but that is not an option for meright now.

Thanks,

Patrick

[ChrisCollinson]

We use Process Explorer by Sysinternals



Think its part of the Windows Server Admin kit, and downloadable from
Microsoft

Best Regards

Chris Collinson
CAD Administrator

[patrickchin2000]

Thanks guys,

I tried Process Explorer by Sysinternals but it doesn't map the process id to the cpu core #. I know with top in unix/linux, we can create SAR graphical displays of process id against CPU core # with history and so forth. Thus, we can capture when the server is having issues.

[ddemay]

You wants sysinternals also makes ps commands available as command line tools. I install the whole package on windows to get tools like du. For ssh and if you really want top install a limited version of cygwin.


Sent from my Verizon Wireless 4G LTE Smartphone

[jessh]

Actually a Java process, including a method server can extensively
utilize numerous CPU cores. For a bad example, if one has a tight
infinite loop in some request handling code and multiple such requests
issued one can see clear evidence of multiple cores at 100% utilization
due to this bug.

Any given Java *thread* cannot utilize more than a single CPU. That's
not really just Java -- one native, OS-level thread cannot leverage more
than 1 CPU core.

Many requests are processed mostly or entirely by a single thread,
without any possibility of delegating to other threads. This
unfortunately limits how many CPU resources (in a system with idle CPUs)
can be applied to any given request -- but splitting a request's
processing across multiple threads in a robust, reliable and efficient
fashion is far from trivial, particularly when one starts with code
designed around the assumption that the request would be processed by a
single thread.

Multiple CPUs are certainly utilized for improved scaling under
concurrent load -- as each concurrent requests is handled by a separate
thread. Multiple CPUs are also of benefit in non-stop-the-world garbage
collection phases or even during a stop-the-world garbage collection
phase when parallel GC is used.

--
Jess Holle

[ddemay]

Spoke too soon forget about powershell and the mem command.


Sent from my Verizon Wireless 4G LTE Smartphone

[patrickchin2000]

Thanks Dave!

cygwin is a great idea and powershell and the mem command. I'll give thata try. Great idea to put a unix emulator on the Windows machine to get the desired monitoring results. As for Jess, yep, java process can jump from core to core based on completion of the thread. That's a given. But, that is exactly what I'm after is to monitor that process id the CPU core #. Most cases, a max cpu core# if there is only 1 java process (Windchill method server) can help with finding the root cause of the issue and demonstrate/educate to the business the cause of the issues. It is so much easier with TOP and unix monitoring tools.

[patrickchin2000]

According to Cygwin, you just need the

[jessh]

Ah, so what you're really saying is that in cases where performance is
really bad 1 JVM will tend to monopolize a CPU core -- not that 1 JVM
can't use (or monopolize) multiple cores, which is how I read your e-mail.

So you typically see a core max'ed out and then are left looking for the
guilty process.

I've often found myself looking at the opposite end of things -- what
are active request and method context threads and what are they doing.
From this data for instance, one can sometimes clearly see that the
%CPU usage for a time interval is 100/(# of CPUs) -- in which case the
thread in question is completely sapping a CPU in some overtly CPU
intensive code (e.g. a tight infinite loop).

That said, I'm a developer, not a system administrator. I've merely
found this instructive in some cases when I've had cause to look at
PTC's own ProjectLink deployment.

[patrickchin2000]

Hi Jess,

No worries,I'm just trying to show this case to mycompany which I've shown the same thing occur in many companies. I can see the issue occur in Windows process manager performance monitor but can't map the exact process id.

Not trying to diss ya man. You have always been a great help. Right now I'm looking for a very common issue in Windchill which I'm used to having a unix system to display it and you said it exactly. 1 JVM can kill the entire Windchill no matter how many cores you have because it maximizes 1 CPU core and can then tie up your database as well.

We have been in this business to long and need each other to make this product better.

[patrickchin2000]

Hi All,

Sometimes the most active request are not the culprit to the problems. The issues can originate from many potential sources:

• bad code (cutomized and OOTB)


• bad java version


• complexity in the query


• not enough jvms (method servers, tomcatsessions(flexpdm)) with too many required users sessions based on weight (CAD centric)
  
  
  
  • need more foreground
  
  
  • need more background
  
  


• not enough memory


• not enough CPU cores


• database issues
  
  
  
  • index required/not required
  
  
  • statistics
  
  
  • SQL Server not supported to multiple sessions to the same record
  
  
  • Oracle temp tablespace or SQL Server tempdb size and transaction loguncontrollable growth
  
  
  • patches
  
  


• OS


• Network and other dependent IT infrastructure (LAN/WAN,)


• Rate of Usage (Automated)


• Apache requires cluster


• SANappliance


• and finally not following PTC basic documentation for server sizing and configuration

Like a doctor, Iwould like to get alerted for a problematic issue at a specific point in time and the complete behavior of that process before I start looking at the overall body or average of all the patients. Symptoms be a result of a cascading effect in Windchill caused by an issue(s) of the ones mentioned above. Even the simpliest functions have a performance issue when the system is already bad state.

I'vebeen working with Windchill since 1998/1999 with the best DBAs, programmers, solution architects, system administrators with almost the entire suite of Windchill.It takes the whole team of these experts to make the product better. We have tocare more about the users/customers and how Windchill can help them in terms of business solutions and improving their current working environment with great performing systems.

[jessh]

Not to disagree here, but I wasn't talking about the "most active requests".

I'm talking about the precise requests and method contexts that are
active at the time when CPU usage, memory usage, response time, or other
indicators show there's a problem.

This certainly isn't everything -- but it can show if the requests users
are complaining about are all stuck waiting on a Java lock or on the
database or gobbling CPU time, for instance.

It's just another tool to shed light on the overall, complex problem.