27 сентября, 2021
27 сентября, 2021
Дано:
Ошибка:
Неспецифицированная ошибка работы с ресурсом
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
Недостаточно свободной памяти для выполнения операции
Ошибка обнаружена на платформе 8.3.18.1289
Что было проделано в попытках исправить ситуацию:
- ТиИ со всеми возможными вариантам включая исправления.
- перезагрузка сервера 1С, СУБД, а так же самой железки.
- изменение настроек выделения памяти СУБД
- чистки КЭШей 1С на стороне сервера (тут было очень страшно, но с чистилось только то что можно) и клиента
- Удаление базы из сервера 1С и восстановление из dt
Решение
В итоге после долгих поисков ошибка нашлась среди багов платформы (полная официальная информация тут: Код ошибки: 10230003), решение так же нашлось, но, конечно, оно подойдет не всем.
Эта ошибка платформы возникает по причине того, что несколько расширений расширяют функционал одной и той же формы. В моем случае одно расширение было неактивно и не использовалось, поэтому я мог беспрепятственно его удалить из базы. Таким образом важно понимать, что даже из-за неактивного расширения может возникать ошибка.
Для тех, кто не может просто удалить расширение, может быть выходом станет обновление платформы до новых релизов, так как согласно официальному источнику ошибка исправлена в новых релизах версия 8.3.18.1433 и версия 8.3.19.1150. Лично не проверял. Но думаю это так.
Показывать по
10
20
40
сообщений
![]()
![]()
Дата регистрации: 17.02.2009
Сообщений:
Обновились на Платформа: 1С:Предприятие 8.3 (8.3.15.1747) и понеслось:
Неспецифицированная ошибка работы с ресурсом
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
Недостаточно свободной памяти для выполнения операции
Кто как боролся, особенно на сервере 2003 ??
![]()
![]()
Дата регистрации: 17.02.2009
Сообщений:
Вот ответ 1С:
Тоесть я устанавливаю версию для работы в 32-х битной системе, но от меня требуют 64-х битную, это ли не косяк 1С, который они не желают исправлять?
Дата регистрации: 18.02.2009
Сообщений:
А чего тут бороться? Написано же «недостаточно памяти».
Увеличиваете память и всё.
На 64 переходить не обязательно.
![]()
![]()
Дата регистрации: 17.02.2009
Сообщений:
Девушка, милая, на 32 разрядной ОС ограничение в 4 ГБ. Из них ОС задействует под программы 2 и 2 оставляет для системных задач. Можно только перераспределить.
![]()
Контрольное Cоотношение Равенство
![]()
Дата регистрации: 28.01.2018
Сообщений:
SoNik,
судя по тексту ошибки, надо просто обрезать и настроить размер ЖР — Журнал Регистрации
![]()
![]()
Дата регистрации: 28.01.2020
Сообщений:
![]()
Контрольное Cоотношение Равенство
![]()
Дата регистрации: 28.01.2018
Сообщений:
Ответили же уже выше:
— уменьшите (размер) ЖР и
— увеличте размер , выделяемой под процессы 1С оперативной памяти
— удалите ненужное
![]()
![]()
Дата регистрации: 28.01.2020
Сообщений:
Контрольное Cоотношение Равенство пишет:
а про уменьшить размер ЖР можно чуть подробнее?
![]()
Контрольное Cоотношение Равенство
![]()
Дата регистрации: 28.01.2018
Сообщений:
Показывать по
10
20
40
сообщений
1
2
Показывать по
10
20
40
сообщений
![]()
![]()
Дата регистрации: 25.12.2004
Сообщений:
![]()
![]()
Дата регистрации: 25.12.2004
Сообщений:
![]()
![]()
Дата регистрации: 25.12.2008
Сообщений:
где читал про это — решалась задача увеличением количества рабочих процессов
![]()
![]()
Дата регистрации: 05.03.2007
Сообщений:
Кто-то ест память.<br>Попробуйте посмотреть через КонсольЗаданий.epf нет ли заданий для выплнения сервером. Если есть попробуйте отключить.<br>Возможно есть утечка памяти в самой конфигурации, но тут ничего не поделаешь.
![]()
![]()
Дата регистрации: 25.12.2004
Сообщений:
Пробовал увеличить — не помогло..
![]()
![]()
Дата регистрации: 25.12.2004
Сообщений:
Отключение заданий проблему не решило ![]()
![]()
![]()
Дата регистрации: 24.02.2009
Сообщений:
![]()
![]()
Дата регистрации: 25.12.2004
Сообщений:
По поводу перезапуска рабочих процессов — с какого момента начинается отсчет указанный в настройке кластера? C момента нажатия на клавишу «ОК»?
![]()
![]()
Дата регистрации: 24.02.2009
Сообщений:
С момента старта процесса. Например стартовал в 18:00:00. Период перезапуска 86400 секунд, т.е. 24 часа. Соответственно через сутки в 18:00:00 процесс остановится и будет создано новый процесс.
![]()
![]()
Дата регистрации: 25.12.2004
Сообщений:
Понятно, спасибо. Добавил сейчас еще 2-а процесса, не помогло..
Показывать по
10
20
40
сообщений
![]()
![]()
Дата регистрации: 06.03.2019
Сообщений:
Ситуация такая. Была установлена 1С, всё работало год,наверное, проблем не было.
И вот один в день программа перестала запускаться. Может быть после обновления чего-то в Xubuntu, не могу сказать точно, так как базу 1С использую раз в месяц, веду крошечное ИП.
Если заходить через конфигуратор, то появляется ошибка «недостаточно памяти», если заходить через пользователя, то получаю сообщение «Неспецифицированная ошибка работы с ресурсом», после перезапуска появляется окно с ошибкой:
Долгий эпос со службой поддержки ни к чему не привел. Но было сделано следующее:
1. Последняя база отправлена к ним на проверку — вердикт «база в порядке».
2. База скачана обратно, попытка подключить ее — результат ноль, все те же ошибки.
3. Совет — снести и переустановить на версию раньше,так как у последней, по их словам, глюки. Снёс полностью программу, установил снова теперь уже версию 8.3.13.1690. Результат ноль, все те же ошибки.
Хелп. Что делать?
![]()
![]()
Дата регистрации: 12.09.2019
Сообщений:
Здравствуйте.
Вам ещё нужна помощь?
![]()
![]()
Дата регистрации: 06.03.2019
Сообщений:
Анатолий Соломонов, Анатолий Соломонов пишет:
Да, система так и не запустилась.
Переписка со службой поддержки в течении нескольких месяцев привела к результату: мы не знаем,почему у вас не запускается.
В итоге я плюнул и отказался от 1С.
![]()
![]()
Дата регистрации: 12.09.2019
Сообщений:
![]()
![]()
Дата регистрации: 06.03.2019
Сообщений:
Анатолий Соломонов пишет:
да там просто после очередного обновления 1С что-то стало несовместимо с Xubuntu-шной жизнью ![]()
а переустанавливать Linux, который я настраивал долго и занудно, желания нет.
Комп слабый, так что в VirtualBox 1С не полетит.
Так что на этом мои отношения с 1С закончились.
Спасибо за желание помочь ![]()
![]()
![]()
Дата регистрации: 12.09.2019
Сообщений:
Andrew Survila, Ну вот я тоже подумал поставить виртуалку и туда 1с поставить.Я в скором времени хочу вспомнить весь этот процесс)
![]()
![]()
Дата регистрации: 06.03.2019
Сообщений:
Анатолий Соломонов пишет:
если комп мощный — то все получится.
увы, не мой вариант
Показывать по
10
20
40
сообщений
Расследование
возникшей ошибки нехватки памяти на
сервере 1С
Поступило
обращение со следующей
ошибкой:
«Неспецифицированная ошибка
работы с ресурсом
Ошибка при выполнении
запроса POST к ресурсу /e1cib/login:
Недостаточно
свободной памяти для выполнения
операции
Выполняется ожидание
возможности запуска.
При
появлении возможности, запуск будет
выполнен автоматически.
Нажмите «Выполнить запуск» для немедленной
попытки запуска.
Нажмите «Отмена» для отказа от запуска.»



Настроив
ТЖ с событием EXCP, EXCPCNTX обнаруживаем
запись:
«Ошибка
СУБД out of memory for query result»
Обе
ошибки сообщают о проблеме объема
памяти, на основании которых подозреваемым
становится код конфигурации (возможно
наличие неоптимальных запросов).
Находим
код конфигурации, вызывающий ошибку:
В
журнале регистрации указан следующий
код:
Недостаточно
памяти для получения результата запроса
к базе данных
Открываем
конфигуратор и переходим в указанный
модуль к указанному номеру строки кода:

Строка,
на которой произошла ошибка:
Смотрим
тип объекта (константы), к которой идет
обращение:

Итак,
в конфигурации есть константа
«ДокументооборотСКонтролирующимиОрганами_ВнешнийМодуль»,
которая хранит в базе что-то
неструктурированое (двоичные данные),
и это неструктурированное может занимать
значительный объем памяти.
Проверяем,
какой объем данных фактически занимает
константа.
Узнаем
имя таблицы хранения в базе PostgreSQL —
таблица «_Const10013», индекс «_Const10013_ByKey».

Узнаем
размер таблиц «Const10013», «_Const10013_ByKey» на
диске:

На
диске таблица занимает всего 4688 Кб = 4,6
Мб. Размер является незначительным,
причина не в константе.
Обнаруживаем,
что кластер 1С является 32-разрядным:

