Ni kiasi gani cha kumbukumbu kinaweza kutolewa kweli katika Windows

Jibu fupi

Kile kinachoweza kutolewa kwa kweli ni kidogo kuliko wanavyoahidi “waboreshaji wa kumbukumbu”. Katika jaribio hili, kuzima vipengele vya chinichini kulitoa 1,0–1,5 GB ya kumbukumbu inayopatikana na kupunguza kiasi cha ahadi (commit) kwa 52 % katika mfululizo wa 2. Lakini njia za haraka maarufu hazifanyi kazi: kumaliza michakato ya ganda — Windows huzianzisha tena yenyewe katika takriban sekunde 20; kusafisha working set — kurasa zilizotolewa hubaki kwenye RAM kama kache; vigezo vya rejista vya kidhibiti cha kumbukumbu — hakuna faida iliyothibitishwa. Kuzima kwa kulenga juu ya mfumo ulioboreshwa tayari kulitoa +22–30 MB za kweli. Kumbukumbu iliyo kwenye orodha ya standby ni kache ambayo tayari imehesabiwa katika “inayopatikana”.

Hali: namba za mwisho zilipatikana katika mashine pepe yenye 8 GB RAM kwenye Windows 11 (26H2, build 26300.9457). Mielekeo imethibitishwa na nyaraka za Microsoft na majaribio yetu yaliyodhibitiwa; thamani kamili kwenye usanidi mwingine zitakuwa tofauti.

Madai yanayoweza kuthibitishwa

Tulithibitisha madai manne:

1. Kumaliza michakato ya chinichini “isiyo ya lazima” hutoa kumbukumbu.
2. Kusafisha working set au orodha ya standby (mbinu ya “waboreshaji wa RAM”) hutoa kumbukumbu.
3. Vigezo vya rejista vya kidhibiti cha kumbukumbu hutoa kumbukumbu kwa kiasi kinachoonekana.
4. Kuzima vipengele vya chinichini hutoa kiasi kikubwa cha kumbukumbu.

Wigo wa utafiti

• Windows 11 Pro, build 26300.9457 (26H2); mashine pepe, 8 GB RAM;
• hali mbili za usakinishaji mmoja: ya awali (“kabla”) na baada ya kutumia wasifu wa uboreshaji wa BoosterX — kipimo kilifanyika katika mfululizo mbili huru (itifaki ya kina na vipimo vingine — katika “Utulivu wa kimya: chinichini ya Windows kabla na baada ya uboreshaji”);
• juu ya hali ya “baada” — kifurushi cha kuzima kwa kulenga vyanzo vya chinichini (walogaji wa kiotomatiki wa uchunguzi wa ETW, huduma za arifa, kunakili kivuli na mratibu wa masasisho);
• vipimo: kumbukumbu inayopatikana na iliyotumika, kiasi cha ahadi (commit), nonpaged/paged pool, working set na private bytes kwa michakato, makosa ya kurasa (hard faults).

Hakukuwa na: maunzi halisi, mifumo yenye kiasi kingine cha RAM, majaribio ya kuzima pagefile na zana za nje za “uboreshaji wa kumbukumbu”.

Mbinu

• Orodha ya kumbukumbu ilichukuliwa katika utulivu ulioimarika: vihesabu vya mfumo (inayopatikana, iliyotumika, commit, pools) na orodha ya michakato yenye working set na private bytes.
• Jaribio lililodhibitiwa “maliza michakato ya ganda”: michakato miwili ya kiolesura ilisimamishwa (SearchHost.exe na StartMenuExperienceHost), hali ilikaguliwa baada ya sekunde 20 na 40; commit ilirekodiwa kabla na baada.
• Kifurushi cha kuzima kwa kulenga kilitumika kwa hali ya “baada”, kisha kuwasha upya na kulinganisha na upashaji nne wa udhibiti wa hali hiyo hiyo bila kifurushi; majaribio ya upashaji yalikagua kutokuwepo kwa kushuka kwa utendaji.
• Tabaka la kupima (ufuatiliaji, vihesabu, skripti za kukusanya) lenyewe huchukua kumbukumbu — hadi mia moja na zaidi ya MB ya working set katika vipimo vingine; hili limeelezwa katika mipaka.

Matokeo

Chinichini inachukua kiasi gani

Picha ya orodha katika utulivu (mfululizo wa 1):

	Kabla	Baada	Mabadiliko
Jumla ya working set, MB	3 841	1 868	−51 %
Jumla ya private bytes, MB	1 524	660	−57 %
Kumbukumbu inayopatikana, MB	5 490	6 518	+1 028

