Agar siz virtual infratuzilmani VMware vSphere (yoki boshqa har qanday texnologiya stek) asosida boshqarsangiz, foydalanuvchilardan ko'pincha shikoyatlarni eshitasiz: "Virtual mashina sekin!" Ushbu maqolalar seriyasida men ishlash ko'rsatkichlarini tahlil qilaman va nima va nima uchun sekinlashayotganini va sekinlashmasligiga qanday ishonch hosil qilish kerakligini aytaman.
Men virtual mashina ishlashining quyidagi jihatlarini ko'rib chiqaman:
- MARKAZIY PROTSESSOR,
- Operativ xotira,
- DISK,
- Tarmoq.
Men CPUdan boshlayman.
Samaradorlikni tahlil qilish uchun bizga kerak bo'ladi:
- vCenter ishlash hisoblagichlari – grafiklarini vSphere Client orqali ko'rish mumkin bo'lgan ishlash hisoblagichlari. Ushbu hisoblagichlar haqidagi ma'lumot mijozning istalgan versiyasida mavjud (C# da qalin mijoz, Flex-da veb-mijoz va HTML5-da veb-mijoz). Ushbu maqolalarda biz C# mijozining skrinshotlaridan foydalanamiz, chunki ular miniatyurada yaxshiroq ko'rinadi :)
- ESXTOP – ESXi buyruq satridan ishlaydigan yordamchi dastur. Uning yordami bilan siz real vaqt rejimida ishlash hisoblagichlarining qiymatlarini olishingiz yoki keyingi tahlil qilish uchun ma'lum vaqt uchun ushbu qiymatlarni .csv fayliga yuklashingiz mumkin. Keyinchalik, men sizga ushbu vosita haqida ko'proq ma'lumot beraman va mavzu bo'yicha hujjatlar va maqolalarga bir nechta foydali havolalarni taqdim etaman.
Bir oz nazariya
ESXi-da alohida jarayon - VMware terminologiyasida dunyo - har bir vCPU (virtual mashina yadrosi) ishlashi uchun javobgardir. Bundan tashqari, xizmat ko'rsatish jarayonlari mavjud, ammo VM ishlashini tahlil qilish nuqtai nazaridan ular kamroq qiziq.
ESXi-dagi jarayon to'rtta holatdan birida bo'lishi mumkin:
- yugurish - jarayon ba'zi foydali ishlarni bajaradi.
- kutib turing - jarayon hech qanday ish qilmayapti (bo'sh) yoki kirish/chiqish kutilmoqda.
- Costop – ko‘p yadroli virtual mashinalarda yuzaga keladigan holat. Bu gipervisor protsessor rejalashtiruvchisi (ESXi CPU Scheduler) jismoniy server yadrolarida barcha faol virtual mashina yadrolarining bir vaqtning o'zida bajarilishini rejalashtira olmaganida yuzaga keladi. Jismoniy dunyoda barcha protsessor yadrolari parallel ishlaydi, VM ichidagi mehmon OS ham shunga o'xshash xatti-harakatni kutadi, shuning uchun gipervisor soat aylanishini tezroq tugatish qobiliyatiga ega bo'lgan VM yadrolarini sekinlashtirishi kerak. ESXi ning zamonaviy versiyalarida protsessor rejalashtiruvchisi bo'shashgan birgalikda rejalashtirish deb ataladigan mexanizmdan foydalanadi: gipervisor "eng tez" va "eng sekin" virtual mashina yadrosi (qiyshiq) o'rtasidagi bo'shliqni hisobga oladi. Agar bo'shliq ma'lum bir chegaradan oshsa, tezkor yadro kostop holatiga kiradi. Agar VM yadrolari bu holatda ko'p vaqt sarflasa, u ishlash bilan bog'liq muammolarga olib kelishi mumkin.
- tayyor - jarayon gipervisor uni bajarish uchun resurslarni ajrata olmaganida bu holatga kiradi. Yuqori tayyor qiymatlar VM ishlashi bilan bog'liq muammolarga olib kelishi mumkin.
Asosiy virtual mashina CPU ishlash hisoblagichlari
CPU foydalanish, %. Muayyan davr uchun protsessordan foydalanish foizini ko'rsatadi.
Qanday tahlil qilish kerak? Agar VM doimiy ravishda 90% protsessordan foydalansa yoki 100% gacha cho'qqilar bo'lsa, bizda muammolar bor. Muammolar nafaqat VM ichidagi dasturning "sekin" ishlashida, balki VM ning tarmoq orqali mavjud emasligida ham ifodalanishi mumkin. Agar monitoring tizimi VM vaqti-vaqti bilan tushib ketishini ko'rsatsa, CPU foydalanish grafigidagi eng yuqori nuqtalarga e'tibor bering.
Virtual mashinaning CPU yukini ko'rsatadigan standart signal mavjud:
Nima qilish kerak? Agar VM ning protsessordan foydalanishi doimiy ravishda tomdan o'tib ketsa, u holda siz vCPUlar sonini ko'paytirish (afsuski, bu har doim ham yordam bermaydi) yoki VMni kuchliroq protsessorlarga ega serverga o'tkazish haqida o'ylashingiz mumkin.
MGts da protsessordan foydalanish
VCenter Usage-dagi grafiklarda % da siz faqat butun virtual mashinani ko'rishingiz mumkin, alohida yadrolar uchun grafiklar mavjud emas (Esxtop-da yadrolar uchun % qiymatlari mavjud). Har bir yadro uchun MGts da foydalanishni ko'rishingiz mumkin.
Qanday tahlil qilish kerak? Ko'p yadroli arxitektura uchun dastur optimallashtirilmagan bo'ladi: u faqat bitta yadrodan 100% foydalanadi, qolganlari esa yuklamasdan ishlamaydi. Masalan, standart zaxira sozlamalari bilan MS SQL jarayonni faqat bitta yadroda boshlaydi. Natijada, zaxiralash disklarning sekin tezligi tufayli emas (foydalanuvchi dastlab shikoyat qilgan), balki protsessor bardosh bera olmagani uchun sekinlashadi. Muammo parametrlarni o'zgartirish orqali hal qilindi: zaxira bir nechta fayllarda (mos ravishda, bir nechta jarayonlarda) parallel ravishda ishlay boshladi.
Yadrolarga notekis yuklanish misoli.
Yadrolar notekis yuklangan va ularning ba'zilari 100% cho'qqilarga ega bo'lgan vaziyat ham mavjud (yuqoridagi grafikda bo'lgani kabi). Faqat bitta yadroni yuklashda bo'lgani kabi, protsessordan foydalanish uchun signal ishlamaydi (bu butun VM uchun), lekin ishlashda muammolar bo'ladi.
Nima qilish kerak? Agar virtual mashinadagi dasturiy ta'minot yadrolarni notekis yuklasa (faqat bitta yadro yoki yadrolarning bir qismini ishlatsa), ularning sonini ko'paytirishning ma'nosi yo'q. Bunday holda, VMni kuchliroq protsessorli serverga o'tkazish yaxshiroqdir.
Shuningdek, siz BIOS serveridagi quvvat sarfi sozlamalarini tekshirishga urinib ko'rishingiz mumkin. Ko'pgina ma'murlar BIOS-da yuqori unumdorlik rejimini yoqadi va shu bilan C-holatlari va P-holatlari energiya tejash texnologiyalarini o'chiradi. Zamonaviy Intel protsessorlari Turbo Boost texnologiyasidan foydalanadi, bu esa boshqa yadrolar hisobiga alohida protsessor yadrolarining chastotasini oshiradi. Lekin u faqat energiya tejovchi texnologiyalar yoqilganda ishlaydi. Agar biz ularni o'chirib qo'ysak, protsessor yuklanmagan yadrolarning quvvat sarfini kamaytira olmaydi.
VMware serverlarda energiya tejovchi texnologiyalarni o‘chirib qo‘ymaslikni, balki quvvatni boshqarishni imkon qadar gipervisorga qoldiradigan rejimlarni tanlashni tavsiya qiladi. Bunday holda, gipervisor quvvat sarfi sozlamalarida siz Oliy ishlashni tanlashingiz kerak.
Agar infratuzilmangizda protsessor chastotasini oshirishni talab qiluvchi individual VM (yoki VM yadrolari) bo‘lsa, quvvat sarfini to‘g‘ri sozlash ularning ish faoliyatini sezilarli darajada yaxshilashi mumkin.
CPU tayyor
Agar VM yadrosi (vCPU) Tayyor holatda bo'lsa, u foydali ishni bajarmaydi. Bu holat gipervisor virtual mashinaning vCPU jarayonini tayinlash mumkin bo'lgan bepul jismoniy yadroni topa olmaganida yuzaga keladi.
Qanday tahlil qilish kerak? Odatda, agar virtual mashinaning yadrolari 10% dan ko'proq vaqt tayyor holatda bo'lsa, unumdorlik bilan bog'liq muammolarni sezasiz. Oddiy qilib aytganda, vaqtning 10% dan ko'prog'i VM jismoniy resurslar mavjud bo'lishini kutadi.
vCenter-da CPU Ready bilan bog'liq 2 ta hisoblagichni ko'rishingiz mumkin:
- tayyorlik,
- Tayyor.
Ikkala hisoblagichning qiymatlarini ham butun VM uchun, ham alohida yadrolar uchun ko'rish mumkin.
Tayyorlik qiymatni darhol foiz sifatida ko'rsatadi, lekin faqat Real vaqt rejimida (oxirgi soat ma'lumotlari, o'lchov oralig'i 20 soniya). Ushbu hisoblagichni faqat "to'piqlarda issiq" muammolarni qidirish uchun ishlatish yaxshiroqdir.
Tayyor hisoblagich qiymatlarini tarixiy nuqtai nazardan ham ko'rish mumkin. Bu naqshlarni o'rnatish va muammoni chuqurroq tahlil qilish uchun foydalidir. Masalan, agar virtual mashina ma'lum bir vaqtda ishlashda muammolarga duch kela boshlasa, siz CPU Ready qiymatining intervallarini ushbu VM ishlayotgan serverdagi umumiy yuk bilan solishtirishingiz va yukni kamaytirish choralarini ko'rishingiz mumkin (agar DRS bo'lsa). muvaffaqiyatsiz).
Tayyor, Tayyorlikdan farqli o'laroq, foizlarda emas, millisekundlarda ko'rsatiladi. Bu Summation tipidagi hisoblagich, ya'ni o'lchash davrida VM yadrosi tayyor holatda qancha vaqt bo'lganligini ko'rsatadi. Ushbu qiymatni oddiy formuladan foydalanib foizga aylantirishingiz mumkin:
(CPU tayyor yig'indisi qiymati / (diagrammaning birlamchi yangilash oralig'i soniyalarda * 1000)) * 100 = CPU tayyor %
Misol uchun, quyidagi grafikdagi VM uchun butun virtual mashina uchun eng yuqori Ready qiymati quyidagicha bo'ladi:
Tayyor foizni hisoblashda siz ikkita nuqtaga e'tibor berishingiz kerak:
- Butun VM uchun Ready qiymati yadrolar bo'ylab Ready yig'indisidir.
- O'lchov oralig'i. Haqiqiy vaqt uchun bu 20 soniya va, masalan, kundalik grafiklarda bu 300 soniya.
Faol muammolarni bartaraf etish orqali ushbu oddiy fikrlarni osongina o'tkazib yuborish mumkin va mavjud bo'lmagan muammolarni hal qilish uchun qimmatli vaqtni behuda sarflash mumkin.
Quyidagi grafikdagi ma’lumotlarga asoslanib Ready ni hisoblaymiz. (324474/(20*1000))*100 = butun VM uchun 1622%. Agar siz yadrolarga qarasangiz, unchalik qo'rqinchli emas: 1622/64 = har bir yadro uchun 25%. Bunday holda, ushlashni aniqlash juda oson: Ready qiymati haqiqiy emas. Ammo agar biz bir nechta yadroli butun VM uchun 10-20% haqida gapiradigan bo'lsak, unda har bir yadro uchun qiymat normal diapazonda bo'lishi mumkin.
Nima qilish kerak? Yuqori Ready qiymati serverda virtual mashinalarning normal ishlashi uchun protsessor resurslari etarli emasligini ko'rsatadi. Bunday vaziyatda protsessor (vCPU: pCPU) tomonidan ortiqcha obunani kamaytirish qoladi. Shubhasiz, bunga mavjud VMlarning parametrlarini kamaytirish yoki VMlarning bir qismini boshqa serverlarga ko'chirish orqali erishish mumkin.
Birgalikda to'xtash
Qanday tahlil qilish kerak? Ushbu hisoblagich ham Summation turiga kiradi va Ready bilan bir xil tarzda foizlarga aylantiriladi:
(CPU birgalikda toʻxtash yigʻindisi qiymati / (diagrammaning birlamchi yangilanish oraligʻi soniyalarda * 1000)) * 100 = CPU birgalikda toʻxtashi %
Bu erda siz VMdagi yadrolar soniga va o'lchov oralig'iga ham e'tibor berishingiz kerak.
Kostop holatida yadro foydali ishni bajarmaydi. VM hajmini to'g'ri tanlash va serverdagi normal yuk bilan birgalikda to'xtash hisoblagichi nolga yaqin bo'lishi kerak.
Bunday holda, yuk aniq g'ayritabiiy :)
Nima qilish kerak? Agar bitta gipervizorda ko'p sonli yadroli bir nechta VM ishlayotgan bo'lsa va protsessorda ortiqcha obuna bo'lsa, u holda birgalikda to'xtash hisoblagichi ko'payishi mumkin, bu esa ushbu VMlarning ishlashi bilan bog'liq muammolarga olib keladi.
Bundan tashqari, agar bitta VM ning faol yadrolari giper-treading yoqilgan holda bitta jismoniy server yadrosidagi oqimlardan foydalansa, birgalikda to‘xtash kuchayadi. Bu holat, masalan, agar VM ishlayotgan serverda jismoniy mavjud bo'lgandan ko'ra ko'proq yadrolarga ega bo'lsa yoki VM uchun "afzal" sozlamasi yoqilgan bo'lsa paydo bo'lishi mumkin. Ushbu parametr haqida o'qishingiz mumkin .
Yuqori ko-stop tufayli VM ishlashi bilan bog'liq muammolarni oldini olish uchun ushbu VMda ishlaydigan dasturiy ta'minot ishlab chiqaruvchisi tavsiyalariga va VM ishlaydigan jismoniy serverning imkoniyatlariga muvofiq VM hajmini tanlang.
Zaxiraga yadro qo'shmang; bu nafaqat VMning o'zi, balki uning serverdagi qo'shnilari uchun ham ishlash muammolariga olib kelishi mumkin.
Boshqa foydali CPU ko'rsatkichlari
yugurish - o'lchash davrida vCPU qancha vaqt (ms) RUN holatida bo'lgan, ya'ni u haqiqatda foydali ishni bajargan.
Bo'ston - o'lchash davrida vCPU qancha vaqt (ms) harakatsizlik holatida bo'lgan. Kutishning yuqori qiymatlari muammo emas, vCPU-da shunchaki "hech narsa qilish kerak emas".
kutib turing - o'lchash davrida vCPU qancha vaqt (ms) kutish holatida bo'lgan. IDLE ushbu hisoblagichga kiritilganligi sababli, yuqori kutish qiymatlari ham muammoni ko'rsatmaydi. Ammo agar kutish yuqori bo'lsa, kutish bo'sh bo'lsa, bu VM kiritish/chiqarish operatsiyalari tugashini kutayotganini anglatadi va bu, o'z navbatida, qattiq disk yoki VMning har qanday virtual qurilmalari ishlashi bilan bog'liq muammoni ko'rsatishi mumkin.
Maksimal cheklangan – o‘lchash davrida vCPU qancha vaqt (ms) o‘rnatilgan resurs chegarasi tufayli Tayyor holatda bo‘lgan. Agar unumdorlik tushunarsiz darajada past bo'lsa, u holda VM sozlamalarida ushbu hisoblagichning qiymatini va CPU chegarasini tekshirish foydali bo'ladi. VM-lar haqiqatan ham siz bilmagan cheklovlarga ega bo'lishi mumkin. Masalan, bu protsessor chegarasi o'rnatilgan shablondan VM klonlanganida sodir bo'ladi.
Kutishni almashtiring – o‘lchash davrida vCPU VMkernel Swap bilan ishlashni qancha vaqt kutganligi. Agar ushbu hisoblagichning qiymatlari noldan yuqori bo'lsa, u holda VMda ishlash bilan bog'liq muammolar mavjud. RAM hisoblagichlari haqidagi maqolada SWAP haqida ko'proq gaplashamiz.
ESXTOP
Agar vCenter-dagi ishlash hisoblagichlari tarixiy ma'lumotlarni tahlil qilish uchun yaxshi bo'lsa, muammoni operativ tahlil qilish ESXTOPda yaxshiroq amalga oshiriladi. Bu erda barcha qiymatlar tayyor shaklda taqdim etiladi (hech narsani tarjima qilish shart emas) va minimal o'lchash davri 2 soniya.
CPU uchun ESXTOP ekrani "c" tugmasi bilan chaqiriladi va quyidagicha ko'rinadi:
Qulaylik uchun Shift-V tugmalarini bosib faqat virtual mashina jarayonlarini qoldirishingiz mumkin.
Alohida VM yadrolari uchun koʻrsatkichlarni koʻrish uchun “e” tugmasini bosing va qiziqqan VMning GID kodini kiriting (quyidagi skrinshotda 30919):
Sukut bo'yicha taqdim etilgan ustunlarni qisqacha ko'rib chiqaylik. Qo'shimcha ustunlar "f" tugmasini bosib qo'shilishi mumkin.
NWLD (dunyolar soni) - guruhdagi jarayonlar soni. Guruhni kengaytirish va har bir jarayon uchun ko'rsatkichlarni ko'rish uchun (masalan, ko'p yadroli VM ning har bir yadrosi uchun) "e" tugmasini bosing. Agar guruhda bir nechta jarayon mavjud bo'lsa, u holda guruh uchun metrik qiymatlar individual jarayonlar uchun ko'rsatkichlar yig'indisiga teng bo'ladi.
%FOYDALANILGAN - jarayon yoki jarayonlar guruhi tomonidan qancha server protsessor sikllari ishlatiladi.
% RUN - o'lchov davrida qancha vaqt davomida jarayon RUN holatida bo'lgan, ya'ni. foydali ish qildi. U %USED dan farq qiladi, chunki u giper-threading, chastota miqyosi va tizim vazifalariga (%SYS) sarflangan vaqtni hisobga olmaydi.
%SYS – tizim vazifalariga sarflangan vaqt, masalan: ishlov berishni uzish, kiritish-chiqarish, tarmoq bilan ishlash va hokazo. Agar VM katta kiritish/chiqarishga ega bo‘lsa, qiymat yuqori bo‘lishi mumkin.
%OVRLP – VM jarayoni ishlayotgan jismoniy yadro boshqa jarayonlarning vazifalariga qancha vaqt sarflagan.
Ushbu ko'rsatkichlar bir-biri bilan quyidagicha bog'liq:
%USED = %RUN + %SYS - %OVRLP.
Odatda %USED koʻrsatkichi koʻproq maʼlumot beradi.
%KUTMOQ - o'lchash davrida jarayon qancha vaqt kutish holatida bo'lganligi. IDLE ni yoqadi.
%IDLE - o'lchash davrida jarayon qancha vaqt IDLE holatida bo'lgan.
%SWPWT – o‘lchash davrida vCPU VMkernel Swap bilan ishlashni qancha vaqt kutganligi.
%VMWAIT - o'lchash davrida vCPU qancha vaqt voqeani kutish holatida bo'lgan (odatda I/O). vCenter-da shunga o'xshash hisoblagich yo'q. Yuqori qiymatlar VMda kiritish-chiqarish bilan bog'liq muammolarni ko'rsatadi.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Agar VM VMkernel Swap-dan foydalanmasa, unumdorlik muammolarini tahlil qilishda %VMWAIT-ga qarash tavsiya etiladi, chunki bu ko'rsatkich VM hech narsa qilmagan vaqtni (%IDLE) hisobga olmaydi.
%RDY – o‘lchash davrida jarayon qancha vaqt Tayyor holatda bo‘lganligi.
%CSTP - o'lchash davrida jarayon qancha vaqt kostop holatida bo'lganligi.
%MLMTD - o'lchash davrida vCPU qancha vaqt davomida o'rnatilgan resurs chegarasi tufayli Tayyor holatda edi.
%WAIT + %RDY + %CSTP + %RUN = 100% - VM yadrosi har doim ushbu to'rtta holatdan birida bo'ladi.
Gipervisorda protsessor
vCenter’da gipervisor uchun protsessor unumdorligi hisoblagichlari ham mavjud, ammo ular qiziq emas – ular shunchaki serverdagi barcha VMlar uchun hisoblagichlar yig‘indisidir.
Serverdagi CPU holatini ko'rishning eng qulay usuli Xulosa yorlig'ida:
Server uchun ham, virtual mashina uchun ham standart signal mavjud:
Server protsessor yuki yuqori bo'lsa, unda ishlaydigan VMlar ishlashda muammolarga duch kela boshlaydi.
ESXTOP-da server protsessorini yuklash ma'lumotlari ekranning yuqori qismida taqdim etiladi. Gipervizorlar uchun unchalik ma'lumotli bo'lmagan standart protsessor yukiga qo'shimcha ravishda yana uchta ko'rsatkich mavjud:
CORE UTIL(%) – jismoniy server yadrosini yuklash. Ushbu hisoblagich o'lchov davrida yadro qancha vaqt ishlaganligini ko'rsatadi.
PCPU UTIL(%) – agar giper-threading yoqilgan bo'lsa, u holda har bir jismoniy yadroda ikkita ip (PCPU) mavjud. Ushbu ko'rsatkich har bir ip ishni bajarish uchun qancha vaqt ketganini ko'rsatadi.
FOYDALANILGAN PCPU(%) – PCPU UTIL(%) bilan bir xil, lekin chastota masshtabini (yoki energiya tejash maqsadida asosiy chastotani kamaytirish yoki Turbo Boost texnologiyasi tufayli yadro chastotasini oshirish) va giper-tortishuvni hisobga oladi.
PCPU_USED% = PCPU_UTIL% * samarali yadro chastotasi / nominal yadro chastotasi.
Ushbu skrinshotda ba'zi yadrolar uchun Turbo Boost tufayli USED qiymati 100% dan yuqori, chunki yadro chastotasi nominaldan yuqori.
Hyper-threading qanday hisobga olinishi haqida bir necha so'z. Agar jarayonlar 100% serverning jismoniy yadrosining ikkala ipida bajarilsa, yadro nominal chastotada ishlayotgan bo'lsa, unda:
- Yadro uchun CORE UTIL 100% bo'ladi,
- Ikkala mavzu uchun PCPU UTIL 100% bo'ladi,
- PCPU ikkala ip uchun ham 50% ni tashkil qiladi.
Agar o'lchash davrida ikkala ip ham 100% ishlamagan bo'lsa, u holda iplar parallel ravishda ishlagan davrlarda yadrolar uchun USED PCPU yarmiga bo'linadi.
ESXTOP shuningdek, server protsessorining quvvat sarfi parametrlariga ega ekranga ega. Bu yerda siz server energiya tejovchi texnologiyalardan foydalanayotganini ko'rishingiz mumkin: C-holatlari va P-holatlari. "p" tugmasi bilan chaqiriladi:
Umumiy protsessor unumdorligi muammolari
Va nihoyat, men VM CPU ishlashi bilan bog'liq muammolarning odatiy sabablarini ko'rib chiqaman va ularni hal qilish uchun qisqa maslahatlar beraman:
Yadro soat tezligi etarli emas. Agar VM-ni kuchliroq yadrolarga yangilash imkoni bo'lmasa, Turbo Boost yanada samarali ishlashi uchun quvvat sozlamalarini o'zgartirishga urinib ko'rishingiz mumkin.
Noto'g'ri VM o'lchami (juda ko'p/kam yadro). Agar siz bir nechta yadrolarni o'rnatsangiz, VMda yuqori protsessor yuki bo'ladi. Agar juda ko'p bo'lsa, yuqori to'xtash joyini tuting.
Serverda protsessorga katta obuna. Agar VM yuqori tayyor bo'lsa, protsessorga ortiqcha obunani kamaytiring.
Katta VMlarda noto'g'ri NUMA topologiyasi. VM (vNUMA) tomonidan ko'rilgan NUMA topologiyasi serverning NUMA topologiyasiga (pNUMA) mos kelishi kerak. Diagnostika va ushbu muammoning mumkin bo'lgan echimlari, masalan, kitobda yozilgan . Agar siz chuqurroq borishni istamasangiz va VM-da o'rnatilgan operatsion tizimda litsenziyalash cheklovlari bo'lmasa, VM-da bir vaqtning o'zida bir yadroli ko'plab virtual rozetkalarni yarating. Siz ko'p narsani yo'qotmaysiz :)
Bu men uchun protsessor haqida. Savollar bering. Keyingi qismda men RAM haqida gapiraman.
Foydali havolalar
Manba: www.habr.com