Die meisten Befehle mit langer Laufzeit wurden auf Amazon EC2 (Ubuntu 10.04) sofort beendet.

26

Wenn Sie im Terminal einen Befehl mit langer Laufzeit ausführen, wird das Programm sofort beendet und das Terminal gibt den Text aus Killed.

Irgendwelche Hinweise? Vielleicht gibt es eine Protokolldatei mit Daten, die erklären, warum die Befehle beendet werden?

Aktualisieren

Hier ist ein Ausschnitt davon dmesg, der hoffentlich aufzeigen sollte, was das Problem verursacht. Ein weiterer Hinweis, der hilfreich sein könnte, ist, dass es sich um eine Amazon EC2-Instanz handelt.

May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184209] Call Trace:
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184218]  [<c01e49ea>] dump_header+0x7a/0xb0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184221]  [<c01e4a7c>] oom_kill_process+0x5c/0x160
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184224]  [<c01e4fe9>] ? select_bad_process+0xa9/0xe0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184227]  [<c01e5071>] __out_of_memory+0x51/0xb0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184229]  [<c01e5128>] out_of_memory+0x58/0xd0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184232]  [<c01e7f16>] __alloc_pages_slowpath+0x416/0x4b0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184235]  [<c01e811f>] __alloc_pages_nodemask+0x16f/0x1c0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184238]  [<c01ea2ca>] __do_page_cache_readahead+0xea/0x210
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184241]  [<c01ea416>] ra_submit+0x26/0x30
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184244]  [<c01e3aef>] filemap_fault+0x3cf/0x400
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184247]  [<c02329ad>] ? core_sys_select+0x19d/0x240
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184252]  [<c01fb65c>] __do_fault+0x4c/0x5e0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184254]  [<c01e4161>] ? generic_file_aio_write+0xa1/0xc0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184257]  [<c01fd60b>] handle_mm_fault+0x19b/0x510
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184262]  [<c05f80d6>] do_page_fault+0x146/0x440
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184265]  [<c0232c62>] ? sys_select+0x42/0xc0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184268]  [<c05f7f90>] ? do_page_fault+0x0/0x440
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184270]  [<c05f53c7>] error_code+0x73/0x78
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.184274]  [<c05f007b>] ? setup_local_APIC+0xce/0x33e
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272161]  [<c05f0000>] ? setup_local_APIC+0x53/0x33e
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272163] Mem-Info:
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272164] DMA per-cpu:
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272166] CPU    0: hi:    0, btch:   1 usd:   0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272168] Normal per-cpu:
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272169] CPU    0: hi:  186, btch:  31 usd:  50
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272171] HighMem per-cpu:
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272172] CPU    0: hi:  186, btch:  31 usd:  30
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272176] active_anon:204223 inactive_anon:204177 isolated_anon:0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272177]  active_file:47 inactive_file:141 isolated_file:0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272178]  unevictable:0 dirty:0 writeback:0 unstable:0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272179]  free:10375 slab_reclaimable:1650 slab_unreclaimable:1856
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272180]  mapped:2127 shmem:3918 pagetables:1812 bounce:0May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272186] DMA free:6744kB min:72kB low:88kB high:108kB active_anon:300kB inactive_anon:308kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15812kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272190] lowmem_reserve[]: 0 702 1670 1670May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272197] Normal free:34256kB min:3352kB low:4188kB high:5028kB active_anon:317736kB inactive_anon:317308kB active_file:144kB inactive_file:16kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:719320kB mlocked:0kB dirty:4kB writeback:0kB mapped:32kB shmem:0kB slab_reclaimable:6592kB slab_unreclaimable:7424kB kernel_stack:2592kB pagetables:7248kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:571 all_unreclaimable? yes
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272201] lowmem_reserve[]: 0 0 7747 7747May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272207] HighMem free:500kB min:512kB low:1668kB high:2824kB active_anon:498856kB inactive_anon:499092kB active_file:44kB inactive_file:548kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:991620kB mlocked:0kB dirty:0kB writeback:0kB mapped:8472kB shmem:15672kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:430 all_unreclaimable? yes
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272211] lowmem_reserve[]: 0 0 0 0May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272215] DMA: 10*4kB 22*8kB 38*16kB 33*32kB 16*64kB 10*128kB 4*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 6744kBMay 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272223] Normal: 476*4kB 1396*8kB 676*16kB 206*32kB 23*64kB 2*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 34256kBMay 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272231] HighMem: 1*4kB 2*8kB 28*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 500kB
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272238] 4108 total pagecache pages
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272240] 0 pages in swap cache
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272242] Swap cache stats: add 0, delete 0, find 0/0
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272243] Free swap  = 0kB
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.272244] Total swap = 0kB
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.276842] 435199 pages RAM
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.276845] 249858 pages HighMem
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.276846] 8771 pages reserved
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.276847] 23955 pages shared
May 14 20:29:15 ip-10-112-33-63 kernel: [11144050.276849] 405696 pages non-shared

ubuntu amazon-ec2 terminal

— Dan Loewenherz
quelle

Sehr hilfreich, hatte gerade das gleiche Problem

— Cookie

36

Sie sollten in der Lage sein herauszufinden, was Ihren Prozess beendet hat, indem Sie sich die Ausgabe des dmesgBefehls ansehen. oder in den Log - Dateien /var/log/kern.log, /var/log/messagesoder /var/log/syslog.

Es gibt eine Reihe von Dingen, die dazu führen können, dass ein Prozess vorübergehend abgebrochen wird:

Wenn es das harte ulimit für verschiedene Speicher- oder CPU-Nutzungstypen überschreitet, die Sie mit überprüfen können ulimit -H -a
Wenn der virtuelle Speicher des Systems fast voll ist, kann der Kernel oom-killer Prozesse beenden, um Speicher freizugeben. (In Ihrem Fall ist dies wahrscheinlich nicht der Fall.)
Wenn auf dem System SELinux und / oder PaX / grsecurity installiert sind, kann ein Prozess abgebrochen werden, wenn versucht wird, etwas zu tun, das die Sicherheitsrichtlinie nicht zulässt, oder wenn versucht wird, selbst modifizierten Code auszuführen.

Die Protokolle oder Dmesg sollten Ihnen sagen, warum der Prozess abgebrochen wurde.

— Heide
quelle

Danke für deine Antwort! Sie haben gerade die von Ihnen erwähnten Protokolldateien überprüft, aber ich kann anscheinend keine nützlichen Daten finden. Sehen Sie sich das Update zu meiner Antwort an, um einen Blick darauf zu werfen.

— Dan Loewenherz

3

Ja, du wirst vom Oom-Killer gebissen; was bedeutet, dass Ihnen der Speicher ausgeht. Versuchen Sie, Ihrer Instanz etwas Auslagerungsspeicher hinzuzufügen (in Situationen mit wenig Arbeitsspeicher können bereits einige hundert Megabyte Auslagerungsspeicher viel helfen).

— Heath

Für andere, die sich gefragt haben, wie man einer EC2-Instanz einen Swap hinzufügt, hat mir diese Antwort geholfen (nach dem Einfügen von SSH in die Instanz): stackoverflow.com/a/17173973/4900327

— Abhishek Divekar

10

Die Protokolle, die Sie bei der Aktualisierung gepostet haben, zeigen an, dass auf Ihrem System nicht mehr genügend Arbeitsspeicher vorhanden ist und der OOM-Killer aufgerufen wird, um Prozesse abzubrechen , um freien Arbeitsspeicher zu erhalten, wenn "alles andere fehlschlägt". Der Auswahlalgorithmus für den OOM-Killer zielt möglicherweise positiv auf Ihre "langfristigen" Prozesse ab. Auf der verlinkten Seite finden Sie eine Beschreibung des Auswahlalgorithmus.

Die offensichtliche Lösung ist mehr Arbeitsspeicher, aber es kann sein, dass Ihnen aufgrund eines Speicherverlusts irgendwo der Arbeitsspeicher ausgeht und das Hinzufügen von mehr Arbeitsspeicher den Aufruf des OOM-Killers nur verzögert, wenn dies der Fall ist. Überprüfen Sie Ihre Prozesstabelle auf Prozesse, die mit Ihrem bevorzugten Tool (top, ps usw.) den meisten Speicher belegen, und wechseln Sie von dort aus.

— Thomson
quelle

Der OOM-Killer bevorzugt auf jeden Fall lang andauernde Prozesse mit geringer Aktivität. Wenn sshd auf einem Produktionsserver beendet wird, ist das Debuggen schwierig.

— mfarver

Sshd passt seinen eigenen / proc / pid / oom_adj-Score an, damit er nicht von oom killer getötet werden kann (bevor er alles andere tötet).

— Yaplik

@yaplik Dies scheint nicht länger auf neuere Distributionen zuzutreffen. Da untergeordnete Prozesse den Wert von oom_adj erben, kann ein böswilliger Benutzer einen DoS verursachen, indem er den gesamten Speicher verbraucht, ohne dass seine Prozesse vom OOM-Killer beendet werden.

— so

4

Wie bereits von anderen erklärt, hat man nicht mehr genügend Arbeitsspeicher, daher wird der Killer für unzureichenden Arbeitsspeicher ausgelöst und bricht einen bestimmten Prozess ab.

Sie können dies folgendermaßen beheben:

a) Rüsten Sie Ihre ec2-Maschine auf eine leistungsstärkere auf. Die "kleine Instanz" hat 2,5-mal mehr Speicher (1,7 GB) als die "Mikroinstanz" (0,64 GB). Sie kostet zusätzliches Geld

b) Hinzufügen von Swap - Partition - fügen Sie zusätzliches EBS - Laufwerk mkswap /dev/sdx, swapon /dev/sdxkostet EBS Speicher- und IO Gebühren

c) Hinzufügen von Auslagerungsdatei - dd if=/dev/zero of=/swap bs=1M count=500, mkswap /swap, swapon /swapkostet IO Gebühren und freien Speicherplatz auf dem Root - EBS

Das c) sollte ausreichen, aber denken Sie daran, dass die Mikroinstanz aufgrund von CPU-Beschränkungen keine lang andauernden CPU-intensiven Aufgaben ausführen soll (nur kurze Bursts zulässig).

— yaplik
quelle

3

Ich hatte das gleiche problem Meine Prozesse wurden getötet.

Ich fand heraus, dass auf dem von mir verwendeten Ubuntu AMI kein Swap Space eingerichtet war. Wenn der Speicher voll ist und kein Auslagerungsspeicher verfügbar ist, bricht der Kernel unvorhersehbar Prozesse ab, um sich selbst zu schützen. Swap Space verhindert das. (Dieses Problem ist aufgrund der geringen Speicherkapazität von 613 MB besonders für die Micro-Instanz relevant.)

So überprüfen Sie, ob ein Swap Space eingerichtet ist: swapon -s

Richten Sie den Swap Space ein: http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space

Weitere Ressourcen: http://wiki.sysconfig.org.uk/display/howto/Build+your+own+Core+CentOS+5.x+AMI+for+Amazon+EC2

— Köstlich
quelle

Arbeitete für mich! Mein dmesg enthielt nur viele "select proccess_name to kill" nacheinander und ich hatte keine / var / log / messages oder nützliche Logs, aber das Ausführen von "free -h" zeigte, dass fast kein Speicher mehr vorhanden war. Danke vielmals!

— Divieira

1

Das Protokoll zeigt an, dass Ihnen der Swap / Cache-Speicher ausgeht.

    14. Mai 20:29:15 ip-10-112-33-63 Kernel: [11144050.272240] 0 Seiten im Auslagerungscache
    14. Mai 20:29:15 ip-10-112-33-63 Kernel: [11144050.272242] Cache-Statistiken tauschen: 0 hinzufügen, 0 löschen, 0/0 finden
    14. Mai 20:29:15 ip-10-112-33-63 Kernel: [11144050.272243] Free Swap = 0 KB
    14. Mai 20:29:15 ip-10-112-33-63 Kernel: [11144050.272244] Total Swap = 0 KB

Können Sie den Job / Prozess, den Sie ausführen, stapelweise aufteilen? Vielleicht können Sie versuchen, es isoliert auszuführen, nachdem Sie die anderen Prozesse gestoppt haben?

— Software-Mechaniker
quelle