Mfululizo wa 2: kumbukumbu iliyotumika 3 017 → 1 538 MB, inayopatikana 5 174 → 6 653 MB, kiasi cha ahadi 2 617 → 1 249 MB. Mwelekeo unafanana katika mfululizo wote mawili: vipengele vya chinichini hushikilia takriban nusu ya kumbukumbu iliyotumika ya wasifu huu.

Muundo wa kumbukumbu iliyotumika

Katika hali ya “baada” kumbukumbu iligawanywa hivi (jumla ya working set, mfululizo wa 1):

• ganda (File Explorer, DWM, utafutaji kwenye menyu ya “Start”, nodi ya kikao) — takriban 640 MB;
• huduma za chinichini — takriban 640 MB (huduma 57 katika michakato 39 ya mwenyeji);
• kipengele cha wavuti cha utafutaji — takriban 320 MB;
• pools za kernel — takriban 167 MB, kati yake takriban 76 MB huchukuliwa na pools za rejista.

Working set ya mchakato hailingani na kumbukumbu inayotolewa: inajumuisha kurasa zinazoshirikiwa (msimbo wa maktaba za mfumo, data ya pamoja), ambazo huhesabiwa katika kila mchakato kwa wakati mmoja. Katika hali ya “baada” ya mfululizo wa 1 jumla ya working set ya michakato 75 ilikuwa 1 868 MB, na jumla ya private bytes — 660 MB; katika upashaji wa udhibiti wa jaribio la kuzima kwa kulenga jumla ya working set ilikuwa 2 036 MB. Michakato mikubwa ya kiolesura (mfululizo wa 2):

Mchakato	Working set, MB	Private, MB
SearchHost.exe (utafutaji)	187	80
explorer.exe (File Explorer)	167	36
StartMenuExperienceHost	107	24
dwm.exe (DWM)	73	34

Katika hali ya “baada” orodha ya standby ilikuwa 711 MB. Hii si kumbukumbu iliyopotea, bali kache: standby tayari imehesabiwa katika “inayopatikana”, na Windows hutumia kurasa hizi mara moja wakati programu inahitaji kumbukumbu.

Jaribio: kumaliza michakato ya ganda

Baada ya kusimamisha SearchHost.exe na StartMenuExperienceHost (mfululizo wa 2):

• michakato yote miwili ilianzishwa tena kiotomatiki katika takriban sekunde 20 na vitambulisho vipya; baada ya sekunde 40 ilikuwa bado inafanya kazi;
• kiasi cha ahadi hakikupungua, bali kiliongezeka kwa 12,6 MB (kutoka 1 386,9 hadi 1 399,5 MB) — kuanzisha tena michakato ya ganda yenyewe huunda kazi mpya;
• ongezeko la muda mfupi la kumbukumbu “inayopatikana” kwa 93 MB si akiba: michakato iliyolengwa ilirudi, commit iliongezeka.

Kumaliza File Explorer katika kipimo tofauti (mfululizo wa 1) pia hakukutoa ongezeko thabiti la kumbukumbu huru: katika kipindi hiki kumbukumbu huru hata ilipungua kwa 97 MB wakati standby iliongezeka kwa 13 MB — kurasa zilizotolewa hubaki kwenye mfumo kama kache, na ganda na michakato inayohusiana huendelea kufanya kazi.

Hitimisho la jaribio: kumaliza kwa nguvu michakato ya mfumo hakutoa kumbukumbu. Windows huanzisha tena vipengele vya ganda kiotomatiki, na badala ya akiba unapata mzigo wa ziada.

Kusafisha working set na orodha ya standby

Mbinu imeandikwa na Microsoft. Kutolewa kwa kurasa kutoka working set (kwa mfano, kwa kitendakazi EmptyWorkingSet au SetProcessWorkingSetSize chenye ukubwa “tupu” — ndivyo “waboreshaji wa RAM” wanavyotumia) huhamisha kurasa katika hali ya mpito: hubaki kwenye kache kwenye RAM hadi zitakapohitajika tena au kutumiwa upya. Kufikia mchakato kwa kurasa kama hiyo — kosa laini la kurasa na kurudi kwenye working set.

Kwa hiyo kusafisha working set hubadilisha namba ya “huru” kwenye vihesabu, lakini hakuundi kumbukumbu inayopatikana kifizikia: kurasa hazipotei popote, na kufikia tena kwao huwa ghali zaidi. Kusafisha orodha ya standby hakuna maana kwa sababu hiyo hiyo: standby ni kumbukumbu inayopatikana tayari kwa mfumo. Katika vipimo vyetu shinikizo la kumbukumbu halikuwepo katika hali zote mbili (hard faults zilibaki chini), kwa hiyo kutolewa kwa ziada hakuboresha chochote.

