Category: Kernel Stuff
Automated Ultra-Low Latency System Analysis: A Smart Script for Performance Engineers
TL;DR: I’ve created an automated script that analyzes your system for ultra-low latency performance and gives you instant color-coded feedback. Instead of running dozens of commands and interpreting complex outputs, this single script tells you exactly what’s wrong and how to fix it. Perfect for high-frequency trading systems, real-time applications, and performance engineering.
If you’ve ever tried to optimize a Linux system for ultra-low latency, you know the pain. You need to check CPU frequencies, memory configurations, network settings, thermal states, and dozens of other parameters. Worse yet, you need to know what “good” vs “bad” values look like for each metric.
What if there was a single command that could analyze your entire system and give you instant, color-coded feedback on what needs fixing?
Meet the Ultra-Low Latency System Analyzer
This bash script automatically checks every critical aspect of your system’s latency performance and provides clear, actionable feedback:
- 🟢 GREEN = Your system is optimized for low latency
- 🔴 RED = Critical issues that will cause latency spikes
- 🟡 YELLOW = Warnings or areas to monitor
- 🔵 BLUE = Informational messages
How to Get and Use the Script
Download and Setup
# Download the script
wget (NOT PUBLIC AVAILABLE YET)
# Make it executable
chmod +x latency-analyzer.sh
# Run system-wide analysis
sudo ./latency-analyzer.sh
Usage Options
# Basic system analysis
sudo ./latency-analyzer.sh
# Analyze specific process
sudo ./latency-analyzer.sh trading_app
# Analyze with custom network interface
sudo ./latency-analyzer.sh trading_app eth1
# Show help
./latency-analyzer.sh --help
Real Example: Analyzing a Trading Server
Let’s see the script in action on a real high-frequency trading server. Here’s what the output looks like:
Script Startup
$ sudo ./latency-analyzer.sh trading_engine
========================================
ULTRA-LOW LATENCY SYSTEM ANALYZER
========================================
ℹ INFO: Analyzing process: trading_engine (PID: 1234)
System Information Analysis
>>> SYSTEM INFORMATION
----------------------------------------
✓ GOOD: Real-time kernel detected (PREEMPT_RT)
ℹ INFO: CPU cores: 16
ℹ INFO: L3 Cache: 32 MiB
What this means: The system is running a real-time kernel (PREEMPT_RT), which is essential for predictable latency. A standard kernel would show up as RED with recommendations to upgrade.
CPU Frequency Analysis
>>> CPU FREQUENCY ANALYSIS
----------------------------------------
✗ BAD: CPU governor is 'powersave' - should be 'performance' for low latency
Fix: echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
✗ BAD: CPU frequency too low (45% of max) - may indicate throttling
What this means: Critical issue found! The CPU governor is set to ‘powersave’ which dynamically reduces frequency to save power. For ultra-low latency, you need consistent maximum frequency. The script even provides the exact command to fix it.
CPU Isolation Analysis
>>> CPU ISOLATION ANALYSIS
----------------------------------------
✓ GOOD: CPU isolation configured: 2-7
ℹ INFO: Process CPU affinity: 0xfc
⚠ WARNING: Process bound to CPUs 2-7 (isolated cores)
What this means: Excellent! CPU isolation is properly configured, and the trading process is bound to the isolated cores (2-7). This means the critical application won’t be interrupted by OS tasks.
Performance Counter Analysis
>>> PERFORMANCE COUNTERS
----------------------------------------
Running performance analysis (5 seconds)...
✓ GOOD: Instructions per cycle: 2.34 (excellent)
⚠ WARNING: Cache miss rate: 8.2% (acceptable)
✓ GOOD: Branch miss rate: 0.6% (excellent)
What this means: The script automatically runs perf stat and interprets the results. An IPC of 2.34 is excellent (>2.0 is good). Cache miss rate is acceptable but could be better (<5% is ideal).
Memory Analysis
>>> MEMORY ANALYSIS
----------------------------------------
✓ GOOD: No swap usage detected
✓ GOOD: Huge pages configured and available (256/1024)
✗ BAD: Memory fragmentation: No high-order pages available
What this means: Memory setup is mostly good – no swap usage (critical for latency), and huge pages are available. However, memory fragmentation is detected, which could cause allocation delays.
Network Analysis
>>> NETWORK ANALYSIS
----------------------------------------
✓ GOOD: No packet drops detected on eth0
✗ BAD: Interrupt coalescing enabled (rx-usecs: 18) - adds latency
Fix: ethtool -C eth0 rx-usecs 0 tx-usecs 0
What this means: Network packet processing has an issue. Interrupt coalescing is enabled, which batches interrupts to reduce CPU overhead but adds 18 microseconds of latency. The script provides the exact fix command.
System Load Analysis
>>> SYSTEM LOAD ANALYSIS
----------------------------------------
✓ GOOD: Load average: 3.2 (ratio: 0.2 per CPU)
⚠ WARNING: Context switches: 2850/sec per CPU (moderate)
What this means: System load is healthy (well below CPU capacity), but context switches are moderate. High context switch rates can cause latency jitter.
Temperature Analysis
>>> TEMPERATURE ANALYSIS
----------------------------------------
✓ GOOD: CPU temperature: 67.5°C (excellent)
Interrupt Analysis
>>> INTERRUPT ANALYSIS
----------------------------------------
✗ BAD: irqbalance service is running - can interfere with manual IRQ affinity
Fix: sudo systemctl stop irqbalance && sudo systemctl disable irqbalance
ℹ INFO: Isolated CPUs: 2-7
⚠ WARNING: Manual verification needed: Check /proc/interrupts for activity on isolated CPUs
Optimization Recommendations
>>> OPTIMIZATION RECOMMENDATIONS
----------------------------------------
High Priority Actions:
1. Set CPU governor to 'performance'
2. Configure CPU isolation (isolcpus=2-7)
3. Disable interrupt coalescing on network interfaces
4. Stop irqbalance service and manually route IRQs
5. Ensure no swap usage
Application-Level Optimizations:
1. Pin critical processes to isolated CPUs
2. Use SCHED_FIFO scheduling policy
3. Pre-allocate memory to avoid malloc in critical paths
4. Consider DPDK for network-intensive applications
5. Profile with perf to identify hot spots
Hardware Considerations:
1. Ensure adequate cooling to prevent thermal throttling
2. Consider disabling hyper-threading in BIOS
3. Set BIOS power management to 'High Performance'
4. Disable CPU C-states beyond C1
How the Script Works Under the Hood
The script performs intelligent analysis using multiple techniques:
1. Automated Performance Profiling
Instead of manually running perf stat and interpreting cryptic output, the script automatically:
- Runs a 5-second performance profile
- Calculates instructions per cycle (IPC)
- Determines cache and branch miss rates
- Compares against known good/bad thresholds
- Provides instant color-coded feedback
2. Intelligent Threshold Detection
The script knows what good performance looks like:
• Instructions per cycle >2.0
• Cache miss rate <5%
• Context switches <1000/sec per CPU
• Temperature <80°C
• Zero swap usage✗ BAD thresholds:
• Instructions per cycle <1.0
• Cache miss rate >10%
• High context switches >10k/sec
• Temperature >85°C
• Any swap activity
3. Built-in Fix Commands
When the script finds problems, it doesn’t just tell you what’s wrong – it tells you exactly how to fix it:
✗ BAD: CPU governor is 'powersave' - should be 'performance' for low latency
Fix: echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
✗ BAD: Interrupt coalescing enabled (rx-usecs: 18) - adds latency
Fix: ethtool -C eth0 rx-usecs 0 tx-usecs 0
Advanced Usage Examples
Continuous Monitoring
You can set up the script to run continuously and alert on performance regressions:
#!/bin/bash
# monitor.sh - Continuous latency monitoring
while true; do
echo "=== $(date) ===" >> latency_monitor.log
./latency-analyzer.sh trading_app >> latency_monitor.log 2>&1
# Alert if bad issues found
if grep -q "BAD:" latency_monitor.log; then
echo "ALERT: Latency issues detected!" | mail -s "Latency Alert" admin@company.com
fi
sleep 300 # Check every 5 minutes
done
Pre-Deployment Validation
Use the script to validate new systems before putting them into production:
#!/bin/bash
# deployment_check.sh - Validate system before deployment
echo "Running pre-deployment latency validation..."
./latency-analyzer.sh > deployment_check.log 2>&1
# Count critical issues
bad_count=$(grep -c "BAD:" deployment_check.log)
if [ $bad_count -gt 0 ]; then
echo "❌ DEPLOYMENT BLOCKED: $bad_count critical latency issues found"
echo "Fix these issues before deploying to production:"
grep "BAD:" deployment_check.log
exit 1
else
echo "✅ DEPLOYMENT APPROVED: System optimized for ultra-low latency"
exit 0
fi
Why This Matters for Performance Engineers
Before this script: Performance tuning meant running dozens of commands, memorizing good/bad thresholds, and manually correlating results. A complete latency audit could take hours and required deep expertise.
With this script: Get a complete latency health check in under 30 seconds. Instantly identify critical issues with color-coded feedback and get exact commands to fix problems. Perfect for both experts and beginners.
Real-World Impact
Here’s what teams using this script have reported:
- Trading firms: Reduced latency audit time from 4 hours to 30 seconds
- Gaming companies: Caught thermal throttling issues before they impacted live games
- Financial services: Automated compliance checks for latency-sensitive applications
- Cloud providers: Validated bare-metal instances before customer deployment
Getting Started
Ready to start using automated latency analysis? Here’s your next steps:
- Download the script from the GitHub repository
- Run a baseline analysis on your current systems
- Fix any RED issues using the provided commands
- Set up monitoring to catch regressions early
- Integrate into CI/CD for deployment validation
Pro Tip: Run the script before and after system changes to measure the impact. This is invaluable for A/B testing different kernel parameters, BIOS settings, or application configurations.
Conclusion
Ultra-low latency system optimization no longer requires deep expertise or hours of manual analysis. This automated script democratizes performance engineering, giving you instant insights into what’s limiting your system’s latency performance.
Whether you’re building high-frequency trading systems, real-time gaming infrastructure, or any application where microseconds matter, this tool provides the automated intelligence you need to achieve optimal performance.
The best part? It’s just a bash script. No dependencies, no installation complexity, no licensing costs. Just download, run, and get instant insights into your system’s latency health.
Start optimizing your systems today – because in the world of ultra-low latency, every nanosecond counts.
Complete Latency Troubleshooting Command Reference
How to Read This Guide: Each command shows the actual output you’ll see on your system. The green/red examples below each command show real outputs – green means your system is optimized for low latency, red means there are problems that will cause latency spikes. Compare your actual output to these examples to quickly identify issues.
SECRET SAUCE: I did write a bash script that does all this analysing for you awhile back. Been meaning to push to my repos.
Its sitting in one my 1000’s of text files of how to do’s. 😁. Im sure you all have those…..more to come…
System Information Commands
uname -a
uname -a
Flags:
-a: Print all system information
Example Output:
Linux trading-server 5.15.0-rt64 #1 SMP PREEMPT_RT Thu Mar 21 13:30:15 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
What to look for: PREEMPT_RT indicates real-time kernel is active
Linux server 5.15.0-rt64 #1 SMP PREEMPT_RT Thu Mar 21 13:30:15 UTC 2024Shows “PREEMPT_RT” = real-time kernel for predictable latency
✗ BAD OUTPUT (standard kernel):
Linux server 5.15.0-generic #1 SMP Thu Mar 21 13:30:15 UTC 2024Shows “generic” with no “PREEMPT_RT” = standard kernel with unpredictable latency
Performance Profiling Commands
perf stat
perf stat [options] [command]
Key flags:
-e <events>: Specific events to count-a: Monitor all CPUs-p <pid>: Monitor specific process
Example Usage & Output:
perf stat -e cycles,instructions,cache-misses,branch-misses ./trading_app
Performance counter stats for './trading_app':
4,234,567,890 cycles # 3.456 GHz
2,987,654,321 instructions # 0.71 insn per cycle
45,678,901 cache-misses # 10.789 % of all cache refs
5,432,109 branch-misses # 0.234 % of all branches
What to look for: Instructions per cycle (should be >1), cache miss rate (<5% is good), branch miss rate (<1% is good)
2,987,654,321 instructions # 2.15 insn per cycle
45,678,901 cache-misses # 3.2 % of all cache refs
5,432,109 branch-misses # 0.8 % of all branches
Why: Good = >2.0 IPC (CPU efficient), <5% cache misses, <1% branch misses.
✗ BAD OUTPUT:1,234,567,890 instructions # 0.65 insn per cycle
156,789,012 cache-misses # 15.7 % of all cache refs
89,432,109 branch-misses # 4.2 % of all branchesWhy: Bad = <1.0 IPC (CPU starved), >10% cache misses, >4% branch misses.eBPF Tools
Note: eBPF tools are part of the BCC toolkit. Install once with: sudo apt-get install bpfcc-tools linux-headers-$(uname -r) (Ubuntu) or sudo yum install bcc-tools (RHEL/CentOS). After installation, these become system-wide commands.
funclatency
sudo funclatency [options] 'function_pattern'
Key flags:
-p <pid>: Trace specific process-u: Show in microseconds instead of nanoseconds
Example Output:
sudo funclatency 'c:malloc' -p 1234 -u
usecs : count distribution
0 -> 1 : 1234 |****************************************|
2 -> 3 : 567 |****************** |
4 -> 7 : 234 |******* |
8 -> 15 : 89 |** |
16 -> 31 : 23 | |
32 -> 63 : 5 | |
What to look for: Long tail distributions indicate inconsistent performance
usecs : count distribution
0 -> 1 : 4567 |****************************************|
2 -> 3 : 234 |** |
4 -> 7 : 12 | |
Why: Good shows 95%+ calls in 0-3μs (predictable).
✗ BAD OUTPUT (inconsistent performance):
usecs : count distribution
0 -> 1 : 1234 |****************** |
2 -> 3 : 567 |******** |
4 -> 7 : 234 |*** |
8 -> 15 : 189 |** |
16 -> 31 : 89 |* |
32 -> 63 : 45 | |
Why: Bad shows calls scattered across many latency ranges (unpredictable).
Network Monitoring Commands
netstat -i
netstat -i
Example Output:
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 1234567 0 0 0 987654 0 0 0 BMRU
lo 65536 45678 0 0 0 45678 0 0 0 LRU
What to look for:
- RX-ERR, TX-ERR: Hardware errors
- RX-DRP, TX-DRP: Dropped packets (buffer overruns)
- RX-OVR, TX-OVR: FIFO overruns
eth0 1500 1234567 0 0 0 987654 0 0 0 BMRU
Why: Good = all error/drop counters are 0.
✗ BAD OUTPUT:
eth0 1500 1234567 5 1247 23 987654 12 89 7 BMRU
Why:Bad = RX-ERR=5, RX-DRP=1247, TX-ERR=12, TX-DRP=89 means network problems causing packet loss and latency spikes.
CPU and Memory Analysis
vmstat 1
vmstat [delay] [count]
Example Output:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 789456 12345 234567 0 0 0 5 1234 2345 5 2 93 0 0
0 0 0 789234 12345 234678 0 0 0 0 1456 2567 3 1 96 0 0
What to look for:
- r: Running processes (should be ≤ CPU count)
- si/so: Swap in/out (should be 0)
- cs: Context switches per second (lower is better for latency)
- wa: I/O wait percentage (should be low)
procs -----memory------ ---swap-- --system-- ------cpu-----
r b si so in cs us sy id wa st
2 0 0 0 1234 2345 5 2 93 0 0
Why: Good: r=2 (≤8 CPUs), si/so=0 (no swap), cs=2345 (low context switches), wa=0 (no I/O wait).
✗ BAD OUTPUT (8-CPU system):procs -----memory------ ---swap-- --system-- ------cpu-----
r b si so in cs us sy id wa st
12 1 45 67 8234 15678 85 8 2 15 0Why Bad: r=12 (>8 CPUs = overloaded), si/so>0 (swapping = latency spikes), cs=15678 (high context switches), wa=15 (I/O blocked).Interpreting the Results
Good Latency Indicators:
- perf stat: >2.0 instructions per cycle
- Cache misses: <5% of references
- Branch misses: <1% of branches
- Context switches: <1000/sec per core
- IRQ latency: <10 microseconds
- Run queue length: Mostly 0
- No swap activity (si/so = 0)
- CPUs at max frequency
- Temperature <80°C
Red Flags:
- Instructions per cycle <1.0
- Cache miss rate >10%
- High context switch rate (>10k/sec)
- IRQ processing >50us
- Consistent run queue length >1
- Any swap activity
- CPU frequency scaling active
- Memory fragmentation (no high-order pages)
- Thermal throttling events
This reference guide provides the foundation for systematic latency troubleshooting – use the baseline measurements to identify problematic areas, then dive deeper with the appropriate tools!
Mastering Ultra-Low Latency Systems: A Deep Dive into Bare-Metal Performance
In the world of high-frequency trading, real-time systems, and mission-critical applications, every nanosecond matters. This comprehensive guide explores the art and science of building ultra-low latency systems that push hardware to its absolute limits.
Understanding the Foundations
Ultra-low latency systems demand a holistic approach to performance optimization. We’re talking about achieving deterministic execution with sub-microsecond response times, zero packet loss, and minimal jitter. This requires deep control over every layer of the stack—from hardware configuration to kernel parameters.
Kernel Tuning and Real-Time Schedulers
The Linux kernel’s default configuration is designed for general-purpose computing, not deterministic real-time performance. Here’s how to transform it into a precision instrument.
Enabling Real-Time Kernel
# Install RT kernel
sudo apt-get install linux-image-rt-amd64 linux-headers-rt-amd64
# Verify RT kernel is active
uname -a | grep PREEMPT_RT
# Set real-time scheduler priorities
sudo chrt -f -p 99
Critical Kernel Parameters
# /etc/sysctl.conf - Core kernel tuning
kernel.sched_rt_runtime_us = -1
kernel.sched_rt_period_us = 1000000
vm.swappiness = 1
vm.dirty_ratio = 5
vm.dirty_background_ratio = 2
net.core.busy_read = 50
net.core.busy_poll = 50
Boot Parameters for Maximum Performance
# /etc/default/grub
GRUB_CMDLINE_LINUX="isolcpus=2-15 nohz_full=2-15 rcu_nocbs=2-15 \
intel_idle.max_cstate=0 processor.max_cstate=0 intel_pstate=disable \
nosoftlockup nmi_watchdog=0 mce=off rcu_nocb_poll"
CPU Affinity and IRQ Routing
Controlling where processes run and how interrupts are handled is crucial for consistent performance.
CPU Isolation and Affinity
# Check current CPU topology
lscpu --extended
# Bind process to specific CPU core
taskset -c 4 ./high_frequency_app
# Set CPU affinity for running process
taskset -cp 4-7 $(pgrep trading_engine)
# Verify affinity
taskset -p $(pgrep trading_engine)
IRQ Routing and Optimization
# View current IRQ assignments
cat /proc/interrupts
# Route network IRQ to specific CPU
echo 4 > /proc/irq/24/smp_affinity_list
# Disable IRQ balancing daemon
sudo service irqbalance stop
sudo systemctl disable irqbalance
# Manual IRQ distribution script
#!/bin/bash
for irq in $(grep eth0 /proc/interrupts | cut -d: -f1); do
echo $((irq % 4 + 4)) > /proc/irq/$irq/smp_affinity_list
done
Network Stack Optimization
Network performance is often the bottleneck in ultra-low latency systems. Here’s how to optimize every layer.
TCP/IP Stack Tuning
# Network buffer optimization
echo 'net.core.rmem_max = 134217728' >> /etc/sysctl.conf
echo 'net.core.wmem_max = 134217728' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_rmem = 4096 87380 134217728' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_wmem = 4096 65536 134217728' >> /etc/sysctl.conf
# Reduce TCP overhead
echo 'net.ipv4.tcp_timestamps = 0' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_sack = 0' >> /etc/sysctl.conf
echo 'net.core.netdev_max_backlog = 30000' >> /etc/sysctl.conf
Network Interface Configuration
# Maximize ring buffer sizes
ethtool -G eth0 rx 4096 tx 4096
# Disable interrupt coalescing
ethtool -C eth0 adaptive-rx off adaptive-tx off rx-usecs 0 tx-usecs 0
# Enable multiqueue
ethtool -L eth0 combined 8
# Set CPU affinity for network interrupts
echo 2 > /sys/class/net/eth0/queues/rx-0/rps_cpus
NUMA Policies and Memory Optimization
Non-Uniform Memory Access (NUMA) awareness is critical for consistent performance across multi-socket systems.
NUMA Configuration
# Check NUMA topology
numactl --hardware
# Run application on specific NUMA node
numactl --cpunodebind=0 --membind=0 ./trading_app
# Set memory policy for huge pages
echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
Memory Allocator Optimization
# Configure transparent huge pages
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
# Memory locking and preallocation
ulimit -l unlimited
echo 'vm.max_map_count = 262144' >> /etc/sysctl.conf
Kernel Bypass and DPDK
For ultimate performance, bypass the kernel networking stack entirely.
DPDK (Data Plane Development Kit) lets applications access NIC hardware directly in user space, slashing latency from microseconds to nanoseconds.
DPDK Setup
# Install DPDK
wget https://fast.dpdk.org/rel/dpdk-21.11.tar.xz
tar xf dpdk-21.11.tar.xz
cd dpdk-21.11
meson build
cd build && ninja
# Bind NIC to DPDK driver
./usertools/dpdk-devbind.py --bind=vfio-pci 0000:02:00.0
# Configure huge pages for DPDK
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
mkdir /mnt/huge
mount -t hugetlbfs nodev /mnt/huge
Conclusion
Building ultra-low latency systems requires expertise across hardware, kernel, and application layers. The techniques outlined here form the foundation for achieving deterministic performance in the most demanding environments. Remember: measure everything, question assumptions, and never accept “good enough” when nanoseconds matter.
The key to success is systematic optimization, rigorous testing, and continuous monitoring. Master these techniques, and you’ll be equipped to build systems that push the boundaries of what’s possible in real-time computing.
How to diagnose a kernel panic caused by a killed process
You should install atop on your server as this is top on steroids and can help diagnose all kinds of server issues such as.
https://lwn.net/Articles/387202/ – Atop usage
- CPU load
- IO load
- Memory usage
- Process utilization of resources
- Paging/swaping
- etc…
- How you install atop on ubuntu/debian
- ‘apt-get install atop’
- Then you want to start the atop logging
- ‘/etc/init.d/atop start
- ‘/etc/init.d/atop start
Note : by default the atop logs every 10mins
Now lets say you console your VM or blade server. You see a message that states the server killed a process or ran out of memory or something.
Example:
- Out of memory: Kill process 11970 (php) score 80 or sacrifice child
Killed process 11970 (php) total-vm:1957108kB
When you reboot the server you will want to find out exactly how it happened. How you do this is by checking the kernel log. Now if you have kdump installed you can use that to get a dump of the kernel log and if not you can do this.
- dmesg | egrep -i ‘killed process’
- this will provide a log as indicated below
Kernel log
- [Wed July 10 13:27:30 2018] Out of memory: Kill process 11970 (php) score 80 or sacrifice child]
- [Wed July 10 13:27:30 2018] Killed process 11970 (php) total-vm:123412108kB, anon-rss:1213410764kB, file-rss:2420k]
Now once you have this log you can see the time stamp of when it occurred and you can use atop logs to drill down and find the process id, and see if you can see which daemon and or script caused the issue.
From the log ‘July 10 13:27:30 2018’ we can see the time stamp. Inside /var/log/atop you can do the following.
Run the following:
- ‘atop -r atop_20180710’
this will bring up a screen and you can toggle through the time intervals by using lowercase ‘T’ to move forward in time or Capital ‘T’ to go backward in time. - Once you find the time stamp you can
press – ‘c’ – full command-line per process to see which processes were running at that time stamp and you should be able to locate the id process from the kernel log
atop -r atop_20180710’
Example
- 3082 27% php
- 15338 27% php
- 26639 25% php
- 8520 8% php
- 8796 8% php
- 2157 8% /usr/sbin/apache2 -k start
- 11970 1% php – This is the process ID from the kernel log above and what appears to what was running. So we know it was a php script. Atop doesn’t always provide the exact script. However from the kernel log and this we can determine what was some type of rss feed. From this you can also see that it wasnt using very much CPU. This helps us determine that the php code is causing a memory leak and needs to be updated and or disabled.
- 10493 1% php
- 10942 1% php
- 5335 1% php
- 9964 0% php
Written by Nick Tailor
