## page was renamed from BulgarianDocumentation/linux_memory
= ... или "Защо няма свободна памет?" =

 Ревизия 2.3

 Български превод на [[http://forums.gentoo.org/viewtopic-t-175419-postdays-0-postorder-asc-start-0.html?sid=619cda6e4dae2a0651c474f9f5e4dfcf|Linux Memory Management or 'Why is there no free RAM?']] - английския оригинал е от sapphirecat.<<BR>>
 Bulgarian translation of [[http://forums.gentoo.org/viewtopic-t-175419-postdays-0-postorder-asc-start-0.html?sid=619cda6e4dae2a0651c474f9f5e4dfcf|Linux Memory Management or 'Why is there no free RAM?']] originally by sapphirecat.

 Авторско право 2004 sapphirecat. Текста е лицензиран под [[http://creativecommons.org/licenses/by-sa/2.0/|Creative Commons License.]]<<BR>>
 Copyright 2004 sapphirecat. The text of this post is licensed under a [[http://creativecommons.org/licenses/by-sa/2.0/|Creative Commons License.]]

Раздели

   1. Общ преглед на управлението на паметта
   2. Странния 880 MB лимит на x86
   3. Разликата между VIRT, RES, и SHR във изхода на top
   4. Разликата между буфери и кеш
   5. Swappiness (2.6 kernels) (параметър на ядрото, който... четете по-долу)



=== Общ преглед на управлението на паметта ===
Традиционните Unix инструменти като 'top' често показват изненадващо малък обем свободна памет след като систамата е работила известно време. Например след около 3 часа, на машината на която пиша този текст показва 60М свободна памет, при положение, че имам 512М RAM. Къде е отишло всичко?

Най-големият потребител за това е дисковия кеш, който в момента е 290Мб. Тази памет е показана от top като кеширана (cached). Кешираната памет е на практика свободна, като бързо може да бъде презаписана от работеща или новостартирана програма, нуждаеща се от памет.

Причината Linux да потребява толкова много памет за дисков кеш е, че RAM паметта се "пилее" ако не е използвана. Пазенето от друга страна на кеша е полезно в случай, че ако нещо има нужда от същите данни както преди, има шанс тези данни да са все още в кеша. Черпенето на информация от там е около 1000 пъти по-бързо от прочитането им от твърдия диск. Ако данните не са намерени в кеша, дискът трябва да бъде прочетен така или иначе, но време за това не се губи.

За да видим по-точно колко памет е достъпна за програмите стартираме командата:
{{{
free -m
}}}
"-m" опцията означава мегабайти и изхода ще е нещо подобно на това:
{{{
             total       used       free     shared    buffers     cached
Mem:           503        451         52          0         14        293
-/+ buffers/cache:        143        360
Swap:         1027          0       1027
}}}
Редът -/+ buffers/cache показва колко памет е използвана за кеш, но е свободна от гледна точка на приложенията. Накратко ако е използван малко суоп, използването на паметта няма ефект върху работата на компютъра като цяло.

Забележете че имам 512 MB памет на машината, но само 503 са показани като достъпни от "free". Това е главно защото ядрото не може да бъде изпратено в суоп, така че паметта за него никога не може да бъде освободена. Може да има и региони от паметта резервирани за/от хардуера за други цели, в зависимост от системната архитектура.



=== Странния 880 MB лимит на x86 ===
По подразбиране Linux ядрото стартира и управлява само долната (low) памет. Това прави управлението на таблиците на страниците малко по-лесно, което от своя страна води до малко по-бръз достъп до паметта. Тъмната страна на това е, че не може да се използва цялата памет, когато големината на RAM паметта приближи 880 MB. Това исторически не би било проблем, особено при десктоп машини.

За да бъде използвана цялата памет на машина с 1GB или повече, ядрото трябва да се прекомпилира. Идете в 'make menuconfig' (или който конфигуратор предпочитате) и включете следната опция:
{{{
Processor Type and Features ---->
High Memory Support ---->
(X) 4GB
}}}
Това е приложимо и при 2.4 и при 2.6 ядра. Настойката на поддръжка на високата (high) памет теоретично леко забавя достъпа, но съгласно Joseph_sys и log, практически няма разлика.



=== Разликата между VIRT, RES, и SHR във изхода на top ===
VIRT е съкращение на virtual size of a process (виртуален размер на процес), което е сумата от паметта, която процесът всъщност използва, паметта която е резервирал (например паметта на видеокартата за Х сървъра), файловете на диска, които е резервирал в себе си (най-вече споделени библиотеки) и паметта споделена с други процеси. VIRT представя паметта, която програмата може да достъпи в текущия момент.

RES е съкращение на resident size (резидентен размер), който е точно представяне на колко физическа памет консумира процеса. (Това също кореспондира директно с колонката %MEM.) Този размер виртуално ще бъде винаги по-малък от VIRT размера, след като повечето програми зависят от C библиотеката.

SHR показва колко от VIRT размера може да бъде споделен (памет или библиотеки). При библиотеките не означава задължително че цялата библиотека е резидентна. Например, ако програмата използва само няколко функции от библиотеката цялата библиотека ще бъде резервирана и ще се пресмята във VIRT и SHR, но само частите от библиотеката съдържащи използваните функции ще бъдат фактически заредени и калкулирани в RES.



=== Разликата между буфери и кеш ===
Буферите се асоциират със специфично блоково устройство, и показват кеширането на метаданните на файловата система, както и следенето на страниците "в полет" (страниците, които се четат в момента). Кешът съдържа само данни на паркирани файлове. Тоест, буферите "помнят" какво има в директориите, какви са правата на файловете и коя памет е била записвана или четена от специфично блоково устройство. Кешът държи само съдържанието на файловете.

Корекции и добавяния към секцията са добре дошли, това бяха моите заключения при разглеждането на /proc/meminfo.



=== Swappiness (2.6 kernels) ===
След ядро 2.6 вече има начин за настройка на съотношението на суопираната част към намаляването на кеша когато паметта започне да се запълва.

ghoti добави:
Когато приложение има нужда от памет и цялата RAM е заета, ядрото има два начина да освободи памет за използване: може да намали дисковия кеш в RAM като елиминира старите данни, или да суопира най-неизползваните порции (страници) от програмите върху суоп раздела на диска.
Не е лесно да се предскаже кой метод би бил по-ефективен.
Ядрото прави избор като грубо предполага ефективността на двата метода в даден момент, базирайки се на историята на активността до момента.

Преди ядрата 2.6, потребителят нямаше възможност да влияе на изчисленията и бяха възможни ситуации когато ядрото прави грешен избор, водещ до забавяне на системата. Добавянето на swappiness в ядрата 2.6 промени това.
Благодарности за ghoti!

Swappiness има стойности между 0 и 100 за промяна на баланса между суопиране на приложения и освобождаване на кеш. На 100 ядрото винаги предпочита суоп за неактивните страници; в други случаи суопирането зависи от това колко памет се потребява от приложението и колко зле се представя кеша при намиране и освобождаване на неактивни части.

По подразбиране стойността на swappiness е 60. Стойност 0 дава нещо подобно на старото поведение, където приложенията в глада си за памет могат да намалят кеша до миниатюрен размер от паметта. За лаптопи които биха предпочели дискът им да намали обороти (т.е. да не се ползва суоп по възможност) се препоръчва стойност 20 или по-малко.

Като параметър в sysctl, swappiness може да бъде зададен с някоя от командите:
{{{
# sysctl -w vm.swappiness=30
# echo 30 >/proc/sys/vm/swappiness
}}}
По подразбиране в Gentoo (и в Убунту) параметърът може да се настрои в /etc/sysctl.conf:
{{{
# Control how much the kernel should favor swapping out applications (0-100)
vm.swappiness = 30
}}}

Някои пачове позволяват на ядрото да настройва автоматично swappiness когато забележи подобие; тогава стойността зададена от потребителя може да не се запази.