અભ્યાસક્રમના વિદ્યાર્થીઓ માટે તૈયાર કરેલ લેખનો અનુવાદ "લિનક્સ એડમિનિસ્ટ્રેટર".

અગાઉ, મેં Linux પર Hugepages ને કેવી રીતે ચકાસવું અને સક્ષમ કરવું તે વિશે વાત કરી.
આ લેખ ફક્ત ત્યારે જ ઉપયોગી થશે જો તમારી પાસે ખરેખર વિશાળ પૃષ્ઠોનો ઉપયોગ કરવાની જગ્યા હોય. હું એવા ઘણા લોકોને મળ્યો છું જેઓ એવી સંભાવનાથી મૂર્ખ બન્યા છે કે વિશાળ પૃષ્ઠો જાદુઈ રીતે ઉત્પાદકતામાં સુધારો કરશે. જો કે, વિશાળ પેજીંગ એ એક જટિલ વિષય છે અને જો ખોટી રીતે ઉપયોગ કરવામાં આવે તો તે પ્રભાવને બગાડી શકે છે.

ભાગ 1: Linux (મૂળ અહીં)

સમસ્યા:
તમારી સિસ્ટમ પર HugePages સક્ષમ છે કે કેમ તે તમારે તપાસવાની જરૂર છે.

ઉકેલ:
તે ખૂબ સરળ છે:

cat /sys/kernel/mm/transparent_hugepage/enabled

તમને આના જેવું કંઈક મળશે:

always [madvise] never

તમે ઉપલબ્ધ વિકલ્પોની સૂચિ જોશો (હંમેશ, મદમસ્ત, ક્યારેય નહીં), અને હાલમાં સક્રિય વિકલ્પ કૌંસમાં બંધ કરવામાં આવશે (મૂળભૂત રીતે madvise).

madvise તેનો અર્થ છે transparent hugepages માત્ર મેમરી વિસ્તારો માટે જ સક્ષમ છે જે સ્પષ્ટપણે વિશાળ પૃષ્ઠોનો ઉપયોગ કરીને વિનંતી કરે છે મેડવાઈસ(2).

હંમેશા તેનો અર્થ છે transparent hugepages હંમેશા બધી પ્રક્રિયાઓ માટે સક્ષમ. આ સામાન્ય રીતે કાર્યક્ષમતામાં સુધારો કરે છે, પરંતુ જો તમારી પાસે ઉપયોગનો કેસ હોય જ્યાં ઘણી પ્રક્રિયાઓ થોડી માત્રામાં મેમરીનો ઉપયોગ કરી રહી હોય, તો એકંદર મેમરી લોડ નાટકીય રીતે વધી શકે છે.

ક્યારેય તેનો અર્થ છે transparent hugepages madvise નો ઉપયોગ કરીને વિનંતી કરવામાં આવે ત્યારે પણ સમાવેશ કરવામાં આવશે નહીં. વધુ જાણવા માટે, સંપર્ક કરો દસ્તાવેજીકરણ Linux કર્નલ.

ડિફૉલ્ટ મૂલ્ય કેવી રીતે બદલવું

વિકલ્પ 1: સીધો બદલો sysfs (રીબૂટ કર્યા પછી પેરામીટર તેના ડિફોલ્ટ મૂલ્ય પર પાછા આવશે):

echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled

વિકલ્પ 2: સંશોધિત રૂપરેખાંકન સાથે કર્નલને પુનઃકમ્પાઇલ કરીને સિસ્ટમ ડિફોલ્ટને બદલો (જો તમે વૈવિધ્યપૂર્ણ કર્નલનો ઉપયોગ કરી રહ્યાં હોવ તો જ આ વિકલ્પની ભલામણ કરવામાં આવે છે):

• હંમેશા ડિફૉલ્ટ રૂપે સેટ કરવા માટે, આનો ઉપયોગ કરો:

  CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
  # Comment out CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

• મેડવિઝને ડિફોલ્ટ તરીકે સેટ કરવા માટે, આનો ઉપયોગ કરો:

  CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
  # Comment out CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y

ભાગ 2: વિશાળ પૃષ્ઠોના ફાયદા અને ગેરફાયદા

અમે હ્યુજપેજનો ઉપયોગ કરવાના ફાયદા, ગેરફાયદા અને સંભવિત મુશ્કેલીઓને પસંદગીપૂર્વક સમજાવવાનો પ્રયાસ કરીશું. એક તકનીકી રીતે જટિલ અને પેડન્ટિક લેખ એ લોકો માટે સમજવું મુશ્કેલ હશે કે જેઓ વિશાળ પૃષ્ઠો એ રામબાણનો ઉપાય છે તેવું વિચારતા હોય છે, તેથી હું સરળતા માટે ચોકસાઈનો બલિદાન આપીશ. તે ધ્યાનમાં રાખવું યોગ્ય છે કે ઘણા બધા વિષયો ખરેખર જટિલ છે અને તેથી મોટા પ્રમાણમાં સરળ છે.

મહેરબાની કરીને નોંધ કરો કે અમે લિનક્સ ચલાવતી 64-બીટ x86 સિસ્ટમો વિશે વાત કરી રહ્યા છીએ, અને હું ફક્ત એમ ધારી રહ્યો છું કે સિસ્ટમ પારદર્શક વિશાળ પૃષ્ઠોને સપોર્ટ કરે છે (કારણ કે તે કોઈ ગેરલાભ નથી કે વિશાળ પૃષ્ઠો ઓવરરાઈટ ન થાય), જેમ કે લગભગ કોઈપણ આધુનિક Linux માં છે. પર્યાવરણ

હું નીચેની લિંક્સમાં વધુ તકનીકી વર્ણન જોડીશ.

વર્ચ્યુઅલ મેમરી

જો તમે C++ પ્રોગ્રામર છો, તો તમે જાણો છો કે મેમરીમાં ઑબ્જેક્ટ ચોક્કસ સરનામાં (પોઇન્ટર મૂલ્યો) ધરાવે છે.

જો કે, આ સરનામાંઓ જરૂરી નથી કે મેમરીમાં ભૌતિક સરનામાંઓને પ્રતિબિંબિત કરે (RAM સરનામાં). તેઓ વર્ચ્યુઅલ મેમરીમાં સરનામાંનું પ્રતિનિધિત્વ કરે છે. પ્રોસેસર પાસે ખાસ MMU (મેમરી મેનેજમેન્ટ યુનિટ) મોડ્યુલ છે જે કર્નલ મેપ વર્ચ્યુઅલ મેમરીને ભૌતિક સ્થાન પર બનાવવામાં મદદ કરે છે.

આ અભિગમના ઘણા ફાયદા છે, પરંતુ સૌથી મહત્વપૂર્ણ છે:

• પ્રદર્શન (વિવિધ કારણોસર);
• પ્રોગ્રામ આઇસોલેશન, એટલે કે, કોઈ પ્રોગ્રામ બીજા પ્રોગ્રામની મેમરીમાંથી વાંચી શકતો નથી.

પૃષ્ઠો શું છે?

વર્ચ્યુઅલ મેમરી પૃષ્ઠોમાં વહેંચાયેલી છે. દરેક વ્યક્તિગત પૃષ્ઠ ચોક્કસ ભૌતિક મેમરી તરફ નિર્દેશ કરે છે, તે RAM માં વિસ્તાર તરફ નિર્દેશ કરી શકે છે, અથવા તે ભૌતિક ઉપકરણને સોંપેલ સરનામાને નિર્દેશ કરી શકે છે, જેમ કે વિડિઓ કાર્ડ.

તમે જે પૃષ્ઠો સાથે વ્યવહાર કરો છો તેમાંના મોટાભાગનાં કાં તો RAM તરફ નિર્દેશ કરે છે અથવા અદલાબદલી થાય છે, એટલે કે તે તમારી હાર્ડ ડ્રાઇવ અથવા SSD પર સંગ્રહિત છે. કર્નલ દરેક પૃષ્ઠના ભૌતિક લેઆઉટનું સંચાલન કરે છે. જો સ્પુફ પેજ એક્સેસ કરવામાં આવે, તો કર્નલ થ્રેડને રોકે છે જે મેમરીને એક્સેસ કરવાનો પ્રયાસ કરી રહી છે, હાર્ડ ડ્રાઈવ/એસએસડીમાંથી RAM માં પેજ વાંચે છે, અને પછી થ્રેડને ચલાવવાનું ચાલુ રાખે છે.

આ પ્રક્રિયા સ્ટ્રીમ પારદર્શક છે, એટલે કે તે HDD/SSD માંથી સીધું વાંચે તે જરૂરી નથી. સામાન્ય પૃષ્ઠોનું કદ 4096 બાઇટ્સ છે. વિશાળ પૃષ્ઠોનું કદ 2 મેગાબાઇટ્સ છે.

ટ્રાન્સલેશન-એસોસિએટીવ બફર (TLB)

જ્યારે પ્રોગ્રામ મેમરીના પૃષ્ઠને ઍક્સેસ કરે છે, ત્યારે CPU એ જાણવું જોઈએ કે કયા ભૌતિક પૃષ્ઠમાંથી ડેટા વાંચવો છે (એટલે ​​​​કે, વર્ચ્યુઅલ સરનામાંનો નકશો હોવો જોઈએ).

કર્નલ પાસે ડેટા સ્ટ્રક્ચર (પૃષ્ઠ કોષ્ટક) છે જેમાં ઉપયોગમાં લેવાતા પૃષ્ઠો વિશેની તમામ માહિતી શામેલ છે. આ ડેટા સ્ટ્રક્ચરનો ઉપયોગ કરીને, તમે વર્ચ્યુઅલ એડ્રેસને ફિઝિકલ એડ્રેસ પર મેપ કરી શકો છો.

જો કે, પેજ ટેબલ એકદમ જટિલ અને ધીમું છે, તેથી જ્યારે પણ પ્રક્રિયા મેમરીને એક્સેસ કરે છે ત્યારે અમે સમગ્ર ડેટા સ્ટ્રક્ચરનું વિશ્લેષણ કરી શકતા નથી.

સદનસીબે, અમારા પ્રોસેસરમાં TLB છે જે વર્ચ્યુઅલ અને ફિઝિકલ એડ્રેસ વચ્ચે મેપિંગને કેશ કરે છે. આનો અર્થ એ છે કે જો કે અમારે પ્રથમ એક્સેસ પ્રયાસ પર પેજ ટેબલને પાર્સ કરવાની જરૂર છે, તો પણ પેજની તમામ અનુગામી એક્સેસને TLB માં હેન્ડલ કરી શકાય છે, જેનાથી ઝડપી કામગીરી થઈ શકે છે.

કારણ કે તે ભૌતિક ઉપકરણ તરીકે અમલમાં મૂકવામાં આવ્યું છે (જે તેને પ્રથમ સ્થાને ઝડપી બનાવે છે), તેની ક્ષમતા મર્યાદિત છે. તેથી જો તમે વધુ પૃષ્ઠોને ઍક્સેસ કરવા માંગતા હો, તો TLB તે બધા માટે મેપિંગ સંગ્રહિત કરી શકશે નહીં, જેના કારણે તમારો પ્રોગ્રામ ખૂબ ધીમો ચાલશે.

વિશાળ પૃષ્ઠો બચાવમાં આવે છે

તો TLB ઓવરફ્લો ટાળવા માટે આપણે શું કરી શકીએ? (અમે ધારીએ છીએ કે પ્રોગ્રામને હજી પણ એટલી જ મેમરીની જરૂર છે).

આ તે છે જ્યાં વિશાળ પૃષ્ઠો આવે છે. માત્ર એક TLB એન્ટ્રીની જરૂર હોય તેવા 4096 બાઈટને બદલે, એક TLB એન્ટ્રી હવે 2 મેગાબાઈટ્સનો નિર્દેશ કરી શકે છે. ચાલો ધારીએ કે TLB પાસે 512 એન્ટ્રીઓ છે, અહીં વિશાળ પૃષ્ઠો વિના આપણે મેચ કરી શકીએ છીએ:

4096 b⋅512=2 MB

તો પછી આપણે તેમની સાથે કેવી રીતે તુલના કરી શકીએ:

2 MB⋅512=1 GB

આ શા માટે વિશાળ પૃષ્ઠો અદ્ભુત છે. તેઓ વધુ પ્રયત્નો કર્યા વિના ઉત્પાદકતામાં સુધારો કરી શકે છે. પરંતુ અહીં નોંધપાત્ર ચેતવણીઓ છે.

વિશાળ પૃષ્ઠો સ્પુફિંગ

કર્નલ આપોઆપ મોનીટર કરે છે કે દરેક મેમરી પેજ કેટલી વાર વપરાય છે. જો ત્યાં પૂરતી ભૌતિક મેમરી (RAM) ન હોય, તો કર્નલ ઓછા મહત્વપૂર્ણ (ઓછી વારંવાર ઉપયોગમાં લેવાતા) પૃષ્ઠોને વધુ મહત્વપૂર્ણ પૃષ્ઠો માટે કેટલીક RAM ખાલી કરવા માટે હાર્ડ ડિસ્ક પર ખસેડશે.
સૈદ્ધાંતિક રીતે, તે જ વિશાળ પૃષ્ઠોને લાગુ પડે છે. જો કે, કર્નલ ફક્ત આખા પૃષ્ઠોને સ્વેપ કરી શકે છે, વ્યક્તિગત બાઇટ્સ નહીં.

ચાલો કહીએ કે અમારી પાસે આના જેવો પ્રોગ્રામ છે:

char* mymemory = malloc(2*1024*1024); // Возьмем это за одну Hugepage!
// Заполним mymemory какими-либо данными
// Сделаем много других вещей,
// которые приведут к подмене страницы mymemory
// ...
// Запросим доступ только к первому байту
putchar(mymemory[0]); 

આ કિસ્સામાં, કર્નલને હાર્ડ ડ્રાઇવ/એસએસડીમાંથી 2 મેગાબાઇટ્સ જેટલી માહિતી બદલવાની (વાંચવાની) જરૂર પડશે માત્ર એક બાઇટ વાંચવા માટે. નિયમિત પૃષ્ઠો માટે, હાર્ડ ડ્રાઇવ/એસએસડીમાંથી ફક્ત 4096 બાઇટ્સ વાંચવાની જરૂર છે.

તેથી, જો વિશાળ પૃષ્ઠને ઓવરરાઇડ કરવામાં આવ્યું હોય, તો જો તમારે સમગ્ર પૃષ્ઠને ઍક્સેસ કરવાની જરૂર હોય તો તે વાંચવું વધુ ઝડપી છે. આનો અર્થ એ છે કે જો તમે મેમરીના વિવિધ ભાગોને અવ્યવસ્થિત રીતે ઍક્સેસ કરવાનો પ્રયાસ કરી રહ્યાં છો અને માત્ર એક-બે કિલોબાઈટ વાંચી રહ્યાં છો, તો તમારે નિયમિત પૃષ્ઠોનો ઉપયોગ કરવો જોઈએ અને અન્ય કંઈપણ વિશે ચિંતા ન કરવી જોઈએ.

બીજી બાજુ, જો તમારે ક્રમશઃ મેમરીના મોટા ભાગને ઍક્સેસ કરવાની જરૂર હોય, તો વિશાળ પૃષ્ઠો તમારા પ્રદર્શનમાં સુધારો કરશે. જો કે, તમારે તેને જાતે ચકાસવાની જરૂર છે (અમૂર્ત સૉફ્ટવેર સાથે નહીં) અને જુઓ કે શું ઝડપથી કાર્ય કરે છે.

મેમરીમાં ફાળવણી

જો તમે C લખો છો, તો તમે જાણો છો કે તમે ઢગલામાંથી મનસ્વી રીતે નાની (અથવા લગભગ મનસ્વી રીતે મોટી) માત્રામાં મેમરીની વિનંતી કરી શકો છો. malloc(). ચાલો કહીએ કે તમને 30 બાઇટ્સ મેમરીની જરૂર છે:

char* mymemory = malloc(30);

પ્રોગ્રામરને, એવું દેખાઈ શકે છે કે તમે ઓપરેટિંગ સિસ્ટમમાંથી 30 બાઇટ્સ મેમરીની "વિનંતી" કરી રહ્યાં છો અને કેટલીક વર્ચ્યુઅલ મેમરી પર પોઇન્ટર પરત કરી રહ્યાં છો. પરંતુ વાસ્તવમાં malloc () માત્ર એક C ફંક્શન છે જે ફંક્શનની અંદરથી કૉલ કરે છે brk અને sbrk ઑપરેટિંગ સિસ્ટમમાંથી મેમરીની વિનંતી કરવા અથવા મુક્ત કરવા માટે.

જો કે, દરેક ફાળવણી માટે વધુ અને વધુ મેમરીની વિનંતી કરવી બિનકાર્યક્ષમ છે; સંભવ છે કે કેટલાક મેમરી સેગમેન્ટ પહેલાથી જ મુક્ત કરવામાં આવ્યા છે (free()), અને અમે તેનો ફરીથી ઉપયોગ કરી શકીએ છીએ. malloc() મુક્ત મેમરીનો પુનઃઉપયોગ કરવા માટે તદ્દન જટિલ અલ્ગોરિધમ્સ લાગુ કરે છે.

તે જ સમયે, તમારા માટે બધું અજાણ્યું થાય છે, તો તમારે શા માટે ચિંતા કરવી જોઈએ? પરંતુ કારણ કે પડકાર free() તેનો અર્થ એ નથી મેમરી ઓપરેટિંગ સિસ્ટમ પર તરત જ પાછી આવે તે જરૂરી છે.

