O script R de execução longa está sendo morto automaticamente

Question

Estou tentando executar um experimento para minha tese de mestrado que envolve um script R que precisa ser executado por um bom tempo (até 24 horas de uso de 100% da CPU). É um processo de núcleo único e, até onde sei, tenho bastante memória para o trabalho. O problema é que quando eu o executo durante a noite, ele está sendo morto em algum momento no meio da noite sem que eu inicie nada. Para ter uma ideia da saída, veja o que estou vendo:

➜  r-lda git:(master) ✗ Rscript slda-test-gibbs-1E6-01.r | tee slda-test-gibbs-1E6-01.log
Loading required package: lattice
Loading required package: ggplot2
Loading required package: methods
[1] "LOADING DATASET: data/split_1E6.dat"
[1] "DATASET LOADED"
[1] "TRAINING DATASET SIZE: 800000"
[1] "TESTING DATASET SIZE: 200000"
[1] "VOCAB SIZE: 129276"
[1] "TRAINING E=50 M=2 K=600"
[1]    17722 killed     Rscript slda-test-gibbs-1E6-01.r | 
       17723 done       tee slda-test-gibbs-1E6-01.log

Eu sei que não é muito informativo, mas eu realmente não sei como diagnosticar este sintoma ainda mais. Já aconteceu duas vezes agora, e não tenho ideia do que está acontecendo. Eu normalmente não trabalho muito com scripts R, e um pouco de googling não trouxe nenhuma explicação real para isso. Para ter uma ideia do meu sistema:

➜  r-lda git:(master) ✗ uname -a
Linux ****** 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015 x86_64 GNU/Linux


➜  r-lda git:(master) ✗ head -n26 /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 60
model name      : Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
stepping        : 3
microcode       : 0x12
cpu MHz         : 3499.863
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
bugs            :
bogomips        : 7015.72
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

➜  r-lda git:(master) ✗ free -h
              total        used        free      shared  buff/cache   available
Mem:            15G        3.4G         10G        291M        1.4G         11G
Swap:           15G        773M         15G

Qualquer ideia seria muito apreciada. Agradecemos antecipadamente.

    

Answer 1

O melhor ponto de partida são os logs. Como você diz que o log do aplicativo não mostrou nada útil, você deve examinar os logs do sistema como dmesg e cron jobs. Uma entrada comum no dmesg seria um erro OOM (falta de memória), mas você disse que havia bastante memória livre. Para obter o tempo de uma falha, minha maneira preferida é executar

date; time command

onde comando é o programa a ser executado. Adicionando o tempo de saída pelo tempo após o programa ter caído para o tempo de saída por data ao iniciar, você obtém o tempo que ele caiu. Execute isso várias vezes e procure padrões como o mesmo tempo de execução ou tempo de falha. Veja também os cronjobs diários que não são iniciados todos os dias à mesma hora.

Outros motivos podem ser um bug no programa ou no programa usando ponteiro de 32 bits e não alocar mais memória.