☰

Einige Prozesse nutzen 100 % der CPU und bleiben beim select()-Aufruf für einige Zeit hängen

tag-icon • tag-icon linux
Einige Prozesse nutzen 100 % der CPU und bleiben beim select()-Aufruf für einige Zeit hängen

Ich habe also dieses seltsame Szenario: Es gibt einen Server namens Apache/Passenger/Rails und einige andere Dienste. Beispielsweise benötigt der Top-Befehl selbst 100 % der CPU-Zeit (auch iostat und Ruby, andere Prozesse scheinen normal). Zuerst dachte ich, dies sei ein bekannter Futex-FehlerLinux futex_wait() Fehler(als Prozessor dient Xeon E5), aber dies ist Centos 6.5 mit 3.2.13-grsec-xxxx-grs-ipv6-64-Kernel und dieser scheint nicht vom Futex-Bug betroffen zu sein. Hier ist die Ausgabe des Top-Befehls:

 top - 18:14:46 up 60 days,  6:32,  2 users,  load average: 2.15, 1.24, 1.04
Tasks: 180 total,   1 running, 179 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.6%us,  1.0%sy,  0.0%ni, 95.0%id,  1.7%wa,  0.0%hi,  0.7%si,  0.0%st
Mem:  66008460k total, 21226356k used, 44782104k free,   817252k buffers
Swap: 61437944k total,        0k used, 61437944k free, 17404540k cached
Change delay from 3.0 to: 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                    
18042 root      20   0 15076 1272  904 S 100.0  0.0  5109402h top                                                       
18041 root      20   0  105m 1192 1028 S 100.0  0.0 900776:13 sh                                                        
18043 root      20   0 98.6m  808  692 S 100.0  0.0 900776:13 iostat                                                    
    1 root      20   0 19276 1508 1228 S  0.0  0.0   0:02.40 init                                                       
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.02 kthreadd                                                   
    3 root      20   0     0    0    0 S  0.0  0.0  5119411h ksoftirqd/0                                                
    5 root      20   0     0    0    0 S  0.0  0.0 10218485h kworker/u:0                                                
    6 root      RT   0     0    0    0 S  0.0  0.0 986912:21 migration/0                                                
    7 root      RT   0     0    0    0 S  0.0  0.0 906076:59 migration/1                                                
    9 root      20   0     0    0    0 S  0.0  0.0  45038,51 ksoftirqd/1                                                
   11 root      RT   0     0    0    0 S  0.0  0.0 911444:25 migration/2                                                
   13 root      20   0     0    0    0 S  0.0  0.0 120103,33 ksoftirqd/2                                                
   14 root      RT   0     0    0    0 S  0.0  0.0 941393:43 migration/3

strace zeigt, dass dieser Prozess beim Systemaufruf select() hängen bleibt

# strace -p 1938
Process 1938 attached - interrupt to quit
select(12, [0 11], NULL, NULL, NULL^C <unfinished ...>
Process 1938 detached

Was kann der Grund hierfür sein?

Antwort1

Ich hatte heute mit einer ähnlichen Situation zu kämpfen. Meine Freunde waren gdb, rb_backtrace()und rake debug. Und in meinem Fall war es unter einigen seltenen Umständen eine unendliche while-Schleife.

Nur rb_backtrace()um den Backtrace auszudrucken. In meinem Fall wurde er im Fehlerprotokoll des Apache ausgedruckt ( /var/log/apache2/error.log).

Dieser Backtrace erfolgt in umgekehrter Reihenfolge als üblich. Sehen Sie sich die letzten Zeilen an und suchen Sie nach Zeilen, die sich auf Ihren Anwendungscode beziehen. Verwenden Sie dann einen Ruby-Debugger, um direkt vor dieser Zeile zu debuggen.

Dieser Beitraghttps://robots.thoughtbot.com/using-gdb-to-inspect-a-running-ruby-processwar hilfreich.

verwandte Informationen