Linux Recipes

  1. Generally, all CPU cores should not be consistently saturated. Check CPU 100 - idle% with tools such as vmstat, top, nmon, etc.
  2. Review snapshots of process activity using tools such as top, nmon, etc., and for the largest users of resources, review per thread activity using tools such as top -H -p $PID.
  3. Generally, swapping of program memory from RAM to disk should rarely happen. Check that current swapping is 0 with vmstat so/si columns and use tools such as vmstat or top and check if swap amount is greater than 0 (i.e. swapping occurred in the past).
  4. Consider using TuneD and applying the latency-performance, network-latency, throughput-performance, or network-throughput profile.
  5. Unless power consumption is important, change the CPU speed governors to performance.
  6. Unless power consumption is important, ensure processor boosting is enabled in the BIOS.
  7. Monitor TCP retransmissions with nstat -saz *Retrans* or netstat -s | grep -i retrans. Ideally, for LAN traffic, they should be 0.
  8. Monitor network interface packet drops, errors, and buffer overruns. Ideally, for LAN traffic, they should be 0.
  9. For systems with low expected usage of file I/O, set vm.swappiness=0 to reduce the probability of file cache driving program memory swapping.
  10. If there is extra network capacity and a node has extra CPU capacity, test permanently disabling TCP delayed acknowledgments using quickack 1.
  11. Review saturation, response time, and errors of input/output interfaces such as network cards and disks.
  12. If the operating system is running in a virtualized guest, review the configuration and whether or not resource allotments are changing dynamically. Review CPU steal time in tools such as vmstat, top, etc.
  13. Check if CPU is being throttled: grep nr_throttled /sys/fs/cgroup/cpu.stat
  14. Consider testing explicitly tuned TCP/IP network buffer sizes.
  15. Review CPU instructions per cycle and tune appropriately.
  16. For hosts with incoming LAN network traffic from clients using persistent TCP connection pools (e.g. a reverse HTTP proxy to an application server such as IHS/httpd to WAS), set net.ipv4.tcp_slow_start_after_idle=0 to disable reducing the TCP congestion window for idle connections.
  17. General operating system statistics and process (and thread) statistics should be periodically monitored and saved for historical analysis.
  18. Review sysctl -a for any uncommon kernel settings.
  19. If there are firewall idle timeouts between two hosts on a LAN utilizing a connection pool (e.g. between WAS and a database), consider tuning TCP keep-alive parameters.
  20. Linux on IBM Power CPUs:
    1. Test with the IBM Java parameter -Xnodfpbd
    2. Test with hardware prefetching disabled
    3. Test with idle power saver disabled
    4. Test with adaptive frequency boost enabled
    5. Test with dynamic power saver mode enabled
    6. Use 64-bit DMA adapter slots for network adapters
  21. Linux on IBM System z CPUs:
    1. Use QUICKDSP for production guests

For details, see the Linux chapter.