= Сообщение: 8650 из 10753 ===================================== RU.UNIX.BSD = От : Eugene Grosbein 2:5006/1 13 Feb 19 00:57:22 Кому : Slawa Olhovchenkov 13 Feb 19 00:57:22 Тема : Re: висим стабильненько FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+c92e604b На : area://RU.UNIX.BSD?msgid=2:5030/500+5ab7d67c = Кодировка сообщения определена как: IBM866 ================================= Ответ: area://RU.UNIX.BSD?msgid=2:5030/500+5c63e712 ============================================================================== 25 марта 2018, воскресенье, в 17:45 NOVT, Slawa Olhovchenkov написал(а):
SO> ты зря так думаешь. SO> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP SO> mbuf_jumbo_page: 4096, 16777216, 987894, 759655,8205734907395, 0, 0 SO> вот тебе пожалуйста 3ГБ свободной память в mbuf. SO> она действительно свободная, т.е. сейчас не используется mbuf jubmbo. SO> а я видел и 40ГБ. SO> и когда у нас будет дефицит памяти, ты можешь быстро-быстро конечно что-то из SO> ARC выкинуть. SO> только во-первых это будет все же что-то наверное нужное, в отличии от SO> вышепоказанного. а во-вторых оно вообще-то не попадет в систему. оно попадет во SO> что-то типа (если специально не применить некоторых трюков, а трюки эти таки SO> немножко дорогие, см.ниже.) SO> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP SO> zio_data_buf_1048576: 1048576, 0, 217577, 1604,14972433811, 0, 0 SO> (вот тут у нас 1.6Г свободной памяти) SO> и потом её оттуда достанут, если pressure будет продолжаться. как и из jumbo. и SO> из остальных мест. и после этого свободной памяти окажется ДОХУЯ.
SO> но а) это будет потом б) мы уже повыкидывали всякое из ARC да и ARC зачем-то SO> уменьшили в) это затратный по CPU процесс и вдобавок он тормозит много что, т.к. SO> при этом происходит contention lock (причем по памяти). SO> пункт в) -- он из-за оптимизации под SMP: для того, что бы всякие подсистемы не SO> дрались постоянно за один lock при alloc/free они живут по зонам. и если если в SO> зону память берут достаточно дешево, то обратно в систему ты её дешево вернуть SO> не можешь -- надо будет брать глобальный лок, вертать память, освобождать лок. SO> это дорого. поэтому free память помещает во внутризоновый free. из него в SO> систему подбирает кажется pagedaemon, когда начинают стучать по балде "freepages SO> меньше лимита! ааа!". но как уже сказанно -- это дорогая операция -- локи и все SO> такое.
Hа 11.2-STABLE/amd64 r335757 что-то "потом" у меня так и не произошло на восьми гигабайтах RAM, когда память кончилась совсем: ZFS ARC выкушал немного менее своего лимита в 3GB, firefox выжрал 5GB RSS плюс Xorg плюс xfce4, в итоге в свопе более 3.5GB, Free около нуля, Wired более 4.5GB, полный трешинг vm с десятками мегабайт page-in/page-out в секунду, firefox убивался несколько минут, хотя и сдох в конце концов.
Я даже после этого вышел в single user mode и экспортировал пул ZFS, что дропнуло размер ARC до 44 мегабайт, но Wired остался как был, включая 1.8 гигабайта "свободных" в adb_chunk и более 450 мегабайт в dnode_t, 350M в zio_buf_512, 226M в zio_buf_16384, 173M в dmu_buf_impl_t и ещё 136M в zio_data_buf_131072.
Где всё это время был pagedaemon, я так и не понял.
