Re: "why is my Linux so damn slow?"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Saturday, February 12, 2011 12:55:12 pm M. Fioretti wrote:
> On Sat, Feb 12, 2011 12:47:13 PM -0600, Rick Sewill (rsewill@xxxxxxxxx) 
wrote:
> > Could you show us the output of twice, the second time a few seconds
> > after the first time so we can see if any interrupt number changes fast.
> > more /proc/interrupts
> 
> here are two runs, 5/6 seconds apart:
> 
> [root@polaris ~]# more /proc/interrupts
>            CPU0       CPU1
>   0:        136        180   IO-APIC-edge      timer
>   1:          0          2   IO-APIC-edge      i8042
>   4:          0          2   IO-APIC-edge
>   7:          1          0   IO-APIC-edge      parport0
>   8:          0          1   IO-APIC-edge      rtc0
>   9:          0          0   IO-APIC-fasteoi   acpi
>  12:          0          4   IO-APIC-edge      i8042
>  14:          0          0   IO-APIC-edge      pata_amd
>  15:          0          0   IO-APIC-edge      pata_amd
>  17:          0          2   IO-APIC-fasteoi   firewire_ohci
>  20:     116972        135   IO-APIC-fasteoi   ohci_hcd:usb3, nvidia
>  21:        947        289   IO-APIC-fasteoi   ehci_hcd:usb2, hda_intel
>  22:          0          3   IO-APIC-fasteoi   ehci_hcd:usb1
>  23:     252957         24   IO-APIC-fasteoi   ohci_hcd:usb4
>  43:     449718       5490   PCI-MSI-edge      ahci
>  44:     850242         23   PCI-MSI-edge      eth0
> NMI:          0          0   Non-maskable interrupts
> LOC:   12772218   13583547   Local timer interrupts
> SPU:          0          0   Spurious interrupts
> PMI:          0          0   Performance monitoring interrupts
> PND:          0          0   Performance pending work
> RES:    6896487    7547957   Rescheduling interrupts
> CAL:       8607      11701   Function call interrupts
> TLB:      43915      42920   TLB shootdowns
> TRM:          0          0   Thermal event interrupts
> THR:          0          0   Threshold APIC interrupts
> MCE:          0          0   Machine check exceptions
> MCP:        103        103   Machine check polls
> ERR:          1
> MIS:          0
> [root@polaris ~]#
> [root@polaris ~]# more /proc/interrupts
>            CPU0       CPU1
>   0:        136        180   IO-APIC-edge      timer
>   1:          0          2   IO-APIC-edge      i8042
>   4:          0          2   IO-APIC-edge
>   7:          1          0   IO-APIC-edge      parport0
>   8:          0          1   IO-APIC-edge      rtc0
>   9:          0          0   IO-APIC-fasteoi   acpi
>  12:          0          4   IO-APIC-edge      i8042
>  14:          0          0   IO-APIC-edge      pata_amd
>  15:          0          0   IO-APIC-edge      pata_amd
>  17:          0          2   IO-APIC-fasteoi   firewire_ohci
>  20:     116985        135   IO-APIC-fasteoi   ohci_hcd:usb3, nvidia
>  21:        947        289   IO-APIC-fasteoi   ehci_hcd:usb2, hda_intel
>  22:          0          3   IO-APIC-fasteoi   ehci_hcd:usb1
>  23:     252957         24   IO-APIC-fasteoi   ohci_hcd:usb4
>  43:     449809       5490   PCI-MSI-edge      ahci
>  44:     850456         23   PCI-MSI-edge      eth0
> NMI:          0          0   Non-maskable interrupts
> LOC:   12774821   13585530   Local timer interrupts
> SPU:          0          0   Spurious interrupts
> PMI:          0          0   Performance monitoring interrupts
> PND:          0          0   Performance pending work
> RES:    6896974    7548786   Rescheduling interrupts
> CAL:       8608      11703   Function call interrupts
> TLB:      43919      42921   TLB shootdowns
> TRM:          0          0   Thermal event interrupts
> THR:          0          0   Threshold APIC interrupts
> MCE:          0          0   Machine check exceptions
> MCP:        103        103   Machine check polls
> ERR:          1
> MIS:          0
> [root@polaris ~]#
> 
> 
> will try now to find out the clock interrupt rate. Thanks

I think the clock interrupt rate is shown by the "Local timer interrupts".
I don't know if that number is okay or not.  I think it might be okay.

I am curious about the Rescheduling interrupts.
I do not have a dual core system so I have no rescheduling interrupts.

I do not know how many rescheduling interrupts is too many. 

I did google searches, "Resheduling interrupts"
and Linux "Resheduling interrupts"
It appears there have been problems, in this area, over the years.
We should be careful to limit ourselves to any recent problems.

I found some sort of explanation of rescheduling interrupts at
https://help.ubuntu.com/community/ReschedulingInterrupts
Also at this URL were suggestions for troubleshooting problems.
One suggestion, from this URL was to use "vmstat 1".
I haven't used vmstat before so this is educational.
Another suggestion was troubleshooting ACPI and APIC problems.

This problem sounds similar to another person's problem:
http://www.spinics.net/lists/kvm/msg49558.html
I mention this problem because of the date and also it's
Debian (not Fedora).  We don't know if this person's problem
is a "Rescheduling interrupt" problem...but it sounds similar.

Attachment: signature.asc
Description: This is a digitally signed message part.

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux