Здравствуйте!

Есть серверная база ЗУПа (2.5.102.2). Платформа 8.3.7.1873. На сервере (Server 2008 R2 виртуальная машина проц Core i7 2 GHz 4 процессора ОЗУ 12 Гб) установлено СУБД PostgreSQL 9.4

База типовая. На замочке. Очень маленькая dt занимает 250 Мб. Акти вных пользователей порядка 2-4 чел. При выполнении банальных действий вроде заполнения табличной части документа возникает повисание на 4 минуты. Если выгрузить эту базу и загрузить в файловую та же самая операция длится порядка 7 секунд. Доступ к базе по сети каждый со своего компьютера. Не терминальный доступ

Подскажите что можно понастраивать или куда смотреть??

Спасибо!

(0) >>>На сервере (Server 2008 R2 виртуальная машина

Дальше можно не читать, проблема описана явно.

Что уже попробовал, но не помогло:

1) Тестирование и исправление
2) Очистка 1Совского кеша. На сервере и на клиентах
3) Выгрузка и загрузка базы через dt
4) Так называемый "шринк" в СУБД
может что-то еще сразу могу не вспомнить...

(1) а можно чуть подробнее?

постгри же настаивать надо, он из коробки невесело работает

(0) Поди дисковая система тоже виртуальная?

(2) Сервер в виртуалке, чего уж тут подробнее?

попробовать http://www.postgrespro.ru/products/1c_build последнюю стабильную

(0) RLS?

Попробовать без виртуалок можешь?Вот и будет видна разница

(4) А куда там потыкать надо?
(5) Да.
(8) Включал/Выключал результат одинаковый((

(7) Я думаю дело не сколько в версии, сколько в ее настройке. У нас то редакция более менее свежая.Но все равно спасибо за совет. Когда совсем ничего не останется наверное попробую.

Еще. Если смотреть на сервере в момент выполнения операции в монитор ресурсов особо нагрузки нет ни на винты, ни на память, ни на проц. Понимаю, что это не показатель, но тем не менее

(9) что вы имеете ввиду? На физическом сервере развернуть копию и посмотреть как там отработает?

(0) отладчиком попробуй всё ж пройтись. Железо может быть не виновато.

и с виртуалками под сервер БД крайне советуют юзать физический диск (direct access)

(12) Разумеется.
Виртуализация это всегда потеря производительности.
А там еще не известно как она у вас настроена, и сколько ресурсов отдано.
В итоге выяснится что база лежит на виртуальном диске, память у виртуалки регулярно отжимает другая машина, процессор тоже.

(12) Да именно так.Мы пробовали все виртуалить(субд и сервер приложения).В итоге на виртуалку уехали инстансы 8.2 и 8.3,а вот субд физическая

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

Блин, ну сейчас гляну куда можно на физическую машину развернуть...

судя по http://fragster.ru/perfomanceTest/results.php у постгре часто проблема именно с временными таблицами, которые вор множестве используются в ЗУПе
типичная ситуация (ткнуть на графике в серую надпись):
постгре http://fragster.ru/perfomanceTest/result.php?guid=e1e605e8-3df7-11e6-aeed-e0cb4e4e15b4
мсскуль http://fragster.ru/perfomanceTest/result.php?guid=3162b339-34c6-11e6-a5fa-001c23e1b047

в серую надпись "временные таблицы". видно, что у постгре разница между временными и "прикладными" таблицами мала, в то время, как у мсскуля - временные быстрее в разы.

хотя вот этот результат внушает надежду http://fragster.ru/perfomanceTest/result.php?guid=131fd96a-1c0c-11e6-80c1-00155d7c6d06 (хотя таких мало)

А сколько всего виртуалок у вас на сервере, и сколько ресурсов они отбирают? потестил как-то виртуалки эти, потом удалил все, только реал

+ (17) нашел физический сервер с Постгри. Поставил на загрузку...

(18-20) Спасибо!
(21) 3 виртуальные машины. Одна вообще пустая. Вторая на линуксе вроде как ничего не должна потреблять и третья моя с ЗУПом

(23) А для чего вообще вы сервер в виртуалку засунули? Каких целей хотели этим добиться?

Это не йа! Это админы у нас такую архитектуру замутили))

(25) им проще, а всем гемор. Это же админы. У них всё всегда работает, пока мордой не тыкнешь.

но в отладчик ты так и не посмотрел

(0) 8.3.8 последние(релиз, тестовая, неважно) попробуй.
1С медленно делает расчет на postgresql
1с на postgresql

то, что удалось найти сегодня буду пробовать


Настройки PostgreSQL для работы с 1С:Предприятием
Краткое содержание:
Рекомендации по настройкам PostgreSQL для достижения максимальной производительности при работе с 1С6Предприятием 8.1
Применимость:
Платформа: 1С:Предприятие 8.1
СУБД: PostgreSQL
Настройки:

fsync
effective_cache_size
Для повышения производительности 1С:Предприятия 8.1 при работе с СУБД PostgreSQL рекомендуется установить приведенные ниже значения параметров. Значения параметров устанавливаются в конфигурационном файле postgresql.conf.

Параметр "fsync"

На производительность PostgreSQL оказывает существенное влияние производительность дисковой системы, поскольку по умолчанию, параметр fsync включен. Это означает, что при выполнении операции COMMIT данные сразу переписываются из кеша операционной системы на диск, тем самым гарантируется консистентность при возможном аппаратном сбое. Обратной стороной этого является снижение производительности операций записи на диск, поскольку при этом не используются возможности отложенной записи данных операционной системы.

Повышение производительности возможно при использовании многодисковых RAID-массивов, созданных на основе кэширующих RAID-контроллеров с энергонезависимой кэш-памятью и использования источников бесперебойного питания(UPS). В этом случае задачу по обеспечению консистентности данных при аппаратном сбое берут на себя описанные выше устройства, поэтому появляется возможность отключения параметра fsync и увеличения производительности операций записи на диск.

Следует отметить, что увеличение количества дисков в RAID-массиве и объема кеша RAID-контроллера само по себе позволяет компенсировать снижение производительности, обусловленное включением параметра fsync.

Параметр "effective_cache_size"

Работа оптимизатора в PostreSQL 8.2 существенно зависит от размера выделенной PostreSQL оперативной памяти. При использовании PostgreSQL 8.2 при работе с 1С:Предприятием 8.1 рекомендуется увеличить значение параметра effective_cache_size в конфиргурационном файле postgresql.conf. Значение этого параметра рекомендуется устанавливать не менее половины объема оперативной памяти установленной на компьютере.

Попробуй enable_nestloop = off

(29) Ты для начала админам скажи чтобы на реальное железо перенесли все с виртуалки.

Наблюдения продолжаются. После разворота копии на физический сервер с Постгри мои вычисления работают одинаково хреново((

Еще нарыл
Короче ранее 8.3.8 зуп на постгре лучше не ставить
https://bugboard.v8.1c.ru/error/000002673.html

В клиент-серверном варианте информационной базы при использовании СУБД PostgreSQL удаление набора записей регистра расчета с поддержкой периода действия выполняется неоправданно медленно.

Исправлена:
"Технологическая платформа", версия 8.3.8

(32) Попробуй все-таки "enable_nestloop = off" в настройках постгреса.

http://kb.1c.ru/articleView.jsp?id=91

поставь мсскл и все будет нормально.
в том числе и под виртуалкой (хиперв или вмваре) - потери производительности мизерные,  на уровне погрешности измерений.

С такой базой у тебя мсскл экспресс на ура работать будет

Народ, подскажите, а почему под виртуалкой работает хуже?

У меня под виртуалкой MS SQL 2014 + 1c 8.3, тоже наблюдаются тормоза в момент когда отрабатывет универсальный обмен данными.
Проц., память, диски в норме, в чем проблема подскажите плиз. Виртуализация под ESXI.

Обмен работает на загрузку данных, проводит документы, вроде нагрузка понятна. Но в этот момент даже открытие документа длится секунд 15-20, это ужас!!!!!

(39) Выдыхай и сделай замер кода 1С для начала, если длительность в коде отличается от длительности реальной - то покури профайлер

но ведь все равно найдется человек, который скажет что постгри для адинес это здорово

(0) В топку PostgreSQL!
(38) Загрузку дисков смотри.

(33) Сегодня попробую.
(41) Да. И это скорее всего буду я))

Проблема на первый взгляд решена. (Время как всегда покажет) Установил платформу  8.3.8.1784

Всем спасибо за активность!

(41) Ну... если есть время посидеть, пооптимизировать запросы, вычистить тормоза и проч. То почему бы и нет :-)