Покрутите
/proc/sys/vm/dirty_ratio
/proc/sys/vm/dirty_background_ratio

И погуглите в таком духе.

Так может по крону запускать время от времени «echo 3 > /proc/sys/vm/drop_caches». Способ некрасивый, но реализовать легко :)

>Подскажите, как ограничить использование памяти под кэши ?

vm.min_free_kbytes

Жуть какая то. Кеш - это и есть свободная память. И по хорошему ее надо использовать всю.

Проблема точно в этом?

Команда free показывает незанятую память, кеши и буфера отдельно, а например команда htop - показывает их вместе чтобы не вводить в заблуждение новичков и виндузятников.

>> новичков и виндузятников.

которые думают, что кеш - это кем то занятая память, которая мешает выполняться их программам)

Нашлись очень полезные ссылки по тюнингу памяти

Спасибо,

vm/dirty_ratio - похоже, то, что надо

Вроде не тот параметр

vm.min_free_kbytes - это, кажется, наоборот, дать побольше резерва под внутриядерные нужды (сейчас тут всего 3Мб выставлено)

Кэши совсем не мешают?

А какова стоимость (в миллисекундах) освобождения приличного куска памяти из состояния, когда всего 5-7% процентов памяти доступно пользовательским программам? Хорошо, что ядро позволяет выбирать между отзывчивостью системы и эффективностью кэшей.

та это еще ничего, вот тут чувак вбросил просто адово http://linuxportal.ru/forums/index.php/m/79937/

«Важный момент - данные будут просто уничтожаться, поэтому перед запуском этих процессов имеет смысл выполнить sync чтобы сбросить изменённые данные на диск. Тем не менее, на мой взгляд, для сильно нагруженного сервера, обрабатывающего большие объёмы данных за короткое время, между запуском sync и записью значения в этот файл в кэш могут попасть новые данные, которые на диск уже записаны не будут и, соответственно, будут утеряны. Так что пользоваться этим механизмом следует редко и осторожно, осознавая последствия. Пример команды записи: „sync && echo 2 > /proc/sys/vm/drop_caches“.»

как по твоему происходит освобождение памяти? что при этом просиходит? ну так, чисто поржать...

Конопляные поля горят?

Кстати, ради примера можно попробовать запустить эту:

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>

extern int errno;

#define MAXMB (4<<10)
#define MB (1<<20)
#define PG (4<<10)

int main(int argc, char *argv[])
{
	char *m;
	int i,j;

	printf("PG = %d\n", PG);
	printf("MB = %d\n", MB);
	printf("MAXMB = %d\n\n", MAXMB);
	sleep(3);
	for(i=0; i<MAXMB; i++){
		m = malloc(MB);
		printf("%d MB ...",i+1);
		if(errno || !m) break;
		for(j=0;j<MB;j+=PG) m[j]='A';
		printf(" OK\n");
	}
	printf("\n\nAllocated %d MB\n",i);

	exit(0);
}

Неужели мгновенно

Что, неужто указатель границы доступной памяти сдвинуть?

Есть подозрение, что в ситуации, когда памято мало. при большом количестве вызовов malloc а также открытии множества файлов, ядро выделит под нужды новой программы не все требуемые ресурсы , и ввод/вывод может тормознуть

пост ни о чем. повторю вопрос: что происходит при высвобожении памяти? подсказка: сколько времени нужно для выполнения команды «echo 3 > /proc/sys/vm/drop_caches»?

Спасибо за тест.

После исправления бага с инкрементом, система тратит на около пары секунд на запуск этой программы, и на каждый мегабайт около 20 миллисекунд

>сколько времени нужно для выполнения команды «echo 3 > /proc/sys/vm/drop_caches»?
ты не понимаешь, что происходит при этой команде и что при нормальной работе
кэш освобождает память далеко не сразу!

Мгновенно

Но в этом случае система не делает никакие проверки, т.е. это нештатный и нерекомендованный способ освобождения ресурсов

Кстати, поэкспериментируйте с запуском программ в ситуации, когда вся память израсходована на файловый и страничный кэши.

Но в этом случае система не делает никакие проверки, т.е. это нештатный и нерекомендованный способ освобождения ресурсов

А ты упортный. Какой-то идиот в интернете ляпнул глупость, ты настойчиво за ним повторяешь.

я точно знаю что происходит при этой команде, и что происходит при нормальной работе

на всех моих серверах вся память что не занята процессами — занята кешем. там постоянно запускаются какието процессы, и все летает. ЧЯДНТ?

А что за скрипт? Может быть, в нем дело?

>я точно знаю что происходит при этой команде, и что происходит при нормальной работе
что-то меня терзают смутные сомнения...
и что же происходит?

Мужыки, вы это.. Не спугните.

Время ламеров на ЛОРе заканчивается... Наступает время упоротых :(

> и что же происходит?

Братство MMU не позволяет мне делиться этим секретным знанием. И все-таки хотело бы выслушать версию ТС (он ее так и не озвучил)

>Братство MMU не позволяет мне делиться этим секретным знанием
ухты - а меня примите в свои ряды?
каков обряд посвящения ? )

>т.к. пару минут происходит ее освобождение от кэша.

не может этого быть. Разве что если память на электромеханических реле.
Пару минут эти требуемые 150Мб могут сбрасываться в своп, т.к. по дефолту ядро пытается сохранить часть кеша. Собственно, ответ прост: смотреть вывод `free -m` перед и после запуска скрипта.

Если действительно свопит, то тебе поможет vm.swappiness = 10.

cache должен высвобождаться _мгновенно_ - у вас в чём-то другом проблема.

Вот так выглядит распределение ресурсов

Вывод top при незапущенном скрипте:

top - 13:37:18 up 18 days, 12:49,  1 user,  load average: 0.06, 0.02, 0.00
Tasks:  97 total,   2 running,  95 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.1%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    524288k total,   518748k used,     5540k free,    59904k buffers
Swap:        0k total,        0k used,        0k free,   178572k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                  
 8006 www-data  16   0 72136  40m 7184 S    0  7.9   0:05.32 apache2                   
 8003 www-data  16   0 70908  39m 7180 S    0  7.7   0:05.32 apache2                   
 8004 www-data  15   0 69836  38m 7288 S    0  7.5   0:05.42 apache2                   
32184 mysql     15   0  117m  35m 5688 S    0  7.0   0:17.39 mysqld                    
29776 root      15   0 42140  26m 2536 S    0  5.1   5:02.50 python                    
 7451 root      15   0 37264  19m 5748 S    0  3.8   1:08.10 python                    
28142 nobody    15   0 14832  12m  196 S    0  2.4   0:33.64 memcached                 
 1660 root      17   0 27732  11m 1172 S    0  2.1   4:26.32 console-kit-dae           
 7999 root      18   0 33460 8672 4488 S    0  1.7   0:00.01 apache2                   
13565 root      18   0 94348 7064  316 S    0  1.3   0:53.20 python                    
16793 root      18   0 94492 6076  316 S    0  1.2  10:06.50 python                    
13798 root      15   0 17056 3044  280 S    0  0.6   1:04.31 python                    
20377 root      15   0 17044 3000  280 S    0  0.6  15:13.65 python                    
 1657 haldaemo  15   0  6348 1568  656 S    0  0.3   0:37.18 hald                      
    1 root      15   0  3084 1396   72 S    0  0.3   0:01.33 init                      
32142 root      22   0  3960 1348 1128 S    0  0.3   0:00.00 mysqld_safe               
 7434 root      18   0  2844 1256  980 S    0  0.2   0:00.00 cron                      
11960 root      15   0  4424 1172  660 S    0  0.2   0:09.73 bash                      
 1641 www-data  15   0  4872 1152  448 S    0  0.2   0:19.10 nginx                     
 8336 root      15   0  2448 1152  904 R    0  0.2   0:00.02 top                       
11951 root      15   0  8884 1044  216 R    0  0.2   0:12.27 sshd                      
 7448 root      18   0  2624 1036  892 S    0  0.2   0:00.00 sh                        
31217 root      15   0  4396 1016  528 S    0  0.2   0:04.27 screen.real               
 1165 klog      16   0  2492  992  176 S    0  0.2   0:17.28 klogd                     
 1183 messageb  16   0  2796  780  416 S    0  0.1   1:25.45 dbus-daemon               
32185 root      20   0  3052  692  604 S    0  0.1   0:00.00 logger                    
 1725 root      15   0  3328  604  428 S    0  0.1   0:02.77 hald-runner               
17284 root      15   0  4396  580    4 S    0  0.1   0:01.69 screen.real               
  929 root      15   0  4300  480    4 S    0  0.1   0:00.18 screen.real

А для работы скрипта требуется запуск Xvfb, и также много запросов к базе mysql. Да, нужно упомянуть что сервер - VDS.

Своп отсутствует

Своп раздела нет как такового (система досталась в таком виде)

Спасибо, вы правы

drop_caches -и правда безопасный способ очистить файловый кэш - сбрасываются только non-dirty страницы

Пару минут эти требуемые 150Мб могут сбрасываться в своп, т.к. по дефолту ядро пытается сохранить часть кеша. Собственно,

ничего подобного.

http://www.linuxatemyram.com/

Скрипт - автоматизация сбора данных через webkit

Дело в том, что на некоторых кривых веб-страницах webkit зависает, потому скрипт пишет heartbeat во временный файл, а запускающий bash-скрипт делает перезапуск скрипта в случае отсутствия heartbeat

Какая может быть тут версия?

Проблема появилась после добавления большого количества изображений в доступ через apache. Т.е. то, что кэширование файлов вызвало данный эффект - несомненно. Правда не уверен, что именно кэширование ядром linux, но то, что проблемный скрипт _нормально_ запускается и работает после сброса кэшей - факт. Но если только google или yahoo начнет индексировать страницы - кэш опять будет захвачен и прощай стабильная работа.

>ничего подобного.
что ничего подобного? На что, по-твоему, влияет vm.swappiness?

>Своп раздела нет как такового

и в этом тоже может быть проблема. Агентство ОБС сообщает, что при полном отсутствии свопа могут возникать странные тормоза. Попробуй создать своп хотя бы на пару мегабайт в файле, посмотри что будет

>при полном отсутствии свопа могут возникать странные тормоза

Поподробнее, пожалуйста..

на drop_caches vm.swappiness никакого влияния не имеет

root@true_tachka:~# sysctl vm.swappiness=100
vm.swappiness = 100
root@true_tachka:~# time { echo 3 > /proc/sys/vm/drop_caches; }

real    0m0.071s
user    0m0.000s
sys     0m0.072s
root@true_tachka:~# free
             total       used       free     shared    buffers     cached
Mem:       1025716     429392     596324          0        268      49756
-/+ buffers/cache:     379368     646348 
Swap:       995988      39988     956000

я ж говорю, ОБС :)
Подробностей не знаю и не проверял, у меня всегда есть своп. Слышал неоднократно, проверить в общем то не долго.

>на drop_caches vm.swappiness никакого влияния не имеет

А должно? :) Причем тут drop_caches, речь шла про обычный запуск скрипта при забитой кешем памяти

>Подробностей не знаю

Похоже на бред, тк на основной системе свопа нет - необъяснимых тормозов тоже нет.

а памяти сколько? Возможно, на новых версиях ядер это починили.
Попробуй скопировать несколько больших файлов чтобы вся память забилась кешем, поставь высокий vm.swappiness и запусти очень толстое приложение

2G и на другом компе без свопа 768M.

>высокий vm.swappiness

60 стоит )

Если из /dev/null на диск писать - тогда да, подлагивает.

>Да, нужно упомянуть что сервер - VDS

Какая виртуальная машина используется?

drop_caches освобождает память. Я показал что кэш очищается практически моментально(если это не «грязные» страницы), грешить на то кэш мешает запуску программ неправильно.

>Я показал что кэш очищается практически моментально

А теперь забей память кешем, поставь vm.swappiness=100, запусти любое толстое приложение и удивись.