- Community Home
- >
- Servers and Operating Systems
- >
- HPE ProLiant
- >
- ProLiant Servers (ML,DL,SL)
- >
- ML350e G8 Much slower than ML350 G5 it replaced
ProLiant Servers (ML,DL,SL)
1753795
Members
7086
Online
108799
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-24-2014 09:47 AM
06-24-2014 09:47 AM
Re: ML350e G8 Much slower than ML350 G5 it replaced
I think the only way to know for sure is to check with performance monitor on the physical server itself.
I don't remember if Windows still handles system interrupts with just the first core. If there's a lot of disk thrashing that could account for it. Check out "Process Explorer" from Sysinternals or just the Windows task manager and see if the CPU usage is from a particular program or from interrupt handling.
I'm thinking that in newer versions of Windows, it can handle interrupts on multiple CPUs, smartly, so I don't know if that would explain it, but at least using one of those tools you can see exactly what process is munching away on CPU cycles. If the interrupts are all being caused by the same subsystem, then I guess it would tend to keep the interrupts on the same core. Whenever I've seen high interrupt usage, it's caused by something doing disk thrashing, like the stupid Windows Media Library thing scanning all my videos and songs.
It does seem odd that it's only using 100% of one core. Unless it's "sticky" (affinity) to a particular core, even if it's not a multi-threading app the OS would still spread the load over all the CPU's more or less equally.
For instance, VCRM (version control repository manager) is non-threading and when it's doing catalog validation it will use 100% of a single thread, but on a multi-core system the OS still spreads that out over all the cores. If you have 4 cores, the overall usage is 25% and the graphs for individual cores will show peaks and valleys as the OS slices up the load.
I don't remember if Windows still handles system interrupts with just the first core. If there's a lot of disk thrashing that could account for it. Check out "Process Explorer" from Sysinternals or just the Windows task manager and see if the CPU usage is from a particular program or from interrupt handling.
I'm thinking that in newer versions of Windows, it can handle interrupts on multiple CPUs, smartly, so I don't know if that would explain it, but at least using one of those tools you can see exactly what process is munching away on CPU cycles. If the interrupts are all being caused by the same subsystem, then I guess it would tend to keep the interrupts on the same core. Whenever I've seen high interrupt usage, it's caused by something doing disk thrashing, like the stupid Windows Media Library thing scanning all my videos and songs.
It does seem odd that it's only using 100% of one core. Unless it's "sticky" (affinity) to a particular core, even if it's not a multi-threading app the OS would still spread the load over all the CPU's more or less equally.
For instance, VCRM (version control repository manager) is non-threading and when it's doing catalog validation it will use 100% of a single thread, but on a multi-core system the OS still spreads that out over all the cores. If you have 4 cores, the overall usage is 25% and the graphs for individual cores will show peaks and valleys as the OS slices up the load.
- « Previous
-
- 1
- 2
- Next »
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP