Showing posts with label solaris. Show all posts
Showing posts with label solaris. Show all posts

Thursday, 2 May 2013

Solaris CPU info


This script is courtesy of Oracle and was taken from
https://blogs.oracle.com/mandalika/entry/solaris_show_me_the_cpu


#!/bin/bash

/usr/bin/kstat -m cpu_info | egrep "chip_id|core_id|module: cpu_info" > /var/tmp/cpu_info.log

nproc=`(grep chip_id /var/tmp/cpu_info.log | awk '{ print $2 }' | sort -u | wc -l | tr -d ' ')`
ncore=`(grep core_id /var/tmp/cpu_info.log | awk '{ print $2 }' | sort -u | wc -l | tr -d ' ')`
vproc=`(grep 'module: cpu_info' /var/tmp/cpu_info.log | awk '{ print $4 }' | sort -u | wc -l | tr -d ' ')`

nstrandspercore=$(($vproc/$ncore))
ncoresperproc=$(($ncore/$nproc))

speedinmhz=`(/usr/bin/kstat -m cpu_info | grep clock_MHz | awk '{ print $2 }' | sort -u)`
speedinghz=`echo "scale=2; $speedinmhz/1000" | bc`

echo "Total number of physical processors: $nproc"
echo "Number of virtual processors: $vproc"
echo "Total number of cores: $ncore"
echo "Number of cores per physical processor: $ncoresperproc"
echo "Number of hardware threads (strands or vCPUs) per core: $nstrandspercore"
echo "Processor speed: $speedinmhz MHz ($speedinghz GHz)"

# now derive the vcpu-to-core mapping based on above information #

echo -e "\n** Socket-Core-vCPU mapping **"
let linenum=2

for ((i = 1; i <= ${nproc}; ++i ))
do
        chipid=`sed -n ${linenum}p /var/tmp/cpu_info.log | awk '{ print $2 }'`
        echo -e "\nPhysical Processor $i (chip id: $chipid):"

        for ((j = 1; j <= ${ncoresperproc}; ++j ))
        do
                let linenum=($linenum + 1)
                coreid=`sed -n ${linenum}p /var/tmp/cpu_info.log | awk '{ print $2 }'`
                echo -e "\tCore $j (core id: $coreid):"

                let linenum=($linenum - 2)
                vcpustart=`sed -n ${linenum}p /var/tmp/cpu_info.log | awk '{ print $4 }'`

                let linenum=(3 * $nstrandspercore + $linenum - 3)
                vcpuend=`sed -n ${linenum}p /var/tmp/cpu_info.log | awk '{ print $4 }'`

                echo -e "\t\tvCPU ids: $vcpustart - $vcpuend"
                let linenum=($linenum + 4)
        done
done

rm /var/tmp/cpu_info.log
It's also useful to verify that this agrees with what you see in /usr/sbin/psrinfo -pv

Friday, 15 February 2013

Solaris TCP Monitoring

netstat -sP tcp - Show TCP stats 
tcpListenDrop and tcpListenDropQ0 should be zero

If either are above zero you need to increase  tcp_conn_req_max_q and tcp_conn_req_max_q0 respectively, for example ... /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q = 1200

ndd -get /dev/tcp \? - Tells you what TCP params are available

/usr/sbin/ndd -get /dev/tcp tcp_conn_req_max_q - Gets the value of tcp tcp_conn_req_max_q

Below is an extract from a good Oracle blog (https://blogs.oracle.com/terrygardner/entry/solaris_tcp_ip_parameters_tcp)

tcp_conn_req_max_q and tcp_conn_req_max_q0 are associated with the maximum number of requests that can be accepted per IP address per port. tcp_conn_req_max_q is the maximum number of incoming connections that can be accepted on a port. tcp_conn_req_max_q0 is the maximum number of “half-open” TCP connections that can exist for a port. The parameters are separated in order to allow the administrator to have a mechanism to block SYN segment denial of service attacks on Solaris.
The default value for tcp_conn_req_max_q on Solaris 8 and Solaris 9 is 128, the default value for tcp_conn_req_max_q0 on Solaris 8 and Solaris 9 is 4096. These defaults may be too low for a non-trivial web server, messaging server or directory server installation or any server that expects more than 128 concurrent accepts or 4096 concurrent half-opens. There is only one way to determine appropriate values, though. Read on!
It is pretty simple really: never change these parameters unless connections are refused because the values are too low. The only way to determine this empirically is to use ‘netstat –s | fgrep –i listendrop’. If tcpListenDrop is non-zero, increase tcp_conn_req_max_q. If tcpListenDropQ0 is non-zero, increase tcp_conn_req_max_q0.
Hang on a moment: maybe it is not quite that simple. Increasing tcp_conn_req_max_q to a value that is too high can result in a system that is vulnerable to SYN segment denial of service attacks. Solaris IP is brilliantly executed in this respect due to the separation of these parameters. Increase tcp_conn_req_max_q in increments of 256. Use tcp_conn_req_max_q0 to increase the number of “half-open” TCP connections that are available. If a software cannot service connections quick enough, increasing tcp_conn_req_max_q0 can prevent clients from not being able to connect at all. Connections from clients remain in the “half-open” state until the server software can process them.
The defaults on Solaris 8 and Solaris 9 are too low for a system that processes more than 128 incoming TCP connections or 4096 “half-open” TCP connection at a time. Change these parameters with great care. Do not change them unless tcpListenDrop or tcpListenDropQ0 are non-zero, or you expect the number of connections to change

 

Thursday, 20 December 2012

Looking at Solaris JVM heap

Carry out a a full heap dump
  • jmap -d64 -dump:format=b,file=/tmp/heap.hprof  <PID>

Read the heap dump
  • jhat  -port <port> -J-mx2048m /tmp/heap.hprof
  • Point a browser at the host you are running jhat on using the port specified by -port above