На компьютере (серверное железо) установлена виртуализация VMWare разделена на 2 системы. Windows и Linux на которых соответственно установлены 1С сервер и PostgreSQL.
В последние 2 месяца происходить какая то ерунда. Когда днем пользователи работают - у них проблем как написано ниже -нет. Работают в штатном режиме.
Проблема №1. Блокирую вход в базу и регламентные задания, захожу и ставлю на перепроводку в УПП за 3 месяца. С случайное время и с разными ошибками процесс прерывается. Например, последний раз прервался сообщением от платформы "Ошибка формата потока". На другом компьютере Windows при этой процедуре вывалил окно ссылаясь на BEX имя модуля с ошибкой StackHash_0a9e и прочая систумная инфа.
В консоли "Администрирование серверов 1С" пытаясь попасть в свойства инф. базы часто выскакивает "ошибка получения параметров информационной базы: бла бла бла 10054. Удаленный хость разорвал сущ. соединение". Нажимаю кнопку "ОК"- такое же сообщение но порт (1561) меняется и потом пускает....
Такая же ерунда выскочила при архивировании базы средствами 1С в процессе написало про ошибку разрыва соединения удаленным хостом...
Хотя при штатной работе пользователя с БД жалоб не поступало.
Помогите кто чем может а то копать даже не знаю куда.
В последние 2 месяца происходить какая то ерунда. Когда днем пользователи работают - у них проблем как написано ниже -нет. Работают в штатном режиме.
Проблема №1. Блокирую вход в базу и регламентные задания, захожу и ставлю на перепроводку в УПП за 3 месяца. С случайное время и с разными ошибками процесс прерывается. Например, последний раз прервался сообщением от платформы "Ошибка формата потока". На другом компьютере Windows при этой процедуре вывалил окно ссылаясь на BEX имя модуля с ошибкой StackHash_0a9e и прочая систумная инфа.
В консоли "Администрирование серверов 1С" пытаясь попасть в свойства инф. базы часто выскакивает "ошибка получения параметров информационной базы: бла бла бла 10054. Удаленный хость разорвал сущ. соединение". Нажимаю кнопку "ОК"- такое же сообщение но порт (1561) меняется и потом пускает....
Такая же ерунда выскочила при архивировании базы средствами 1С в процессе написало про ошибку разрыва соединения удаленным хостом...
Хотя при штатной работе пользователя с БД жалоб не поступало.
Помогите кто чем может а то копать даже не знаю куда.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) woozee, у вас проблема либо с устойчивостью рабочих процессов, либо с IPv6.
Включите технологический журнал на сбор дампов. Обеспечьте разрешение имени сервера 1С, как оно указано в консоли кластера, в 127.0.0.1
Это еще не говорит об отсутствии вышеуказанных проблем: со многими сбоями система умеет бороться повтором вызова.
Включите технологический журнал на сбор дампов. Обеспечьте разрешение имени сервера 1С, как оно указано в консоли кластера, в 127.0.0.1
при штатной работе пользователя с БД жалоб не поступало
Это еще не говорит об отсутствии вышеуказанных проблем: со многими сбоями система умеет бороться повтором вызова.
(28) AlexO,
Несколько месяцев назад мы с IT-директором таращились на список из пары десятков активных пользователей, которым не плохело от перезапуска Агента сервера 1С:Предприятия. Невероятно, но факт.
Когда это 1С не падала при малейшей потере связи с сервером.
Несколько месяцев назад мы с IT-директором таращились на список из пары десятков активных пользователей, которым не плохело от перезапуска Агента сервера 1С:Предприятия. Невероятно, но факт.
(34) Естественно, что в первую очередь мы потыкали в документы одной из таких сессий, ожидая, что вот тут-то она и сдохнет. Не сдохла. Для интересу попробовал сейчас на тестовом сервере открыть журнал Планов продаж, перезапустить агент сервера и попробовать открыть один из планов. Открылся, как миленький.
(35) vasyak319,
А почему "не афишировали" такой возврат - так это ж "возврат", а у нас 1С такая вся прогрессивная из себя со своим 8.3...
Только боюсь, что возврат к таким реализациям влечет за собой и те же самые проблемы - неопределенность реального исполнения кода, неотслеживание связи с БД, некорректность данных "у пользователя" и в БД... Ну и о "теперь на клиенте ничего не исполняется!" можно забыть совсем.
P.S. собственно, я это ожидал - 1С по кругу ходит уже 25 лет. Более подробно - в Уж не могу удержаться от ссылки, много тем появилось одновременно об одном и том же ))
Планов продаж, перезапустить агент сервера и попробовать открыть один из планов. Открылся, как миленький.
Значит, на одном из релизов "тихой сапой" произошел переход к давно забытому "старому" - размазыванию данных клиента-сервера между "клиентом" и "сервером", как это было в 8.1. Абсолютно тот же анамнез, тютелька-в-тютельку.
А почему "не афишировали" такой возврат - так это ж "возврат", а у нас 1С такая вся прогрессивная из себя со своим 8.3...
Только боюсь, что возврат к таким реализациям влечет за собой и те же самые проблемы - неопределенность реального исполнения кода, неотслеживание связи с БД, некорректность данных "у пользователя" и в БД... Ну и о "теперь на клиенте ничего не исполняется!" можно забыть совсем.
P.S. собственно, я это ожидал - 1С по кругу ходит уже 25 лет. Более подробно - в Уж не могу удержаться от ссылки, много тем появилось одновременно об одном и том же ))
(33) vasyak319, у меня в тестовой сети с клиентами на Linux уж года два (с самого релиза 8.3) как такая ситуация наблюдается, я думал что так и было задумано в 8.3 =)
Как минимум последний год, аналогичным образом себя ведёт боевая 8.2, из общего с тестовой 8.3 только то, что в обеих сетках серверы на линуксах.
Как минимум последний год, аналогичным образом себя ведёт боевая 8.2, из общего с тестовой 8.3 только то, что в обеих сетках серверы на линуксах.
(38) У меня 8.2.19.83. Этому релизу как раз чуть больше года.
Из других новостей - "Предупреждение" в процедуре ОбработкаПроведения вполне себе живёт на клиент-серверной базе. Обнаружил случайно, когда запустил на ночь перепроведение, а утром увидел, что оно стоит и ждёт, когда я "ОК" нажму. Причём этому приколу заведомо больше полутора лет (тот чувак, который работал тут до меня, ТАКОГО напейсать не мог, а он устроился сюда осенью 2013). Месяц идиотской (Вопрос: "В огороде бузина!", Ответ: "Так в Киеве же дядька") переписки с хотлайном ситуацию не прояснил.
В общем, захотелось перейти на богомерзкие УФ хотя бы для того, чтобы не было ощущения, что тебя водят за нос.
Из других новостей - "Предупреждение" в процедуре ОбработкаПроведения вполне себе живёт на клиент-серверной базе. Обнаружил случайно, когда запустил на ночь перепроведение, а утром увидел, что оно стоит и ждёт, когда я "ОК" нажму. Причём этому приколу заведомо больше полутора лет (тот чувак, который работал тут до меня, ТАКОГО напейсать не мог, а он устроился сюда осенью 2013). Месяц идиотской (Вопрос: "В огороде бузина!", Ответ: "Так в Киеве же дядька") переписки с хотлайном ситуацию не прояснил.
В общем, захотелось перейти на богомерзкие УФ хотя бы для того, чтобы не было ощущения, что тебя водят за нос.
(1) Наступал на эту граблю - при длительных обработках с декабря один из рпхостов выжирает оперативки сверх всех разумных пределов (от 3 до 6 гиг); пока стояло ограничение на 2 гиг/процесс, случались точь в точь такие же вылеты на перепроведении или обновлении КЛАДРа. Если побить процедуры более мелкими транзакциями, проблема уходит (но надо править конфигурацию - у нас это не настраивается) - гонял на тестовой базе. На боевой решили конфу не менять, а увеличить лимит по памяти до 5 гиг/процесс и таймаут вышибания до 3600 - с января ни одного вылета.
А вообще, была бы очень информативна в Вашем вопросе строчка типа "1С:Предприятие 8.2 (8.2.19.121)" и "Управление производственным предприятием, редакция 1.3 (1.3.61.2)" ;-)
А вообще, была бы очень информативна в Вашем вопросе строчка типа "1С:Предприятие 8.2 (8.2.19.121)" и "Управление производственным предприятием, редакция 1.3 (1.3.61.2)" ;-)
(1) woozee, Была аналогичная проблема. При попытке выгрузки базы или Тестировании и исправлении, аналогичное падение (хост разорвал...). Решение: включили логирование , выяснили на чтении какой таблицы происходит падение (в нашем случае был регистр накопления, поле ресурса некорректной размерности ), не хитрым перебором определили период записей (при попытки чтения поврежденных записей сразу падение), удалили записи запросом в PgAdmin. Если интересно распишу подробнее.
(1) woozee,
1 Делом, проверить железо, в том числе ОЗУ,Свичи,Сетевуху
2 Фаервол
3 Процессы запущенные в момент обрыва связи.
т.е. данные ошибки возникают при обрыве сети(или не лепая нагрузка на сеть). Другого ничего нет.
чаще пингуйте и уведите где и откуда ноги растут.
1 Делом, проверить железо, в том числе ОЗУ,Свичи,Сетевуху
2 Фаервол
3 Процессы запущенные в момент обрыва связи.
т.е. данные ошибки возникают при обрыве сети(или не лепая нагрузка на сеть). Другого ничего нет.
чаще пингуйте и уведите где и откуда ноги растут.
(1) woozee,
Прогоняйте chnkdbfl, ТИИ, внутренние постгресовские проверки. Загрузка-выгрузка базы, смотрите, какие ошибки.
Postgres вообще система ненадежная для 1С, там легко могут теряться/биться различные одноэсовые системные таблицы (ref-таблицы и т.д.). Перейдите на MS SQL, тем более, у вас весьма тяжелая и нагруженная конфа.
Также вполне возможно, что из-за битой структуры базы происходит зацикливание и утечка памяти, отсюда - отвал процесса.
И да, виртуальным серверам под УПП надо много быстрых ресурсов. Перейдите на физический сервер, по-крайней мере, 1Совый на него поставьте.
прервался сообщением от платформы "Ошибка формата потока".
... окно ссылаясь на BEX имя модуля с ошибкой StackHash_0a9e и прочая систумная инфа.
..часто выскакивает "ошибка получения параметров информационной базы: бла бла бла 10054.
Это проблема с битой базой.
... окно ссылаясь на BEX имя модуля с ошибкой StackHash_0a9e и прочая систумная инфа.
..часто выскакивает "ошибка получения параметров информационной базы: бла бла бла 10054.
Прогоняйте chnkdbfl, ТИИ, внутренние постгресовские проверки. Загрузка-выгрузка базы, смотрите, какие ошибки.
Postgres вообще система ненадежная для 1С, там легко могут теряться/биться различные одноэсовые системные таблицы (ref-таблицы и т.д.). Перейдите на MS SQL, тем более, у вас весьма тяжелая и нагруженная конфа.
Удаленный хость разорвал сущ. соединение".
...Такая же ерунда выскочила при архивировании базы средствами 1С в процессе написало про ошибку разрыва соединения удаленным хостом...
Это уже не база, это другая проблема - с ненадежной работой сервера 1С. Тут тоже бубен и плясать с процессами-сетью.
...Такая же ерунда выскочила при архивировании базы средствами 1С в процессе написало про ошибку разрыва соединения удаленным хостом...
Также вполне возможно, что из-за битой структуры базы происходит зацикливание и утечка памяти, отсюда - отвал процесса.
И да, виртуальным серверам под УПП надо много быстрых ресурсов. Перейдите на физический сервер, по-крайней мере, 1Совый на него поставьте.
(47) alex_sh2008, Я же писал что выставлено было памяти для линукса в /etc/sysctl.conf kernel.shmmax=8гб (8000*1024*1024) - половина памяти общей
и для postreSQL в postgresql.conf shared_buffers = 7,9 Гб (если ровное как у shmmax поставить - не запускается сервис).
Больше ничего не менял в этом файлике...
и для postreSQL в postgresql.conf shared_buffers = 7,9 Гб (если ровное как у shmmax поставить - не запускается сервис).
Больше ничего не менял в этом файлике...
(48) woozee, если у вас на linux стоит только Postgree зачем вы выделяете только половину памяти от общего объема, самой linux достаточно 2гб для работы, и проверьте с каким интервалом времени sql скидывает транзакции(данные) из памяти на диск, параметры не помню, давно это было когда с Postgree работал, когда sql часто и малыми порциям скидывает данные на диск это приводит к тормозам дисковой системы и особенно на виртуалках, при работе пользователей это не так заметно, но стоит начать обрабатывать большие объемы данных, такие как обновление 1С, архивация, то уже начинаются проблемы.
(45) alex_sh2008, PostgreSQL не читает данные напрямую с диска и не пишет их сразу на диск. Данные загружаются в общий буфер сервера, находящийся в разделяемой памяти, серверные процессы читают и пишут блоки в этом буфере, а затем уже изменения сбрасываются на диск.Если объём буфера недостаточен для хранения часто используемых рабочих данных, то они будут постоянно писаться и читаться из кэша ОС или с диска, что крайне отрицательно скажется на производительности.
В то же время не следует устанавливать это значение слишком большим: это НЕ вся память, которая нужна для работы PostgreSQL, это только размер разделяемой между процессами PostgreSQL памяти, которая нужна для выполнения активных операций. Она должна занимать меньшую часть оперативной памяти вашего компьютера, так как PostgreSQL полагается на то, что операционная система кэширует файлы, и не старается дублировать эту работу. Кроме того, чем больше памяти будет отдано под буфер, тем меньше останется операционной системе и другим приложениям, что может привести к своппингу.
В то же время не следует устанавливать это значение слишком большим: это НЕ вся память, которая нужна для работы PostgreSQL, это только размер разделяемой между процессами PostgreSQL памяти, которая нужна для выполнения активных операций. Она должна занимать меньшую часть оперативной памяти вашего компьютера, так как PostgreSQL полагается на то, что операционная система кэширует файлы, и не старается дублировать эту работу. Кроме того, чем больше памяти будет отдано под буфер, тем меньше останется операционной системе и другим приложениям, что может привести к своппингу.
(1) woozee,
Win 7 не серверная, виртуальная машина - "Windows Virtual PC" 1С версий 8.3.4 и 8.3.5 (обе различных релизов) и PostgreSQL время от времени на старте (!) выдаёт такую-же ошибку ("Ошибка формата потока").
При работе иногда выдаёт разрыв хоста.
При длительных процедурах на сервере (не важно - запущенных как фоновые задания или как задачи, выполнение которых ожидается клиентом) проблем не замечено.
При работе не в VM никаких проблем не замечено.
Напрашивается вывод: сервер 1С с PostgreSQL на виртуальных машинах "чудят".
Win 7 не серверная, виртуальная машина - "Windows Virtual PC" 1С версий 8.3.4 и 8.3.5 (обе различных релизов) и PostgreSQL время от времени на старте (!) выдаёт такую-же ошибку ("Ошибка формата потока").
При работе иногда выдаёт разрыв хоста.
При длительных процедурах на сервере (не важно - запущенных как фоновые задания или как задачи, выполнение которых ожидается клиентом) проблем не замечено.
При работе не в VM никаких проблем не замечено.
Напрашивается вывод: сервер 1С с PostgreSQL на виртуальных машинах "чудят".
ну если дашь листинг настроек постгреса то можно попробовать посмотреть, скорее всего сервер БД чудит, у меня такая же ерунда была когда этеровскую сборку ставил, попробуй из исходников собрать постгрес и все патчи накатить руками, и желательно логи постгреса выложи. Еще покажи что в pg_hba.conf лежит.
Всем спасибо за ответы и предложения. К сожалению в последние 2 месяца что только с сервером не делалось, по этому любая из предложенных вариантов может помочь.
(5) planar74, да, платформа обновлялась и 2 месяца назад и пару недель назад. Последний раз для проверки "а вдруг проблема уйдет". Я так понимаю, под чисткой кэша подразумевается удаление данных в ....\Work8\reg_1544 ?
(4) asved.ru, пока первое подозрение ложится именно на работу процессов. Настроено сейчас: Интервал перезапуска 1 час. Допустимый объем памяти 800мб, интервал превышения допустимого объема памяти - 90 секунд. Выключенные процессы останавливать через 30 секунд, уровень отказоустойчивости 0, Приоритет по производительности. У нас около 50 пользователей работающих одновременно до 3 баз, соотвественно сеансов свыше сотни. До этого стаяла настройка по умолчанию до момента "зависания" программ от того что закончилась свободная оперативная память. У нас для сервера 8Гб только (рассматривается вопрос об увеличении). И соотвественно пока сервер не зависает менять параметры для увеличения "срока службы сервиса" не имеет смысла. Но то что они перезапускаются каждый час- возможно мы попадаем в этот момент и сервер плохо отрабатывает "перекидывания" соединения на другой процесс. И пока это главная зацепка...(8) ZOMI, да, rphost, ragent и rmngr запущен от пользователь "система"
По поводу ТЖ - в скором времени я подключу его, там погляжу (сейчас проблема с свободным местом на HDD)
(5) planar74, да, платформа обновлялась и 2 месяца назад и пару недель назад. Последний раз для проверки "а вдруг проблема уйдет". Я так понимаю, под чисткой кэша подразумевается удаление данных в ....\Work8\reg_1544 ?
(4) asved.ru, пока первое подозрение ложится именно на работу процессов. Настроено сейчас: Интервал перезапуска 1 час. Допустимый объем памяти 800мб, интервал превышения допустимого объема памяти - 90 секунд. Выключенные процессы останавливать через 30 секунд, уровень отказоустойчивости 0, Приоритет по производительности. У нас около 50 пользователей работающих одновременно до 3 баз, соотвественно сеансов свыше сотни. До этого стаяла настройка по умолчанию до момента "зависания" программ от того что закончилась свободная оперативная память. У нас для сервера 8Гб только (рассматривается вопрос об увеличении). И соотвественно пока сервер не зависает менять параметры для увеличения "срока службы сервиса" не имеет смысла. Но то что они перезапускаются каждый час- возможно мы попадаем в этот момент и сервер плохо отрабатывает "перекидывания" соединения на другой процесс. И пока это главная зацепка...(8) ZOMI, да, rphost, ragent и rmngr запущен от пользователь "система"
По поводу ТЖ - в скором времени я подключу его, там погляжу (сейчас проблема с свободным местом на HDD)
(9) woozee, кластер вообще не может перекинуть на другой процесс активный серверный вызов. Это невозможно технически.
Интервал перезапуска и прочие ограничения у вас чрезмерны. Установите настройки перезапуска по умолчанию, параметры числа соединений на РП и числа ИБ на РП в 0, приведите кластер к одному рабочему процессу и посмотрите за его потреблением памяти.
Журналы регистрации переведите в новый формат, они очень здорово кушают память.
Интервал перезапуска и прочие ограничения у вас чрезмерны. Установите настройки перезапуска по умолчанию, параметры числа соединений на РП и числа ИБ на РП в 0, приведите кластер к одному рабочему процессу и посмотрите за его потреблением памяти.
Журналы регистрации переведите в новый формат, они очень здорово кушают память.
(9) woozee, достаточно будет dump create = "true" type = "0", места оно практически не займет, но о фактах падения РП вы знать будете.
каков размер кэша данных сеансов на вечер после утреннего перезапуска сервера с очисткой этого кэша? (папки snccntxXXX... в srvinfo)
ЗЫ сервер, надеюсь, х64?
каков размер кэша данных сеансов на вечер после утреннего перезапуска сервера с очисткой этого кэша? (папки snccntxXXX... в srvinfo)
ЗЫ сервер, надеюсь, х64?
(14) asved.ru, папка 196,609кб весит . Сутра перезагрузка сервера, очистка папки, после работы посмотрел размер. Сервер 64.
(19) bubnov-pi, 1С:Предприятие 8.3 (8.3.5.1383) , Управление производственным предприятием, редакция 1.3 (1.3.60.3)
После увеличении оперативы на сервере буду менять параметры процессов)
(19) bubnov-pi, 1С:Предприятие 8.3 (8.3.5.1383) , Управление производственным предприятием, редакция 1.3 (1.3.60.3)
После увеличении оперативы на сервере буду менять параметры процессов)
PostgreSQL не обновляли? Я так понимаю что она патченый (тот самый который с its)?
Если проблема появилась не сразу, а через какое-то время нормальной работы, то я бы рекомендовал проверить винт, вначале. Хотя бы просто выгрузка-загрузка базы средствами 1С и Постгреса. Далее выгрузить базу на локальную машину и попробовать погонять на ней. Вполне вероятно, что при разрастании базы и по стечении множества обстоятельств создалась кривая таблица и при взаимодействии с ней вылазиют блокировки. Реиндекс и прочий постгресовский функционал пробовали?
Если проблема появилась не сразу, а через какое-то время нормальной работы, то я бы рекомендовал проверить винт, вначале. Хотя бы просто выгрузка-загрузка базы средствами 1С и Постгреса. Далее выгрузить базу на локальную машину и попробовать погонять на ней. Вполне вероятно, что при разрастании базы и по стечении множества обстоятельств создалась кривая таблица и при взаимодействии с ней вылазиют блокировки. Реиндекс и прочий постгресовский функционал пробовали?
Какая версия платформы? в начале декабря была выпущена версия с , возможно память заканчивалась в момент ошибки. Это можно ещё отселить через PerfMon из командной строки, включить замер и посмотреть память в момент вылета 1С.
А меня вот это смущает:
Была аналогичная проблема с УПП. Решилось тем, что сервер 1С просто поставили на физический сервер. Попробуйте, вдруг поможет.
На компьютере (серверное железо) установлена виртуализация VMWare разделена на 2 системы
Была аналогичная проблема с УПП. Решилось тем, что сервер 1С просто поставили на физический сервер. Попробуйте, вдруг поможет.
В консоли "Администрирование серверов 1С" пытаясь попасть в свойства инф. базы часто выскакивает "ошибка получения параметров информационной базы: бла бла бла 10054. Удаленный хость разорвал сущ. соединение".
- у тоже меня такое было после перехода на 8.3.5. Вылечил полным сносом IPv6. ТАм недостаточно только галку снять, нужно еще и в реестре править. У Гилева на сайте хорошо описано:
На компьютере (серверное железо) установлена виртуализация VMWare разделена на 2 системы. Windows и Linux на которых соответственно установлены 1С сервер и PostgreSQL.
В последние 2 месяца происходить какая то ерунда. Когда днем пользователи работают - у них проблем как написано ниже -нет. Работают в штатном режиме.
Проблема №1. Блокирую вход в базу и регламентные задания, захожу и ставлю на перепроводку в УПП за 3 месяца. С случайное время и с разными ошибками процесс прерывается. Например, последний раз прервался сообщением от платформы "Ошибка формата потока". На другом компьютере Windows при этой процедуре вывалил окно ссылаясь на BEX имя модуля с ошибкой StackHash_0a9e и прочая систумная инфа.
В консоли "Администрирование серверов 1С" пытаясь попасть в свойства инф. базы часто выскакивает "ошибка получения параметров информационной базы: бла бла бла 10054. Удаленный хость разорвал сущ. соединение". Нажимаю кнопку "ОК"- такое же сообщение но порт (1561) меняется и потом пускает....
Такая же ерунда выскочила при архивировании базы средствами 1С в процессе написало про ошибку разрыва соединения удаленным хостом...
Хотя при штатной работе пользователя с БД жалоб не поступало.
Помогите кто чем может а то копать даже не знаю куда.
В последние 2 месяца происходить какая то ерунда. Когда днем пользователи работают - у них проблем как написано ниже -нет. Работают в штатном режиме.
Проблема №1. Блокирую вход в базу и регламентные задания, захожу и ставлю на перепроводку в УПП за 3 месяца. С случайное время и с разными ошибками процесс прерывается. Например, последний раз прервался сообщением от платформы "Ошибка формата потока". На другом компьютере Windows при этой процедуре вывалил окно ссылаясь на BEX имя модуля с ошибкой StackHash_0a9e и прочая систумная инфа.
В консоли "Администрирование серверов 1С" пытаясь попасть в свойства инф. базы часто выскакивает "ошибка получения параметров информационной базы: бла бла бла 10054. Удаленный хость разорвал сущ. соединение". Нажимаю кнопку "ОК"- такое же сообщение но порт (1561) меняется и потом пускает....
Такая же ерунда выскочила при архивировании базы средствами 1С в процессе написало про ошибку разрыва соединения удаленным хостом...
Хотя при штатной работе пользователя с БД жалоб не поступало.
Помогите кто чем может а то копать даже не знаю куда.
Переустановите платформу, вернее снесите ее и поставьте заново. У меня похожая проблема решилась таким образом ...
посмотри у Гилёва.... я 2 года назад с ошибкой "Ошибка формата потока" (там же самый "легкий" способ - удалить базу из списка баз и заново добавить... почистить temp и кэш 1С....
2) иногда лечится "просто" выгрузкой в копию и загрузкой заново... если dt не делается.... сделай back-up SQL и загрузи в новую базу...
3) возможно повреждение базы или "битые" ссылки.... пустые значения обязательных полей или ссылки на объект есть, а самого объекта нет (если удаляли неправильно) - тестирование исправление средствами 1С...
запусти в Конфигураторе - Администрирование - Тестирование и исправление (ТОЛЬКО не всё сразу! а последовательно - сначала Реиндексация, выполнить, потом только проверка логич. и ссылочной целостности (без исправлений! просто отчет!!! а только потом исправление запускай)
тоже самое (но быстрее) можно сделать средствами SQL... но сами же 1С не рекомендуют это делать
4) возможно обновляли динамически... или неправильно (исли конфа не типовая, а с изменениями) - возможно ошибки в конфигурации, но это сложно отследить - надо включать "технологический журнал" и смотреть по событиям... excp например...
5) возможны ошибки сервера 1С и/или платформы... закачай по возможности самые последные версии... и всем обнови 1С
2) иногда лечится "просто" выгрузкой в копию и загрузкой заново... если dt не делается.... сделай back-up SQL и загрузи в новую базу...
3) возможно повреждение базы или "битые" ссылки.... пустые значения обязательных полей или ссылки на объект есть, а самого объекта нет (если удаляли неправильно) - тестирование исправление средствами 1С...
запусти в Конфигураторе - Администрирование - Тестирование и исправление (ТОЛЬКО не всё сразу! а последовательно - сначала Реиндексация, выполнить, потом только проверка логич. и ссылочной целостности (без исправлений! просто отчет!!! а только потом исправление запускай)
тоже самое (но быстрее) можно сделать средствами SQL... но сами же 1С не рекомендуют это делать
4) возможно обновляли динамически... или неправильно (исли конфа не типовая, а с изменениями) - возможно ошибки в конфигурации, но это сложно отследить - надо включать "технологический журнал" и смотреть по событиям... excp например...
5) возможны ошибки сервера 1С и/или платформы... закачай по возможности самые последные версии... и всем обнови 1С
я бы начал с физического состояния сервера:
1) сделал тест оперативки
2) тест жестких на беды
потом необходимо проверить параметры ОС и хостовой и виртуальных
3) проверил сколько осталось места на жеских ( если включено ли квотирование - проверить состояние квот)
4) проверить количество снапшотов виртуальных машин - если больше 10 - то файловые операции будут значительно замедленны и 1С может виснуть
5) как чувствует себя Винда - сколько свободной памяти, есть ли "ошибки отсутствия страниц в памяти"?
1) сделал тест оперативки
2) тест жестких на беды
потом необходимо проверить параметры ОС и хостовой и виртуальных
3) проверил сколько осталось места на жеских ( если включено ли квотирование - проверить состояние квот)
4) проверить количество снапшотов виртуальных машин - если больше 10 - то файловые операции будут значительно замедленны и 1С может виснуть
5) как чувствует себя Винда - сколько свободной памяти, есть ли "ошибки отсутствия страниц в памяти"?
По поводу утечки и прочей подобной нечисти - Установил сервер на локальный компьютер версии 8.3.5.1383. Этот засранец сожрал всю мою оперативную память (16гб), при чем в консоли на процессе (настройки по умолчанию, 1 процесс анлим) нет ни фонового задания, ни подключения ни сеанса. Тупо rphost собрал в себя всё и сидит довольный. При чем делает он это за пару часов (может 3).
Сегодня утром поставил 8_3_5_1460 начитавшись про утечки памяти и т.д. - слежу за поведением сервера- prhost мечется от 146мб до 176мб, выше не лезет... На подходе оператива, по ходу с установкой оперативы в сервер и перераспределение настроек кластера еще и платформу обновлю...
Сегодня утром поставил 8_3_5_1460 начитавшись про утечки памяти и т.д. - слежу за поведением сервера- prhost мечется от 146мб до 176мб, выше не лезет... На подходе оператива, по ходу с установкой оперативы в сервер и перераспределение настроек кластера еще и платформу обновлю...
(31) woozee,
Установил сервер на локальный компьютер версии 8.3.5.1383. Этот засранец сожрал всю мою оперативную память
- правильно, есть такая зарегистрированная проблема
В кластере зарегистрированы рабочие процессы, которые являются включенными, но неактивными; агент кластера использует до 100 процентов процессорного времени.
, исправленная в 8.3.5.1443
Память увеличили на 1С сервере, убрали лимиты времени перезапуска процессов и прочую хрень. Проблема за 3 дня не всплыла.
Вывод: из за багнутой платформы и утечки этой памяти у нас "Зависал" 1С Сервер (комп) из за того что память заканчивалась. На что было сделано временное решение ограничить используемую память с прочими сопутствующими настройками. Проблема с утечкой решилась, но недочеты фирмы 1С с переброской сеансов с процесса на процесс дали о себе знать. Но поскольку на работу пользователей данные недочеты не сказывались - менять параметры перестали до закупки памяти. Поставили 24Гб, обновили платформу до 5.1460 и сбросили настройки памяти кластера - проблема решилась (пока что)... Даже (!) архивирование УПП сократилось с 30 минут до 5 минут средствами 1С!!.
Пока остается другой вопрос о падении производительности (критическое) при увеличении одновременно работающих пользователей... Но возможно это уже проблема в настройках Fedora-postgreSQL8. Там у нас запланировано обновление на Ubuntu-postgreSQL9, там видно будет...
Вывод: из за багнутой платформы и утечки этой памяти у нас "Зависал" 1С Сервер (комп) из за того что память заканчивалась. На что было сделано временное решение ограничить используемую память с прочими сопутствующими настройками. Проблема с утечкой решилась, но недочеты фирмы 1С с переброской сеансов с процесса на процесс дали о себе знать. Но поскольку на работу пользователей данные недочеты не сказывались - менять параметры перестали до закупки памяти. Поставили 24Гб, обновили платформу до 5.1460 и сбросили настройки памяти кластера - проблема решилась (пока что)... Даже (!) архивирование УПП сократилось с 30 минут до 5 минут средствами 1С!!.
Пока остается другой вопрос о падении производительности (критическое) при увеличении одновременно работающих пользователей... Но возможно это уже проблема в настройках Fedora-postgreSQL8. Там у нас запланировано обновление на Ubuntu-postgreSQL9, там видно будет...
(42) woozee, Если дополнительно не настраивались параметры использования памяти сервером SQL, хотя бы по рекомендациям с сайта поддержки 1С, то производительность будет падать катастрофически - по умолчанию postgres использует что-то около гигабайта оперативки, что для базы данных в десятки гигабайт кастратофически мало.
(43) bubnov-pi, дело в том что когда мы начинаем менять параметры postrgeSQL он зависает через некоторое время. Даже если взять последний пример - на сервере оперативки 16 гб. Выставляю shmmax 8Гб, в postrgesconf sharedbuffers ставлю чуть меньше 8гб. Больше ничего не меняю - через некоторое время (час-два) линукс виснет.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот