Kung nagdumala ka usa ka virtual nga imprastraktura nga gibase sa VMware vSphere (o bisan unsang uban pang teknolohiya nga stack), tingali kanunay ka makadungog mga reklamo gikan sa mga tiggamit: "Ang virtual nga makina hinay!" Niini nga serye sa mga artikulo akong analisahon ang mga sukatan sa pasundayag ug isulti kanimo kung unsa ug ngano nga kini hinay ug kung giunsa pagsiguro nga dili kini hinay.
Akong tagdon ang mosunod nga mga aspeto sa performance sa virtual machine:
- cpu,
- FRAME,
- DISK,
- Network.
Magsugod ko sa CPU.
Sa pag-analisar sa performance kinahanglan nato:
- vCenter Performance Counter – performance counters, ang mga graph nga makita pinaagi sa vSphere Client. Ang kasayuran sa kini nga mga counter magamit sa bisan unsang bersyon sa kliyente ("baga" nga kliyente sa C #, kliyente sa web sa Flex ug kliyente sa web sa HTML5). Sa kini nga mga artikulo magamit namon ang mga screenshot gikan sa kliyente sa C #, tungod lamang kay mas maayo kini tan-awon sa gamay :)
- ESXTOP – usa ka utility nga nagdagan gikan sa ESXi command line. Uban sa tabang niini, mahimo nimong makuha ang mga kantidad sa mga counter sa pasundayag sa tinuud nga oras o i-upload kini nga mga kantidad alang sa usa ka piho nga panahon sa usa ka .csv file alang sa dugang nga pagsusi. Sunod, isulti ko kanimo ang labi pa bahin sa kini nga himan ug maghatag daghang mapuslanon nga mga link sa dokumentasyon ug mga artikulo bahin sa hilisgutan.
Usa ka teoriya
Sa ESXi, usa ka bulag nga proseso - kalibutan sa terminolohiya sa VMware - ang responsable sa operasyon sa matag vCPU (virtual machine core). Adunay usab mga proseso sa serbisyo, apan gikan sa punto sa pagtan-aw sa pag-analisar sa pasundayag sa VM sila dili kaayo makapaikag.
Ang usa ka proseso sa ESXi mahimong sa usa sa upat ka estado:
- run – ang proseso naghimo sa pipila ka mapuslanon nga trabaho.
- maghulat – ang proseso walay pagbuhat sa bisan unsa nga trabaho (idle) o naghulat alang sa input/output.
- Gasto – usa ka kondisyon nga mahitabo sa multi-core virtual machines. Kini mahitabo kung ang hypervisor CPU scheduler (ESXi CPU Scheduler) dili maka-iskedyul sa dungan nga pagpatuman sa tanang aktibong virtual machine cores sa physical server cores. Sa pisikal nga kalibutan, ang tanan nga mga cores sa processor nagtrabaho nga managsama, ang bisita nga OS sa sulod sa VM nagpaabut sa parehas nga pamatasan, mao nga ang hypervisor kinahanglan nga hinayhinay ang mga VM core nga adunay katakus nga mahuman ang ilang siklo sa orasan nga mas paspas. Sa modernong mga bersyon sa ESXi, ang CPU scheduler naggamit ug mekanismo nga gitawag ug relaxed co-scheduling: gikonsiderar sa hypervisor ang gintang tali sa "labing paspas" ug sa "labing hinay" nga virtual machine core (skew). Kung ang gintang molapas sa usa ka piho nga sukaranan, ang paspas nga kinauyokan mosulod sa estado sa costop. Kung ang mga core sa VM mogugol ug daghang oras sa kini nga estado, mahimo’g hinungdan kini nga mga isyu sa pasundayag.
- Andam – ang proseso mosulod niini nga kahimtang sa diha nga ang hypervisor dili makahimo sa paggahin sa mga kapanguhaan alang sa iyang pagpatuman. Ang taas nga andam nga mga kantidad mahimong hinungdan sa mga problema sa pasundayag sa VM.
Basic virtual machine CPU performance counters
Paggamit sa CPU, %. Nagpakita sa porsyento sa paggamit sa CPU alang sa usa ka gihatag nga panahon.
Unsaon pag-analisa? Kung ang usa ka VM kanunay nga naggamit sa CPU sa 90% o adunay mga taluktok hangtod sa 100%, nan kami adunay mga problema. Ang mga problema mahimong ipahayag dili lamang sa "hinay" nga operasyon sa aplikasyon sa sulod sa VM, apan usab sa pagkadili maabot sa VM sa network. Kung ang sistema sa pagmonitor nagpakita nga ang VM matag karon ug unya mahulog, hatagi'g pagtagad ang mga peak sa CPU Usage graph.
Adunay usa ka standard nga Alarm nga nagpakita sa CPU load sa virtual machine:
Unsay akong buhaton? Kung ang Paggamit sa CPU sa VM kanunay nga moagi sa atop, nan mahimo nimong hunahunaon ang pagdugang sa gidaghanon sa mga vCPU (sa kasubo, dili kini kanunay nga makatabang) o pagbalhin sa VM sa usa ka server nga adunay labi ka kusgan nga mga processor.
Paggamit sa CPU sa MHz
Sa mga graph sa vCenter Usage sa % makita ra nimo ang tibuok virtual machine; walay mga graph para sa indibidwal nga mga cores (sa Esxtop adunay % values para sa mga cores). Alang sa matag kinauyokan imong makita ang Paggamit sa MHz.
Unsaon pag-analisa? Nahitabo nga ang usa ka aplikasyon wala ma-optimize alang sa usa ka multi-core nga arkitektura: kini naggamit lamang sa usa ka core nga 100%, ug ang uban wala’y trabaho nga wala’y karga. Pananglitan, uban sa default backup setting, MS SQL magsugod sa proseso sa usa lamang ka core. Ingon usa ka sangputanan, ang pag-backup nagpahinay dili tungod sa hinay nga tulin sa mga disk (kini ang una nga gireklamo sa tiggamit), apan tungod kay ang processor dili makasagubang. Nasulbad ang problema pinaagi sa pagbag-o sa mga parameter: ang backup nagsugod sa pagdagan nga managsama sa daghang mga file (sa matag usa, sa daghang mga proseso).
Usa ka pananglitan sa dili patas nga pagkarga sa mga cores.
Adunay usab usa ka sitwasyon (sama sa graph sa ibabaw) kung ang mga cores gikarga nga dili patas ug ang uban niini adunay mga peak nga 100%. Sama sa pagkarga sa usa ra ka kinauyokan, ang alarma alang sa Paggamit sa CPU dili molihok (kini alang sa tibuuk nga VM), apan adunay mga problema sa pasundayag.
Unsay akong buhaton? Kung ang software sa usa ka virtual nga makina nagkarga sa mga core nga dili patas (naggamit lamang sa usa ka core o bahin sa mga cores), walay kapuslanan ang pagdugang sa ilang gidaghanon. Sa kini nga kaso, mas maayo nga ibalhin ang VM sa usa ka server nga adunay labi ka kusgan nga mga processor.
Mahimo usab nimo sulayan pagsusi ang mga setting sa konsumo sa kuryente sa BIOS sa server. Daghang mga administrador ang makahimo sa High Performance mode sa BIOS ug sa ingon gi-disable ang C-states ug P-states nga mga teknolohiya sa pag-save sa enerhiya. Ang modernong Intel nga mga processor naggamit sa Turbo Boost nga teknolohiya, nga nagpadugang sa frequency sa tagsa-tagsa nga processor cores sa gasto sa ubang mga cores. Apan kini molihok lamang kung ang mga teknolohiya sa pagtipig sa enerhiya gi-on. Kung gi-disable namon kini, ang processor dili makapakunhod sa konsumo sa kuryente sa mga cores nga wala gikarga.
Girekomenda sa VMware nga dili pag-disable ang mga teknolohiya sa pag-save sa kuryente sa mga server, apan pagpili sa mga mode nga nagbilin sa pagdumala sa gahum sa hypervisor kutob sa mahimo. Sa kini nga kaso, sa hypervisor power consumption settings, kinahanglan nimo nga pilion ang High Performance.
Kung ikaw adunay indibidwal nga mga VM (o mga VM core) sa imong imprastraktura nga nanginahanglan dugang nga frequency sa CPU, ang husto nga pag-adjust sa konsumo sa kuryente mahimo’g makapauswag sa ilang pasundayag.
Andam na ang CPU
Kung ang VM core (vCPU) naa sa Ready nga estado, wala kini maghimo mapuslanon nga trabaho. Kini nga kahimtang mahitabo sa diha nga ang hypervisor wala makakita sa usa ka libre nga pisikal nga kinauyokan diin ang proseso sa vCPU sa virtual machine mahimong ma-assign.
Unsaon pag-analisa? Kasagaran, kung ang mga core sa virtual machine anaa sa Ready nga estado labaw sa 10% sa panahon, makamatikod ka sa mga isyu sa performance. Sa yanong pagkasulti, labaw pa sa 10% sa panahon nga ang VM naghulat alang sa pisikal nga mga kapanguhaan nga magamit.
Sa vCenter mahimo nimong tan-awon ang 2 nga mga counter nga may kalabutan sa CPU Ready:
- andam,
- Andam.
Ang mga kantidad sa parehas nga mga counter mahimong tan-awon alang sa tibuuk nga VM ug alang sa indibidwal nga mga cores.
Ang pagkaandam nagpakita sa bili diha-diha dayon isip porsyento, apan sa Real-time lamang (data alang sa katapusang oras, sukod sa interval 20 segundos). Mas maayo nga gamiton kini nga counter aron pangitaon ang mga problema nga "init sa mga tikod".
Ang mga andam nga kontra nga kantidad mahimo usab nga tan-awon gikan sa usa ka panan-aw sa kasaysayan. Kini mapuslanon alang sa pag-establisar sa mga sumbanan ug alang sa mas lawom nga pagtuki sa problema. Pananglitan, kung ang usa ka virtual nga makina magsugod sa pagsinati sa mga problema sa pasundayag sa usa ka piho nga oras, mahimo nimong itandi ang mga agwat sa kantidad nga Andam sa CPU sa kinatibuk-ang pagkarga sa server diin kini nga VM nagdagan, ug paghimo mga lakang aron makunhuran ang karga (kung DRS mapakyas).
Andam, dili sama sa Pagkaandam, gipakita dili sa porsyento, apan sa milliseconds. Kini usa ka Summation type counter, nga mao, kini nagpakita kung unsa kadugay sa panahon sa pagsukod ang VM core anaa sa Ready state. Mahimo nimong i-convert kini nga kantidad ngadto sa porsyento gamit ang usa ka yano nga pormula:
(CPU andam summation bili / (chart default update interval sa segundos * 1000)) * 100 = CPU andam %
Pananglitan, alang sa VM sa graph sa ubos, ang peak Ready value alang sa tibuok virtual machine mahimong ingon sa mosunod:
Kung gikalkula ang porsyento nga andam, kinahanglan nimo nga hatagan pagtagad ang duha ka punto:
- Ang Ready value sa tibuok VM mao ang sum sa Ready sa mga cores.
- Interval sa pagsukod. Alang sa Real-time kini 20 segundos, ug, pananglitan, sa adlaw-adlaw nga mga tsart kini 300 segundos.
Uban sa aktibo nga pag-troubleshoot, kini nga mga yano nga punto dali nga makalimtan ug ang bililhon nga oras mahimong magamit sa pagsulbad sa wala’y mga problema.
Atong kuwentahon ang Ready base sa datos gikan sa graph sa ubos. (324474/(20*1000))*100 = 1622% para sa tibuok VM. Kung imong tan-awon ang mga core dili kaayo makahadlok: 1622/64 = 25% kada core. Sa kini nga kaso, ang kuha dali ra makit-an: ang Ready nga kantidad dili realistiko. Apan kung naghisgot kami bahin sa 10-20% alang sa tibuuk nga VM nga adunay daghang mga cores, nan alang sa matag core ang kantidad mahimong naa sa sulod sa normal nga range.
Unsay akong buhaton? Ang usa ka taas nga Ready value nagpakita nga ang server walay igo nga mga kapanguhaan sa processor alang sa normal nga operasyon sa mga virtual machine. Sa ingon nga sitwasyon, ang nahabilin mao ang pagpakunhod sa sobra nga subskripsyon sa processor (vCPU:pCPU). Dayag, kini makab-ot pinaagi sa pagkunhod sa mga parameter sa kasamtangan nga mga VM o pinaagi sa pagbalhin sa bahin sa mga VM ngadto sa ubang mga server.
Co-stop
Unsaon pag-analisa? Kini nga counter kay sa Summation type ug gi-convert ngadto sa mga porsyento sa samang paagi sa Ready:
(CPU co-stop summation value / (chart default update interval sa mga segundo * 1000)) * 100 = CPU co-stop %
Dinhi kinahanglan nimo usab nga hatagan pagtagad ang gidaghanon sa mga core sa VM ug ang agwat sa pagsukod.
Sa costop nga estado, ang kernel wala maghimo ug mapuslanong trabaho. Uban sa husto nga pagpili sa gidak-on sa VM ug normal nga load sa server, ang co-stop counter kinahanglan nga duol sa zero.
Sa kini nga kaso, ang load klaro nga abnormal :)
Unsay akong buhaton? Kung daghang mga VM nga adunay daghang mga core ang nagdagan sa usa ka hypervisor ug adunay sobra nga subskripsyon sa CPU, nan ang co-stop counter mahimong modaghan, nga mosangput sa mga problema sa paghimo sa kini nga mga VM.
Usab, ang co-stop modaghan kung ang mga thread gigamit alang sa mga aktibo nga core sa usa ka VM sa usa ka pisikal nga server core nga adunay hyper-treading nga gipagana. Kini nga sitwasyon mahimong motumaw, pananglitan, kung ang VM adunay daghang mga core kaysa sa pisikal nga magamit sa server diin kini nagdagan, o kung ang setting nga "preferHT" gipagana alang sa VM. Makabasa ka bahin niini nga setting .
Aron malikayan ang mga problema sa performance sa VM tungod sa taas nga co-stop, pilia ang gidak-on sa VM sumala sa mga rekomendasyon sa tiggama sa software nga nagdagan niini nga VM ug ang mga kapabilidad sa pisikal nga server diin ang VM midagan.
Ayaw pagdugang sa mga core sa reserba; kini mahimong hinungdan sa mga problema sa pasundayag dili lamang alang sa VM mismo, kondili alang usab sa mga silingan niini sa server.
Uban pang mapuslanon nga mga sukatan sa CPU
run – pila ka oras (ms) sa panahon sa pagsukod ang vCPU naa sa kahimtang sa RUN, nga mao, kini sa tinuud naghimo ug mapuslanon nga trabaho.
Dili – unsa kadugay (ms) sa panahon sa pagsukod nga ang vCPU anaa sa kahimtang sa pagkadili aktibo. Ang taas nga mga kantidad sa Idle dili usa ka problema, ang vCPU wala’y mahimo.
maghulat – unsa kadugay (ms) sa panahon sa pagsukod ang vCPU anaa sa kahimtang sa Paghulat. Tungod kay ang IDLE gilakip sa kini nga counter, ang taas nga mga kantidad sa Paghulat wala usab magpakita usa ka problema. Apan kung ubos ang Wait IDLE kung taas ang Wait, kini nagpasabut nga ang VM naghulat alang sa mga operasyon sa I/O nga makompleto, ug kini, sa baylo, mahimong magpakita sa usa ka problema sa pasundayag sa hard drive o bisan unsang virtual nga aparato sa VM.
Max limitado – unsa ka dugay (ms) sa panahon sa pagsukod ang vCPU anaa sa kahimtang sa Andam tungod sa gitakdang limitasyon sa kahinguhaan. Kung ang pasundayag gamay ra kaayo, nan mapuslanon nga susihon ang kantidad sa kini nga counter ug ang limitasyon sa CPU sa mga setting sa VM. Ang mga VM mahimo nga adunay mga limitasyon nga wala nimo nahibal-an. Pananglitan, kini mahitabo kung ang usa ka VM gi-clone gikan sa usa ka template diin ang limitasyon sa CPU gitakda.
Pagbaylo paghulat - unsa ka dugay sa panahon sa pagsukod ang vCPU naghulat alang sa usa ka operasyon sa VMkernel Swap. Kung ang mga kantidad sa kini nga counter labaw sa zero, nan ang VM siguradong adunay mga problema sa pasundayag. Maghisgot pa kami bahin sa SWAP sa artikulo bahin sa mga counter sa RAM.
ESXTOP
Kung ang mga counter sa pasundayag sa vCenter maayo alang sa pag-analisar sa makasaysayan nga datos, nan ang pag-analisar sa operasyon sa problema mas maayo nga buhaton sa ESXTOP. Dinhi, ang tanan nga mga kantidad gipresentar sa andam nga porma (dili kinahanglan nga hubaron ang bisan unsa), ug ang minimum nga panahon sa pagsukod mao ang 2 segundos.
Ang ESXTOP screen alang sa CPU gitawag gamit ang "c" nga yawe ug ingon niini:
Alang sa kasayon, mahimo nimong biyaan ang mga proseso sa virtual machine pinaagi sa pagpindot sa Shift-V.
Para tan-awon ang metrics para sa indibidwal nga VM cores, pindota ang “e” ug isulod ang GID sa VM nga interes (30919 sa screenshot sa ubos):
Tugoti ako sa pag-adto sa kadali sa mga kolum nga gipresentar sa default. Ang dugang nga mga kolum mahimong idugang pinaagi sa pagpindot sa "f".
NWLD (Gidaghanon sa Kalibutan) – gidaghanon sa mga proseso sa grupo. Aron mapalapad ang grupo ug makita ang mga sukatan sa matag proseso (pananglitan, alang sa matag core sa usa ka multi-core VM), pindota ang "e". Kung adunay labaw pa sa usa ka proseso sa usa ka grupo, nan ang metric nga mga kantidad alang sa grupo parehas sa kantidad sa mga sukatan alang sa indibidwal nga mga proseso.
%GIGAMIT – pila ka server CPU cycles ang gigamit sa usa ka proseso o grupo sa mga proseso.
%MADAGAN - unsa ka dugay sa panahon sa pagsukod ang proseso anaa sa RUN state, i.e. nagbuhat ug mapuslanong trabaho. Lahi kini sa %USED tungod kay wala kini magtagad sa hyper-threading, frequency scaling ug oras nga gigugol sa mga buluhaton sa sistema (%SYS).
%SYS – oras nga gigugol sa mga buluhaton sa sistema, pananglitan: interrupt processing, I/O, network operation, ug uban pa. Ang bili mahimong taas kon ang VM adunay dako nga I/O.
%OVRLP – pila ka oras ang pisikal nga kinauyokan diin ang proseso sa VM gigugol sa mga buluhaton sa ubang mga proseso.
Kini nga mga sukatan adunay kalabotan sa usag usa sama sa mosunod:
%GINAMIT = %RUN + %SYS - %OVRLP.
Kasagaran ang %USED metric kay mas impormasyon.
%HULAT – unsa ka dugay sa panahon sa pagsukod ang proseso anaa sa kahimtang sa Paghulat. Makapahimo sa IDLE.
%IDLE – unsa ka dugay sa panahon sa pagsukod ang proseso anaa sa IDLE nga estado.
%SWPWT - unsa ka dugay sa panahon sa pagsukod ang vCPU naghulat alang sa usa ka operasyon sa VMkernel Swap.
%VMWAIT – unsa kadugay sa panahon sa pagsukod ang vCPU anaa sa kahimtang sa paghulat alang sa usa ka panghitabo (kasagaran I/O). Walay susama nga counter sa vCenter. Ang taas nga mga kantidad nagpakita sa mga problema sa I/O sa VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Kung ang VM wala mogamit sa VMkernel Swap, unya kung mag-analisa sa mga problema sa pasundayag mas maayo nga tan-awon ang% VMWAIT, tungod kay kini nga sukatan wala magtagad sa oras nga wala’y nahimo ang VM (%IDLE).
%RDY – unsa ka dugay sa panahon sa pagsukod ang proseso anaa sa kahimtang sa Andam.
%CSTP – unsa ka dugay sa panahon sa pagsukod ang proseso anaa sa costop state.
%MLMTD – unsa kadugay sa panahon sa pagsukod ang vCPU anaa sa kahimtang nga Andam tungod sa gitakdang limitasyon sa kahinguhaan.
%WAIT + %RDY + %CSTP + %RUN = 100% – ang VM core kanunay anaa sa usa niining upat ka estado.
CPU sa hypervisor
Ang vCenter usab adunay CPU performance counters alang sa hypervisor, apan kini walay bisan unsa nga makapaikag - kini mao lamang ang gidaghanon sa mga counter para sa tanang VM sa server.
Ang labing sayon nga paagi sa pagtan-aw sa kahimtang sa CPU sa server anaa sa tab nga Summary:
Alang sa server, ingon man sa virtual machine, adunay usa ka standard nga Alarm:
Kung taas ang karga sa CPU sa server, ang mga VM nga nagdagan niini magsugod nga makasinati mga problema sa pasundayag.
Sa ESXTOP, ang data sa pagkarga sa CPU sa server gipresentar sa ibabaw sa screen. Dugang pa sa standard nga load sa CPU, nga dili kaayo informative alang sa hypervisors, adunay tulo pa ka metrics:
CORE UTIL(%) - pagkarga sa pisikal nga server core. Gipakita niini nga counter kung pila ka oras ang pagtrabaho sa core sa panahon sa pagsukod.
PCPU UTIL(%) - kung ang hyper-threading gipagana, nan adunay duha ka mga hilo (PCPU) matag pisikal nga kinauyokan. Kini nga sukatan nagpakita kung unsa kadugay ang matag hilo aron makompleto ang trabaho.
PCPU GIGAMIT(%) – sama sa PCPU UTIL(%), apan gikonsiderar ang frequency scaling (bisan pagpakunhod sa core frequency alang sa energy saving purposes, o pagpataas sa core frequency tungod sa Turbo Boost technology) ug hyper-threading.
PCPU_USED% = PCPU_UTIL% * epektibo nga core frequency / nominal core frequency.
Sa kini nga screenshot, alang sa pipila ka mga core, tungod sa Turbo Boost, ang USED nga kantidad mas dako pa sa 100%, tungod kay ang core frequency mas taas kaysa sa nominal.
Pipila ka mga pulong kung giunsa ang pagkonsiderar sa hyper-threading. Kung ang mga proseso gipatuman 100% sa panahon sa duha ka mga hilo sa pisikal nga kinauyokan sa server, samtang ang kinauyokan naglihok sa nominal nga frequency, unya:
- Ang CORE UTIL alang sa kinauyokan mahimong 100%,
- Ang PCPU UTIL alang sa duha ka mga hilo mahimong 100%,
- Ang PCPU GAMITON alang sa duha ka mga hilo mahimong 50%.
Kung ang duha ka mga hilo wala molihok 100% sa panahon sa panahon sa pagsukod, unya sa mga panahon nga ang mga hilo nagtrabaho nga managsama, ang PCPU nga GIGAMIT alang sa mga cores gibahin sa tunga.
Ang ESXTOP usab adunay screen nga adunay mga parameter sa konsumo sa kuryente sa CPU sa server. Dinhi imong makita kung ang server naggamit sa mga teknolohiya sa pagluwas sa enerhiya: C-states ug P-states. Gitawag sa "p" nga yawe:
Kasagarang Mga Isyu sa Pagganap sa CPU
Sa katapusan, akong hisgotan ang kasagarang mga hinungdan sa mga problema sa pasundayag sa VM CPU ug maghatag mugbo nga mga tip sa pagsulbad niini:
Dili igo ang core clock speed. Kung dili posible nga i-upgrade ang imong VM sa labi ka kusgan nga mga cores, mahimo nimong sulayan ang pagbag-o sa mga setting sa kuryente aron mahimo ang Turbo Boost nga molihok nga mas episyente.
Sayop nga pagsukod sa VM (sobra ka daghan/diyutay nga mga cores). Kung mag-install ka pipila ka mga cores, adunay taas nga load sa CPU sa VM. Kung daghan, pagdakop ug taas nga co-stop.
Dako nga oversubscription sa CPU sa server. Kung ang VM adunay taas nga Ready, pagpakunhod sa sobra nga subskripsyon sa CPU.
Sayop nga NUMA topology sa dagkong mga VM. Ang NUMA topology nga makita sa VM (vNUMA) kinahanglang motakdo sa NUMA topology sa server (pNUMA). Ang mga diagnostic ug posible nga mga solusyon niini nga problema gisulat, pananglitan, sa libro . Kung dili nimo gusto nga mas lawom ug wala ka mga pagdili sa paglilisensya sa OS nga na-install sa VM, paghimo daghang mga virtual socket sa VM, usa ka core matag higayon. Dili kaayo ka mawala :)
Kana ang tanan alang kanako bahin sa CPU. Pangutana. Sa sunod nga bahin maghisgot ako bahin sa RAM.
Mapuslanon nga mga link
Source: www.habr.com