Bagaimana cara mengetahui alasan keluarnya kontainer buruh pelabuhan?


104

Saya memiliki container Docker yang berjalan di host RAM 1G (ada juga container lain yang berjalan di host yang sama). Aplikasi dalam kontainer Docker ini akan mendekode beberapa gambar, yang mungkin menghabiskan banyak memori.

Dari waktu ke waktu, penampung ini akan keluar. Saya ragu itu karena kehabisan memori tetapi tidak terlalu yakin. Saya membutuhkan metode untuk menemukan akar masalahnya. Jadi adakah cara untuk mengetahui apa yang terjadi dengan kematian wadah ini?


5
Anda dapat memeriksa log untuk penampung itu melalui docker logs <container-id>.
techtabu

2
tetapi wadahnya telah keluar, saya kira saya tidak dapat mencatatnya lagi?
Li Bin

Baru saja mencoba di mesin saya. Anda masih dapat mengakses log meskipun penampung telah keluar.
Samuel Toh

Apakah Anda setidaknya mencoba?
techtabu

techtabu, ya saya lakukan. Itu tidak membantu
Li Bin

Jawaban:


122

Orang lain telah menyebutkan docker logs $container_iduntuk melihat keluaran aplikasi. Ini akan selalu menjadi hal pertama yang saya periksa.

Selanjutnya, Anda dapat menjalankan docker inspect $container_iduntuk melihat detail tentang status, misalnya:

    "State": {
        "Status": "exited",
        "Running": false,
        "Paused": false,
        "Restarting": false,
        "OOMKilled": false,
        "Dead": false,
        "Pid": 0,
        "ExitCode": 2,
        "Error": "",
        "StartedAt": "2016-06-28T21:26:53.477229071Z",
        "FinishedAt": "2016-06-28T21:26:53.478066987Z"
    },

Baris penting ada "OOMKilled" yang akan menjadi true jika Anda melebihi batas memori container dan Docker membunuh aplikasi Anda. Anda mungkin juga ingin mencari kode keluar untuk melihat apakah itu mengidentifikasi penyebab keluarnya aplikasi Anda.

Catatan, ini hanya menunjukkan jika buruh pelabuhan itu sendiri menghentikan proses Anda, dan mengharuskan Anda telah menetapkan batas memori pada penampung Anda. Di luar buruh pelabuhan, kernel Linux dapat melemahkan proses Anda jika host itu sendiri kehabisan memori. Linux sering menulis ke log in / var / log saat ini terjadi. Dengan Docker Desktop di Windows dan Mac, Anda dapat menyesuaikan memori yang dialokasikan ke VM Linux tertanam di pengaturan buruh pelabuhan.


9
Saya tidak mengerti di sini karena kontainer saya hilang, bagaimana cara "memeriksa" akan bekerja? Dari pembahasan di atas, setelah aplikasi mati, penampung juga akan mati. Maksud Anda, restart gambar yang sama lalu periksa?
Li Bin

9
@LiBin sebuah wadah tidak terhapus ketika mati, itu hanya sampai ke keadaan berhenti seperti status = berhenti atau keluar. 'buruh pelabuhan ps -a' dan lihat sendiri
Samuel Toh

Saya mendapatkan keluar 0 setiap kali menjalankan operasi intensif memori dan OOMKilled salah. Meningkatkan memori membuatnya berfungsi kembali.
Andrei

1
Hal ini dapat terjadi jika kernel Linux, bukan mesin buruh pelabuhan, yang mematikan proses dalam penampung. Anda akan sering melihatnya di log OS di bawah / var / log di host.
BMitch

5

Anda dapat mengetahui apakah proses di dalam wadah telah OOMkilled dengan membaca log. OOMkills diprakarsai oleh kernel sehingga setiap kali itu terjadi ada banyak baris /var/log/kern.log, misalnya:

python invoked oom-killer: gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=995
oom_kill_process+0x22e/0x450
Memory cgroup out of memory: Kill process 31204 (python) score 1994 or sacrifice child
Killed process 31204 (python) total-vm:7350860kB, anon-rss:4182920kB, file-rss:2356kB, shmem-rss:0kB

Jawaban ini membantu saya menemukan apa yang salah dengan penampung yang pekerja galangan akan restart saat keluar (inspeksi buruh pelabuhan tidak banyak membantu di sini).
m90

0

Meskipun jawaban yang diterima adalah pilihan terbaik, terkadang akan berguna untuk memeriksa konten jurnal juga dari host (di linux).

Anda dapat melakukannya dengan mengetik:

sudo journalctl -u docker

atau membuntutinya

sudo journalctl -u docker -f

atau menyalurkan output ke lebih sedikit jika terlalu panjang untuk buffer terminal Anda

journalctl -xn -u docker | less
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.