Титла: проблем с ram и swap Публикувано от: ko_drugo в Feb 12, 2007, 21:12 Здравейте, проблемът ми е следния: Наскоро си истеглих няколко теми за Super Karamba. Едната от тях е системен монитор. Когато и да го погледна имам най много 10-11 МБ свободни RAM, а от друга страна SWAP-а стои неизползван. Ако някой знае от какво е това да ми отговори.(аз съм на Fedora, ако е от значение)
Титла: проблем с ram и swap Публикувано от: Goust в Feb 12, 2007, 21:27 Ами попринцип първо се пълни рамта и после суап .
Титла: проблем с ram и swap Публикувано от: SHTILL в Feb 12, 2007, 22:03
И аз имам същия проблем, а съм с 1 гб рам... Титла: проблем с ram и swap Публикувано от: TheNightmare в Feb 12, 2007, 22:34 Тая тема е дискутирана милиони пъти. Нормално е да имате малко свободна рам. За повече инфо -> Търсачката!
Титла: проблем с ram и swap Публикувано от: neter в Feb 12, 2007, 23:06 Ае да се обадя и аз
![]() Монитора ти показва малко свободна памет, защото по-голямата част от останалото се използва за кеш. Не всичко се използва за работата на системата. Просто системата пази в кеша информация за програмите, за да може при следващото им включване да стартират по-бързо. Ако искаш, можеш да си редактираш файловете, за да ти показва информация за свободната памет + кеша или някаква друга комбинация ![]() Титла: проблем с ram и swap Публикувано от: ko_drugo в Feb 12, 2007, 23:13 Е, благодаря за бързия отговор! Наистина не знаех, че първо се пълни рам-а.
Титла: проблем с ram и swap Публикувано от: neter в Feb 12, 2007, 23:31 Зададено е RAM-та да се пълни първо и след това да се отива към swap-а, защото RAM паметта е по-бърза от харддиска и така, при обръщение към информацията, нещата се зареждат по-бързо. Точно заради това се кешира колкото може повече
Титла: проблем с ram и swap Публикувано от: Lord Bad в Feb 13, 2007, 10:49 Виж тази статия - тук. Там е описано как да регулираш съотношението между потребление на ram и swap.
Титла: проблем с ram и swap Публикувано от: gat3way в Feb 13, 2007, 11:20 От 2.6.17 нататък има вариант през procfs да форс-неш изхвърлянето от РАМ-та на (почти) всичкия cache - ако не се лъжа през /proc/sys/vm/drop_cache става номера.
Дори с по-старо 2.6 ядро това не е много сложно - имайки предвид колко свободна РАМ имаш, както и колко от нея е заета за кеширане, просто пишеш няколко реда програма, която malloc()-ва определен обем памет. Смъкваш swappiness на 0, за да изхвърляш максимално ефективно кешираната информация, вдигаш vfs_cache_pressure на някаква голяма стойност, защото линукския VMM упорито избягва да изхвърля от паметта малки обекти, каквито са inode/dentry кешираните глупости. След това компилираш програмката, викаш sync, за да се flush-нат и dirty буферите, и изпълняваш програмата. Обикновено почти никакъв кеш не е останал в паметта ако си сметнал колко памет да malloc()-невш като хората. Ако случайно си заделил повечко памет без да искаш (дори и много правилни сметки да си правил, не можеш да гарантираш, че някой процес не е заявил повечко памет точно тогава да речем) - тогава ще забележиш, че системата леко е навлязла в swap-a. Тъй като след тази операция със сигурност имаш освободена немалко оперативна памет, можеш спокойно да направиш swapoff -a;swapon -a, би трябвало да мине бързо и без грешки. Това всичкото при положение че имаш упоритото желание да гониш кешове от паметта де. В повечето случаи това е глупава идея, но наистина има варианти, в които се кешира абсолютно безсмислена информация - примерно ако монтираш отдалечена файлова система и и изчетеш директориите и след това я размонтираш или загубиш свързаност, почти всичкия vfs cache свързан с нея, ще остане в рам-та (buffer cache-a иначе ще се flush-не при umount). Друго приложение на горните методи е ако правиш тестове за прозводителност, за които кешът влияе силно върху крайните резултати. |