практические максимальные дескрипторы открытых файлов (ulimit -n) для систем с большим объемом

<p>недавно мы начали нагрузочное тестирование нашего приложения и заметили, что оно исчерпало файловые дескрипторы примерно через 24 часа.</p><p>мы используем rhel 5 на dell 1955:</p><p>процессор: 2 двухъядерных 2,66 ггц 4 мб 5150/1333fsb озу: 8 гб ram hdd: 2 x 160 гб 2,5-дюймовые жесткие диски sata</p><p>я проверил предел дескриптора файла, и он был установлен на 1024. учитывая, что наше приложение может иметь около 1000 входящих и 1000 исходящих соединений, это кажется довольно низким. не говоря уже о реальных файлах, которые нужно открыть.</p><p>моей первой мыслью было просто увеличить параметр ulimit -n на несколько порядков, а затем перезапустить тест, но я хотел знать возможные последствия слишком высокой установки этой переменной.</p><p>существуют ли передовые практики для установки этого параметра, кроме определения количества файловых дескрипторов, которые теоретически может открыть наше программное обеспечение?</p>

<p>эти ограничения возникли в то время, когда несколько "обычных" пользователей (не приложений) разделяли сервер, и нам требовались способы защитить их от использования слишком большого количества ресурсов.</p><p>они очень низкие для высокопроизводительных серверов, и мы обычно устанавливаем их на очень большое число. (24k или около того) если вам нужны более высокие числа, вам также нужно изменить параметр sysctl file-max (обычно ограниченный 40k в ubuntu и 70k в rhel).</p><p>настройка ulimit:</p><pre><code># ulimit -n 99999 </code></pre><p>sysctl max файлы:</p><pre><code>#sysctl -w fs.file-max=100000 </code></pre><p><strong>кроме того, и это очень важно, вам может понадобиться проверить, есть ли в вашем приложении утечка памяти/файлового дескриптора. используйте lsof, чтобы увидеть все, что у него открыто, чтобы убедиться, что они действительны или нет. не пытайтесь изменить система для обхода ошибок приложений.</strong></p>

<p>вы всегда можете просто</p><pre><code>cat /proc/sys/fs/file-nr </code></pre><p>в ситуации "высокой нагрузки" посмотреть, сколько файловых дескрипторов используется.</p><p>что касается максимума - это зависит только от того, что вы делаете.</p>

<p>если файловые дескрипторы являются сокетами tcp и т.д., то вы рискуете использовать большой объем памяти для буферов сокетов и других объектов ядра; эта память не будет заменяемой.</p><p>но в остальном нет, в принципе проблем не должно быть. обратитесь к документации по ядру, чтобы попытаться выяснить, сколько памяти он будет использовать, и/или протестировать ее.</p><p>мы запускаем серверы баз данных с ~ 10 тыс. открытых файловых дескрипторов (в основном на реальных дисковых файлах) без особых проблем, но они 64-битные и имеют множество оперативной памяти.</p><p>настройка ulimit указана для каждого процесса, но есть и общесистемный лимит (я думаю, 32k по умолчанию)</p>

<p>я лично не осведомлен о каких-либо лучших практиках. это несколько субъективно в зависимости от функции системы.</p><p>помните, что 1024 вы видите для каждого пользователя, а не для всей системы. посмотрите, сколько приложений вы запускаете в этой системе. это единственный? пользователь, который запускает это приложение, делает что-нибудь еще? (ie у вас есть люди, использующие эту учетную запись для входа в систему и запуска сценариев, которые могут потенциально убежать?)</p><p>поскольку на этом устройстве запущено только одно приложение, а учетная запись, в которой запущено указанное приложение, предназначена только для этой цели, увеличение вашего лимита, как вы предлагаете, не повредит. если это собственная команда разработчиков, я бы спросил их мнение. если это от стороннего поставщика, у них могут быть определенные требования или рекомендации.</p>

<p>мне кажется, что на один из этих вопросов лучше всего ответить "проверь его в среде разработки". я помню, как много лет назад солнце нервничало, когда ты с этим связывался, но не так нервничало. в то время его лимит был также 1024, поэтому я немного удивлен, увидев, что сейчас то же самое для linux, похоже, что оно должно быть выше.</p><p>я нашел следующую ссылку образовательной, когда нашел свои ответы на ваш вопрос: <a href="http://www.netadmintools.com/art295.html">http://www.netadmintools.com/art295.html</a> </p><p>и этот также: <a href="https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible">https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible</a> </p>