La maggior parte dei comandi di lunga durata vengono immediatamente eliminati su Amazon EC2 (Ubuntu 10.04)


26

Quando si esegue qualsiasi tipo di comando di lunga durata nel terminale, il programma muore istantaneamente e il terminale emette il testo Killed.

Qualche puntatore? Forse c'è un file di registro con i dati che spiegano perché i comandi vengono uccisi?

Aggiornare

Ecco un frammento dmesgche si spera dovrebbe illuminare ciò che sta causando il problema. Un'altra nota che potrebbe essere utile è che si tratta di un'istanza di Amazon EC2.

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

Molto utile, ho avuto lo stesso problema
Cookie del

Risposte:


36

Dovresti essere in grado di scoprire cosa ha interrotto il tuo processo guardando l'output del dmesgcomando; o ai file di log /var/log/kern.log, /var/log/messageso /var/log/syslog.

Ci sono un certo numero di cose che possono causare l'uccisione sommaria di un processo:

  • Se supera l'ulimit hard per vari tipi di utilizzo della memoria o della cpu che puoi esaminare usando ulimit -H -a
  • Se il sistema ha poca memoria virtuale, i processi possono essere uccisi dal kernel oom-killer per liberare memoria (Nel tuo caso, probabilmente non è questo)
  • Se il sistema ha SELinux e / o PaX / grsecurity installati, un processo potrebbe essere ucciso se tenta di fare qualcosa che non è consentito dalla politica di sicurezza o se tenta di eseguire codice auto-modificato.

I registri o dmesg dovrebbero dirti perché il processo è stato interrotto.


Grazie per la tua risposta! Ho appena controllato i file di registro che hai citato, ma non riesco a trovare molti dati utili. Dai un'occhiata all'aggiornamento della mia risposta per vedere un assaggio.
Dan Loewenherz,

3
Sì, stai diventando morso dall'omicida; il che significa che hai esaurito la memoria. Prova ad aggiungere un po 'di spazio di swap alla tua istanza (anche solo poche centinaia di mega di swap possono aiutare molto in una situazione di memoria insufficiente).
Heath,

Per gli altri che si chiedevano come aggiungere lo swap a un'istanza EC2, questa risposta mi ha aiutato (dopo SSHing nell'istanza): stackoverflow.com/a/17173973/4900327
Abhishek Divekar,

10

I registri che hai pubblicato come in aggiornamento indicano che il tuo sistema sta esaurendo la memoria e il killer OOM viene invocato per eliminare i processi al fine di mantenere la memoria libera quando "tutto il resto fallisce". L'algoritmo di selezione per il killer OOM potrebbe essere indirizzato favorevolmente ai tuoi processi "di lunga durata". Vedere la pagina collegata per una descrizione dell'algoritmo di selezione.

La soluzione ovvia è più memoria, ma potresti esaurire la memoria a causa di una perdita di memoria da qualche parte e l'aggiunta di più memoria probabilmente ritarderebbe l'invocazione del killer OOM in questo caso. Controlla la tabella dei processi per i processi che utilizzano la maggior quantità di memoria con il tuo strumento preferito (top, ps, ecc.) E vai da lì.


Il killer OOM ha una preferenza definita per i processi di lunga durata, a bassa attività. Avere kill sshd su un server di produzione rende difficile il debug.
mfarver,

Sshd regola il proprio punteggio / proc / pid / oom_adj in modo che non possa essere ucciso dal killer di Oom (prima che uccida tutto il resto).
yaplik,

@yaplik Questo non sembra applicarsi più alle recenti distribuzioni. Poiché i processi figlio ereditano il valore di oom_adj, un utente malintenzionato potrebbe causare un DoS consumando tutta la memoria senza che i suoi processi vengano uccisi dal killer OOM.
ikso,

4

Come già spiegato da altri, stai esaurendo la memoria, quindi l'eccesso di memoria viene attivato e uccide alcuni processi.

Puoi risolvere questo facendo:

a) aggiorna la tua macchina ec2 a una più potente, "piccola istanza" ha 2,5 volte più memoria (1,7 GB) di "microistanza" (0,64 GB), costa denaro aggiuntivo

b) l'aggiunta di partizione di swap - aggiungere unità aggiuntiva EBS, mkswap /dev/sdx, swapon /dev/sdx, i costi di storage EBS e spese IO

c) l'aggiunta di file di swap - dd if=/dev/zero of=/swap bs=1M count=500, mkswap /swap, swapon /swap, oneri Commissioni IO e lo spazio libero su radice EBS

La c) dovrebbe essere sufficiente, ma tieni presente che non si suppone che la microistanza esegua attività ad alta intensità di CPU a lungo termine a causa dei limiti della CPU (sono ammessi solo brevi scoppi).


3

Ho avuto lo stesso problema. I miei processi venivano uccisi.

Ho scoperto che l'AMI di Ubuntu che stavo usando non aveva uno spazio di swap impostato. Quando la memoria è piena e non c'è spazio di scambio disponibile, il kernel inizierà imprevedibilmente a uccidere i processi per proteggersi. Lo spazio di swap lo impedisce. (Questo problema è particolarmente rilevante per l'istanza Micro a causa dei piccoli 613 MB di memoria.)

Per verificare se si dispone di uno spazio di configurazione impostato, digitare: swapon -s

Imposta lo spazio di swap: http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space

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


Ha funzionato per me! Il mio dmesg conteneva solo molti "select proccess_name da uccidere" uno dopo l'altro e non avevo / var / log / messaggi o registri utili, ma eseguendo "free -h" mostrava che non rimaneva quasi memoria. Grazie molto!
divieira,

1

Il registro indica che si sta esaurendo la memoria di swap / cache.

    14 maggio 20:29:15 kernel ip-10-112-33-63: [11144050.272240] 0 pagine nella cache di scambio
    14 maggio 20:29:15 kernel ip-10-112-33-63: [11144050.272242] Statistiche cache di swap: aggiungi 0, elimina 0, trova 0/0
    14 maggio 20:29:15 kernel ip-10-112-33-63: [11144050.272243] Swap gratuito = 0kB
    14 maggio 20:29:15 kernel ip-10-112-33-63: [11144050.272244] Swap totale = 0kB

Puoi dividere il processo / processo in esecuzione in batch? Forse puoi provare a eseguirlo da solo dopo aver interrotto gli altri processi?

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.