1с ошибка субд lost synchronization with server
Хотите использовать в продуктиве PostgreSQL в связке с 1С? Мы проведем
Вас по пути настройки базы с нуля и до "террабайта".
Добрый день.
Подскажите будет ли повтор мероприятия в ближайшем будущем или возможность посмотреть запись позже?
К сожалению, нет возможности участвовать в вебинаре из-за командировки.
(89) GROOVY,
Можете что-нибудь прокомментировать насчет оплаты платных вебинаров. Я думал что если у меня на ИС есть рубли (не старт мани, а именно рубли), то я смогу ими оплатить какие-либо покупки на данном сайте (в т.ч. участи в вебинаре)
Но как я понимаю на данный момент такой возможности нет.
В чем сложность такой реализации и планируется ли когда нибудь такое сделать ?
(96) headMade, скоро такая возможность появится.
В чем сложность, сказать не могу, не я этим занимаюсь.
Очень интересует запись. Не понимаю сложностей с ее получением. Запись с экрана видеотрансляции еще никто не отменял. В наше время любой пользователь может записать видеопоток со своего экрана. Но это геморой, надо ее запускать, следить за качеством звука, вырезать перерывы, оно нам надо!? Зачем тогда нам доставлять такие неудобства? Тем более что запись вебинара всегда предоставляется сервисом на котором проводится этот вебинар. Хватит уже приседать и боятся. В наш век ценность информации не в самой информации, а в ее актуальности и доступности. Так что можно проводить вебинар и выкладывать ее в полный доступ. Через год ценность ее сильно уменьшится. И вот тогда выпустите новый вебинар и снова денег поднимите. Люди за вебинар платят за то что бы на нем задать вам свои вопросы и получить на них ответы первыми.
(91) stneon, Во-первых Вы нарушаете авторское право делая запись с экрана. Модераторы Вас забанят.
Во-вторых: у нас 11 медиапотоков при трансляции, их надо все синхронизировать, обработать, убрать моменты, которые никому не нужны. Брендировать. Переключение трансляции ведущего, скринкастинг, презентация.
Вам кажется - это просто, одной кнопкой? Нет, это все производится вручную.
А политику распространения материалов определяет автор. И если он решил, что распространятся все это он будет на платной основе, то так тому и быть.
(92) Делая запись с экрана я ничего не нарушаю. Я на своем компьютере имею полное право делать все что я хочу. Далее контент оплачен и был мною получен на мой же компьютер и точка. Как записать изображение с экрана это уже техническое дело.
Так что не говорите мне как организовать вебинар и всю эту муть с потоками тоже не вешайте мне на уши. Если у вас все так грустно с технической стороны, то могу помочь либо советом, либо делом.
Все работало стабильно почти 2 года, пока не обновил конфу на релиз 1.1.107.4 .
Заметил, что перестали восстанавливаться архивы созданные с помощью pg_dump.
Начал разбираться и выяснил, что pg_dump в процессе архивации выдает ошибки :
Переносил базу на другие сервера , менял версии Postgres (9.6 и 10.5), менял платформу (8.3.9.2309 и 8.3.10.2772) - результат тот же, pg_dump не может нормально создать архив.
При постановке конфы обратно на поддержку архивация начинает работать нормально.
Как можно решить проблему?
(0)[Как можно решить проблему?]
invalid memory alloc request size 1174829507
видимо копать нужно от сюда
Проводил эксперимент:
1. Выгружаю конфу поставщика в cf.
2. Из цф создаю чистую базу.
3. Запускаю pg_dump - архивация проходит нормально.
4. В этой же конфе включаю возможность изменения.
5. Запускаю pg_dump - архивация проходит НЕ нормально.
(7) Был у меня клиент пару лет назад. Жаловался на похожие траблы. Поскольку ему нужно было хоть какое-то решение, то ему пришлось делать все такие штуки непосредственно в линуксе - под виндой уже не работало.
Именно с конфигой на КА 1.1 .
Если кто имеет возможность провести эксперимент (6), попробуйте и напишите о результате. На все про все нужно 15 минут на нормальном компе.
Я пробовал на WinServer 2008 R2 и Win7 .
(2) Вроде как у Postgres лимиты не маленькие :
Максимальный размер таблицы - 32 TB
(0)
Покажи скрипт, как бэкап делается.
[проблемы с архивацией]
не путаешь понятия дампа и архива? Проблемы именно с архивацией?
"C:\Program Files\PostgresPro 1C\9.4\bin\pg_dump" -U postgres -F c -Z9 -c -f C:\arc\arc_pg\ara_backup.backup bs
ren C:\arc\arc_pg\ara_backup.backup bs_%f_name%.*
(15) Снятие с поддержки любой другой конфигурации также приводит к такой ошибке? Или только КА указанной версии?
(18) немного не так - если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть.
з.ы. Трабл именно при снятии с "замка" и при сохранении поддержки
(18) Именно в версиях КА 1.1.107.3 и 1.1.107.4.
В КА 1.1.106 проблемы еще нет.
Попробовал уже с типовыми демоконфами КА - все так же.
Т.е проблема не в моей базе , а в конфигурации конкретной версии.
(19) Я понимаю. У нас бухгалтерия и зарплата в таком режиме поддержки уже много лет, ничего подобного никогда не возникало. Правда, и сервер приложений и СУБД на Linux(тоже много лет).
(19) [если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть]
А что за ограничение в этом случае срабатывает?
(25) твой же пост:
-*-
Вроде как у Postgres лимиты не маленькие :
(31) я бы чисто ради интереса грохнул что-нибудь из конфы, чтоб привести размер cf к 0.99Гб, и проверить еще раз бэкап. (что там есть такого, макеты с двоичными данными, какие-нибудь)
(32) да я ж и предлагаю - снять с поддержки полностью и размер в два раза упадет и проблема должна уйти, если это в ней причина.
Но это ни одного там в ней изменения нет, когда вкл изм и накидать туда макетов огромных, то будет больше, конечно.
з.ы. Все-таки я думаю, что в КА 1.1 там не прямая зависимость с размером, а с самим наличием "второй копии" конфигурации, которая конфликтует с "первой" при запихивании ее в БЛОБ платформой - просто глючит в данном случае при попытке архивации баз, а так оно и в других событиях глючит тоже. При накатывании обновлений из Поддержка-Обновить конфигурацию, например.
(40) [ просто глючит в данном случае при попытке архивации баз]
+100500
проблема Postgres, с MS SQL её нет
(40) Такая же проблема должна быть и под линуксом. Ведь лимит на размер поля у Postgres одинаковый для обоих версий.
таблицы "config invalid memory alloc request size 1174829507
можно и дальше позаниматься флюдом, но тема закрыта
т.е. дело однозначно в размере cf
BLOB побился явно. Перезагрузить конфу прямой загрузкой.
(47) попробовать можно, но в тех вариантах не помогало, на которые я ссылался, что ошибки с КА 1.1 возникали в серверном режиме.
я сегодня проверю вариант с большой конфигой по размеру (ка_2.4) на субд постгри и сервером на винде - сглючит или нет - проверю. Не знаю только получится ли протестить, если сервер для субд будет линуксовый. долго такое городить и профита не будет чисто поэкспериментировать и прокачать экспу разве что :-)
"C:\Program Files\PostgreSQL\10.3-2.1C\bin\pg_dump.exe" --host localhost --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --section pre-data --section data --section post-data --encoding UTF8 --verbose --file "D:\1cBackupNew\BUH_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup" "BUH"
Вырезал из конфигурации несколько макетов ненужных драйверов.
cf сократил до 0,98 Гб. Но проблема с архивацией осталась.
(64) гугл упорно говорит, что таблица битая. Я бы уменьшил ее еще, но значительно - до 500мб, например, и еще раз пг_дамп. Это подтвердит битая или нет
можно предположить, что источником ошибки и вовсе окажется некий конкретный объект метаданных, только сколько раз надо провернуть все-все-все манипуляции, чтоб найти такой объект. Причем, сбоить этот объект начинает в процессе клонирования конфиги поставщика в подкопию основной ЦФ-конфиги
(66) Похоже ты прав.
Развернул демоконфу КА2, включил возможность изменения - в результате cf размером 1,2 Гб.
Архивация проходит без проблем.
Такая же проблема. dt делается. в копию серверную(Postgres pro 9.6) не грузится, ругается на память, а в файловую загрузился. Пытаюсь определить проблемный объект в метаданных. Попутно попробую в mssql 2008 загрузить dt.
(75) А я бы просто оставил базу с полностью снятой с поддержки, а обновления заготавливал по мере необходимости из файлового режима. Какая разница, если развернута тестовая копия и завершить процедуру обновления все равно нужно только на тестовой, а затем уже из тестовой забирать CF и обновлять продакшн базу сравнением/объединением.
(76) как сейчас решение да, но причина явно не устранена. попробую 107.5 накатить на файле и перенести на серверную.
В MsSQL действительно все загружается без ошибок. Проблема на стороне Postgres, попробую покопать настройки. Ни у кого нет опыта тонкой настройки? Не хочется верить, что Postgres настолько не продуман.
(78) никто и не заставляет. Только две конфиги КА 1.1 и УПП 1.3 - с остальными проблем нет. с КА 2.4 тоже проблем нет.
(79) этому косяку уже много лет.
Раньше была проблема на 32-ух битных версиях PostgreSQL, не хватало им памяти для больших конфигураций. Приходилось снимать с поддержки конфу, чтобы работать. С появлением 64-битной проблема ушла.
И вот опять что-то похожее.
Насколько я разобрался 1С пихает файл конфигурации в поле. Поле имеет ограничение 1 Гб. Размер конфы закрытой для ред. и снятой с поддержки не превышает 1 Гб, а частично дописанная превышает. 1С рекомендует (прочитал на форуме SQL) снимать с поддержки полностью или использовать pg_basebackup. Снял на тестовой с поддержки - дамп отработал без ошибок.
(87) Просто рекомендация 1С не совсем честная. Если снять конфу КА 1.1 с поддержки или УПП 1.3 с поддержки, то проблема действительно пропадает. Однако, есть другие конфы, с которыми этой проблемы в принципе нет - см (74),
а так же и другие.
(89) и решения от 1с скорее всего не дождемся. Работу с данными в этом случае организует кластер серверов 1с? имею в виду структуру таблиц.
(87)В тему: те же проблемы с УПП 1.3.112.4 на pg 9.6:
-при архивировании средствами pg - описанная выше ошибка
При анализе выяснилось, что ошибка возникает с таблицей config (конфигурация БД), при обработке определенной строки таблицы, подробности ниже.
1. Просмотрел таблицу config, поля: filename (строка), creation (датавремя), modified(датавремя), attributes(целое), datasize(целое), binarydata(bytea).
2. Строк 34017.
3. Сумма размера бинарных полей примерно 98% размера файла .cf (остальное занимают оставшиеся поля), т.е. в binarydata хранится конфигурация.
4. Проверил: для любой строки размер binarydata не более 100МБ. Кроме одной, там размер binarydata 555МБ. И именно в этой строке возникает ошибка. Выяснил, что в данной строке, в одном поле хранится конфигурация поставщика.
5. Поэтому при снятии с поддержки или запрете изменений (замок) ошибка исчезает, т.к. при этом удаляется строка по п.4.
Суммируя вышеизложенное: максимальный размер данных, внесенных в ОДНО поле - 0,55ГБ (см. п.4.), что не дотягивает до озвученного лимита объема данных в ОДНОМ поле 1ГБ.
Вывод: либо лимит объема ОДНОГО поля около 0,5ГБ, либо причина в другом.
Пробовал играть настройками конфигурации pg (размеры буферов памяти и т.п.) - ошибка не исчезла.
(92)Кстати, и обычный select средствами pg вызывает эту же ошибку, если в его результате содержится поле Binarydata с конфигурацией поставщика (555МБ) - еще одно подтверждение что ограничение 1ГБ ни при чем.
(0) ровно та же проблема у меня была с УПП в 2012 году - с той же ошибкой pg_dump грохался. Стабильность - признак мастерства, чо. Сколько лет прошло, а ничего не меняется.
(96) отписывались. Я помню об этих глюках примерно с 2011-2012 годов. Когда это поперло, то начали откладывать на ИТС полные дистрибы КА 1.1 и УПП 1.3 , т.к. реально был всплеск обращений, что не проходит процедура обновления конфиги апдейтами.
Переводим БД с postgree на MS SQL.
При попытке выгрузить БД получаю ошибку Ошибка СУБД out of memory for query result.
Кто сталкивался подскажите варианты выгрузки.
Какой объем бд, железо, версии ПО?
PS Если просите помощи, прикладывайте как можно больше информации о проблеме. А то получается почти как "Ваша программа нам неправильно считает".
Тестирование и исправление базы пробовали делать?
А платформу 1С обновить не пробовали?
У нас на одной из версий платформы 8.2 такая же ошибка была с постгри
Как правильно обновить платформу?
Установил 8.2, сервер 8.2. - прописываю путь к бд - пишет БД не найдена.
Тии попробую.
(7)комп перегрузили после установки 8.2? В 8.2 новые базы создавать получается?
(9) опять же, комп перегрузили?
(10)у него не выгружается база из конфигуратора. Как он в файловую версию выгрузит то?
(11) alexbur,
Комп перезагрузил, новые бд создаются а эту не видит зараза.
Может у кого есть conf файл норм настроенный - поделитесь. все таки мне кажется проблема в нем.
Еще одну вещь заметил БД выгружается, но как только начинается операция сохранения в файл вываливается ошибка.
(13)Какой именно текст ошибки выдает при попытке выгрузки базы из postgre? на какую-нибудь таблицу ссылается?
У нас не выгружается типовая база УПП, ругается на таблицу public.config. Проблема решается отвязкой конфы от поддержки, но нас это решение не устраивает.
(14) alexbur,
через постгри выгружается без ошибок.
Но вот если потом загрузить в пустую базу(восстановить) - то база выдает разные ошибки и ни конфигуратор, ни клиент не грузятся..
(15) на всякий случай тормозните postgre и сохраните каталог в котором база храниться. Сделайте техобслуживание базы в pgadmin (analyze, vacuum, reindex) может выдаст какие-нибудь ошибки
Может быть уже имеет смысл думать о том, чтобы вытащить инфу другим путем? К примеру, создать пустую базу с такой же конфой и перетащить в неё данные с помощью обработки "Универсальный обмен данными черех XML". Не самый плохой путь, на мой взгляд.
(17) alexbur,
Это крайний вариант так как на этой бд у нас РИБ + обмены с сайтами(2 штуки)
Это все полетит в данном случае.
конф файл был стандартный - ошибка и на нем была, сейчас я уже влез в него прилично, но успехов пока нет. Все таки надеюсь что получится стандартными средствами выгрузку сделать.
А если я подниму эту же версию постгри на сервере и скопирую туда папку постгри - он увидит БД. Может на болле мощной машине получится выгрузить.
(22) kliman, не факт что слетит. Универсальный обмен данными в формате xml при загрузке формирует объекты БД с теми же уникальными идентификаторами что и в исходной БД. При повторной выгрузке/загрузке информация не дублируется, а "ложится" на нужные объекты.
РИБ использует тот же самый механизм при обмене. Скорее всего при первом обмене придётся перегрузить весь объём инфы, но, во всяком случае, я бы повел эксперимент.
(14) alexbur, дак снимай с поддержки - загрузи в СКУЛь - потом "загрузить конф. из файла", правда какие-нибудь аналитики могут пропасть.
(20) Мне это незачем, т.к. dt файл из конфигурации прекрасно выгружается. А если снять с поддержки и потом загрузить конфу из файла, то проблема выгрузки из postgre возвращается.
Так что пока обхожусь бэкапами из конфигуратора и подумываю о переходе на x64 postgre.
(19)дык я об это же говорил в (17). Кстати, а какого плана горе может возникнуть при проведении?
(13) Конф файл настраивается индивидуально под каждую конфигурацию - та ещё пляска с бубном.
Возможно имеет смысл наоборот попробовать выгрузить со стандартным конф файлом. Или он у вас изначально стандартный был?
в интернете нашел что у кого-то помогло установка значений
work_mem = 64MB
maintenance_work_mem = 256MB
проставил галочки в конф файле, перезапустил.
Если захожу в конф файл там в значение верное знач, а в текущем значение другие цифры.
Что за колонка текущее значение?
есть вариант с выгрузкой данных в идентичную конфигурацию(на ИТСе есть обработки), если получится в СКУЛе в чистой базе развернуть .cf, то переноси данные через обработки, только галочку "выгружать движения" поставь, иначе при проведении горя хапнешь.
Когда-то давно задавал вопрос на партнерском форуме 1С, а сейчас решил выложить в общий доступ.
Исходные данные:
Платформа: 1С:Предприятие 8.1 (8.1.15.14)
Кофигурация: БП 1.6.24.7 (Конфигурация типовая, на поддержке). Ситуация может воспроизвестись на любой конфигурации.
Сервер СУБД: Postgres 8.3.8 (сборка 1с)
ОС: Debian Lenny 5.0 (Linux 2.6.26-2-686-bigmem i686 GNU/Linux)
Физ: на сервере 8Гб памяти, параметры остального оборудования думаю не критичны.
Воспроизводимость 100%
При закрытии месяца вылетает с ошибкой: Ошибка СУБД. ERROR: Out of memory. DETAIL: Failed on request size 8388608
enable_mergejoin=off (в .conf файле или через SET в консоли/PgAdmin)
Проблема в оптимизаторе, который выбирает неудачный план(merge join), требующий большого объема памяти и большого времени для выполнения запроса.
«If the default plan chosen by the optimizer for a particular query is not optimal, a temporary solution can be found by using one of these configuration parameters to force the optimizer to choose a different plan. Turning one of these settings off permanently is seldom a good idea, however. «
Что такое mergejoin? Алгоритм соединения слиянием сортированных списков (merge join, sort merge join, sort-merge join) — разновидность алгоритма соединения. Алгоритм получает на вход 2 таблицы и условие соединения. Результатом его работы является таблица с результатами соединения. Главным недостатком алгоритма является необходимость в предварительной сортировке списков. Накладные расходы на сортировку могут быть неприемлемо высокими.
(26) Да, решить удалось на этих выходных. Перенес Постгри полностью на новый сервер(64 и и хороший по производительности) и на нем удалось произвести выгрузку в dt. Все таки дело в ресурсах. С постгри больше не работаю)
(28) перенес dump, каталоги не получилось перенести. Загрузить дамп получилось(архив не меняли) раза с 5, до этого сыпались какие-то ошибки. причем каждый раз разные.
Спешу поделиться решением проблемы. Недавно перевел 1с из файлового варианта в SQL, при этом решил использовать PostgreSQL. По началу, при попытки выгрузить базу в .dt файл, вылетала ошибка "Соединение разорвано и чего-то там еще. ". Платформа 1с была 8.2.19.68, в тех. поддержке посоветовали поставить более старую версию (установил 8.2.18.61), ошибка исчезла, но появилась другая "Ошибка СУБД out of memory for query result". Перекопал весь интернет, пробовал различные советы, но ничего не помогало. Исходя из текста ошибки, я понял что программе не хватает памяти, но вот только какой?! На сервере стоит Win2008srv c 8Гб оперативной памяти (вроде должно хватать), но вот в настройках Windows виртуальная память выбирается автоматом, при этом если у вас два раздела (C и D), то на диске D файл подкачки отключен по умолчанию. А так как у меня все базы находятся на диске D, и размер базы 1с составляет порядка 1,5 Гб, то для того чтобы её выгрузить в файл .dt необходимо было включить использование файла подкачки с параметром "по выбору системы" и будет вам счастье.
Спешу поделиться решением проблемы. Недавно перевел 1с из файлового варианта в SQL, при этом решил использовать PostgreSQL. По началу, при попытки выгрузить базу в .dt файл, вылетала ошибка "Соединение разорвано и чего-то там еще. ". Платформа 1с была 8.2.19.68, в тех. поддержке посоветовали поставить более старую версию (установил 8.2.18.61), ошибка исчезла, но появилась другая "Ошибка СУБД out of memory for query result". Перекопал весь интернет, пробовал различные советы, но ничего не помогало. Исходя из текста ошибки, я понял что программе не хватает памяти, но вот только какой?! На сервере стоит Win2008srv c 8Гб оперативной памяти (вроде должно хватать), но вот в настройках Windows виртуальная память выбирается автоматом, при этом если у вас два раздела (C и D), то на диске D файл подкачки отключен по умолчанию. А так как у меня все базы находятся на диске D, и размер базы 1с составляет порядка 1,5 Гб, то для того чтобы её выгрузить в файл .dt необходимо было включить использование файла подкачки с параметром "по выбору системы" и будет вам счастье.
(31)Спасибо совет помог. Но есть еще одна проблемка на другой машине. При выгрузке dt ошибка субд server closed connection unexpectedly
This problems means the server terminated abnormally before or while processing the request.
Такая же ерунда. Ничего не помогло :( Сделал дамп из PG. На локальной машине с Виндой развернул 1с сервер и PG, дамп закинул туда и через конфигуратор выгрузил ИБ.
(34) Ну вот не факт что поможет.
На текущий момент имею тестовую виртуалку под CentOS 7 + PostgresPRO 9.6 + 1C sever x32 - 8.3.10.2580
База УТ 10.3, вес в слоне 22Gb. В виртуалке 8Gb памяти, 2cpu по 6core.
При попытке выгрузить в dt выпадает с ошибкой Out of memory. Хотя память в виртуалке отъедалась максимум в районе половины.
Благо это все эксперименты и можно поиграться. Все что выше советовалось - не помогает. Пока играюсь и смотрю.
Плюс заметил глюк этой версии платформы под CentOS:
Грузил dt этой базы (9,3Гб). Толстым клиентом подсоединялся к 1С серверу на этой виртуалке. И начинаю загрузку. По поведению системы вижу, что dt туда перекачался, и пошла закачка базы в postgres. После заливки примерно 1,3Gb конфигуратор выдает ошибку, что (кратко): "Не все данные загружены. Ошибка формата потока."
Тесты, настройки, чпоки, эксперименты с настройками Postgres и 1С сервер на этой машине ничего не дали.
Делаю следующее: У себя на виндовой машине поднимаю туже версию 1С сервера (и тоже х32), создаю тестовую базу и в качестве СУБД указываю тот же Postgres в той тестовой виртуалке. Заливаю dt и вулая! База залилась без ошибок!
Т.е. есть какой-то глюк в платформе.
Вот в качестве эксперимента по той же схеме запустил выгрузку dt. В итоге в CentOS занято чуть меньше 1,7Гб. По активности сети вижу, что база интенсивно льется на мой компьютер через 1С сервер на моем компьютере. Ошибки пока не выпадало. Будем посмотреть.
UPD: Тоже упало с ошибкой out of memory. Хотя памяти при этом на сервер до опы свободной.
Ну собственно, потыкавшись и помыкавшись, посмотрев за памятью, пришел к выводу, что PostgreSQL тут как бы не причем.
rphost давится. 32-битный процесс доходит до своего предела в 3,5 гига озу и все. после этого резкое высвобождение памяти и в последующем нелюбимая ошибка Out of memory.
Установа х64 1C сервера и последующая повторная выгрузка прошли без проблем.
В процессе наблюдения за поведением x64 rphost, было видно, что потребление памяти процессом доходило до 4,5 Гигабайт. Причем несколько раз.
Интересно, почему та же база, на х32 1C сервере в сочетании с MSSQL не дает такого эффекта?
А вот c PostgreSQL такое наблюдаю постоянно?
Тоже была такая проблема. Мне помог перезапуск службы сервера 1С. Но на огромных базах такое решение скорее всего не поможет, но почему бы не попробовать?
В настройках 1С сервера 32х Свойства рабочего сервера - количество ИБ на процесс. Было 8, сделал 1. Помогло без перезапуска 1С сервера и постгри.
Была точно такая проблема, ничего не помогло из того что тут написано.
Но помогло вот что: в postgresql.conf параметр shared_buffers снизил в разы.
а с линуксов создаются нормально?
На сервере с консоли терминала в среде СУБД PostgreSQL базы создаются и тестируются.
Там мильйон причин по которым у вас вылазит такая ошибка. Вы через оснастку Администрирование серверов 1с, бд подключали?
нет. Я просто установил клиент и с него. В меня клиентский ПК под Win 7. Попробую через оснастку. Спасибо.
А постгрес пропатчен для 1С?
Попробовал через оснастку. Но при создании Центрального сервера после задания его имени «Serv1С» или IP выдаэтся следуюющее собщение: Server addr=tcp://Serv1C:1541 descr=192.168.101.10:1541; Ошибка сетевого доступа к серверу (Windows Sockets-10065(0x00002751). Сделана попытка выполнить операцию на сокете для недоступного хоста); lin=545 file=src\DataExchange TcpClientlmpl.cpp
Приехали. Я так понял, что с сети не видно сервера. Хотя через самбу я его вижу и даже пишу в расшаренную папку. А вот сервера 1С, видимо не видно. И как его открыть для сети?
А как это сделать?
Пройди в оснастку управления и администрирования сервером 1С предприятие. Зайди в свой кластер и обрати внимание на «Рабочие серверы». Удали то что там сейчас и укажи реально существующий сервер. После этого возможно потребуется создать рабочие процессы.
Скачай с офф.сайта производителя патчи, если сам сервер Postgres не с офф. сайта.
petav ★★★★★ ( 05.04.13 13:36:58 )
Последнее исправление: petav 05.04.13 13:38:09 (всего исправлений: 1)
«Serv1С» надо прописать в hosts.
Да, но как пройти в оснастку управления и администрирования сервером 1С предприятие, если Центальный сервер не виден: Server addr=tcp://Serv1C:1541 descr=192.168.101.10:1541; Ошибка сетевого доступа к серверу (Windows Sockets-10065(0x00002751). Сделана попытка выполнить операцию на сокете для недоступного хоста); lin=545 file=src\DataExchange TcpClientlmpl.cpp .
Для начала рабочий сервер поправьте в кластере. Я почему-то думаю что postgres у тебя с офф.сайта.
Установи ее на виндовс машине и мышкой нашелкай, или поправь все в файле сервера 1С на Линукс
Инициировал в кластере: su -u postgres -c '/usr/pgsql/bin/initdb -D /var/lib/pgsql/data --locale=ru_RU.UTF-8' Далее сделал: psql -U postgres -c «ALTER USER postgres PASSWORD 'sayar77ma'»
Вы вообще не в теме, да?
Человек слабо понимает, что делает, и вообще не понимает, что ему говорят. На днях этот же вопрос он уже задавал.
База PostgreSQL и «информационная база» 1С имеют между собой примерно столько же общего, сколько база автомобиля и база отдыха.
Дружище, ты не там ищешь ответы. Тебе придётся сесть и изучить документацию вообще по всему, что ты используешь, научится диагностике и решению проблем.
А когда ты станешь гуру pgsql и 1с, ты поймёшь, какой бесполезнейшей хернёй ты вообще занимаешься. Связка 1C+pgsql не даст тебе никакого прироста в производительности, напротив, такая связка гарантированно хуже в этом плане чем 1с+дефолтный mssql, даже если ты базы утащишь в рамфс и воткнёшь столько мощных процессоров, сколько у тебя хватит фантазии. И дело не в тебе и не в pgsql, дело в 1С.
Но я тебя обрадую, (не в даваясь в историю появления mssql) 1С под linux идеально чувствует себя в связке с db2 от ibm. Эффект «вау» от бухгалтеров гарантирован и отсутствие нервотрёпок в дальнейшим тоже. Да, для использования больше 2Гб памяти она требует покупку лицензии, очень не дешёвой.
Удачи, и смотри первый абзац.
И, да, я считаю идиотизмом менять обкатанное десятилетием, рабочее решение 1с+mssql только ради экономии одной лицензии на винду. Причём на решение, которое заведомо хуже в плане производительности. Впрочем, если у тебя база ИП и куча лишнего времени - ок, твой выбор.
bass ★★★★★ ( 09.04.13 22:23:05 )
Последнее исправление: bass 09.04.13 22:26:52 (всего исправлений: 1)
Тебе придётся сесть и изучить документацию вообще по всему
Связка 1C+pgsql не даст тебе никакого прироста в производительности, напротив, такая связка гарантированно хуже в этом плане чем 1с+дефолтный mssql
Заведомо хуже постгрес работает в одном случае - если его не настроить, но науки в этом нет, всё разжёвано. Да, в теории на автоматических блокировках в сильно многопользовательском режиме будет хуже скуля, а на практике. а непонятно, и объективной методики оценки не существует, слишком много нюансов в оценке производительности как самой платформы, так и конкретных решений. Некие тесты сферических 10/50/100500 пользователей на сферической базе со сферическими данными мало кому интересны.
1С под linux идеально чувствует себя в связке с db2 от ibm.
Близко к 4.2. Заливку dt по 10 часов уже починили? Администрирование этого чуда даже не рассматриваем.
И, да, я считаю идиотизмом менять обкатанное десятилетием, рабочее решение 1с+mssql только ради экономии одной лицензии на винду. Причём на решение, которое заведомо хуже в плане производительности. Впрочем, если у тебя база ИП и куча лишнего времени - ок, твой выбор.
У меня клиентские базы далеко не ИП, но почему-то прекрасно себя с постгресом чувствуют, и типовые, и собственные. Про кучу лишнего времени мимо. Ну а про «одну лицензию на винду» как-то даже не смешно.
ollowtf ★★★ ( 09.04.13 23:27:38 )
Последнее исправление: ollowtf 09.04.13 23:28:01 (всего исправлений: 1)
Ты не берёшься утверждать что производительность pgsql лучше чем db2, у тебя всё отлично и так. Хорошо, сколько гигабайт твоя база и сколько в ней работает человек?
Надеюсь, что ты пробовал не триальную версию с ограничением в процессорах, памяти и процессах.
Заливку dt по 10 часов уже починили?
А что была какая-то проблема у тех кто догадался прочитать документацию? У меня таких проблем нет.
Администрирование этого чуда даже не рассматриваем
А какие проблемы с администрированием? И она не чудо, она «суровый энтерпрайз» со всеми вытекающими плюсами и минусами.
Давай пойдём по пути простой логики, как ты думаешь, что движет людьми, что они заменяют mssql и pgsql на db2? Ну или не заменяют, а хотя бы пытаются?
Я не агитирую за db2, у меня к ней тоже есть претензии, но они нивилируются удовлетворением от производительности. К сожалению, pgsql мне эту радость не подарил, и мне жаль потраченного на него времени при решения задачи «обеспечить производительность выше mssql». Я работал с базами 15-80Гб с 20-40 активными юзерами, это было лето 2011г.
p.s. допускаю, что за последние почти 2 года произошёл какой-то прорыв в связке с pgsql, но зная инертность 1с разработчиков, просто в это не верю.
Ты не берёшься утверждать что производительность pgsql лучше чем db2.
Конечно нет, фирма 1С тоже вот не берётся. Про сферические базы со сферическими пользователями я уже писал. По опыту могу сказать, что серьёзные затыки с производительность обычно связаны с нюансами учётных алгоритмов, и не решаются ни железом, ни настройкой чего-либо. Только изменение/оптимизация алгоритма.
Хорошо, сколько гигабайт твоя база и сколько в ней работает человек?
Ок, есть база на 50Гб с 30+ пользователями. Внезапно, на постгресе чувствует себя лучше, чем на скуле.
А что была какая-то проблема у тех кто догадался прочитать документацию?
Ага, посмотри закрытый форум.
как ты думаешь, что движет людьми, что они заменяют mssql и pgsql на db2?
Отсутствие программистов в штате? Имеющийся db2? :)
но зная инертность 1с разработчиков, просто в это не верю.
Всем бы такую инертность, за 5 лет полностью переписать платформу, реализовать полноценный клиент-сервер, кроссплатформенность, веб-клиента, декларативное описание интерфейса и ещё обеспечивать обратную совместимость.
P.S. Обратите внимание, что можно оплачивать с личного счета Инфостарта, например, после обмена StartMoney на рубли.
Видеозапись вебинара предоставляется только участникам вебинара в защищенном формате (одна лицензия на компьютер для просмотра только в OS Windows).
Добрый день.
Подскажите будет ли повтор мероприятия в ближайшем будущем или возможность посмотреть запись позже?
К сожалению, нет возможности участвовать в вебинаре из-за командировки.
(89) GROOVY,
Можете что-нибудь прокомментировать насчет оплаты платных вебинаров. Я думал что если у меня на ИС есть рубли (не старт мани, а именно рубли), то я смогу ими оплатить какие-либо покупки на данном сайте (в т.ч. участи в вебинаре)
Но как я понимаю на данный момент такой возможности нет.
В чем сложность такой реализации и планируется ли когда нибудь такое сделать ?
(96) headMade, скоро такая возможность появится.
В чем сложность, сказать не могу, не я этим занимаюсь.
Очень интересует запись. Не понимаю сложностей с ее получением. Запись с экрана видеотрансляции еще никто не отменял. В наше время любой пользователь может записать видеопоток со своего экрана. Но это геморой, надо ее запускать, следить за качеством звука, вырезать перерывы, оно нам надо!? Зачем тогда нам доставлять такие неудобства? Тем более что запись вебинара всегда предоставляется сервисом на котором проводится этот вебинар. Хватит уже приседать и боятся. В наш век ценность информации не в самой информации, а в ее актуальности и доступности. Так что можно проводить вебинар и выкладывать ее в полный доступ. Через год ценность ее сильно уменьшится. И вот тогда выпустите новый вебинар и снова денег поднимите. Люди за вебинар платят за то что бы на нем задать вам свои вопросы и получить на них ответы первыми.
(91) stneon, Во-первых Вы нарушаете авторское право делая запись с экрана. Модераторы Вас забанят.
Во-вторых: у нас 11 медиапотоков при трансляции, их надо все синхронизировать, обработать, убрать моменты, которые никому не нужны. Брендировать. Переключение трансляции ведущего, скринкастинг, презентация.
Вам кажется - это просто, одной кнопкой? Нет, это все производится вручную.
А политику распространения материалов определяет автор. И если он решил, что распространятся все это он будет на платной основе, то так тому и быть.
(92) Делая запись с экрана я ничего не нарушаю. Я на своем компьютере имею полное право делать все что я хочу. Далее контент оплачен и был мною получен на мой же компьютер и точка. Как записать изображение с экрана это уже техническое дело.
Так что не говорите мне как организовать вебинар и всю эту муть с потоками тоже не вешайте мне на уши. Если у вас все так грустно с технической стороны, то могу помочь либо советом, либо делом.
Читайте также: