Un saludo a la lista:
Superviso un par de servidores con debian wheezy que más o menos tienen
la misma configuración y me he encontrado con lo siguiente:
El servidor que es un xeon con dos núcleos balancea bien las
interrupciones. Sin embargo, en el servidor que tiene un i3 con cuatro
núcleos me he encontrado con esto:
#v+
$ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 899 0 0 0 IO-APIC-edge timer
1: 8 0 0 0 IO-APIC-edge i8042
7: 0 0 0 0 IO-APIC-edge parport0
8: 1 0 0 0 IO-APIC-edge rtc0
9: 0 0 0 0 IO-APIC-fasteoi acpi
12: 147 0 0 0 IO-APIC-edge i8042
16: 29599545 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1
19: 7441332 0 0 0 IO-APIC-fasteoi ata_piix, ata_piix
23: 28 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2
43: 7861552 0 0 0 PCI-MSI-edge eth1
44: 7088536 0 0 0 PCI-MSI-edge eth0
45: 7061791 0 0 0 PCI-MSI-edge eth2
46: 5961572 0 0 0 PCI-MSI-edge eth3
47: 173 0 0 0 PCI-MSI-edge snd_hda_intel
48: 2 0 0 0 PCI-MSI-edge i915
[...]
#v-
Vamos, que todas las interrupciones las está gestionando un procesador.
He ido a mirar en /proxc/irq/*/smp_affinity, pero está a "f", o sea,
que teóricamente deberían gestionar las interrupciones entre los cuatro:
#v+
# cat /proc/irq/43/smp_affinity
f
#v-
He estado leyendo esto:
http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-linux
y me ha parecido entender hacia el final del artículo que algunas
configuraciones del kernel, pueden provocar que al final el primer
procesador sea el que se encargue de todo, como es mi caso. Habla en
particular de que esté activa la opción CONFIG_HOTPLUG_CPU, que en
debian lo está.
¿Sabe alguien algo al respecto? Tiene esto una solución que no sea
asignarle una eth a cada cpu (eso sí he visto que funciona): los accesos
a disco no los voy a poder repartir de ninguna forma.
¿Es casualidad que en el xeon funcionen bien las cosas y en el i3 no? En
principio ambos tienen la misma configuración del kernel.
Un saludo.
--
Los grandes hombres solemos ser modestos.
--- Juan de Mairena --
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141005152736.ga8...@cubo.casa
