Изпечатай

[gotha]

Само да питам дали е нормално това:

Цитат

gotha@gotha-laptop:~$ uname -a Linux gotha-laptop 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686 GNU/Linux gotha@gotha-laptop:~$ free -m              total       used       free     shared    buffers     cached Mem:           883        848         35          0         58        321 -/+ buffers/cache:        469        414 Swap:         1984          0       1984

Машината е notebook asus a9rp с 1gb RAM, от която обаче си взема и видео картата - ATI Xpress 200M.
Притеснява ме не само това, че почти цялата RAM е заета, а и че нищо не е swap-нато.
Това нормално ли е ?

[dvbb]

Нормално е '>

[gat3way]

Щеше да е притеснително ако имаше нещо swap-нато.

[plamen_f]

Не ти го казвт другарите, но това е нормалното поведение на линукс - оптимално използване на ресурсите.

[gotha]

Благодаря за отговорите, но все пак ми е интересно кога започва да swap-ва?
Всичката RAM ли трябва да заеме за да започне да swap-ва ?
Май съм прекалено win32 обременен '>

ps. sry за lame темата '>

[neter]

Swap започва да се пълни тогава, когато няма достатъчно място за буферите в RAM паметта - от твоя пример, това са числата 469 (системен буфер) и 58 (периферен буфер) - като не е задължително целият периферен буфер да се вземе предвид, зависи от използването му. Отделената памет за кеш (числото 321 в примера) е опционално заета памет, т.е. нищо критично не зависи от нея, тя се заема само с цел увеличаване на бързодействието, така че тя не се взема предвид при определянето дали има нужда от заемане на swap. Да знаеш обаче, че част или целият кеш може да се прехвърли в swap паметта, за да се освободи повече място за буферите, за да може по-малко от тях да отидат в swap. Или казано по-иначе, чети числата така - в момента имаш реално използвани 527MB (469 + 58) и свободни 356МB (321 + 35), като 321MB от свободните са заети от кеш, който може да бъде изхвърлен по всяко време, ако тази памет потрябва за друго и swap паметта няма да започне да се пълни, преди да свършат тези 356MB '>

edit: Забравих да поясня - системният буфер е паметта, която се използва за работата на ядрото и приложния софтуер, а периферният буфер е паметта, която се използва от устройствата (мишки, клавиатури, твърди дискове, мрежата и т.н.).

[gat3way]

Ъъъ ами всъщност нещата не стоят точно така.

Ядрото кешира ужасно много неща, но най-голям процент от тях е pagecache-a. В днешната (2.6) дефиниция за това попадат:

* блокове изчетени или за writeback-ване от/върху блокови устройства, напр. /dev/sda1. Затва например копирането на по-големи файлове става по-бързо когато имаш повече РАМ '>

* всякакви mmap()-нати файлове. В това число влизат и shared библиотеки и exec-нати binaries например и затова  използването на едни и същи библиотеки става по-бързо и повторното стартиране на една програма - тоже.

Тези неща съставят това, което free показва като "cached". Самото разделение 'buffers/cached' е малко глупаво и смислово не е много вярно за момента. Всичко вътре е кеширана информация някаква.

Останалите неща, които се кешират и влизат в графата "buffers" са VFS информация (inode кеш, съдържания на директории - затова вторият път като пуснеш find срещу голяма директория, минава по-бързо). Но има и още много други неща де (cat /proc/slabinfo).

Съответно има механизми, които изчистват всичката кеширана информация, която може (за малка част от нея е невъзможно).  Има механизми за тунинговане на нещата. Най-вече понеже паметта е ограничена и не може да се кешира абсолютно всичко, чрез procfs може да се контролира дали да се набляга на кеширането на VFS cache или на pagecache. Параметри, които контролират при заявяване на нова памет дали да се изхвърлят кешове от паметта или да се влиза в суоп-а и в какво съотношение (swappiness).

По дефолт (макар че не е гаранция), когато един процес заяви памет и няма свободна, се изхвърлят най-отдавна използваните кешове от паметта, за да може програмата да се вмести в РАМ-та. В този случай, цялото това buffers+cache може да се приема дефакто като свободна памет.

Това е добра стратегия в много случаи, но в никакъв случай не е оптимална. Това означава, че ако пуснеш една ядяща памет като свиня програма и я държиш на заден фон да мързелува, дефакто губиш производителност, защото нямаш достатъчно памет за кешове. Тогава е добре swappiness да ти е повече от 0.

Обаче ако раздутата програма влезе в суоп-а, тогава кликването вървху нея ще трябва да изкара мегабайти от суопа, а това става бавно, т.е системата като цяло е по-малко responsive.


Кешираната информация НИКОГА не влиза в суопа - това е безсмислено разхищение на суоп памет, на дисково I/O и на процесорно време. Еб*л съм ти кеша дето за да го достъпиш трябва да го чакаш да се изкара от суопа и това да стане по-бавно ако въобще не се минаваше през кеширането. Просто се губи смисъла.


Гррр трябва да се науча да си преглеждам кво пиша преди да го постна, а не да го редактирам след тва '>

[ilian_BIOS]

Цитат (gotha @ Окт. 22 2008,17:57)

..Май съм прекалено win32 обременен '>

Нещата с паметта при Windows не стоят така както ти си мислиш...

[Ivshti]

Разбира се, че кешираното не влиза в swap-а: (примерно) какъв е смисъла да записва един кеширан executable файл в swap-a, вместо да не си го кешира ваобще: той си е на диска '>

Именно за това държанието на swap-а ти се струва странно.

Такива неща изглеждат като проблеми в Linux и му слагат етикет "боза", защото примерно не чисти използвана памет докато не потрябва на ядрото. Тези технологии се възползват доста добре от повече RAM.

Наскоро четох едно такова изказване, в което един се оплаква от Linux, че сървъра му когато го пуснал ползвал 50 MB RAM, с течение на времето, без видима причина, ползването станало на 210 MB. Това се дължи точно на това нечистене на паметта докато не потрябва '>

[gotha]

wow, благодаря за подробните обяснения.

Цитат (ilian_BIOS @ Окт. 22 2008,20:59)

Нещата с паметта при Windows не стоят така както ти си мислиш...

А как? Не искам да ми обясняваш, ако може един линк бих бил доволен.
Интересно ми е да прочета как стават тези неща при Linux, windows, mac, bsd и т.н., но не знам какво да търся. '>

gat3way, neter, благодаря отново '>

[gat3way]

Доколкото знам в windows нещата стоят по същият начин, но просто операционната система показва pagecache-a като "свободна памет" и там разни такива фини настройки по въпроса липсват (обаче за последното не съм сигурен, щото не им разбирам от уиндоусите толкова, може пък и да има разни registry keys примерно). Идеята за pagecache е много стара, още в DOS имаше някаква тъкава тъпня която кешираше изчетени/такива за запис блокове от диска. Това си спомням ускоряваше доста някои игри '> Вече не помня как се казваше програмата, но беше част от операционната система.

В линукс преди време "buffer cache" е значело точно това (дисковия кеш), а pagecache - съответно тези mmap()-вани неща, които се пазят в кеша и се изпълняват оттам или в случая с библиотеките директно се мапват в адресното пространство на новите процеси, линкнати с тая библиотека. Оттам е останало това buffers/cached, но сега pagecache включва и дисковия кеш и дефакто buffers не съдържа "buffer cache", забавно '>

А как точно става в детайли е забавен въпрос  и е всъщност  доста дебела работа. Не съм точно аз компетентен да говоря за memory management, но все пак поне в основи как работи '> Ако те интересува повече може да опиша paginga накратко как работи. Предполагам във всички други операционни системи нещата са малко или много сходни, не вярвам да има някакви генерални разлики '>

[ilian_BIOS]

Наистина интересна тема, Gotha - http://www.aumha.org/win5/a/xpvm.php

С това което каза, си помислих че се опитваш да кажеш че Windows ползва swap постоянно, от мой наблюдения като ползвах Линукс на 1 гб рам като се опитвах да играя игри съм забелязвал даже по кофти поведение от Windows със суапването (моля без нападки) после 10 минути не мога да изляза от суапа '> в момента с 2 гб рам на XP цялата система се кеширва в рам и ако не играя игри системата лети '> обаче не успяваm да разбера особенно идеята за Pagefile някой може да поясни (Gat3way) '> , ясно ми е че линукс memory managment-a е по добър от windows '> иначе интересни неща '> и във Vista съм забелязал че винаги оставя фрее мемори много малко подобно на линукс, докато ХП показва цялата фрее памет, но пише и систем кеш (1,7 гб при мен в момента на 12 дена up) ето и нещо интересно от cmd
System Up Time:            12 Days, 3 Hours, 56 Minutes, 18 Seconds
 - Total Physical Memory:     2 047 MB
Available Physical Memory: 1 627 MB
Virtual Memory: Max Size:  2 048 MB
Virtual Memory: Available: 2 008 MB
Virtual Memory: In Use:    40 MB
 не съм забелязвал Virtual memory in use да скача повече от 40 мб каквото и да става и не мога да си обясня какво точно прави '>
пп мисля че имаше един трик, във system.ini - VirtualMemory=0 или нещо такова което оказваше да се използва ПФ или виртуалната не се сещам да се използва само ако няма достатъчно физическа памет '> (не съм никак компетентен по тая тема '> )

[Ivshti]

В Mac OS X мисля, че стоят както в BSD, защото е базирана на FreeBSD и не са правени съществени модификации.
Единственото, което знам за мемори мениджмънта на BSD е, че за разлика от Linux, освобождава памет още преди да се изисква.

[gat3way]

pagefile е еквивалента на swap file/partition в линукс. Идеята е много проста - като не ти достига физическа РАМ да ползваш дискова такава. Как става това е доста по-сложна работа.

Първо трябва да се почне оттам, че с 386 процесорите се въвежда защитения режим и страницирането на памет. Горното значи, че паметта се "разбива" на страници по 4 килобайта и има структури от данни (pagetables) в паметта, които осъществяват мапировка - страници от физическата РАМ на някакъв адрес се мапират върху страници от "виртуалната" РАМ, а тези таблици пазят информация за мапировката. Също така пазят и информация дали тази памет може да се чете, пише и при x86_64 - да се "изпълнява", може да пазят и друга информация, например дали страницата е в суоп-а. Съответно хардуерът може да помага, чрез нещо наречено TLB - това е буфер, съдържащ ентри-та от pagetable-a и се нахожда нейде из процесорните кешове => достъпва се по-бързо от физическата РАМ. Благодарение на това странициране се постига голяма гъвкавост и се постигат 2 важни неща - "изолация" на адресните пространства на процесите, т.е процесът може, или не може да вижда паметта на останалите и така работата на един процес не може да унищожи работата на друг процес, замазвайки паметта му. За един процес, зад адресът Х реално е мапнат физическият адрес А, за друг процес зад адресът Х може реално да е мапнат физическият адрес В. Как се постига това? Ами всеки процес си има собствена page table, а в ядрото си има page directory, който е нещо като индекс на pagetables за всеки процес.

Второто важно нещо е че зад една страница на процеса може да не стои мапировка върху физическата РАМ (всъщност върху голяма част от страниците няма мапировка въобще, поне в началото на изпълнение на програмата). Може тази страница да е маркирана...като такава върху дисково устройство! Точно по този начин се реализира идеята за swap.

Сега какво става когато един процес реши да прочете какво има на адресът X, който дефакто се намира в суопа?

Първо, адресът Х се намира в страницата A. Процесорът почва да рови из TLB буфера дали има такава страница. Съответно няма. Когато търсената страница не може да се открие в TLB, възниква page fault (прекъсване, което се прихваща от ядрото). Ядрото почва да рови цялата page таблица в РАМ-та за да открие заявената страница върху какво е мапната...и открива мапировката заедно с информация за това че е влезнала в суоп-а. Съответно страницата се "вади" от суоп-а и се оставя някъде във физическата РАМ, а мапировката се променя по начин, по който страницата сочи към новото си място във физическата РАМ. Страницата се изчита (по този начин влизайки в TLB).

Това е половината магия, другата половина е как една страница "влиза" в суопа. Ето там вече нещата доста загрубяват '> Значи механизмът в началото е същият - програмата иска да задели и използва нова памет (обикновено "заявяването" става или с brk() или с mmap(), въпреки че C програмите викат malloc(), последното пак накрая свежда до горните 2). brk()/mmap() са системни извиквания и карат системата да премине в kernel mode. Ядрото се опитва оттам нататък да намери свободен регион със сходна големина, към който да мап-не исканите от процеса страници. Ако не намери такъв, има сложни алгоритми според които се решава дали да се "изхвърлят" кешове или не и ако не, кои страници от физическата памет да се пратят в суоп-а, така че заявените да могат да бъдат мап-нати на тяхно място във физическата памет. Как точно става това е голяма тарапана и не бих казал че разбирам особено '>

[ilian_BIOS]

нещата са доста интересни '>