Actualmente veo mucho uso de CPU events/1y quería saber cómo descubrir qué está causando eso.
cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15
0: 575075290 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-edge timer
1: 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-edge i8042
8: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-edge rtc0
9: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-fasteoi acpi
18: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-fasteoi ata_piix
19: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-fasteoi ata_piix
20: 27 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1
21: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb5, uhci_hcd:usb8
22: 48 0 0 0 203 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4, uhci_hcd:usb7
23: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb6
32: 7511 0 0 0 0 0 0 169991 0 0 0 0 0 0 0 0 IO-APIC-fasteoi megasas
49: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0
50: 14013 79342 0 0 13699 5817 0 0 916084 0 0 0 43447 0 0 0 PCI-MSI-edge eth0-TxRx-0
51: 21 0 0 0 0 0 0 0 0 491153 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-1
52: 16 0 0 0 0 0 0 0 0 0 0 0 0 490363 0 0 PCI-MSI-edge eth0-TxRx-2
53: 15 0 0 0 0 0 0 0 0 0 512295 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-3
54: 14 0 0 0 0 0 0 0 0 0 0 0 0 0 2137545 0 PCI-MSI-edge eth0-TxRx-4
55: 14 0 0 0 0 0 0 0 0 0 0 472322 0 0 0 0 PCI-MSI-edge eth0-TxRx-5
56: 14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1261400 PCI-MSI-edge eth0-TxRx-6
57: 46039 101974 16307 0 177472 22446 0 0 78146 0 0 0 3060 0 0 0 PCI-MSI-edge eth0-TxRx-7
NMI: 116990 104030 89718 76478 57282 42770 27106 7229 11177 12608 16074 17471 15123 17563 17220 9457 Non-maskable interrupts
LOC: 1240959 513359079 608524106 453845650 545193366 480747439 402785555 456482461 620998409 526207907 405289993 406272537 426647321 459716091 532029492 578607757 Local timer interrupts
SPU: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Spurious interrupts
PMI: 116990 104030 89718 76478 57282 42770 27106 7229 11177 12608 16074 17471 15123 17563 17220 9457 Performance monitoring interrupts
IWI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IRQ work interrupts
RES: 3518 3786 1864 535 5509 4985 1982 2083 2640 1854 1547 1067 2261 2259 1744 1742 Rescheduling interrupts
CAL: 57062 229 228 228 3541 227 228 225 222 210 222 226 212 212 224 217 Function call interrupts
TLB: 10184 9632 3623 3081 15017 12586 3242 2803 7624 33023 5225 4085 4565 45383 7271 4827 TLB shootdowns
TRM: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Machine check exceptions
MCP: 1185 1185 1185 1185 1185 1185 1185 1185 1185 1185 1185 1185 1185 1185 1185 1185 Machine check polls
ERR: 0
MIS: 0
¿Podría ser esto un problema de hardware?
EDITAR:
ps auxf
Respuesta1
Bien, gracias por la información agregada. Entonces, events/1 es el problema. Estos eventos/significan eventos/CPU_NO. Los eventos threadds se introdujeron como un medio para que el kernel se despertara y realizara un trabajo que reemplazó a keventd. Sin embargo, en el árbol git v3.9-rc8, todavía veo keventd y events/per_cpu ambos.
Supongo que irq 57 está afectando a la CPU 1. De lo contrario, en /proc/interrupts, no veo nada inusual. La carga de trabajo está prácticamente igualada. ¿Puedes ver qué irq es 57?
Además, sinceramente, no creo que podamos solucionar este problema utilizando los métodos tradicionales de top, ps y todo. Con toda sutileza, esto requerirá un análisis de rendimiento. Déjame saber si puedes conseguirlo. Y si lo recibes, debes enviármelo por correo porque puedes poner esa cantidad de datos aquí.