Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 18 Jan 24 18:16:22, всего сообщений: 10753
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 8654 из 10753 ===================================== RU.UNIX.BSD =
От   : Slawa Olhovchenkov               2:5030/500         13 Feb 19 12:32:16
Кому : Eugene Grosbein                                     13 Feb 19 12:32:16
Тема : висим стабильненько
FGHI : area://RU.UNIX.BSD?msgid=2:5030/500+5c63e712
На   : area://RU.UNIX.BSD?msgid=grosbein.net+c92e604b
= Кодировка сообщения определена как: FIDO ===================================
Ответ: area://RU.UNIX.BSD?msgid=grosbein.net+e9940657
==============================================================================
Hello Eugene!

13 Feb 19, Eugene Grosbein writes to Slawa Olhovchenkov:

SO>> но а) это будет потом б) мы уже повыкидывали всякое из ARC да и ARC
SO>> зачем-то уменьшили в) это затратный по CPU процесс и вдобавок он
SO>> тормозит много что, т.к. при этом происходит contention lock (причем
SO>> по памяти). пункт в) -- он из-за оптимизации под SMP: для того, что бы
SO>> всякие подсистемы не дрались постоянно за один lock при alloc/free они
SO>> живут по зонам. и если если в зону память берут достаточно дешево, то
SO>> обратно в систему ты её дешево вернуть не можешь -- надо будет брать
SO>> глобальный лок, вертать память, освобождать лок. это дорого. поэтому
SO>> free память помещает во внутризоновый free. из него в систему
SO>> подбирает кажется pagedaemon, когда начинают стучать по балде
SO>> "freepages меньше лимита! ааа!". но как уже сказанно -- это дорогая
SO>> операция -- локи и все такое.

EG> Hа 11.2-STABLE/amd64 r335757 что-то "потом" у меня так и не произошло
EG> на восьми гигабайтах RAM, когда память кончилась совсем: ZFS ARC выкушал
EG> немного менее своего лимита в 3GB, firefox выжрал 5GB RSS плюс Xorg
EG> плюс xfce4, в итоге в свопе более 3.5GB, Free около нуля, Wired более
EG> 4.5GB, полный трешинг vm с десятками мегабайт page-in/page-out в
EG> секунду, firefox убивался несколько минут, хотя и сдох в конце концов.

EG> Я даже после этого вышел в single user mode и экспортировал пул ZFS,
EG> что дропнуло размер ARC до 44 мегабайт, но Wired остался как был,
EG> включая 1.8 гигабайта "свободных" в adb_chunk и более 450 мегабайт
EG> в dnode_t, 350M в zio_buf_512, 226M в zio_buf_16384, 173M в dmu_buf_impl_t
EG> и ещё 136M в zio_data_buf_131072.

я тебя не понимаю. вот ты всех учишь -- пиши было ли что нестандартное в конфигурации?
а сам?
патчи какие-то наложенны? нет? тогда зачем ты мне пишешь?
да, без патчей как-то так и будет. (и не только и не обязательно с arc. с mbuf* тоже такое бывает. я про это уже года два как знаю)
для минимально хорошего результата нужно хотя бы мой патч.
а для совсем хорошего надо 12 версию, D16667, еще один патч от меня, который нигде пока не опубликован (только послан markj) и модификация моего патча для arc.c

если D16667 спортировать на 11 версию -- то и там можно все сделать.

EG> Где всё это время был pagedaemon, я так и не понял.

отдыхал, если у тебя был vm.v_free_min < vm.stats.vm.v_free_count

при твоем объеме памяти vm.v_free_min довольно невилика, если что. мегабайт 20-30, что ли.

... Hе все то глюк, что блестит
--- GoldED+/BSD 1.1.5-b20110223-b20110223
* Origin:  (2:5030/500)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.083182 секунды