32-разрядный
кластер 1С имеет ограничение, примерно,
3.8 Гб, по достижении которого происходит
падение процесса, службы.
В
режиме отсутствия нагрузки rphost занял
3,2 Гб, что близко к порогу падения.
Подобные
падения будут происходить в любой момент
времени.
— в
кластере серверов 1С «Интервал превышения
допустимого объема памяти процессов»
= 300. Настройка не избавляет от ошибки,
но необходима для снижения частоты
возникновения ошибки.
— в
планировщике Windows настроен перезапуск
службы 1С; такими образом освобождается виртуальное адресное пространство
в памяти, создается новый рабочий
процесс. Настройка тоже не гарантирует исключение ошибки, но снижает
вероятность ее возникновения.

Для
предотвращения повторной ошибки
лучше:
—
сменить 32-разрядный кластер серверов
1С на 64-разрядный;
—
осуществить переход на платформенные
лицензии КОРП для снятия ограничений
по настройкам, возможности гибкой
настройки распределения памяти сервера.
Так
как на сервере используется 14 ядер
процессора, то необходим переход на
платформенные лицензии КОРП.
При обмене с сайтом Битрикс, возникает ошибка: «Неспецифицированная ошибка работы с ресурсом. Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm. Недостаточно свободной памяти для выполнения операции <Перезапустить>/<Завершить>».
Сама 1С запускается из локальной папки, база на SQL.
В чем может быть проблема?
Искал в интернете, но там в основном эта же проблема описывается при публикации базы на веб-сервере. А у меня программа запускается из файла на компьютере пользователя + база на SQL.
Может файлики поменьше туда посылать?
(0) А у меня программа запускается из файла на компьютере пользователя + база на SQL.
Поясните мне, что автор имеет в виду.
Это файловая база? Тогда причем тут SQL.
Это серверная база? Тогда причем тут «запускается из файла» ?
(2) Ну типа нету у него web-сервера.
Попробуйте 64-х битную платформу.
(3) Это база на SQL.
«Запускается из файла» — я имел ввиду, что сама платформа запускается из локального файла на компьютере. То есть нет никаких RDP.
1) Сколько ОЗУ на «сервере» ? (видел «сервера» с 8Гб ОЗУ — хотя конечно это не повод падать)
2) Обмен это обмен в вакууме ?
Это полный обмен ? По изменениям?
В логах пишется на чем конкретно обмен поломался.
Обмен ломается при выгрузке? или при загрузке?
3) В настройках узла битрикса есть реквизит «Количество товаров/объектов в пакете». Можно попробовать уменьшить кол-во
4) Раньше работало, а сейчас поломалось.
Раньше было 10 товаров и 2 свойства, а вчера импортировали еще 80к позиций номенклатуры.
Вот такой набор вопросов, на которых нужно ответить самому себе.
32 бита сервер небось
(6)
«1) Сколько ОЗУ на «сервере» ? »
«2) Обмен это обмен в вакууме ?
Это полный обмен ? По изменениям?
В логах пишется на чем конкретно обмен поломался.
Обмен ломается при выгрузке? или при загрузке?»
Что значит «обмен в вакууме»?
Ломается при выгрузке.
На самоме деле это обмен не с Битриксом, а «Выгрузка товаров (Настройка обмена с интернет-магазином)». Нам нужны только файлы с данными, потом мы сами с ними работаем.
«3) В настройках узла битрикса есть реквизит «Количество товаров/объектов в пакете». Можно попробовать уменьшить кол-во»
Поскольку сейчас идет только выгрузка из 1С, наверное, там тоже есть такие же настройки?
«4) Раньше работало, а сейчас поломалось.»
Да именно так.
+(8) Платформа 64.
«4) Раньше работало, а сейчас поломалось.»
Да именно так.
(10) Там стоит галочка «Выгрузка на сайт». Если ставлю выгрузку в каталог, все проходит нормально, но в каталоге ничего не появляется.
(0) позовите программиста
но для начала ТиИ сделать
Deal with it
(15) сначала все же следует сделать бэкап, а уже потом все что угодно)
О логах.
Указанный каталог надеюсь расположен на сервере? И у службы 1С есть права туда писать?
Ибо Битрикс при выгрузке туда таки пишет.
В моей практике в битрикс выгружали по 40к номенклатуры по (это грустно да) 200 свойств. Сервер печалился, но выгружал.
А так да — зовите уже погроммиста.
(17) В этот каталог я могу писать файлы, разве может быть так, что 1С не может? )
(15) А при чем здесь ТиИ? Что могло порушиться?
Deal with it
(18) пользователь, под которым запускается служба 1С имеет права на этот каталог? НЕ пользователь сеанса, прошу заметить.
Этот каталог на сервере?
А у службы 1С есть права туда писать?
Зови своего админа и пусть он дает права службе 1С на этот каталог.
Заодно на каталог с логами пуст даст
фото пожми
или выгрузи без фото на сайт — посмотри как будет
(20) Дело в том, что когда эта ошибка выскакивала отдельным окном, внизу была ссылка для получения лог-файла. И он действительно создавался и записывался в этот каталог. https://yadi.sk/d/yRJHG1r8PIXhtg
Значит, доступ на запись у пользователя 1С есть.
Но тут это окно выскакивать перестало. Все пишется в окне сообщений, и там возникает такая строка: «Ошибка получения параметров обмена (ограничение размера файла)!»
Вот полный текст в окне сообщений: https://yadi.sk/d/Vixak3W832KDhQ .
(14) Да мы сами программисты, просто именно с такой проблемой раньше не сталкивались. Ничего, поработаем отладчиком, все и разъяснится.
А вот если бы вы сами делали, то какую вилку времени бы задали? Не по вопросу оплаты, а сколько клиенту ждать решения проблемы?
(24) может картинку прикрепили к товару жирную (под гиг) вот и загибается ваш обмен?
(28) если штатно картинки цепляли, то там размер должен быть в реквизите указан.
(28) — «Недостаточно свободной памяти для выполнения операции» — Лечится установкой ограничения (со стороны 1С) на отправляемые пакеты. Например отправлять по 50 позиций в пакете. Правда на твоих скринах я не увидел такой настройки. Может где на других закладках.
— «Ошибка получения параметров обмена (ограничение размера файла)» — Это баг/глюк/ошибка на стороне сайта (битрикса). Гуглится какие параметры нужно подкрутить в битриксе.
Это как решались данные ошибки у меня в связке УТ11 — Битрикс (обмен типовой встроенный в УТ)
(31) У меня вообще задано 1000 позиций )
Делал 100, то же самое. Попробую делать еще меньше. Потому что в этой выгрузке будет выгружаться справочник целиком.
Перешли сегодня на 8.3.15.1700 и PG 10.10.
До этого гоняли на тестовой базе — все путем работало.
Сейчас когда зашли все пользователи, стало периодически выкидывать пользователей с сообщением:
«Ошибка выполнения запроса
Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call:
по причине:
На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто»
Выкидывает из всех конфигураций и свежих ЕРП и древних УПП.
Че это за такое и как с этим бороться? Может у кого было такое.
Сейчас выяснилось, что ресурс у всех разный. Т.е. вообще в разнобой. Как то может быть связано с кэшем серверным или чем то подобным?
какая то срочная необходимость в 8.3.15 вообще есть ?
(2) Просто сидели на 8.3.13, а новые конфиги уже рекомендуют 8.3.14. Посмотрели ошибки, что в 8.3.14 что в 8.3.15 одинаковые, решили на последний переходить. Тем более что есть отзывы, что он быстрее.
Ну и описанное в (0), судя по тому что пишут в инете, происходит буквально на чуть не на всех релизах начиная с 8.3.5. Так что надо понять что за проблема и как ее решать.
(0) Вчера вышел очередной релиз. Идите дальше.
(0) посмотри на процессы 1с, скорее всего они перезапускаються в момент падения, изучи журналы ошибок возможно проблемы лицензирования
(2) Тоже перешли на 8.3.15, ибо
«Рекомендуется использовать текущую версию конфигурации «Управление торговлей», редакция 11 с версией системы 1С:Предприятие 8 8.3.15.1489 (и выше).»
Всё виндовое, MS SQL Server.
После установки платформы 8.3.15.1565 стали возникать периодические вылеты КАМИНа (после ТиИ получше стало, но совсем не исчезло).
А вчера попробовал запустить УТ в толстом клиенте (обычно в тонком работает): постоянные вылеты.
Может, совпадение, но похоже, что дело в толстом клиенте — КАМИН как раз использует толстый клиент. В тонком таких проблем нет.
(7) У нас похоже наоборот. Щас всех заставили ходить под толстым клиентом и уже полтора часа все норм. ТЖ запустил, логи смотрю, пока никакого криминала, но пока и не рушится ничего.
(5) Ну каждый день мы не можем релизы менять. Просто пока переходили, тестировали и прочее, выпустили новый релиз и там поправлены пара незначительных ошибок.
Для статистики.
В течение недели поменял платформу 8.3.15.1700 (Две PG, одна MSQL)
Полёт нормальный
Хм, почти два часа все было норм, щас опять выкинуло, причем не всех. Может старые конфиги УПП и КА мешают современной ЕРП? Фигово что все на одном РПХосте сидит. Так можно было бы локализовать хоть на предмет какая база выглючивает.
Может в лицензии ПРОФ есть ограничение на количество соединений/сеансов? У нас в сумме свыше 256 точно бывает, если считать фоновые и вообще все.
(0) ктож одновременно меняет платформу и субд?
(12) чисти настройки кластера и заново настраивай
ТС, не гонитесь за хотелками типовых. Типовая хочет, а платформа не может. Вот как бывает оказывается.
В смысле последние релизы (13-14-15) платформ баговатые идут. И конца и края не видно.
Откатитесь на тот релиз платформы где работало. В крайнем случае поставите отдельно службу 15ю для одной базы, а остальные будут жить спокойно.
(11) Запустите несколько агентов на разных портах.
Для начала почистить кэш на сервере.
Скрипт с 1С-овского ИТС.
Остановка службы 1С:Предприятие с очисткой временных файлов. (естественно подставить свои пути к кластеру, и имена служб).
set LOG_FILE="scripts.log" set SERVICE_1C_NAME="C:Enterprise . Server Agent (x86-)" set SERVICE_RAS_NAME="C:Enterprise . Remote Server" set CNTX_PATH="C:\srvinfo\reg_1541" set PFL_PATH="C:\ProgramData\C\cv8" set TEMP_PATH="C:\Windows\Temp" echo stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE% sc stop %SERVICE_1C_NAME% sc stop %SERVICE_RAS_NAME% timeout taskkill /f /im "rphost.exe" taskkill /f /im "rmngr.exe" taskkill /f /im "ragent.exe" taskkill /f /im "ras.exe" timeout echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE% echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE% DEL /Q /F /S %CNTX_PATH%\snccntx* DEL /Q /F %PFL_PATH%\*.pfl DEL /Q /F /S %TEMP_PATH%\*.* echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
Если баз не много (3-5), то установить в настройках рабочего сервера 1 базу на процесс.
Хотя для начала я бы попробовал наоборот — типовые настройки.
Очень странно, что при 256 сеансах у вас один rphost.
Проверьте — нет ли ограничений по памяти.
Включить ТЖ, анализировать логи падающих процессов.
PS Довольно рискованная операция — одновременная смена и СУБД, и платформы. Правильнее было бы разделить, чтобы сузить круг возможных причин любых косяков.
(13) Мы. Просто появилась возможность сделать все и сразу. Изначально стояла задача перейти на PG, а так как PG хочет не менее 14-ой, то решили не мелочиться и ставить сразу 15-ую. Естественно тестили это дело. (15) Ну 13-ая у нас пока висит, на всякий случай. (16) Тоже вариант, но щас пока смотрим как оно работает без извращений. Есть еще мнение что не почистили кэш, но админы уверяли что почистили, потому что щас выкинуло только двух пользователей, остальные работают.
(17) Кэш на сервере почистился, ибо базы полностью пересоздавали когда со скуля на PG переводили. Т.е. в оснастке удалялись и создавались заново, по крайней мере со слов админов. 🙂
(17) «Если баз не много (3-5), то установить в настройках рабочего сервера 1 базу на процесс.
Хотя для начала я бы попробовал наоборот — типовые настройки.
Очень странно, что при 256 сеансах у вас один rphost. » Для этого надо иметь лицензию КОРП, а тут только ПРОФ.
Вдогонку к (7).
Ну вот, выходит новая конфа Торговли (ничего принципиально нового, только ошибки исправили), и вот на тебе, рекомендуют ещё более новую платформу, чем предыдущая версия конфы:
«Рекомендуется использовать текущую версию конфигурации «Управление торговлей», редакция 11 с версией системы 1С:Предприятие 8 8.3.15.1656 (и выше).»
Если совсем плохо будет, придётся как-то организовывать возможность работы двух платформ для разных БД. Раньше с таким не сталкивался.
(10) А какие конфигурации, если не секрет?
Хм. Убрали ключ -debug все заработало. Я понимаю что этот ключик зло на рабочей базе, но должно же и с ним работать. Может че с окружением не так.
(23) у вас там что, круглосуточная работа?
(23)И да, вы чистку с отменой отладки не совместили?
(25) Я вчера вечером, всех выгнал, почистил все кэши. Не помогло. Отключил отладку на сервере. Помогло. На ночь поставил закрытие месяца. Не вылетело до сих пор и пока никого за полтора часа работы не выкинуло. Но в логах много событий типа:
«00:31.881002-0,EXCP,0,process=rphost,OSThread=5664,ClientID=6802,Exception=NetDataExchangeException,Descr=’server_addr=(2)192.168.3.32:59976 descr=2(0x00000002): Не удается найти указанный файл. line=1149 file=src\DataExchangeServerImpl.cpp'»
и
«00:26.084004-0,EXCP,3,process=rphost,p:processName=ERP_SINAR,OSThread=8140,t:clientID=125,t:applicationName=BackgroundJob,t:computerName=1CSA,t:connectID=3800,SessionID=1267,Usr=Жмаева Л.Д.,Exception=SeanceContextException,Descr=’Сеанс отсутствует или удален
ID=4828417a-f23b-4e5b-8c3f-f9dd08327b56, File=src\ClusterDistribImpl.cpp(1640)'»
Хотя пользователи ни на что не жалуются. Твои тезки периодически завершаются и появляются новые вместо них. 🙂
А вообще ЕРП на 8.3.15 и PG довольно быстро работает, по сравнению с 8.3.13 и MSSQL 2005, при прочих равных (оборудование и ОС остались теми же).
(28) сравнил версионник и блокировочник на управляемых блокировках!!! Но только пока не забываешь регулярно постгри обслуживать(бывает и раз в сутки это мало, но это про хайлоад) — он к этому более требователен чем сиквел.
(27) «Отключил отладку на сервере. Помогло. »
А включать отладчик по http пробовали? Просто интересно.
(30) Нет. Не пробовали.
(29) А че конкретно надо регулярно запускать для обслуживания?
(33) vacuum analize — дабы похерить старые версии и обновить статистику.
(34) А что там в новых версиях постгреса со статистикой неявных временных таблиц (подзапросов), починили её? А то, помнится, он ооочень часто ошибался раньше и гонял нестед лупы.
Все равно выкидывает. Значительно реже и не в таких масштабах (меня с двух разных баз выкинуло по одному разу за 4 часа), но выкидывает. Щас есть два мнения: 1. Что то с сетью или сетевыми интерфейсами. 2. На новой платформе могут работать только новые конфиги и надо убирать все старые на старую платформу.
+(38) При этом закрытие месяца работало всю ночь и еще потом два часа днем и доработало до конца без ошибок. Т.е. проблемы начались когда подтянулись пользователи. Буду пробовать добиваться чтобы все старые конфиги убрали с новой платформы.
Писал уже в (6) проверьте процессы они перезапускаются ? если да проверьте логи скорее всего отваливается лицензия следовательно падает процесс который не сразу перезапускается ибо лицензия глюкнула, если конфа работает под толстым клиентом то это 100% вылет пользователя если под тонким может и незаметно пройти если падение не долгое было.
(40) естественно чтобы посмотреть логи необходимо настроить технологический журнал.
(40) Да, процессы перезапускаются. Причем активно. Хотя меньше чем вчера. (41) Настроил ТЖ, но в этом потоке сообщений про лицензию не вижу ничего. Какую надо включить настройку и по какому признаку потом искать именно эти записи?
(20) >> Для этого надо иметь лицензию КОРП, а тут только ПРОФ.
А в ПРОФ эти параметры вообще закрыты для изменения или не принимаются изменения?
Я думал, что в целях эксперимента эти параметры менять всё таки можно.
(40) Выкидывает не всех и не изо всех баз. Т.е. как-то выборочно.
(43) Менять можно. Но при входе очередного пользователя ругается что параметры надо задать по умолчанию.
Пробовали чистить локальный кэш у этих самых выборочных пользователей?
(42) если есть возможность поставь атрибут «ALL» (возможны тормоза) чтобы всвё видеть или «SRVC» чтобы посмотреть что с сервисами происходит
(46) на разных сервисах возможно народ висит при этом вылетел только один, при таком раскладе из толстого клиента выкинет в тонком пройдет не заметно на рабочей процесс переползет (если есть рабочий).
(49) Тогда лучше уж писать результаты пинга в файл txt. И потом анализировать.
(46) Это первое что сделали. Меня тоже выкинуло.
(49) +. Пинг с параметром /L60000. 1С очень любит пакеты большого размера, а потерь и задержек в их передаче может быть на порядок больше, чем при обмене пакетами стандартного размера.
Вообще по сети — убедиться, что везде отключен IPv6 (на сервере и на клиентах), нет косяков с маршрутизацией.
На сервере и на клиентах нигде не включены в ОС режимы энергосбережения (может админы «оптимизировали» что-то массово), а так же в диспетчере устройств в параметрах сетевых карточек не разрешено отключение и/или перевод устройства в спящий режим для экономии энергии.
Но вообще сомнительно, что проблемы сети вылезли одновременно со сменой СУБД и платформы.
(49) Пинг с какой машины и до какой?
(52) Ну если что, то можем быстро переползти обратно на 8.3.13. Щас пока работаем. Но думаю что в итоге так и поступим.
(45) не очередного, а примерно после 10-го пользователя.
А по умолчанию там указано 128 сеансов на один рпхост. Так что наличие только одного рпхоста при таком числе пользователей уже повод насторожиться.
И не можешь подсказать, на какой типовой уже нужно релиз платформы 8.3.14+ ?
(54) Я бы на 8.3.13 не рисковал, точнее говоря, успешно его пропустили и сели на 8.3.14.1779
В сентябре вернули параметры на дефолтные и продолжаем пока сидеть на нем.
(56) Нужно ни на какой, а рекомендуется уже на последней ЕРП. Ну и с PG 10.10 тоже рекомендуется уже 8.3.14, хотя еще пару недель назад было 8.3.15, потом поменяли почему то, может именно по этому.
(57) Если на 8.3.14, то это снова на неделю минимум подготовка, чтобы у всех ее установить.
(53) с на какой валится до сервера 1С, если серверов несколько — до каждого из них.
(52) Точно -l 60000? У меня при таком параметры 100% потери пакетов.
(55) Нет проблемного пользователя. Всех с разной периодичностью выкидывает.
(58) >> пару недель назад было 8.3.15, потом поменяли почему то, может именно по этому.
Нет. Не поэтому.
Во-первых, там указано НЕ НИЖЕ(!!!) 8.3.14.
Во-вторых, есть процедура тестирования СУБД для работы с каждой версией платформы. Только когда весь протокол успешно соблюдён публикуют информацию о требованиях по совместимости.
Если бы была проблема с 8.3.15, об этом написали бы в файлике об особенностях СУБД.
(63) не ниже 8.3.12 вроде. Чего вы нас путаете? Это рекомендованная 8.3.14, это разные вещи, неи ниже и рекомендованная.
(61) Да. /l 60000. Потери могут быть но незначительные.
Можешь попробовать с меньшими значениями. Например, с 1000.
(64) Никто никого не путает. Я писал на сообщение автора ветки в (58) о версии СУБД PG 10.10.
Она (PG 10.10) работает с платформой НЕ НИЖЕ 8.3.14. То есть вполне совместима с 8.3.15.
При откате на 8.3.13 использование PG 10.10 на свой страх и риск. Вроде как, должно работать, но это не точно и 1С это не проверяла.
(61) Ну значит у вас стоит оборудование которое не тянет. коммутаторы/свитчи не все тянут или игнорируют больше заявленного размера.
ОФФ. Вообще странно, что сплошь и рядом встречается игнорирование требований совместимости со стороны пользователей и непонимание того, чем отличается «необходимо» от «рекомендуется» и требования к конфигурации и к СУБД.
(61) У вас сеть точно проводная, не WiFi?
Проверьте маршрутизацию. Через сколько коммутаторов проходят пакеты. Может админы что-то накосячили или действительно какой-нибудь коммутатор глючит или накрылся вовсе.
PostgreSQL, версия 10.10-1.1C
Внимание! Текущая версия PostgreSQL предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.14.1565
(69) Или выяснится что петля в сетке и как только нагрузка на локалку слега вырастает («когда зашли все пользователи») сетевой шторм начинается ))
Админам скажи чтоб iPerf -ом проверили и в НЕ рабочее время. А то всю локаль положат.
(36) https://forum.infostart.ru/forum86/topic229257/#message2327174
В 7-ом сообщении текст запроса на 1С и его трансляция в PostgreSQL.
Не думаю, что довели оптимизатор до такого состояния, чтобы он с легкостью работал с подобным. Жаль, что нет плана этого запроса.
(73) Джойн с подзапросом — тяжелый случай для постгреса всегда был. А в 1с это сплошь и рядом, ибо виртуальная таблица регистра это по сути подзапрос. Суть в том, что на момент формирования плана основного запроса еще нет информации о том, какова будет статистика подзапроса, и оптимизатор её оценивает как-то эвристически. И в большинстве случаев предполагает, что результат будет мелкий, а в 1с он как правило большой. Тут всю систему надо менять, отказываться от принципа формирования плана «сверху вниз», в сторону формирования плана «снизу вверх» с выполнением подзапросов ДО формирования плана запроса верхнего уровня. Но это вряд ли будет в постгресе.. никому кроме 1с это не надо.
(65) /l 60000 — 100% потерь во все стороны, /l 6000 — норм. Уверен, что нолями не ошибся? Проблем с сетью, с 1С нет.
(71) от петли обычно в итоге сеть ложится
(75) Уверен. Нолями не ошибся. 60000 — это максимально возможный размер буфера (точнее — 65536).
Насколько большими пакетами обменивается 1С — я не знаю. Вполне возможно, что и 1000 достаточно.
У меня с 60000 потерь нет.
(77) Даже при /l 20000 — потери: 50%
(78) То что потери при больших пакетах это еще ничего не говорит.
(77) Между сервером 1С и сервером PG ставил 60000 — норм. Между моим компом и сервером 1С 100% потери, может из-за того что 100Мб сеть или куча всякого между нами. Но до перехода на 8.3.15 все же работало. Что интересно оно и на тестовом сервере, в котором пользователи на корпии базы всякое крутили, все работало норм.
(80) а у вас там до кучи админы что-то перепилить не решились пока вы платформу и базовод не апнули?
H A D G E H O G s
Ошибка зарегана, обещали поправить.
Мы у себя отключили пересчет агрегатов, пусть отчеты будут тормознее.
H A D G E H O G s
(82) Спасибо, попробуем.
Регл. задание Обновление агрегатов отключено. Агрегатами вообще не дает никак управлять. Т.е. погашены закладки и кнопки касающиеся агрегатов.
(82)ээээ, если корп и серверов есть — все фоновые можно подальше засунуть.
И да, теоретически пересчитывать можно средствами постгри, но нужно скрипт запилить.
Что то совсем все плохо. Щас при проведении документов начало ругаться что объект не найден. Все встало колом. PG жрет процессор под 100%, при этом все висит. Какой-то так себе опыт перевода на PG получается. 🙂
Или мы не умеем ее готовить или ERP 150Г и 150 пользователей в принципе не способна работать на PG.
(87) В БГУ 1.0 на PostgreSQL 10.10 проведение одного из документов(внутреннее перемещение) может приводить к такому же эффекту, причем еще занимается вся доступная память, включая своп, после чего процесс postgres самоубивается с криками «Out of memory!» и всех выкидывает.
enable_nsetloop=off не помогает.
На 9.6.7 и 11.5 такого происходит.
К (89) Такого не происходит.
А «объект не найден» больше похоже на платформу, чем на СУБД. Может, совокупность версий конфигурации и платформы.
(91) Может. Просто чем дальше тем хуже. Возможно с индексами проблема, хотя делали реиндекс базе. Щас наверное откатим на MS SQL, а на копии посмотрим че это за фигня. Проблема конкретного документа или с базой чета. Тут вообще все странно, отражение в регл. учете запускается, в регистре к отражению все документов 30, но он часами не может их отразить, фоновое задание висит и только в размерах пухнет.
Хм. Короче. Выяснилось что упирается в дисковую подсистему. Длинная очередь к диску. Даже крутой рейд 10 не помогает. Поставили базу на SSD 970 EVO PLUS — все начало летать, право пока только половина пользователей ее нагружают, но раньше все висело даже на меньшем количестве. PG любит быстрые диски. Ну таки SDD даже если каждый год менять, то это все-равно дешевле, чем покупать новый MS SQL, раз так в 50. 🙂 Щас вот думаем, таки в продакт завести SSD или воспользоваться вредными советами и отключить fsync и прочее, ибо типа на рейде есть батарейка и не страшно.
(93) А включить асинхронную запись в постгресе пробовали?
(94) Нет пока. Админы тут посмотрели статистику и выяснили что просела производительность дисков. Короче, расследование показало очевидную вещь. У PG куча мелких файлов и он в процессе работы еще не меньшую кучу создает. Т.е. нужен быстрый произвольный доступ, что SSD конечно предоставляет с легкостью, а массив на SAS, пусть даже серверных дисках, не может. Отсюда же понимание почему у MS SQL не было таких проблем — там два больших файла на базу и еще несколько служебных и нужно быстрое последовательное чтение, что конечно уже рейд легко дает. Так что пока ситуёвина такая: если хотите переходить на PG да еще с большими и нагруженными базами, то нужны SSD или какие-то другие массивы с большой скоростью произвольного доступа.
(95) Ну это понятно. Просто интересно, проседает ли производительность с включенной асинхронной записью, то есть очередь возникает на чтение или на запись.
Тут дело скорее не с количеством файлов как таковым. Ведь внутри этого большого файла базы mssql по сети так же куча «файлов» — таблиц, индексов, метаданных. Возможно связано с особенностью работы винды с большими каталогами, когда при обращении к любой таблице происходит обращение к каталогу, а в случае каких-то проблем с индексами ntfs оно очень медленное, так как производится последовательный поиск.
+(96) «по сети» читать как «по сути»)
H A D G E H O G s
Поставили SSD
Пользователи стали более лучше и быстрее переключаться с упавшего rphost-а 🙂
profit
(99) Ну это да, это косяк платформы. 🙂 Будем переходить на 8.3.16, там в последнем вроде как раз эти косяки с падением процессов пофиксили. Но вообще это конечно засада. После 8.3.12 ни одного стабильного релиза. Они бы вместо всяких, мало кому нужных, рюшечек довели бы до ума платформу, чтобы она тупо не падала от любого чиха. А то похоже на продукцию АвтоВАЗа еще лет 10 назад, когда в рассыпающемся ведре с болтами кучу всяких наворотов, которые тоже через раз работают.

