Ошибка при выполнении файловой операции too many open files 1с
Столкнулся вот с такой проблемой. Уверен, что дело не в обновлении и не в 1с. В последнее время с SQL что-то происходит, после перехода на новую платформу. Уже одну базу полностью обновил и только после внесения ее в предприятие при последующем обновлении появилась ошибка "Ошибка при выполнении файловой операции". А сейчас, после обновления конфы и когда нажимаю "Обновить конфигурацию базы данных", вылетает ошибка. При обновлении на другой базе, вообще писало, что не хватает памяти, хотя она есть. Что это вообще за ошибка и точно, из-за чего это происходит, Скуль?
Пробовала на тестовой базе выгрузку/загрузку DT, также пробовала увеличение пакетов (Network packet Size) до 16388. Не помогает.
Пыталась поставить ниже версию 3,0,75,37, тоже самое и та же ошибка.
Сейчас пробую для узлов в БД, которые либо помечены на удаление, либо не используемые в текущем плане обмена, удалить из регистра сведений версии объектов (с ними,надеюсь и удаляться данные таблицы NG_ регистраций изменений) записи. Может это сработает.
На данный момент вышла еще версия поставщика 3_0_75_93, тоже попробую поставить.
Если кто-то сталкивался именно с такой проблемой и ее преодолел, напишите, пожалуйста. Время уходит, бухгалтерия очень злится), самооценка падает.
Залезла в SQL, нашла таблицу Регистра сведений Версии объектов (у нас dbo._InfoRg18640). Эта таблица даже не имеет таблицы dbo._InfoRg18640NG. Возник вопрос: а что тогда реструктуризирует 1С при обновлении, какие записи? В панели состояния написано" реструктуризация РегистрСведений.ВерсииОбъектов таблица регистрации изменений : 80401000. Помогите, плиз
Аналогичная ситуация на той же платформе (8.3.15.1830) пытаюсь обновить БСО. Появилась, как раз после повышения платформы. Среди попробованного для решения этой проблемы, только чистка кеша привела к тому, что смог обновиться на один релиз из 3-х необходимых, после этого опять вываливается с ошибкой. Причем ранее на той же платформе обновляя ЗУП (5 релизов) дважды сталкивался с этой ошибкой, но там после перезапуска обновления оно завершалось нормально.
Устраняем ошибку «Слишком много открытых файлов» или «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:
Еще можно посмотреть
Настройка непрерывного архивирования (point-in-time-recovery, PITR) в PostgresPro 11 Linux
Практический пример настройки Postgre SQL для непрерывного архивирования баз данных 1С Предприятия на ОС Linux
Установка PostgreSQL для 1С на Linux
Пошаговый процесс установки СУБД PostgreSQL для 1С на Linux сервер.
Ошибки СУБД. 1С+PostgreSQL+Linux. Часть 2.
Отладка на сервере 1С на Linux
Ошибки публикации базы и веб сервиса на веб сервере 1C+ Apache +Linux.
Многие из нас привыкли публиковать базу или веб сервис 1С нажатием нескольких кнопок. Но не все из многих знают, что для этого необходимо запустить(от имени администратора!) конфигуратор 1С:Предприятие именно на той машине, где установлен веб сервер(а именно компонента веб-расширения 1С:Предприятия). В случае, если веб-сервер и компонента веб-расширения 1С:Предприятия установлены на машину с ОС Linux без […]
Хранение файлов 1С в томах на nfs-шаре Linux
Пошаговая настройка варианта хранения файлов 1С Предприятия во внешнем NFS хранилище на ОС Linux
Ошибки сервера 1С на Linux
Описание типичных ошибок которые возникают при запуске службы сервера 1С на Linux и пути их исправления
19.11.2019
VyacheslavK
Linux
комментария 4
Очень часто при работе на высоконагруженных Linux серверах могут возникать ошибки “too many open files». Это означает, что программа открыла слишком много файлов (читай файловых дескрипторов) и не может открыть новые. В Linux ограничения “max open file limit“ установлены по умолчанию для каждого процесса и пользователя, и они не слишком высокие.
В данной статье мы рассмотрим, как проверить текущие ограничения по количеству открытых файлов, как его изменить эту настройку для всего сервера, для отдельных сервисов и для сеанса.
Ошибка: Too many open files и лимиты на количество открытых файлов в Linux
Максимально количество файловых дескрипторов, которые могут быть открыты в вашей системе можно узнать так:
Ограничение на количество открытых файлов для текущего пользователя – 1024. Можно проверить так:
Есть два типа ограничений: Hard и Soft. Пользователь может изменить лимит для soft ограничения (но значение soft не может превышать hard). Hard ограничение можно изменить только от привилегированного пользователя.
Для вывода Soft -граничения выполните:
Для вывода Hard-ограничения:
Настройки лимитов ограничения на количество одновременно открытых файлов в Linux
Ели вы используете Ubuntu, нужно прописать строку:
Данный параметр добавляет возможность загрузки ограничений при авторизации пользователя.
После изменений, перезапустите терминал и проверьте значение лимита max_open_files:
Увеличить лимита открытых файловых дескрипторов для отдельного сервиса
После изменения, нужно обновить конфигурацию сервиса и перезапустить его:
Чтобы проверить, изменились ли значения, нужно получить PID сервиса:
Например, вы определил PID сервиса 32724:
Так вы изменили значения Max open files для конкретного сервиса.
Увеличение максимального количества открытых файлов для Nginx и Apache
После чего выполнить рестарт Nginx.
Для apache, нужно создать директорию:
После этого создайте файл limit_nofile.conf:
И добавьте в него:
Лимиты file-max для текущей сессии
Чтобы изменить лимиты на открытые файлы в рамках вашей сессии терминала, выполните команду:
При закрытии терминала и создания новой сессии, лимиты вернуться к начальным значениям, указанным в файле /etc/security/limits.conf.
Чтобы изменить общее значение в системе /proc/sys/fs/file-max, измените значение fs.file-max в /etc/sysctl.conf:
В данной статье мы разобрались, как решить проблему с недостаточным лимитом для открытых файловых дескрипторов в 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.
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.
Оцените статью:
Об авторе
Описание проблемы
В моей компании заканчивается обновление операционных систем у виртуальных серверов, с Windows Server 2012 R2 на Windows Server 2016, я понимаю, что поддержка первых еще будет несколько лет, но хочется уже не делать это в последний момент, а слегка опережать, да и уже давно пора стремиться к Windows Server 2019. Сервера 1С не были исключением, обновление происходило по быстрому варианты. Тут подразумевается накатывание более новой версии ОС по верх старой, тут мы убивали двух зайцев:
- Получали свежую версию ОС
- Оставляли весь софт на сервере, и не требовалась его переустановка
В случае чего всегда можно было откатиться из снапшота на момент проведения работ, благо ESXI 6.5 это помогает делать в два клика. Все прекрасно обновилось и сервер зажил новой жизнью. В какой-то момент при запуске клиента 1С 8.3 на RDS ферме, стала появляться ошибка:
Устранение проблемы
Начав изучать данный вопрос мы не стали откатываться к бэкапу, так как данная проблема возникала не постоянно, а через некоторые промежутки и была вызвана явно не переходом на более новую версию операционной системы. Подняв исторические данные в системе заявок, я нашел похожую, где решением ошибки был перенос базы данных 1С на другой диск. Меня это заинтересовало и я стал прикидывать, что же могло быть в той ситуации. Через минут 20 я нашел одну закономерность, что на всех проблемных хостах был установлен компонент Windows дедупликации, как раз на тех дисках, где располагались базы данных 1С.
Я для тестирования отключил дедупликацию и вернул все в исходное состояние, и о чудо ошибка при выполнении файловой операции больше не появлялась. Все те же действия я произвел и на остальных серверах.
Из дополнительных методов я могу вам посоветовать еще очистку кэша 1С. Еще в на умных сайтах советуют на серверах, где используется 1С отключать протокол IPv6 на сетевых интерфейсах, но лично я не понимаю этого прикола, так как сама Microsoft советует по возможности этого не делать, в виду того, что очень многие ее сервисы и компоненты Windows в приоритете используют именно его, меньше будет проблем с DNS и Active Directory.
Читайте также: