Ошибка при выполнении файловой операции too many open files 1с
Обновлено: 06.07.2024
Столкнулся вот с такой проблемой. Уверен, что дело не в обновлении и не в 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 релизов) дважды сталкивался с этой ошибкой, но там после перезапуска обновления оно завершалось нормально.
Получилось))) выгрузила базу и загрузила ее снова. все таблицы сели на место. ошибка пропала
(9) Везет.Поздравляю. ) у вас база 1С клиент-сервер или файловая?
Скажите еще, пожалуйста момент, когда вы выгружаете и загружаете базу: выполнили объединение с обновлением и до применения обновления выгрузили, потом загрузили базу и запускаете 1С для принятия обновления? Так?
Попробовал увеличение пакетов, не помогло. Кроме того с аналогичной проблемой столкнулся на платформе (8.3.14.1976).
Либо проверим все ли зависимости были установлены. И установим недостающие.
ERROR: type «tt7» already exists
Пример полного текста ошибки:
HINT : A relation has an associated type of the same name , so you must use a name that doesn ' t conflict .
Описание:
Данная ошибка является «плавающей» и может возникать в различных местах
Решение:
Выгрузим и загрузим базу данных средствами 1С:Предприятия(через файл *.dt).
ERROR: could not read block
Ошибка при выполнении операции с информационно базой по причине : Ошибка СУБД : ERROR : could not read block . . . in file "" Input / output error
Описание ошибки:
База не запускается. Разрушились диски.
Решения:
Переносим базу на другую дисковую систему.
Разворачиваем из резервной копии.
Пример полного текста ошибки:
Не удалось привязаться к адресу . Адрес уже используется . Возможно порт 5432 занят другим процессом postmaster ? Система БД выключена . Не удалось запустить сервер .
Описание:
Такая ситуация часто случается у начинающих администраторов в случае, если они хотят инициализировать сервер в каталог отличный от каталога по умолчанию. При этом сервер уже запустили из каталога по умолчанию.
В этой ситуации при попытке запуска видно ошибку – сервер не запускается.
А при проверке состояния видно, что сервер работает.
Если проверим запущенные процессы пользователя postgres, то можно увидеть, что порт 5432 занят кластером PostgreSQL, только запущенным из каталога по умолчанию.
Решение:
Остановим работающий кластер сервера СУБД.
/ opt / pgpro / ent - 10 / bin / pg_ctl -- locale = ru_RU . UTF - 8 - D / var / lib / pgpro / ent - 10 / data stopИнициализируем кластер из нового каталога(если он не инициализирован).
/ opt / pgpro / ent - 10 / bin / initdb -- locale = ru_RU . UTF - 8 - D / pgpro / pgdataЗапустим из нового каталога.
/ opt / pgpro / ent - 10 / bin / pg_ctl -- locale = ru_RU . UTF - 8 - D / pgpro / pgdata startОписание:
Длительный запуск, длительный захват объектов в хранилище, длительное сохранение конфигурации 1С:Предприятия.
Решение:
Такая проблема может быть связано с настройками СУБД PostgreSQL.
Рассчитаем настройки СУБД.
Описание настроек приведено на ИТС.
Выполним настройки, для этого перейдем в терминал psql:
Через psql установим параметры командой ALTER SYSTEM SET(параметры необходимо указать для вашей СУБД):
ALTER SYSTEM SET max_parallel_workers_per_gather = 22 ;Описание ошибки:
При загрузке данных из файла *.xlsx в 1С отображаются иероглифы. Используемая СУБД PostgreSQL/PostgresPro.
Также возможна проблема с кодировкой в выгружаемом файле из 1С:
Решение:
На сервере СУБД проверим и выполним настройку локали.
1. Проверим наличие локали:
2. Проверим переменную:
Корректное значение результатов выполнения команд 2, 3:
3. Если результат не соответствует, выполним:
5. Выполним перезапуск серверов СУБД
Еще можно посмотреть
Настройка непрерывного архивирования (point-in-time-recovery, PITR) в PostgresPro 11 Linux
Для чего необходимо настраивать непрерывное архивирование базы данных? Для того, чтобы: иметь возможность восстанавливать копию базы данных на произвольный момент времени. в случае сбоя не терять драгоценные часы данных. 1. Знакомимся с каталогами хранения данных и бэкапов. 2. Настраиваем очистку устаревших файлов бэкапов. 3. Устанавливаем параметры непрерывного архивирования PostgresPro 11. 4. Включаем непрерывное архивирование. Описание […]
Основные команды Linux
Список основных команд консоли Linux которые потребуются при установке и настройке 1С. Примеры использования с комментариями.
Основы работы в Linux
Основы работы в Linux. Как подключиться к серверу. Как скопировать файлы на сервер. Редактирование конфигурационных файлов.
Установка двух версий сервера 1С на Linux
Пошаговый процесс установки и запуска двух версий сервера 1С на Linux. Полное описание настройки второго экземпляра сервера 1С.
Ошибки сервера 1С на Linux
Описание типичных ошибок которые возникают при запуске службы сервера 1С на Linux и пути их исправления
Ошибки СУБД. 1С+PostgreSQL+Linux. Часть 1.
Администрирование серверов 1С на Linux
Очень часто при работе на высоконагруженных 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 и рассмотрели несколько вариантов изменения лимитов на сервере.
Описание проблемы
В моей компании заканчивается обновление операционных систем у виртуальных серверов, с 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.
Читайте также: