Не бива така да тормозите човека, верно че можеше да прочете, да прерови гугъл или търсачката, ама все пак...Аз съм много далеч от идеята за някакво там линукс братство дето трябвало да помага на начинаещите ама що да не споделя, хм. Темата е интересна и за съжаление прекалено сложна за да мога да твърдя че съм особено компетентен. Въпреки това някои неща са достатъчно прости и разбираеми
'>
Дискови операции се кешират. На теория максимално възможно памет трябва да е заета от кеша, без да се пречи на нуждите на процесите които вървят. Има няколко хмм "нива" на кеширане - кешират се изчетени последователни сектори от диска (readahead block device buffer). Кешират се buffer_head структурите, както и данните, към които съдържат указатели (т.е отделни изчетени сектори). Кешира се VFS информация - cat /proc/slabinfo |grep ext примерно - inodes, blabla. Кешират се dentries (хмм "листинг" на директории)
Когато записваш нещо върху диска също така никой не е казал че веднага отива там. Има I/O scheduling. Ако в момента се извършва операция четене и се очаква да се извършат още 10 такива, особено последователни като локация, е по-разумно операцията за писане да ги изчака да минат, след 10-те четения информацията от буфера се записва. Това е защото безцелното редуване на запис/четене върху диска е бавно - чака се пренастройване на главите и seek-ване на друго място където се записва информацията. В почти всички случаи предварително нещата за писане отиват по разни буфери в паметта с идеята когато е най-удобно за системата да се запишат на диска. Такива буфери от сорта на "всеки момент може да се запише" се наричат "dirty memory". В един определен момент тя се записва на диска (има /proc tunnables които контролират как и колко често става това). Апропо, винаги можеш да я запишеш насила - ползвай командата sync.
Всичко това не е безгрешно. Ако се загледаш в повечето време заетата ти рам е близка до 100%. Понеже не всеки елемент от рам-та и конкретно от кеша можеш го вкараш в суоп-а когато ти скимне (защо е така е много дълга тема - заради много причини) - ако една програма на теория изведнъж заяви много голям обем от памет, може да се окаже че кешираните VFS глупости, които в момента не се ползват особено, ще останат в паметта. А мегабахтите данни която е заявила твоята програма за да ги напълни с нещо отиватв суоп-а, оттам драскане по диска и производителността отива на майната си. И всичко това заради най-доброто желание да се подобри, а не да се влоши общата производителност
'>
Веднъж влезеш ли в суоп-а има различни стратегии за подобряване на производителността на машината - има параметър наречен swappiness, който определя тенденцията на ядрото да "изхвърля" в суопа памет, която не е достъпвана достатъчно скоро. При висока стойност от една страна се освобождава РАМ в случай че стартираш нова програма или пък че някое приложение прави сериозни игрички с паметта и не трябва да му се пречи със суопинг на неговите данни. От друга страна, това прави responsiveness-а на една десктоп система кошмарен - примерно превключвайки между браузъра и мп3 плеъра забелязваш как диска се изкъртва от четене и писане (това става защото данните на плеъйра вече са били "изхвърлени" в суоп-а и сега се връщат в рам-та, докато данните на браузъра поемат по обратният път - от рамта в суоп-а). Балансът, правилният оптимален баланс е доста...сложна задача
'> За линукс на лаптоп примерно swappiness-а е най-добре да стои равен на 0. За един сървър по-добри са по-високи стойности, въпреки че зависи какво върви на този сървър.
Хубавото е че memory management-a става все по-добър с времето. А този на 2.6 по принцип е много добър, въпреки че не е перфектен.