Kigezo chetu kutoka jaribio hili: matokeo ya “kutoa kumbukumbu” yanapaswa kupimwa kwa commit, makosa ya kurasa na ucheleweshaji wakati kumbukumbu inatumika tena, si kwa ongezeko la muda mfupi la mstari wa “huru”.

Kuzima kwa kulenga: ongezeko la kweli

Juu ya hali ya “baada” tulizima walogaji tisa wa kiotomatiki wa uchunguzi wa ETW na huduma nne za chinichini (arifa, kunakili kivuli, mratibu wa masasisho) na kulinganisha matokeo na upashaji nne wa udhibiti:

Kipimo	Upashaji wa udhibiti	Na kifurushi	Tofauti
Kumbukumbu huru, MB	6 664–6 674	6 696	+22…+30
Nonpaged pool, MB	69,8–71,8	58,7	−11…−13
Jumla ya working set, MB	2 036	1 959	−77
Utendaji wa majaribio	bila mabadiliko	bila mabadiliko	—

Walogaji pekee walitoa −13,2 MB ya nonpaged pool (ilipimwa tofauti). Muhimu: jumla ya working set ya vipengele vilivyozimwa kwa orodha ilikuwa takriban 78 MB, na ongezeko halisi la kumbukumbu huru — +22–30 MB. Tofauti hutokea kwa sababu sehemu ya “iliyozimwa” haikuwa imeanzishwa hata hivyo. Hii ndiyo mpaka wa kweli wa kuzima kwa kulenga bila kuondoa vipengele vya mfumo; kwa pembeni kifurushi hicho hicho kilipunguza shughuli za chinichini za utulivu kwa 24 % zaidi.

Vigezo vya rejista vya kidhibiti cha kumbukumbu (ukubwa wa pools, kache ya mfumo na vinavyofanana) katika jaribio hili hata hazikuzingatiwa kama chanzo cha faida: usomaji na manufaa yao ya kivitendo yamechanganuliwa katika “Memory Manager na kache ya mfumo” — hakuna faida iliyothibitishwa ya kutoa RAM kwao.

Kilichothibitishwa

• Kilirudiwa (mfululizo mbili): kuzima vipengele vya chinichini hutoa 1,0–1,5 GB ya kumbukumbu inayopatikana; jumla ya working set ilipungua kwa 51 % (mfululizo wa 1), kumbukumbu iliyotumika — kwa 49 % na kiasi cha ahadi (commit) — kwa 52 % (mfululizo wa 2).
• Kilipimwa: kuanzishwa tena kiotomatiki kwa michakato ya ganda iliyosimamishwa ndani ya sekunde 20; commit haipungui wakati huo (katika jaribio letu iliongezeka kwa 12,6 MB).
• Kilipimwa: kumaliza File Explorer hakutoa ongezeko thabiti la kumbukumbu huru; kurasa zilizotolewa hubaki kwenye standby.
• Kimeandikwa: kutolewa kwa kurasa kutoka working set huzihamisha katika hali ya mpito, iliyowekwa kwenye kache kwenye RAM; kumbukumbu ya standby huhesabiwa katika inayopatikana.
• Kilipimwa: kuzima kwa kulenga juu ya mfumo ulioboreshwa hutoa +22–30 MB ya kumbukumbu huru bila mabadiliko ya utendaji; jumla ya working set ya kilichozimwa hailingani na ongezeko la huru.

Kilichothibitishwa

• “Waboreshaji wa RAM” wa nje hawakujaribiwa moja kwa moja: mbinu (kusafisha working set) ambayo hujengwa juu yake ilikaguliwa.
• Kuzima pagefile hakukupimwa; inajulikana tu kwamba pagefile inahitajika kwa crash dump na kikomo cha ahadi za kumbukumbu.
• Kuhamisha thamani kwa mashine zenye kiasi kingine cha RAM, builds nyingine na maunzi halisi.
• Uthabiti wa akiba katika vipindi virefu: vipimo vilifanyika katika utulivu ulioimarika.

Mipaka

• Mashine pepe yenye 8 GB RAM: namba kamili zimefungwa kwa usanidi huu; wasifu wenye kiasi kikubwa cha vipengele vya chinichini utatoa zaidi, mfumo “mtulivu” — kidogo.
• Jumla ya working set kwa michakato huongeza athari ya kipekee kwa sababu ya kurasa zinazoshirikiwa; tunatoa private bytes kando kwa sababu hiyo.
• Tabaka la kupima lenyewe lilichukua kumbukumbu inayoonekana (hadi mamia ya MB ya working set katika vipimo vingine) — namba za hali zinajumuisha uwepo wa kipimo.
• Shinikizo la kumbukumbu halikuwepo katika jaribio (hard faults chini), kwa hiyo hatukukagua kama akiba hupunguza thrashing katika hali ya uhaba wa RAM.
• Sehemu ya kutoa inahusiana na kuzima vipengele vya ulinzi vya Microsoft Defender — hii ni maelewano na usalama, si kumbukumbu iliyopatikana bure.

