Para sa mga nabasa na ang tungkol sa mga container at Docker , ngunit hindi nauunawaan kung paano naka-latch ang Java sa mga container. Una, i-refresh natin ang ating memorya tungkol sa Java memory . Hayaan akong ipaalala sa iyo na ang memorya ay binubuo ng Stack at Heap, na gumagamit ng RAM (random access memory) ng server; kapag nagsasalita pa tungkol sa memorya, ibig sabihin ay RAM. Ngayon tingnan natin ang lalagyan sa cross-section. Hindi, siyempre hindi, hindi kami interesado sa puwitan at hita, titingnan namin ang istraktura ng memorya sa lalagyan. Maaari itong hatiin sa tatlong bahagi: • Heap Memory – ang heap mismo; • Ang Off Heap ay lahat ng wala sa heap; • Ang OS Overhead ay ang memory overhead para sa pagpapatupad ng mga proseso sa loob ng container. Sabihin natin: Naglaan kami ng 1 Gb sa lalagyan, sa figure ito ay magiging Container Limit - ang mga hangganan nito ay ipinahiwatig ng isang asul na parihaba. Naglaan kami ng 80%, iyon ay, 0.8 Gb, para sa memorya ng Java sa lalagyan, at kinuha kami ng Heap ng humigit-kumulang 80% ng lalagyan, iyon ay, hindi mas mababa sa 0.8 Gb, dahil kinuha ng OS Overhead ang mga mapagkukunan (overhead) para sa pagpapanatili ng mga proseso. Humigit-kumulang 20% ng container ang natitira para sa lahat ng bagay na hindi konektado sa heap ( Off Heap ). Ang Nagamit na lugar sa figure ay nagpapakita ng ginamit na lugar ng memorya para sa pagpapatakbo ng application. Ngayon ay kailangan nating pag-usapan ang mga sitwasyon kung saan maaaring maubos ang memorya sa lalagyan. OutOfMemoryError Kung ang pagkonsumo ng memorya ng application ( Nagamit na lugar ) ay umabot sa mga limitasyon ng heap ( Heap ), makakakuha tayo ng OutOfMemoryError (OOM Error) . Na nagsasabing walang sapat na espasyo sa heap, ibig sabihin, sa lugar ng memorya kung saan inilalagay ang mga bagay na nilikha ng programmatically sa application. Kung hindi pa ito lubos na malinaw, ipapaliwanag ko ito sa mga pusa. Ang OOM Error ay kapag ang isang pusa ay sumisigaw nang matagal sa harap ng mga pintuan sa balkonahe, at kapag ang pintong ito ay binuksan, siya ay nakatayo sa pintuan at hindi pumunta sa alinmang paraan, madalas nilang sinasabi na ang pusa ay nagyelo. Kung itulak mo siya sa oras, malaglag ang kanyang panga at pumunta sa balkonahe upang gawin ang kanyang kitty business. OOM Killer Ito ay isa pang sitwasyon na maaaring mangyari sa isang container kapag naubusan ng memory. Kung ang isang program ay lumabas sa container, makakakuha tayo ng OutOfMemory Killer (OOM Killer) - ito ay isang proseso na nagwawakas sa application upang i-save ang kernel mula sa pag-crash. Isinakripisyo nito ang aplikasyon para mapanatiling tumatakbo ang lalagyan. Ito ay hindi isang katotohanan na ang lalagyan ay mahuhulog, ngunit ang application na tumatakbo dito ay tiyak na mahuhulog. Nangyayari ito kung hahayaan mong hindi kontrolado ang pagkonsumo ng memory ng isang Java application. Muli sa pusa. Kung nagpasya kang matulog nang mas matagal sa Sabado at nakalimutan mong bigyan ng pagkain ang mga pusa, pagkatapos ay OOM Killerang mga bulaklak ay garantisadong, ang mga kaldero ay maaaring hindi masira, ngunit ang mga bulaklak ay kailangang muling itanim. Ano ang pagkakaiba ng OOM Error at OOM Killer? Maaari mong iproseso ang OOM Error at magsagawa ng ilang pagkilos (halimbawa: sukatin ang application), at papatayin lang ng OOM Killer ang buong proseso. Ang OOM Killer ay katulad ng kill-9 (kill minus nine) - isang command na pumapatay sa isang proseso sa Linux . Ang bagay ay ang pinakasikat na pagpapatupad ng lalagyan ay ang lalagyan ng Docker, na nakabatay sa Linux , kahit na patakbuhin mo ito sa ilalim ng Windows , ang kernel ay mula pa rin sa Linux . Sa Linux, kami ay interesado sa isang konsepto: CGroups (English control group) - isang Linux kernel mechanism na naglilimita at naghihiwalay sa computing resources (processor, network, memory resources, I/O resources) para sa mga grupo ng mga proseso. Sa madaling salita, pinapayagan ka ng mekanismong ito na pamahalaan ang mga mapagkukunan sa isang lalagyan, sa aming memorya ng kaso. Paano nauugnay ang Java dito? Ito ay sa pamamagitan ng mekanismo ng CGroups na maaaring idikit ng Java sa memorya ng lalagyan. Ngunit ang lahat ay nakasalalay sa bersyon ng Java. Halimbawa, hindi alam ng Java 7 kung paano gamitin ang CGroups , at hindi alam nito ang mga limitasyon ng container. Bilang default, ang pinakamataas na laki ng heap = ¼ pisikal na memorya. Kung lumampas ang application sa mga limitasyon ng container, magkakaroon ng OOM Killer , at kung hindi nakatakda ang mga limitasyon ng container, kukuha ang application ng memory mula sa iba pang mga application sa server (mas mahusay na magtakda ng mga limitasyon, kung hindi, mawawala ang lahat) . Maaari mong, siyempre, gumamit ng mga setting ng heap o gumamit ng mga espesyal na "mga imahe" na lumulutas sa problemang ito, ngunit ang pinakamadaling paraan ay ang paggamit ng tamang bersyon ng Java. Ang mga tamang bersyon ay nagsisimula sa Java 8 x131 (na-port mula sa Java 9), nagsisimula itong maunawaan ang CGroups . At sa Java 10, lumitaw ang suporta para sa mga lalagyan: UseContainerSupport , mamaya ang function na ito ay nai-port sa Java 8 x 191 . O maaari mo lamang gamitin ang Java: 11+ . Ano ang maaaring maging konklusyon: Kapag gumagamit ng container memory, maaari kang makatanggap ng OutOfMemoryError (OOM Error) o OutOfMemoryKiller (OOM Killer). Sa unang kaso, hindi agad mag-crash ang application, maaaring mahuli ang OOM Error, maproseso at makokontrol ang mga aksyon. Halimbawa, sukatin ang application. Kung may naganap na OOM Killer, agad na mag-crash ang application, at wala nang matitirang opsyon para i-save ito. At ang pinakamasamang bagay ay ang panlabas na lalagyan mismo ay magiging maayos, iyon ay, hindi ka maaaring maghinala na may nahulog doon. Ginagamit ang mga mekanismo ng Linux upang makipag-ugnayan sa lalagyan at memorya ng Java. Ngunit hindi lahat ng Java ay nagpapatupad ng mga ito. Upang maiwasan ang mga problema para sa Java 8, kailangan mong gumamit ng bersyon na nagsisimula sa 131, o mas mabuti pa, mula sa 191. O gumamit ng Java: 11+. Para sa pagsasanay: OutOfMemoryError: hulihin ito kung magagawa mo
Hindi, siyempre hindi, hindi kami interesado sa puwitan at hita, titingnan namin ang istraktura ng memorya sa lalagyan. Maaari itong hatiin sa tatlong bahagi: • Heap Memory – ang heap mismo; • Ang Off Heap ay lahat ng wala sa heap; • Ang OS Overhead ay ang memory overhead para sa pagpapatupad ng mga proseso sa loob ng container. 
Sabihin natin: Naglaan kami ng 1 Gb sa lalagyan, sa figure ito ay magiging Container Limit - ang mga hangganan nito ay ipinahiwatig ng isang asul na parihaba. Naglaan kami ng 80%, iyon ay, 0.8 Gb, para sa memorya ng Java sa lalagyan, at kinuha kami ng Heap ng humigit-kumulang 80% ng lalagyan, iyon ay, hindi mas mababa sa 0.8 Gb, dahil kinuha ng OS Overhead ang mga mapagkukunan (overhead) para sa pagpapanatili ng mga proseso. Humigit-kumulang 20% ng container ang natitira para sa lahat ng bagay na hindi konektado sa heap ( Off Heap ). Ang Nagamit na lugar sa figure ay nagpapakita ng ginamit na lugar ng memorya para sa pagpapatakbo ng application. Ngayon ay kailangan nating pag-usapan ang mga sitwasyon kung saan maaaring maubos ang memorya sa lalagyan. OutOfMemoryError Kung ang pagkonsumo ng memorya ng application ( Nagamit na lugar ) ay umabot sa mga limitasyon ng heap ( Heap ), makakakuha tayo ng OutOfMemoryError (OOM Error) . Na nagsasabing walang sapat na espasyo sa heap, ibig sabihin, sa lugar ng memorya kung saan inilalagay ang mga bagay na nilikha ng programmatically sa application. 
Kung hindi pa ito lubos na malinaw, ipapaliwanag ko ito sa mga pusa. Ang OOM Error ay kapag ang isang pusa ay sumisigaw nang matagal sa harap ng mga pintuan sa balkonahe, at kapag ang pintong ito ay binuksan, siya ay nakatayo sa pintuan at hindi pumunta sa alinmang paraan, madalas nilang sinasabi na ang pusa ay nagyelo. Kung itulak mo siya sa oras, malaglag ang kanyang panga at pumunta sa balkonahe upang gawin ang kanyang kitty business. 
OOM Killer Ito ay isa pang sitwasyon na maaaring mangyari sa isang container kapag naubusan ng memory. 
Kung ang isang program ay lumabas sa container, makakakuha tayo ng OutOfMemory Killer (OOM Killer) - ito ay isang proseso na nagwawakas sa application upang i-save ang kernel mula sa pag-crash. Isinakripisyo nito ang aplikasyon para mapanatiling tumatakbo ang lalagyan. Ito ay hindi isang katotohanan na ang lalagyan ay mahuhulog, ngunit ang application na tumatakbo dito ay tiyak na mahuhulog. Nangyayari ito kung hahayaan mong hindi kontrolado ang pagkonsumo ng memory ng isang Java application. Muli sa pusa. Kung nagpasya kang matulog nang mas matagal sa Sabado at nakalimutan mong bigyan ng pagkain ang mga pusa, pagkatapos ay OOM Killerang mga bulaklak ay garantisadong, ang mga kaldero ay maaaring hindi masira, ngunit ang mga bulaklak ay kailangang muling itanim. 
Ano ang pagkakaiba ng OOM Error at OOM Killer? Maaari mong iproseso ang OOM Error at magsagawa ng ilang pagkilos (halimbawa: sukatin ang application), at papatayin lang ng OOM Killer ang buong proseso. Ang OOM Killer ay katulad ng kill-9 (kill minus nine) - isang command na pumapatay sa isang proseso sa Linux . 
Ang bagay ay ang pinakasikat na pagpapatupad ng lalagyan ay ang lalagyan ng Docker, na nakabatay sa Linux , kahit na patakbuhin mo ito sa ilalim ng Windows , ang kernel ay mula pa rin sa Linux . Sa Linux, kami ay interesado sa isang konsepto: CGroups (English control group) - isang Linux kernel mechanism na naglilimita at naghihiwalay sa computing resources (processor, network, memory resources, I/O resources) para sa mga grupo ng mga proseso. Sa madaling salita, pinapayagan ka ng mekanismong ito na pamahalaan ang mga mapagkukunan sa isang lalagyan, sa aming memorya ng kaso. Paano nauugnay ang Java dito? Ito ay sa pamamagitan ng mekanismo ng CGroups na maaaring idikit ng Java sa memorya ng lalagyan. Ngunit ang lahat ay nakasalalay sa bersyon ng Java. Halimbawa, hindi alam ng Java 7 kung paano gamitin ang CGroups , at hindi alam nito ang mga limitasyon ng container. Bilang default, ang pinakamataas na laki ng heap = ¼ pisikal na memorya. Kung lumampas ang application sa mga limitasyon ng container, magkakaroon ng OOM Killer , at kung hindi nakatakda ang mga limitasyon ng container, kukuha ang application ng memory mula sa iba pang mga application sa server (mas mahusay na magtakda ng mga limitasyon, kung hindi, mawawala ang lahat) . Maaari mong, siyempre, gumamit ng mga setting ng heap o gumamit ng mga espesyal na "mga imahe" na lumulutas sa problemang ito, ngunit ang pinakamadaling paraan ay ang paggamit ng tamang bersyon ng Java. Ang mga tamang bersyon ay nagsisimula sa Java 8 x131 (na-port mula sa Java 9), nagsisimula itong maunawaan ang CGroups . At sa Java 10, lumitaw ang suporta para sa mga lalagyan: UseContainerSupport , mamaya ang function na ito ay nai-port sa Java 8 x 191 . O maaari mo lamang gamitin ang Java: 11+ . Ano ang maaaring maging konklusyon: Kapag gumagamit ng container memory, maaari kang makatanggap ng OutOfMemoryError (OOM Error) o OutOfMemoryKiller (OOM Killer). Sa unang kaso, hindi agad mag-crash ang application, maaaring mahuli ang OOM Error, maproseso at makokontrol ang mga aksyon. Halimbawa, sukatin ang application. Kung may naganap na OOM Killer, agad na mag-crash ang application, at wala nang matitirang opsyon para i-save ito. At ang pinakamasamang bagay ay ang panlabas na lalagyan mismo ay magiging maayos, iyon ay, hindi ka maaaring maghinala na may nahulog doon. Ginagamit ang mga mekanismo ng Linux upang makipag-ugnayan sa lalagyan at memorya ng Java. Ngunit hindi lahat ng Java ay nagpapatupad ng mga ito. Upang maiwasan ang mga problema para sa Java 8, kailangan mong gumamit ng bersyon na nagsisimula sa 131, o mas mabuti pa, mula sa 191. O gumamit ng Java: 11+. Para sa pagsasanay: OutOfMemoryError: hulihin ito kung magagawa mo
GO TO FULL VERSION