Di recente ho aggiornato il mio server da Debian Squeeze i386 a wheezy amd64 reinstallando e riconfigurando. Inoltre volevo essere in grado di avviare guest virtuali, quindi ho installato anche XEN.
Ho avuto poi il problema che di tanto in tanto il killer OOM distruggeva più processi sul mio Dom0. Ho quindi riavviato e disabilitato diversi servizi (come apache2, mysql, postgresql, ...). Ora sembra che nessun processo sia più distrutto (incerto, in quanto non avviene regolarmente ma in modo stocastico). MA: se metto un po 'di carico sulla macchina (accesso al filesystem crittografato), il killer OOM viene attivato.
Purtroppo il sistema non è più utilizzabile dopo che si è verificato il problema. Quindi non posso accedere tramite SSH per indagare. Anche un'indagine fisica tramite console si blocca la maggior parte delle volte.
Ho un atopdemone in esecuzione ogni minuto in modo da poter vedere la memoria e scambiare i consigli prima dello schianto: la RAM è 1 GB (880 MB) in totale (allocata stabilmente a Dom0, senza mongolfiere) dove aprox. 440 MB sono cache. Alcuni MB sono buffer e circa 20 MB sono gratuiti. Lo swap è di 25GiB in totale e completamente gratuito.
Cosa non capisco: perché il kernel non uccide parte della cache se è necessaria più RAM. È cache, quindi tutto ciò che potrebbe accadere è un problema di prestazioni ma il sistema rimarrebbe stabile. In questo modo il sistema si arresta in modo anomalo. Inoltre, perché le sezioni di memoria non necessarie utilizzate da altri programmi non vengono scambiate? Ci dovrebbe essere abbastanza spazio per fare quello che vuoi.
Qualche volta ho visto un messaggio sulla console che un'attività (jbod / raid5 o qualcosa di simile) stava bloccando (?) Per più di 120 secondi. Non sono sicuro che questa sia la causa o l'impatto del problema OOM.
Ora le mie domande sono:
- Potrebbe essere un problema XEN?
- Potrebbe essere un problema hardware? RAM o HD?
- Cosa posso fare per evitare arresti anomali futuri?
Modifica: ho appena provato a riprodurre l'errore. Si è arrestato in modo anomalo ma questa volta (non esattamente ora se ci fossero altri errori in altre situazioni) il programma bloccato era xenwatch. Quindi nessun programma accede all'HD.
sudo smartctl -a /dev/sdX