У меня есть производственный сервер Squid, на котором были проблемы с обслуживанием контента и сообщением о том, что на нем закончились файловые дескрипторы. Мне удалось увеличить его с 1024 (по умолчанию) до 4096, и это, похоже, устранило мои ошибки в журнале. Я все еще видел код ответа 0 и 0 байтов, полученных для некоторых вызовов, которые не были кэшированы, и это наводит меня на мысль, что в пиковом объеме (загрузочный шторм) мой счетчик файловых дескрипторов все еще слишком мал.
Я уже читал некоторые сообщения, и настройку можно установить на что-то вроде 24k, 40k или даже 70k. Поскольку это выделенный ящик squid, меня не беспокоят другие процессы / пользователи, конкурирующие за файловые дескрипторы в масштабах всей системы, но я действительно хотел бы знать, как лучше всего сделать приблизительный расчет того, сколько файловых дескрипторов я должен настроить. для ulimit -n.
В моей конфигурации у меня есть максимум 3000 клиентских TCP-соединений, максимум 3000 серверных TCP-соединений и несколько файлов журналов, которые по умолчанию настроены в конфигурации squid (cache.log, squid.log). Это так просто, как сказать, что я должен установить свой ulimit -n на 3000 + 3000 + 2 + (некоторая сумма накладных расходов)? Из-за отсутствия документации по этому вопросу я, вероятно, установлю его на 24 КБ, чтобы никогда не приходилось с этим разбираться, но я предпочитаю следовать формуле передовой практики - точно так же, как с apache2, вы можете рассчитать память, необходимую для того, сколько запросов вы хотят иметь возможность обрабатывать одновременно.
Изменить: забыл упомянуть, что я не записываю эти кешированные файлы на диск, они остаются в памяти. Это веб-сайт с несколькими сотнями файлов (всего <5 МБ), который является единственной страницей, которая загружается через это, поэтому я опустил дескрипторы файлов для чтения / записи на диск.
В худшем случае для каждого запроса к серверу squid требуется три файловых дескриптора;
Затем есть накладные расходы, включая файлы журналов, любое межпроцессное взаимодействие, например, помощники и холостые соединения. Итак, в качестве приблизительной оценки вам потребуется три файловых дескриптора для каждого входящего TCP-соединения, а затем учесть любые накладные расходы на это.
В поисках дополнительной информации о «передовых методах» Nasoo решила не думать о том, как рассчитать количество открытых файлов, которые нужно настроить. Я обнаружил, что существуют сложности с тем, как браузеры обрабатывают параллельную загрузку файлов, поэтому 3000 клиентов фактически используют 25-30 сокетов для загрузки полной веб-страницы и динамического контента. Отчасти это зависит от того, как браузеры загружают параллельно, а также от того, как API-интерфейсы javascript обрабатывают загрузку динамического содержимого.
Поэтому, хотя я не могу точно определить правильное число без тонны дополнительных тестов, я также наткнулся на руководство, в котором говорится, что для каждых 4 МБ ОЗУ можно настроить 256 дескрипторов файлов. Так что этого должно быть более чем достаточно, и даже половина из 8 ГБ оперативной памяти, которые у меня есть для этой коробки, будут излишними.
http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec72.html
РЕДАКТИРОВАТЬ: Я также начал вести журнал использования дескриптора файла в файл RRD один раз в минуту через cronjob. Это довольно простой сценарий bash, который все это регистрирует, и вы можете создавать довольно удобные графики без сервера мониторинга или чего-то еще. Если кому-то это интересно, дайте мне знать, и я изложу суть.