Several services are released on HP UNIX, the WebLogic version is 12c, and the server is often 100% (multiple CPUs are 100%). The status of the current process is analyzed, both in the GC. The phenomenon is that CPU usage is up and down.
Then the weblogic down to 10g, redeploy the system, the CPU is down, presumably the server and WebLogic incompatible.
To open the WebLogic console interface:
Server--Check the service-to-the- muxer class: weblogic.socket.NTSocketMuxer instead of: Weblogic.socket.DevPollSocketMuxer
As per bug 18178560, WebLogic Server provides a non-blocking IO muxer implementation as the default Muxer configuration. On 12.1.2 or after, non-blocking IO muxer is default implementation of Muxer. In the default configuration, Muxerclass is set to "Weblogic.socket.NIOSocketMuxer".
Native Muxers and Java muxer is old and deprecated. Bug 18178560 also suggests that switching to the native muxer could improve performance on some platforms like Windows
Native muxers use platform-specific Native binaries to read data from sockets. The majority of all platforms provide some mechanism to poll a sockets for data. For example, Unix systems with the poll system call and the Windows architecture uses completion ports. Native Muxers provide superior scalability because they implement a non-blocking thread model. When a native muxer was used, the server creates a fixed number of threads dedicated to reading incoming requests.
Currently it is just deprecated which means it's still supported at this point in time and may isn't is in the future to EN Able these muxers, Muxer class name needs to being explicitly configured in Muxerclass.
Solaris/hp-ux Native Muxer:weblogic.socket.DevPollSocketMuxer
POSIX Native Muxer:weblogic.socket.PosixSocketMuxer
Windows Native Muxer:weblogic.socket.NTSocketMuxer
WebLogic 12C running CPU on HP UNIX 100%