Как вычислить ulimit -n (дескрипторы файлов) для выделенного сервера Squid

У меня есть рабочий сервер Squid, на котором были проблемы с обслуживанием контента и сообщением о том, что на нем закончились файловые дескрипторы. Мне удалось увеличить его с 1024 (по умолчанию) до 4096, и это, похоже, устранило мои ошибки в журнале. Я все еще видел код ответа 0 и 0 байтов, полученных для некоторых вызовов, которые не были кэшированы, и это наводит меня на мысль, что в пиковом объеме (загрузочный шторм) мой счетчик файловых дескрипторов все еще слишком мал.

Я уже читал несколько сообщений, и настройку можно установить примерно на 24 КБ, 40к, а то и 70к. Поскольку это выделенный ящик squid, меня не беспокоят другие процессы / пользователи, конкурирующие за файловые дескрипторы в масштабах всей системы, но я действительно хотел бы знать, как лучше всего сделать приблизительный расчет того, сколько файловых дескрипторов я должен настроить. для ulimit -n.

В моей конфигурации у меня есть максимум 3000 клиентских TCP-подключений, максимум 3000 серверных TCP-подключений и несколько файлов журналов, которые настроены по умолчанию в конфигурации squid (cache .log, squid.log). Это так просто, как сказать, что я должен установить свой ulimit -n на 3000 + 3000 + 2 + (некоторая сумма накладных расходов)? Из-за отсутствия документации по этому вопросу я, вероятно, установлю 24k, чтобы никогда не приходилось с этим иметь дело, но я предпочитаю следовать формуле передового опыта - как и в случае с apache2, вы можете рассчитать объем памяти, необходимый для того, сколько запросов вы хотите обрабатывать одновременно.

Изменить: Забыл упомянуть, что я не записываю эти кешированные файлы в диск, они остаются в памяти. Это веб-сайт с несколькими сотнями файлов (всего <5 МБ), который является единственной страницей, которая загружается через это, поэтому я пропустил файловые дескрипторы чтения / записи на диск.