On 07/19/13 15:41, greenh wrote:
Дамы и господа, подскажите плз
До меня дошли слухи, что nmbclusters уже нет нужды настраивать, т.к. его
допилили до автотюнинга. Насколько это правда?
В current есть автотюнинг - на основе объема RAM.
Но по моему опыту пользы от лимита nmbclusters к сожалению мало.
Если в nmbclusters поставить маленькое значение, то когда кластера закончится с
большой вероятностьсю получится зависшая система (с процессами висящими в
состоянии zoneli*). Некоторые разработчики утверждают что система зависать в
такой ситуации не должно, но на практике - зависает.
Если в nmbclusters поставить очень большое значение, то под очень большой
нагрузкой кластера могут скушать всю памяти и случится паника из за нехватки
памяти в ядре.
Так что если выбирать из двух зол меньшее, лучше выбрать панику... Для этого в
nmbclusters нужно указать очень большое значение. Автотюнинг, который есть в
current как раз это и делает - указывает в nmbclusters очень большое значение
(хоть и пропорционально объему физической памяти).
Если MFC в 9-ку еще не сделали - просто напишите в loader.conf что то вида
kern.ipc.nmbclusters=2097152
Причем надежды, что когда то такое поведение изменится практически нет.
Если немножко углубиться в детали - в ядре память может аллоцироваться либо с
флагом M_NOWAIT либо M_WAITOK
M_NOWAIT означает, что malloc совсем не должен блокироваться и если память с
первой попытки не удалось аллоцировать - возвращает NULL. Применяется в
обработчиках прерываний и других местах, где нельзя блокироваться. Может иногда
возвращать NULL, даже если свободная память еще есть.
M_WAITOK - никогда не возвращает NULL - если памяти нет, то просто блокируется -
надолго (пока не появится свободная память), иногда на вечно (пока не нажмут
конпку reset).
В сетевом стеке в большинстве мест как раз используется M_WAITOK со всеми
вытекающими последствиями.
В идеале для сетевого стека нужен работающий M_TRYWAIT - можно блокироваться, но
не на вечно, а на некоторое ограниченное время. Но сейчас такого нет (#define
M_TRYWAIT M_WAITOK).
Основной аргумент разработчиков против реализации M_TRYWAIT - если его
реализовать так, что он будет блокировать на ограниченное время, тогда malloc(9)
и все что вокруг него (UMA) все таки будет в некоторых случаях возвращать NULL.
Тогда syscall в котором это произошло, например write(2) или read(2) должно
будет вернуть ошибку ENOBUFS, а в мире очень много софта, который никак не
обрабатывает ошибки возвращаемые syscall-ами. И лучше иногда виснуть, чем ломать
работу криво написанных приложений (которые пока работают).
Ну и когда не нужно проверять, что malloc вернул NULL это удобно (для
программиста), поэтому M_WAITOK используют везде, где его можно использовать.