Utafiti na zana zilizotumika ni mali ya mtengenezaji wa BoosterX, na BoosterX ni kiboreshaji cha Windows, kwa hiyo kupima athari ya uboreshaji ni maslahi yake ya moja kwa moja. Mbinu na mipaka ya matumizi yameelezwa hapo juu, na hitimisho zinaweza kuthibitishwa kwa data huria na vyanzo vya umma vilivyoorodheshwa. Matokeo hasi kuhusu njia maarufu za “kutoa kumbukumbu” yamechapishwa sawa na yale chanya.

Hitimisho la kivitendo

Kinachotoa kumbukumbu kwa kweli, kwa jaribio hili:

• funga programu zisizotumika — private bytes zao hutolewa kikamilifu;
• zima vipengele vya chinichini visivyo ya lazima kwa kweli — athari ya jumla iliyopimwa imeelezwa katika “Utulivu wa kimya”; hii ni njia pekee kati ya zilizokaguliwa iliyotoa gigabaiti, na gharama yake ni kupoteza vipengele vinavyohusiana;
• pima matokeo kwa commit na kumbukumbu inayopatikana (Task Manager → “Performance” → “Memory”), si kwa mstari wa “huru”.

Kinachofanya kazi:

• kumaliza kwa nguvu michakato ya mfumo: Windows huianzisha tena kwa sekunde, commit huongezeka;
• “waboreshaji wa RAM” na kusafisha standby: kurasa zilizotolewa hubaki kwenye RAM kama kache, na kuzirudisha kazini hugharimu makosa laini ya kurasa;
• vigezo vya rejista vya kidhibiti cha kumbukumbu.

Kumbukumbu ya standby si tatizo, bali ni kazi ya kache: “inayopatikana” tayari inaijumuisha. Pagefile iacheni chini ya udhibiti wa mfumo: inahitajika kwa kikomo cha ahadi za kumbukumbu na dumps za hitilafu.

Kurejesha hali

Majaribio yalifanyika katika mashine pepe iliyotengwa kwenye matawi ya majaribio ya hali; baada ya vipimo matawi ya majaribio yalifutwa, mashine ilirudishwa katika hali ya awali. Makala haipendekezi kumaliza michakato ya mfumo au kuzima pagefile, kwa hiyo hatua tofauti ya kurejesha kwenye kompyuta ya mtumiaji haihitajiki.

Vyanzo vya msingi vya umma

• Microsoft: Working Set — muundo wa working set, kutolewa kwa kurasa, kurasa za mpito, zilizowekwa kwenye kache kwenye RAM, na vitendakazi EmptyWorkingSet/SetProcessWorkingSetSize; ilikaguliwa 2026-09-20.
• Microsoft: EmptyWorkingSet — API inayotumiwa na zana za “uboreshaji wa kumbukumbu”; ilikaguliwa 2026-09-20.
• Microsoft: About Memory Management — modeli ya kumbukumbu pepe na kurasa zinazoshirikiwa; ilikaguliwa 2026-09-20.
• Microsoft: Introduction to the page file — commit charge, kikomo cha ahadi na jukumu la pagefile; ilikaguliwa 2026-09-20.
• Memory Manager na kache ya mfumo — utafiti wa vigezo vya rejista vya kidhibiti cha kumbukumbu.
• Utulivu wa kimya: chinichini ya Windows kabla na baada ya uboreshaji — itifaki ya vipimo na vipimo vingine vya jaribio hili hili.
• Jinsi tunavyochunguza Windows — ngazi za ushahidi na kanuni za vipimo.

Historia ya mabadiliko

• 2026-09-20: namba zililinganishwa na majedwali ya mfululizo: “baada” ya mfululizo wa 1 — 1 868/660 MB, uainishaji wa asilimia kwa vipimo na mfululizo umefafanuliwa; kanusho la mgongano wa maslahi limeimarishwa hadi uundaji kamili.
• 2026-09-20: uchapishaji wa kwanza — orodha ya kumbukumbu katika mfululizo mbili, majaribio hasi ya kumaliza michakato na kusafisha, ongezeko la kweli la kuzima kwa kulenga.