મેમરી ફ્રેગમેન્ટેશન જેવી વસ્તુ છે. આત્યંતિક કિસ્સાઓમાં, ત્યાં ઢગલા સેગમેન્ટ્સ છે જ્યાં માત્ર થોડા બાઇટ્સનો ઉપયોગ કરવામાં આવે છે, જ્યારે વચ્ચેની દરેક વસ્તુ મુક્ત કરવામાં આવી છે. (free()).

મહેરબાની કરીને નોંધ કરો કે મેમરી ફ્રેગમેન્ટેશન એ અતિ જટિલ વિષય છે, અને પ્રોગ્રામમાં નાના ફેરફારો પણ નોંધપાત્ર અસર કરી શકે છે. મોટાભાગના કિસ્સાઓમાં, પ્રોગ્રામ્સ નોંધપાત્ર મેમરી ફ્રેગમેન્ટેશનનું કારણ બનશે નહીં, પરંતુ તમારે ધ્યાન રાખવું જોઈએ કે જો ઢગલાના અમુક વિસ્તારમાં ફ્રેગમેન્ટેશનની સમસ્યા હોય, તો વિશાળ પૃષ્ઠો પરિસ્થિતિને વધુ ખરાબ કરી શકે છે.

વિશાળ પૃષ્ઠોનો પસંદગીયુક્ત ઉપયોગ

આ લેખ વાંચ્યા પછી, તમે નક્કી કર્યું છે કે તમારા પ્રોગ્રામના કયા ભાગોને વિશાળ પૃષ્ઠોનો ઉપયોગ કરવાથી ફાયદો થઈ શકે છે અને કયા નહીં. તો શું વિશાળ પૃષ્ઠો બિલકુલ સક્ષમ હોવા જોઈએ?

સદભાગ્યે તમે ઉપયોગ કરી શકો છો madvise()માત્ર તે મેમરી વિસ્તારો માટે વિશાળ પેજીંગને સક્ષમ કરવા માટે જ્યાં તે ઉપયોગી થશે.

પ્રથમ, તપાસો કે વિશાળ પૃષ્ઠો madvise() મોડમાં ચાલી રહ્યું છે સૂચનો લેખની શરૂઆતમાં.

પછી, ઉપયોગ કરો madvise()વિશાળ પૃષ્ઠોનો ક્યાં ઉપયોગ કરવો તે કર્નલને બરાબર જણાવવા માટે.

#include <sys/mman.h>
// Аллоцируйте большое количество памяти, которую будете использовать
size_t size = 256*1024*1024;
char* mymemory = malloc(size);
// Просто включите hugepages…
madvise(mymemory, size, MADV_HUGEPAGE);
// … и задайте следующее
madvise(mymemory, size, MADV_HUGEPAGE | MADV_SEQUENTIAL)

નોંધ કરો કે આ પદ્ધતિ એ કર્નલને મેમરીનું સંચાલન કેવી રીતે કરવું તે અંગેની સલાહ છે. આનો અર્થ એ નથી કે કર્નલ આપેલ મેમરી માટે આપોઆપ વિશાળ પૃષ્ઠોનો ઉપયોગ કરશે.

દસ્તાવેજીકરણ નો સંદર્ભ લો (manpage)madviseમેમરી મેનેજમેન્ટ વિશે વધુ જાણવા માટે અને madvise(), આ વિષય અદ્ભુત રીતે બેહદ શીખવાની વળાંક ધરાવે છે. તેથી જો તમે તેમાં ખરેખર સારું મેળવવા ઇચ્છતા હોવ, તો તમે કોઈ હકારાત્મક પરિણામોની અપેક્ષા કરો તે પહેલાં થોડા અઠવાડિયા વાંચવા અને પરીક્ષણ કરવાની તૈયારી કરો.

શું વાંચવું?

• વિશાળ પૃષ્ઠો પર IBM OpenStack લેખ
• પારદર્શક વિશાળ પૃષ્ઠો વિ બિન-પારદર્શક વિશાળ પૃષ્ઠો
• TLB વિશે વિકિપીડિયા લેખ
• પારદર્શક વિશાળ પૃષ્ઠો પર Linux કર્નલ દસ્તાવેજીકરણ
• સ્ટેકઓવરફ્લો: વિશાળ પૃષ્ઠો મેમરી ફ્રેગમેન્ટેશન માટે સંવેદનશીલ હોય છે
• વર્ચ્યુઅલ મેમરી મેનેજમેન્ટ પર માઈક્રોસોફ્ટ લેખ

એક પ્રશ્ન છે? ટિપ્પણીઓમાં લખો!

સોર્સ: www.habr.com