Fedora 32 ઓછી મેમરી માટે પ્રારંભિક પ્રતિસાદ માટે અર્લીલૂમનો સમાવેશ કરવા માગે છે

પ્રકાશિત યોજના સમાવિષ્ટો Fedora 32 પૃષ્ઠભૂમિ પ્રક્રિયાઓમાં મૂળભૂત રીતે પ્રારંભિક સિસ્ટમમાં ઓછી મેમરી માટે પ્રારંભિક પ્રતિભાવ માટે. જો ઉપલબ્ધ મેમરીની માત્રા નિર્દિષ્ટ મૂલ્ય કરતાં ઓછી હોય, તો SIGTERM (10% કરતા ઓછી મેમરી) અથવા SIGKILL (< 5%) મોકલીને અર્લીલૂમ એ પ્રક્રિયાને બળપૂર્વક સમાપ્ત કરશે જે મેમરીનો સૌથી વધુ સક્રિયપણે ઉપયોગ કરતી હોય (સૌથી વધુ/પ્રોક ધરાવતી હોય. /*/oom_score મૂલ્ય), સિસ્ટમની સ્થિતિને સિસ્ટમ બફર્સને ક્લીયર કરવાના મુદ્દા પર લાવ્યા વિના. Earlyoom તમને OOM (Out of Memory) હેન્ડલરને કૉલ કરવાના બિંદુ સુધી પહોંચ્યા વિના, મેમરીના અભાવને વધુ ઝડપથી પ્રતિસાદ આપવા દેશે. કર્નલ, જે ટ્રિગર થાય છે જ્યારે પરિસ્થિતિ ગંભીર બની જાય છે અને સિસ્ટમ, નિયમ તરીકે, વપરાશકર્તાની ક્રિયાઓને હવે પ્રતિસાદ આપતી નથી.

Fedora ના પછીના પ્રકાશનોમાં શક્યતા પર વિચાર કરવામાં આવી રહ્યો છે આઉટ-ઓફ-મેમરી હેન્ડલરને સક્ષમ કરો ઓછી મેમરી-મોનિટર, જે Linux કર્નલમાં રજૂ કરેલ એકનો ઉપયોગ કરે છે 5.2 સિસ્ટમમાં મેમરીના અભાવનું મૂલ્યાંકન કરવા માટે /proc/પ્રેશર/મેમરી ઇન્ટરફેસ, પરંતુ અર્લીલૂમથી વિપરીત તે તરત જ પ્રક્રિયાઓને સમાપ્ત કરતું નથી, પરંતુ મેમરી વપરાશ ઘટાડવાની જરૂરિયાત વિશે DBus દ્વારા સૂચના મોકલે છે (જો આ પછી પરિસ્થિતિ પાછી ન આવી હોય. સામાન્ય, સક્રિયકરણ શક્ય છે OOM કિલર કર્નલો). લો-મેમરી-મોનિટરને એપ્લીકેશનમાં ફેરફારની જરૂર છે, તેથી તેને લાંબા ગાળાના ઉકેલ તરીકે ગણવામાં આવે છે જેનો ઉપયોગ જીનોમ એપ્લીકેશનને અનુકૂલિત કર્યા પછી કરી શકાય છે.

Glib માં મેમરી સમાપ્ત થતી એપ્લિકેશન્સની પરિસ્થિતિને ટ્રૅક કરવા 2.63.3 API ઉમેર્યું GMemoryMonitor, પરવાનગી આપે છે લો-મેમરી-મોનિટરમાંથી સિગ્નલોનું નિરીક્ષણ કરો અને પગલાં લો (ઉદાહરણ તરીકે, એપ્લિકેશન કેશીંગ માટે ઉપયોગમાં લેવાતી મેમરીને મુક્ત કરી શકે છે, ફાઇલોને સાચવી શકે છે, કચરો એકત્ર કરી શકે છે, મેમરી ફ્રેગમેન્ટેશન ઘટાડવાનો પ્રયાસ કરી શકે છે અથવા નિષ્ક્રિય સહાયક પ્રક્રિયાઓને સમાપ્ત કરી શકે છે). આધાર
ફ્લેટપેક ફોર્મેટમાં વિતરિત સેન્ડબોક્સ્ડ એપ્લીકેશનમાં ઉપયોગ માટે Xdg-desktop-portal પર GMemoryMonitor પણ ઉમેરવામાં આવ્યું છે.

સોર્સ: opennet.ru