Слишком много открытых файлов
Обновлено: 06.07.2024
Я работаю над школьным проектом, где мне пришлось написать многопоточный сервер, и теперь я сравниваю его с apache, проводя некоторые тесты против него. Я использую autobench, чтобы помочь с этим, но после того, как я выполняю несколько тестов, или если я даю ему слишком высокую скорость (около 600+), Чтобы сделать соединения, я получаю ошибку "слишком много открытых файлов".
После того, как я закончил работу с запросом, я всегда делаю close() на сокете. Я также пытался использовать функцию shutdown() , но ничего не получается. помощь. Как-нибудь обойти это?
Есть несколько мест, где Linux может иметь ограничения на количество файловых дескрипторов, которые вы можете открыть.
Вы можете проверить следующее:
Это даст вам системные ограничения файловых дескрипторов.
На уровне оболочки это покажет вам ваш личный предел:
Это можно изменить в файле/etc/security / limits.conf-это nofile param.
Однако, если вы закрываете свои сокеты правильно, вы не должны получать это если только вы не открываете множество симуляторных соединений. Похоже, что-то мешает вашим розеткам быть закрытыми надлежащим образом. Я бы проверил, что с ними обращаются должным образом.
У меня была похожая проблема. Быстрое решение:
Объяснение заключается в следующем - каждое подключение к серверу представляет собой файловый дескриптор. В CentOS, Redhat и Fedora, вероятно, других, ограничение пользователя файла составляет 1024 - не знаю почему. Это можно легко увидеть, когда вы печатаете: ulimit-n
Обратите внимание, что это не имеет большого отношения к system max files (/proc/sys/fs/file-max).
В моем случае это была проблема с Redis, поэтому я сделал:
В вашем случае вместо redis вам нужно начать сервер.
TCP имеет функцию под названием "TIME_WAIT", которая гарантирует, что соединения будут закрыты чисто. Это требует, чтобы один конец соединения оставался слушающим некоторое время после того, как сокет был закрыт.
На высокопроизводительном сервере важно, чтобы в TIME_WAIT входили клиенты, а не сервер. Клиенты могут позволить себе иметь открытый порт, в то время как занятый сервер может быстро исчерпать порты или иметь слишком много открытых FDs.
Для этого сервер никогда не должен закрывать сначала соединение - оно всегда должно ждать, пока клиент его закроет.
Используйте lsof -u `whoami` | wc -l , чтобы узнать, сколько открытых файлов у пользователя
Это означает, что одновременно открыто максимальное количество файлов.
Решено:
В конце файла /etc/security/limits.conf нужно добавить следующие строки:
В текущей консоли от root (sudo не работает) сделать:
Хотя это необязательно, если есть возможность перезапустить сервер.
В файле /etc/nginx/nginx.conf зарегистрировать новое значение worker_connections равное 16384 разделить на значение worker_processes .
Если не сделал ulimit -n 16384 , Нужно перезагрузиться, тогда проблема отступит.
PS:
Если после ремонта видно в логах error accept() failed (24: Too many open files) :
В конфигурации nginx, propevia (например):
У меня тоже была эта проблема. У вас утечка дескриптора файла. Вы можете отладить это, распечатав список всех дескрипторов открытых файлов (в системах POSIX):
Выбросив все открытые файлы, вы быстро выясните, где находится утечка дескриптора файла.
Если ваш сервер порождает подпроцессы. Например, если это сервер в стиле' fork', или если вы создаете другие процессы ( например, через cgi ), вы должны убедиться, что создаете свои дескрипторы файлов с помощью "cloexec" - как для реальных файлов, так и для и розетки тоже.
Без cloexec каждый раз, когда вы разветвляете или порождаете, все открытые дескрипторы файлов клонируются в дочернем процессе.
Также очень легко не закрыть сетевые сокеты - например, просто отказаться от них, когда удаленная сторона отключается. Это будет протекать ручки, как сумасшедший.
Может пройти некоторое время, прежде чем закрытый сокет действительно освободится
lsof список открытых файлов
cat /proc/sys/fs/file-max чтобы увидеть, есть ли предел системы
Просто еще одна информация о CentOS. В данном случае, при использовании "systemctl" для запуска процесса. Вы должны изменить системный файл ==> /usr / lib / systemd/system / processName.обслуживание .Была такая строка в файле:
И просто перезагрузите вашу систему conf:
Когда ваша программа имеет больше открытых дескрипторов, чем открытые файлы ulimit (ulimit-a перечислит это), ядро откажется открывать больше файловых дескрипторов. Убедитесь, что у вас нет утечек дескрипторов файлов - например, запустив его на некоторое время, а затем остановив и посмотрев, открыты ли какие - либо дополнительные fds, когда он простаивает-и если это все еще проблема, измените nofile ulimit для вашего пользователя в /etc/security/limits.conf
У меня была та же проблема, и я не потрудился проверить возвращаемые значения вызовов close (). Когда я начал проверять возвращаемое значение, проблема таинственным образом исчезла.
Я могу только предположить, что ошибка оптимизации компилятора (gcc в моем случае) предполагает, что вызовы close() не имеют побочных эффектов и могут быть опущены, если их возвращаемые значения не используются.
В систему технической поддержки поступила заявка от пользователя, смысл которой сводился к тому, что отсутствовала возможность сохранения рабочих таблиц формата xlsx на корпоративном сетевом ресурсе, в папке департамента к которому принадлежал данный клиент. Дополнительно, самим же пользователем было установлено, что абсолютно идентичной проблемой страдает и другое офисное приложение, почтовый клиент Outlook 2010 в процессе сохранения вложений из писем по тому же самому сетевому пути, а так же и ряд других программ, в частности 1С. В чем же заключались детали инцидента? При попытке сохранения файлов на корпоративном сетевом хранилище, пользователь получал ошибку "Этот путь не существует. Проверьте правильность указания пути и повторите попытку".
Диагностика
Исходя из того, что я успел понять, проводник либо другое приложение взаимодействует с сетевым ресурсом посредством стандартных системных сетевых функций ввода-вывода, которые работают с UNC-путями. С большой вероятностью данные функции используют сервис "Служба доступа к файлам и принтерам сетей Microsoft", а тот, в свою очередь, использует драйвер SMB. Допустим, перед выполнением определенных операций с файлами, гипотетический сервис осуществляет ряд проверок неких предопределенных условий. Одним из таких условий является ограничение на количество одновременно открытых файловых дескрипторов от имени удаленного пользователя. Скажем так, любой открытый сетевой (?) файл, увеличивает некий счетчик открытых файловых дескрипторов. Где задается этот лимит и какое конкретное значение имеет по-умолчанию, на текущий момент для меня остается тайной. Судя по тем немногочисленным осколкам информации, которые мне удалось обнаружить в Сети, этот лимит (начиная с Windows Vista) жестко задан в какой-то переменной ядра, скорее всего в небольшое значение (15). Тем не менее, если это предположение верно, заключим, что именно с этим ограничением и столкнулся наш пользователь, что и привело к генерации описанной выше ошибки Слишком много файлов открыто для совместного доступа. Оригинальная ошибка имеет идентификатор 36 и носит англоязычное название ERROR_SHARING_BUFFER_EXCEEDED . Но почему проблема образовалась именно сейчас, ведь на протяжении продолжительного времени работы подобных инцидентов не возникало, то есть пользователь вполне укладывался в предоставляемые системные лимиты? Вероятнее всего какая-либо служба или программа на станции пользователя, создающая собственные сессии с тем же сетевым ресурсом, от имени того же пользователя, начала "сбоить", создавая собственные сессии в избыточном количестве. В этих условиях штатное подключение пользователя к сетевому ресурсу из программ либо посредством проводника уже не укладывается в лимит. Но это всего-лишь мое предположение, основанное на простой логике и вовсе не опирающееся на глубокие знания работы сервиса "Служба доступа к файлам и принтерам сетей Microsoft", протокола SMB и других вероятных составляющих цепочки доступа к сетевому ресурсу. Однако теория есть теория, но без внутреннего знания нам остается один лишь, временем проверенный и безотказный, великий "метод тыка", имеющий отрицательным свойством своим огромное количество времени, затрачиваемое на перебор возможных вариантов решения. На определенном этапе поиска, я совсем случайно я обратил внимание на небольшой зеленого цвета значок в нижней области статуса сетевой папки.
Данный маркер говорит об использовании автономных файлов.
Автономные файлы, также известные под псевдонимом "кэширование на стороне клиента" (Client Side Caching, CSC), позволяют пользователям работать с сетевыми файлами, когда подключение к серверу недоступно или работает слишком медленно.
Функция "Автономные файлы" имеет в системе собственную одноименную службу и драйвер, которые и выполняют весь объем работ по синхронизации файлов между локальными и сетевыми версиями данных. Как оказалось, между приложением, использующим SMB для доступа к сетевым ресурсам, и клиентским SMB драйвером, имеются еще системные и сторонние драйвера различного функционала, одним из которых является драйвер автономных файлов. В случае включенной функции автономных файлов, данные от приложения сначала попадают на драйвер автономных файлов и, в зависимости от критериев скорости и доступности целевого сетевого ресурса, драйвер либо выполняет локальное кеширование данных, либо использует драйвер SMB для синхронизации с целевым сетевым ресурсом, тем самым уменьшая лимиты дескрипторов? Вот именно какой-то код синхронизации либо в самих автономных файлах, либо в драйвере SMB и вызывает подобный эффект, скорее всего где-то в коде имеется ошибка.
Решение
Поскольку проблему надо было решать достаточно оперативно, самым очевидным решением, которое сразу пришло на ум, было полностью отключить функцию автономные файлы. Следующие действия необходимо выполнять из-под учетной записи с правами локального администратора. Для осуществления этого откроем Панель управления , далее Центр Синхронизации , затем Управление автономными файлами . Увидим перед своими глазами следующее окно:
Далее ждем кнопку Отключить автономные файлы . После отключения может потребоваться перезагрузка операционной системы. После того, как мной было выполнено отключение автономных файлов, проблема на станции пользователя более не повторялась.
Вполне возможно, в описанном выше случае мы имели дело с ошибкой функционирования "автономных файлов". Поэтому не исключено, что существует путь решить проблему не столь кардинальным образом, то есть не отключая автономные файлы.
Устраняем ошибку «Слишком много открытых файлов» или «Too many open files» в 1С под ОС Linux (Red Hat 7/Centos 7)
Подробнее об ошибке
Пример полного текста ошибки:
Ошибка при выполнении файловой операции … Слишком много открытых файлов .
Описание:
Данная ошибка связана с тем, что ОС Linux исчерпала ограниченный ей лимит файлов на открытие и может возникать как при работе пользователя в пользовательском режиме, так и при работе разработчика с хранилищем конфигурации.
Побочными ошибками данной проблемы могут являться также ошибки работы с дисковой подсистемой. Такие как:
Решение:
На всех серверах 1С выполним следующие настройки лимитов открываемых файлов.
Увеличиваем лимит на открытые файлы всей системы.
1. Получим значение количества файлов, которые можно открыть в нашей файловой системе:
Скорее всего, здесь мы увидим числа порядка: 97822; 65208 и т.д.
Такие пределы нас вполне устраивают.
Данное значение используем в дальнейшей настройке.
Но, если понадобится их увеличить – добавим строку настроек в конфигурационный файл /etc/sysctl.conf любым удобным способом:
2. Перечитаем параметры:
где 6500 – это то число файлов, которое нам необходимо иметь возможность открывать в нашей файловой системе.
Увеличиваем лимит на открытые файлы для процессов 1С.
1. Отредактируем файл:
2. Перечитаем параметры:
3. Убедимся, что изменения вступили в силу. Получим pid службы:
4. По номеру pid получим значение параметра «max open files»:
Значение должно быть 65000.
Увеличиваем лимиты на открытые файлы для процесса 1С редактированием файла демона.
Результат данной настройки будет аналогичен предыдущему варианту.
2. Обновим конфигурацию демон:
3. Перезапустим демон:
Отметим также, что помимо настроек, относящихся к количеству открытых файлов – может понадобится обратить внимание на настройки максимального числа сегментов разделяемой памяти для всей системы.
Увеличиваем максимальное число сегментов разделяемой памяти для всей системы.
Все наши модифицированные настройки можем увидеть в конфигурационном файле /etc/sysctl.conf:
Еще можно посмотреть
Публикация 1С на Веб сервере Apache Linux
Пошаговые инструкции по публикация базы и web-сервисов 1С на веб-сервере Apache 2.4 на Linux.
Ошибки публикации базы и веб сервиса на веб сервере 1C+ Apache +Linux.
Многие из нас привыкли публиковать базу или веб сервис 1С нажатием нескольких кнопок. Но не все из многих знают, что для этого необходимо запустить(от имени администратора!) конфигуратор 1С:Предприятие именно на той машине, где установлен веб сервер(а именно компонента веб-расширения 1С:Предприятия). В случае, если веб-сервер и компонента веб-расширения 1С:Предприятия установлены на машину с ОС Linux без […]
Основные команды Linux
Список основных команд консоли Linux которые потребуются при установке и настройке 1С. Примеры использования с комментариями.
Установка и настройка хранилища конфигураций 1C на Linux сервере
Хранилище конфигурации 1С:Предприятия 8.3 является инструментом групповой разработки. Настраиваем сервер хранилища на Linux.
Настройка непрерывного архивирования (point-in-time-recovery, PITR) в PostgresPro 11 Linux
Для чего необходимо настраивать непрерывное архивирование базы данных? Для того, чтобы: иметь возможность восстанавливать копию базы данных на произвольный момент времени. в случае сбоя не терять драгоценные часы данных. 1. Знакомимся с каталогами хранения данных и бэкапов. 2. Настраиваем очистку устаревших файлов бэкапов. 3. Устанавливаем параметры непрерывного архивирования PostgresPro 11. 4. Включаем непрерывное архивирование. Описание […]
Ошибки СУБД. 1С+PostgreSQL+Linux. Часть 2.
Администрирование серверов 1С на Linux
Если вы работали с программами, которым приходится обрабатывать очень большое количество файловых дескрипторов, например с распределенными базами данных, такими, как Elasticsearch, то вы, наверняка, сталкивались с ошибкой "too many open files в Linux".
Ошибка too many open files Linux
Дословно эта ошибка означает, что программа открыла слишком много файлов и больше ей открывать нельзя. В Linux установлены жёсткие ограничения на количество открываемых файлов для каждого процесса и пользователя.
Посмотреть, сколько файлов можно открыть в вашей файловой системе, можно, выполнив команду:
Посмотреть текущие ограничения количества открытых файлов для пользователя можно командой:
Утилита ulimit возвращает два вида ограничений - hard и soft. Ограничение soft вы можете менять в любую сторону, пока оно не превышает hard. Ограничение hard можно менять только в меньшую сторону от имени обычного пользователя. От имени суперпользователя можно менять оба вида ограничений так, как нужно. По умолчанию отображаются soft-ограничения:
Чтобы вывести hard, используйте опцию -H:
Вы можете изменить ограничение, просто передав в ulimit новое значение:
Но поскольку hard-ограничение составляет 4000, то установить лимит больше этого значения вы не сможете. Чтобы изменить настройки ограничений для пользователя на постоянной основе, нужно настроить файл /etc/security/limits.conf. Синтаксис у него такой:
имя_пользователя тип_ограничения название_ограничения значение
Вместо имени пользователя можно использовать звездочку, чтобы изменения применялись ко всем пользователям в системе. Тип ограничения может быть soft или hard. Название - в нашем случае нужно nofile. И последний пункт - нужное значение. Установим максимум - 1617596.
sudo vi /etc/security/limits.conf
* hard nofile 1617596
* soft nofile 1617596
Нужно установить значение для soft и hard параметра, если вы хотите, чтобы изменения вступили в силу. Также убедитесь, что в файле /etc/pam.d/common-session есть такая строчка:
session required pam_limits.so
Если её нет, добавьте в конец. Она нужна, чтобы ваши ограничения загружались при авторизации пользователя.
Если вам нужно настроить ограничения только для определенного сервиса, например Apache или Elasticsearch, то для этого не обязательно менять все настройки в системе. Вы можете сделать это с помощью systemctl. Просто выполните:
sudo systemctl edit имя_сервиса
И добавьте в открывшейся файл такие строки:
[Service]
LimitNOFILE=1617596
LimitNOFILESoft=1617596
Здесь мы устанавливаем максимально возможное ограничение как для hard- так и для soft-параметра. Дальше нужно закрыть этот файл и обновить конфигурацию сервисов:
sudo systemctl daemon-reload
Затем перезагрузить нужный сервис:
sudo systemctl restart имя_сервиса
Убедится, что для вашего сервиса применились нужные ограничения, можно, открыв файл по пути /proc/pid_сервиса/limits. Сначала смотрим PID нужного нам сервиса:
ps aux | grep elasticsearch
Затем смотрим информацию:
Выводы
В этой небольшой статье мы разобрали, что делать, если возникает ошибка "слишком много открытых файлов Linux", а также как изменять ограничения на количество открытых файлов для пользователя и процесса в Linux.
Читайте также: