# Форум 1С > Конфигурирование, программирование 1С - Предприятие > 1С - Предприятие 8.0, 8.1, 8.2, 8.3 >  1C 8.3-PostgreSQL - rphost не кэширует данные в ОЗУ

## garett

Доброго времени суток! :) Хочу вот посоветоваться - развернул недавно в двух разных компаниях 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

ну-у-у.. На вскидку.. Когда 1Ска и сиквел стоят на одной тачке, они могут общаться через "шаред мемору" (что довольно быстро и эффективно). 1Ска с Постргесом так общаться не умеют.

----------


## garett

То есть придется всегда как минимум один сеанс держать открытым, чтобы другие не тратили время на запуск? Кстати, смотрю распределение памяти на Postgre-машине - тоже занимает от силы 450 Мб ОЗУ. Для сравнения на MS SQL кэшируется на 9 гигов, в силу чего очень быстро работает база. С этим тоже ничего не поделаешь?

----------


## avm3110

> То есть придется всегда как минимум один сеанс держать открытым, чтобы другие не тратили время на запуск? Кстати, смотрю распределение памяти на Postgre-машине - тоже занимает от силы 450 Мб ОЗУ. Для сравнения на MS SQL кэшируется на 9 гигов, в силу чего очень быстро работает база. С этим тоже ничего не поделаешь?


Не-е-е.. тут нет "абсолютной истины". Когда 1ска и сиквел находятся на одном сервере - есть свои плюсы, но при этом есть проблемы масштабирования и устойчивости. Все же "по хорошему" настройки виндов (да и самого железа) под нужды 1Ски и под сиквел - различны.
Насчет кэша постгри - там есть свой конфигурационный файл где многое можно отруливать. Опять же - платный энтерпраз постгри -  серьезно производительнее  чем бесплатный пострги проф.

Опять же.. Размещение на бесплатной убунте имеет свои плюсы, но соответственно нужно понимание как настраивать убунту и та же проблема например "быстрых дров" на ту же сеть.
Отдельная песня, когда серваки разворачиваются на виртуалках. И т.д. и т.п.

----------


## garett

Попутно заметил еще одну проблему - теперь не удается обновить конфигурацию базы из конфигуратора - затенено. А как теперь её обновлять? В файловом режиме работало.

----------


## avm3110

> Попутно заметил еще одну проблему - теперь не удается обновить конфигурацию базы из конфигуратора - затенено. А как теперь её обновлять? В файловом режиме работало.


(задумчиво) Принимать роды по телефону конечно увлекательно, но можно посчитать, что это роды у морских свинок, а на самом деле - у человека :-)

ПыСы.. Навскидку - Когда работаешь в файловом варианте - ты работаешь в толстом клиенте. Ну а в клиент-серверном - можно работать и в тонком и в толстом. Но обновление работает только для толстого клиента.

----------


## garett

Схема такая (справа налево) - Ubuntu с PostgreSQL->1С сервер (Windows 2008 R2)->терминальный сервер с RemoteApp (Windows 2008 R2)->клиентский комп с Windows 7. То есть у клиента настроен Remote App и работает он с базой вот по такой цепочке. И если он заходит в базу через конфигуратор, то опция "Обновить конфигурацию" оказывается затененной. Как быть в этом случае?

----------


## avm3110

> Схема такая (справа налево) - Ubuntu с PostgreSQL->1С сервер (Windows 2008 R2)->терминальный сервер с RemoteApp (Windows 2008 R2)->клиентский комп с Windows 7. То есть у клиента настроен Remote App и работает он с базой вот по такой цепочке. И если он заходит в базу через конфигуратор, то опция "Обновить конфигурацию" оказывается затененной. Как быть в этом случае?


(задумчиво) Как вариант: поставь нормального клиента 1с на клиентском компе и зайди в конфигуратор на нем самом напрямую, а не "по цепочке". И посмотри разницу. Если на клиенте все ок, то тогда нужно ковырять "цепочку"

----------


## garett

Разобрался, спасибо :-) Правда, попутно нашел еще одну проблему - не знаю, создавать ли новую тему... При тестировании базы "ЗуП" возникла ошибка: no data left in message. Возникает при прохождении пункта тестирования "Реструктуризация таблиц информационной базы". Добавил скриншот.

err_db.jpg

----------


## avm3110

Косяк с базой (как вариант с правами юзера под которым 1Ска общается с сиквелом)

----------


## garett

Но это только с "Зарплатой" такое при тестировании происходит. Сервер тот же, права postgres'a те же... Как пофиксить?

----------


## avm3110

Кстати, а какой ЗУП юзаете на постгри? Дело в том, что Постгри это "версионник", а ЗУП 2.5 делался под 8.2 и работает в автоматическом режиме - т.е. тут "из пушки по воробьям":blush:

----------


## garett

Блин... Именно 2.5 ЗУП установлен... Там просто бухгалтеры не хотят почему-то переходить на новую конфигурацию, так и тянем это старье. То есть 2.5 некорректно работает с постгре? Хотя ошибок в работе не было, обнаружил случайно при тестировании. Что посоветуете?

----------


## Online_Z

> Именно 2.5 ЗУП установлен... Там просто бухгалтеры не хотят почему-то переходить на новую конфигурацию, так и тянем это старье.


ЗУП 2.5 какой версии, ПРОФ или КОРП? 
Если не КОРП, то бухгалтеров можно обрадовать, т.к. поддержка ЗУП 2.5 всех версий кроме КОРП будет прекращена и с 1 января 2018 г. надо переходить на ЗУП 3.1. 
О прекращении поддержки ЗУП 2.5  и необходимости перехода на ЗУП 3.1
Если конфа типовая, то можно попробовать до НГ, как переносятся данные. Если конфа с изменениями или штатный перенос не пойдет, то возможно будет проще перейти на ЗУП 2.5 КОРП, чем на 3.1.
ЗУП 2.5 КОРП будет поддерживаться минимум еще пару лет.

----------


## avm3110

> Хотя ошибок в работе не было, обнаружил случайно при тестировании. Что посоветуете?


дЫк у вас бухи, когда работают, используют (конечно же посредством платформы) только лишь "подмножество SQL" - DML (язык манипулирования данными).
А вы при тестировании "залезли" уже в DDL (язык определения данных), посредством которого идет реиндексация, реструктуризация и т.д.

Кстати, а какая у вас версия платформы и какой у вас постгри (версия, проф или энтерпрайз)?

----------

