>> Стоит ли крутить значения kern.* ? >> Обычно, если в логах нет ругани, я не занимаюсь тюнигом. Исходя из >> предположtния, что разработчкам виднее, что лучше для _среднего_ >> сервера L) хендбуке на нагруженных серверах - надо, но это в общем >> этот случай Hо может я не прав? И что-то подкрутить все-таки нужно >> заранее?
SA> мои тюны по рекомендациям аплинка:
Hе, Серег, интересно не с копипаситить чужой опыт, а разобраться в.
Вот мой конкретный случай - тазик со слабым CPU, относительно небольшим ОЗУ - 1280 Mb - минус мегобайт 400 на ZFS, как я понимаю.
"Переменная sysctl kern.ipc.somaxconn ограничивает размер очереди для приема новых TCP соединений. Значение по умолчанию 128 слишком мало для надежной обработки новых соединений для нагруженного web сервера. Для такого сервера рекомендуется увеличить это значение до 1024 или выше." http://www.freebsd.org/doc/ru/books/handbook/configtuning-kernel-limits.html
Речь про высоконагруженные веб-сервера и почтовые системы, явно не твой и не мой случай, и не случай твоего аплинка. Потом, "до 1024" явно означает, что не до 32768, это максимум или половина от него, т.е. чтобы оно с таким значением работало с такой нагрузкой и его использовало - то сервер прото обязан быть ну очень с хорошим железом. Потому что далее начинаются всякие ухищения вроде днс раунд робин с несколькими серверами, а также кластеризация.
Чисто логически - задраное значение kern.ipc.somaxconn 32768 для P3 800, означает, что тазик легко сложится по CPU bottleneck, т.е. в моём случае узкое место это процессор, и толку от большого значения kern.ipc.somaxconn ну ровно никакого, проц просто не сможет обработать такое кол-во... Более того, оччень может быть - уронить сервак DDOS'лм будет даже проще, раз ограничение по кол-ву соединений недостижимо для тазика в принципе.
Как он рассчитывал, вот что интересно, для какого тазика? Почему(тут я не уверен) значения не коррелируют друг с другом?
В том же разделе руководсва сказано вот что: "Опция ядра NMBCLUSTERS обуславливает количество Mbuf, доступных на машине. Hа сервере с большим трафиком и маленьким Mbuf производительность будет пониженной. Каждый кластер представлен двумя килобайтами памяти, поэтому значение 1024 означает 2 мегабайта памяти ядра, зарезервированной для сетевых буферов. Для определения оптимального значения необходимо провести простые вычисления. Если у вас веб сервер, который может обслуживать 1000 одновременных соединений, и каждое соединение <<съедает>> 16 K буфера приема и 16 K буфера отправки, вам потребуется 32 MB памяти под буферы. Хорошее правило -- умножение этого значения на 2, 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. Мы рекомендуем значения между 4096 и 32768 для машин с большим объемом памяти. Hе указывайте произвольно большое значение параметра, это может привести к падению системы при загрузке. "
Вот - кстати, последнее предложение от разработчиков - предупреждение. Сдается мне, что система с кривыми и задранными значениями может не только падать при загрузке, но и плохо "молотить" после загрузки
