Доброго времени суток! :) Хочу вот посоветоваться - развернул недавно в двух разных компаниях 1С-сервер (8.3). В одной конторе это связка с MS SQL (Windows Server), а в другой - с PostgreSQL (Ubuntu). Так вот что интересно - в первом варианте 1С-сервер и MS SQL установлены на одном компьютере, при этом во время работы процесс rhost кэширует данные в оперативную память, за счет чего работает все довольно шустро. Но вот во втором варианте 1С-сервер и PostgreSQL установлены на разных машинах, хотя процессор и объем ОЗУ одинаков в обоих вариантах. И в этой связке rphost занимает ОЗУ только если есть хотя бы один рабочий сеанс с любой из баз. Скажем, во время активной работы он занимает порядка 1,5 Гб. Как только все выходят из сеанса, rphost уменьшается до 100 Мб примерно. И потом опять заново считывает всё. А с MS SQL такой проблемы нет почему-то. Что я мог не учесть при настройки 1C-PostgreSQL? Заранее спасибо за ответы :)
avm3110
18.12.2017, 11:26
ну-у-у.. На вскидку.. Когда 1Ска и сиквел стоят на одной тачке, они могут общаться через "шаред мемору" (что довольно быстро и эффективно). 1Ска с Постргесом так общаться не умеют.
garett
18.12.2017, 11:33
То есть придется всегда как минимум один сеанс держать открытым, чтобы другие не тратили время на запуск? Кстати, смотрю распределение памяти на Postgre-машине - тоже занимает от силы 450 Мб ОЗУ. Для сравнения на MS SQL кэшируется на 9 гигов, в силу чего очень быстро работает база. С этим тоже ничего не поделаешь?
avm3110
18.12.2017, 13:58
То есть придется всегда как минимум один сеанс держать открытым, чтобы другие не тратили время на запуск? Кстати, смотрю распределение памяти на Postgre-машине - тоже занимает от силы 450 Мб ОЗУ. Для сравнения на MS SQL кэшируется на 9 гигов, в силу чего очень быстро работает база. С этим тоже ничего не поделаешь?
Не-е-е.. тут нет "абсолютной истины". Когда 1ска и сиквел находятся на одном сервере - есть свои плюсы, но при этом есть проблемы масштабирования и устойчивости. Все же "по хорошему" настройки виндов (да и самого железа) под нужды 1Ски и под сиквел - различны.
Насчет кэша постгри - там есть свой конфигурационный файл где многое можно отруливать. Опять же - платный энтерпраз постгри - серьезно производительнее чем бесплатный пострги проф.
Опять же.. Размещение на бесплатной убунте имеет свои плюсы, но соответственно нужно понимание как настраивать убунту и та же проблема например "быстрых дров" на ту же сеть.
Отдельная песня, когда серваки разворачиваются на виртуалках. И т.д. и т.п.
garett
19.12.2017, 00:22
Попутно заметил еще одну проблему - теперь не удается обновить конфигурацию базы из конфигуратора - затенено. А как теперь её обновлять? В файловом режиме работало.
avm3110
20.12.2017, 07:52
Попутно заметил еще одну проблему - теперь не удается обновить конфигурацию базы из конфигуратора - затенено. А как теперь её обновлять? В файловом режиме работало.
(задумчиво) Принимать роды по телефону конечно увлекательно, но можно посчитать, что это роды у морских свинок, а на самом деле - у человека :-)
ПыСы.. Навскидку - Когда работаешь в файловом варианте - ты работаешь в толстом клиенте. Ну а в клиент-серверном - можно работать и в тонком и в толстом. Но обновление работает только для толстого клиента.
garett
20.12.2017, 11:33
Схема такая (справа налево) - Ubuntu с PostgreSQL->1С сервер (Windows 2008 R2)->терминальный сервер с RemoteApp (Windows 2008 R2)->клиентский комп с Windows 7. То есть у клиента настроен Remote App и работает он с базой вот по такой цепочке. И если он заходит в базу через конфигуратор, то опция "Обновить конфигурацию" оказывается затененной. Как быть в этом случае?
avm3110
21.12.2017, 08:39
Схема такая (справа налево) - Ubuntu с PostgreSQL->1С сервер (Windows 2008 R2)->терминальный сервер с RemoteApp (Windows 2008 R2)->клиентский комп с Windows 7. То есть у клиента настроен Remote App и работает он с базой вот по такой цепочке. И если он заходит в базу через конфигуратор, то опция "Обновить конфигурацию" оказывается затененной. Как быть в этом случае?
(задумчиво) Как вариант: поставь нормального клиента 1с на клиентском компе и зайди в конфигуратор на нем самом напрямую, а не "по цепочке". И посмотри разницу. Если на клиенте все ок, то тогда нужно ковырять "цепочку"
garett
23.12.2017, 01:05
Разобрался, спасибо :-) Правда, попутно нашел еще одну проблему - не знаю, создавать ли новую тему... При тестировании базы "ЗуП" возникла ошибка: no data left in message. Возникает при прохождении пункта тестирования "Реструктуризация таблиц информационной базы". Добавил скриншот.
1766
avm3110
23.12.2017, 12:27
Косяк с базой (как вариант с правами юзера под которым 1Ска общается с сиквелом)
garett
23.12.2017, 12:49
Но это только с "Зарплатой" такое при тестировании происходит. Сервер тот же, права postgres'a те же... Как пофиксить?
avm3110
23.12.2017, 13:52
Кстати, а какой ЗУП юзаете на постгри? Дело в том, что Постгри это "версионник", а ЗУП 2.5 делался под 8.2 и работает в автоматическом режиме - т.е. тут "из пушки по воробьям":blush:
garett
23.12.2017, 14:31
Блин... Именно 2.5 ЗУП установлен... Там просто бухгалтеры не хотят почему-то переходить на новую конфигурацию, так и тянем это старье. То есть 2.5 некорректно работает с постгре? Хотя ошибок в работе не было, обнаружил случайно при тестировании. Что посоветуете?
Online_Z
24.12.2017, 10:19
Именно 2.5 ЗУП установлен... Там просто бухгалтеры не хотят почему-то переходить на новую конфигурацию, так и тянем это старье.
ЗУП 2.5 какой версии, ПРОФ или КОРП?
Если не КОРП, то бухгалтеров можно обрадовать, т.к. поддержка ЗУП 2.5 всех версий кроме КОРП будет прекращена и с 1 января 2018 г. надо переходить на ЗУП 3.1.
О прекращении поддержки ЗУП 2.5 и необходимости перехода на ЗУП 3.1 (http://www.online-ufa.ru/content/news/prekrashchenie-podderzhki-zup-2-5/)
Если конфа типовая, то можно попробовать до НГ, как переносятся данные. Если конфа с изменениями или штатный перенос не пойдет, то возможно будет проще перейти на ЗУП 2.5 КОРП, чем на 3.1.
ЗУП 2.5 КОРП будет поддерживаться минимум еще пару лет.
avm3110
24.12.2017, 14:50
Хотя ошибок в работе не было, обнаружил случайно при тестировании. Что посоветуете?
дЫк у вас бухи, когда работают, используют (конечно же посредством платформы) только лишь "подмножество SQL" - DML (язык манипулирования данными).
А вы при тестировании "залезли" уже в DDL (язык определения данных), посредством которого идет реиндексация, реструктуризация и т.д.
Кстати, а какая у вас версия платформы и какой у вас постгри (версия, проф или энтерпрайз)?