SO>>> я тебя не понимаю. вот ты всех учишь -- пиши было ли что нестандартное SO>>> в конфигурации? а сам? патчи какие-то наложенны? нет? EG>> Всё дефолтное, патчей нет, есть лимит 3G на ARC. SO>>> тогда зачем ты мне пишешь? EG>> Я думал, ты про дефолтное поведение page daemon писал. EG>> markj в листах тоже говорил, что page daemon должен чистить. SO> я не уверен что конкретно этот тред называется page daemon, но да, это SO> дефолтное поведение. SO>>> да, без патчей как-то так и будет. (и не только и не обязательно с SO>>> arc. с mbuf* тоже такое бывает. я про это уже года два как знаю) для SO>>> минимально хорошего результата нужно хотя бы мой патч. а для совсем SO>>> хорошего надо 12 версию, D16667, еще один патч от меня, который нигде SO>>> пока не опубликован (только послан markj) и модификация моего патча SO>>> для arc.c если D16667 спортировать на 11 версию -- то и там можно все SO>>> сделать. EG>>>> Где всё это время был pagedaemon, я так и не понял. SO>>> отдыхал, если у тебя был vm.v_free_min < vm.stats.vm.v_free_count SO>>> при твоем объеме памяти vm.v_free_min довольно невилика, если что. SO>>> мегабайт 20-30, что ли. EG>> vm.v_free_min: 12838 (50 мегабайт), а в свопе было 3.5 гигабайта EG>> и интенсивный pageing. SO> активация pageing и свапинг завязаны на другое соотношение. EG>> Какое-то странное условие для активации page daemon это неравенство. SO> ты хочешь об этом поговорить?
Да, но я уже говорю об этом в stable@, тред 11.2-STABLE kernel wired memory leak Даже с учётом всех "FREE" в зонах UMA и с учётом ZFS ARC, которое в моём случае могу исключить путём размонтирования и экспорта пула, всё равно куда-то ещё два гигабайта Wired утекло за 81 сутки аптайма.
