Member Avatar for linuxaomi

Using LINUX MINT along with XAMPP seems to be a perfect combination.
As I am monitoring most of relevant aspects from different fields (PHP, apache, MySQL, disks, network amm.) there is a question from my side regarding interrupts: cat /proc/interrupts Why so many RES rescheduling interrupts ?

I am complaining about poor responsetime or slowdowns just the high numbers make me thinking.

Thank you

  • 2 Contributors
  • 7 Replies
  • 1K Views
  • 2 Months Discussion Span
  • Latest Post Latest Post by linuxaomi

Dani AI

Generated

RES in /proc/interrupts is the kernel’s reschedule counter—it records how often the kernel asks a CPU to run the scheduler (inter-processor reschedule IPIs and timer-driven wakeups). On SMP machines those counters climb quickly with uptime because they reflect scheduler activity, not a hardware fault. High absolute counts are normal; the important question is the rate (events/sec) and whether those events cause measurable latency or CPU overhead.

What you describe matches common causes. already noted frequent MySQL events and cron jobs; those periodic wakeups are exactly the kind of work that increases RES. is right: if responsiveness and load averages are fine, leave it alone. RES only becomes actionable when you also see sustained high CPU, lots of context switches, or interactive lag.

Practical checks: measure RES per second, watch interrupts/context-switch rates, and find processes that wake frequently. The snippet below sums RES across CPUs and gives RES/sec over 60 seconds:

start=$(awk '/^RES:/ {s=0; for(i=2;i<=NF;i++) s+= $i; print s}' /proc/interrupts)
sleep 60
end=$(awk '/^RES:/ {s=0; for(i=2;i<=NF;i++) s+= $i; print s}' /proc/interrupts)
echo $(( (end - start) / 60 ))   # RES per second

Also use vmstat 1 10 (interrupts and context switches), pidstat -w 1 (per-process cswch/wake activity), and powertop or perf to find wakeup hotspots. Common fixes are reducing unnecessary timers (cron/MySQL event frequency), updating/tuning noisy drivers (network/wireless), or consolidating periodic work. Avoid tuning kernel scheduler knobs unless you can measure scheduler latency and understand the tradeoffs.

Recommended Answers

All 7 Replies

Member Avatar for linuxaomi

I am NOT complaining about poor responsetime or slowdowns just the high numbers make me thinking.

Sorry for my mistake

Member Avatar for rubberman

What is the actual output for RES? Rescheduling interrupts occur frequently due to scheduling priority issues. Example: my Scientific Linux 6 (RHEL 6 clone) after 11 days uptime has 400-500K RES events for each of 8 cores - about 4M in total. There are about 3x as many function call interrupts (CAL), and a fair number more TLB shootdowns (TLB). So, without some real numbers, there isn't much we can say about whether or not your system is performing abnormally. In sum, please post the following information:

1. uptime
2. full output of the "cat /proc/interrupts" command

Member Avatar for linuxaomi

rubberman, your quick response is highly appreciated.
Here you are: uptime and cat /proc/interrupts output

uptime
16:52:57 up 10:34, 2 users, load average: 0.57, 0.78, 0.79

cat /proc/interrupts
CPU0 CPU1
0: 4195377 4213713 IO-APIC-edge timer
1: 12162 11789 IO-APIC-edge i8042
8: 0 1 IO-APIC-edge rtc0
9: 36839 36525 IO-APIC-fasteoi acpi
12: 4036 3950 IO-APIC-edge i8042
16: 0 0 IO-APIC-fasteoi uhci_hcd:usb3
17: 33402 32595 IO-APIC-fasteoi uhci_hcd:usb4, HDA Intel
18: 0 0 IO-APIC-fasteoi uhci_hcd:usb5, uhci_hcd:usb8
19: 0 0 IO-APIC-fasteoi ehci_hcd:usb1
20: 216137 210786 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6
22: 0 0 IO-APIC-fasteoi uhci_hcd:usb7
29: 389402 379444 PCI-MSI-edge ahci
30: 76870 76299 PCI-MSI-edge i915
31: 0 1 PCI-MSI-edge eth0
32: 920360 851211 PCI-MSI-edge iwlagn
NMI: 0 0 Non-maskable interrupts
LOC: 3273123 3155698 Local timer interrupts
SPU: 0 0 Spurious interrupts
CNT: 0 0 Performance counter interrupts
PND: 0 0 Performance pending work
RES: 1544668 1579553 Rescheduling interrupts
CAL: 208 210 Function call interrupts
TLB: 285553 314723 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 127 127 Machine check polls
ERR: 0
MIS: 0

The ratio between RES/CAL/TLB is much different from yours. And let me point out this once again, I am happy with overall performance.

Member Avatar for rubberman

Well, if performance is not impacted, then probably this is not an issue. As they say, if it ain't broke, don't try to fix it! :-) Honestly, scheduling interrupts are largely dependent upon the schedulers you are using, and load factors that I cannot know about.

Member Avatar for linuxaomi

Interesting, I understand that schedulers i.e. crontab and time driven MySQL procedures are contributing to that kind of activities. Mostly I am using this PC for development and testing. Running php scricts again and again.
As I am expecting less workload in production I don't feel concerned about it at all. And you are right, don't touch/break it unless there would be a reason to react.

Many thanks,
linuxaomi

Member Avatar for linuxaomi

Part of AoMi realtime monitor reveals frequent MySQL events. Time driven events.

Edited by happygeek because: fixed formatting
Member Avatar for linuxaomi

Part of AoMi realtime monitor reveals frequent LINUX crontab events. Time driven events.

Edited by Dani because: Formatting fixed
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.