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

Есть сервер Dell PowerEdge C6220
Процессор Xeon E5-2620 0 @ 2.00GHz
На этом оборудовании, в виртуальной среде развернут CentOS 7, на котором установлены сервер 1С x64 8.3.14.1854 и Postgresql 9.6.11, сборка от PostgresPro
Виртуальной машине выделено 16 Gb оперативной памяти и 4 vCPU, дисковая подсистема достаточно производительная.
Развернута информационная база БП 3.0, типовая, очень небольшого размера, порядка 2.5 - 3Гб.

Проблема в следующем, когда заходим в базу, документы открываются и проводятся достаточно быстро, но стоит запустить формирование какого-нибудь бухгалтерского отчета, например ОСВ за месяц - все, этот процесс длится какое-то безумное время, ждал  30, минут отчет так и не сформировался. Пробовал устанавливать различные версии Postgres, 11.5 и 10, сервер 1С 8.3.15.1700. Ситуация не меняется, отчеты формируются вечно. Может, кто-то сможет подсказать, в чем может быть проблема. Спасибо.

ANALYZE

Делал vacuum full analyze к базе, результата не принесло

Сервер свежий, только настроили и решили протестировать работу, прежде чем переводить пользователей и наткнулись на описанную проблему

частота ядра выдающаяся, конечно.. как раз под 1С

(0) >Пробовал устанавливать различные версии Postgres, 11.5 и 10

Попробуй рекомендуемую версию с патчами для 1С.

(3) свежий?!!! на платформе 7ми летней давности?

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

(6) В том плане, что только недавно все установили и сервер с базой еще не был в эксплуатации. А так да, оборудование не самое новое

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

(5) пробовал версию 10.10-1.1C  с сайта 1С, результата не принесло

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

(4) Частота то при чём? Точнее от частоты такого зависона ну точно не может быть. Там дело в другом. А в каком (хехех) не скажу.

Не знаю почему так. Но я бы стал применять метод половинчатого деления:
1. Запустил бы постгре от 1С
2. Запустил бы постгре на винде.
3. Запустил бы сервере 1С на винде
4. Запустил бы клиента на винде
5. С криками "ааааааааааааааа!!!!" убежал бы в отпуск

(11) Настройки выставлял согласно рекомендациям на ИТС

(11) Не правильно помнишь. Все разработки веду только на постгре (виндовом). А это весь спектр конфигураций, в т.ч. и бухия

И скажите админу, что 1С - это не почтовый сервер. Это OLTP - система, тут транзакции, расчеты и запись на диски на порядки больше чем в привычных ему микросервисах и т.п.

(0) > дисковая подсистема достаточно производительная

а можно поподробнее?

(16) dd выдает следующий результат скопировано 1073741824 байта (1,1 GB), 45,7431 c, 23,5 MB/c

(17) я так понимаю, это последовательное чтение/запись?.. а есть возможность еще случайное запись/чтение по 4К прогнать?

(17) 23 ржака, 23.5 точная ржака

(19) погоди.. еще случайные чтение/запись не видели )

(19) IDE-33
Вообще, над чужим горем смеяться не культурно))))))

я понял.. они пыточную для юзеров настраивают

Прошу прощения, сейчас нет возможности проверить листовую систему. Позже протестируем и выложу результат.

(17) К производительности базы эти цифры отношения практически не имеют.

*дисковую :)

(23) Ты хотя бы опиши, какие диски, контроллер, как собраны, ФС, есть ли LVM и т.д.

Я вот недавно ветку создавал в том числе и с тормозами столкнулись. Поставили базу PG на SSD и все шустро начало летать. Это к слову о продвинутой дисковой системе, все эти рейды 10-ые и прочие не дают нормальной скорости произвольного доступа.

О, я виртуальную среду проглядел. В ней может быть дело.

(27) Попробуй диск в памяти развернуть. Вообще обалдеешь от скорости

(24) понаблюдай как нибудь за темп папкой 1с сервера во время формирования отчетов

(17) dd надеюсь с bs=64k запускали? А то по умолчанию он будет 512-байтными блоками читать, с соответствующим результатом.

А по сути вопроса, многоминутные тормоза постгреса при выполнении запросов ПРАКТИЧЕСКИ ВСЕГДА означает одно и то же. Значит при выполнении джойна с подзапросом постгрес применил метод nested loop, хотя не надо было этого делать. Почему-то постгрес при формировании плана выполнения запроса предполагает, что подзапросы всегда возвращают небольшой набор данных, и их проще соединять вложенными циклами. А в характерных для 1с соединениях с виртуальными таблицами это не так - подзапросы огромны, и соединять надо другими методами.
Можно в настройках постгреса задать enable_nestloop=off - это уберет зависания, но может слегка замедлить другие запросы.

(32) плюсую, когда пг тормозит на флешке юсб 1.1 только подтверждает это правило, в топку нестед луп!! =)

(32) [enable_nestloop=off]
Вы серьезно такие советы давать? Чтобы у автора все колом встало? Вы же понимаете, что это использование по сути всех индексов может отключить, когда у вас join маленькой временной таблицы с большой будет по всей большой таблице ВСЕГДА бегать.

У PostgreSQL есть проблема с отсутствием JPPD (проталкиванием условий внутрь подзапросов):
https://habr.com/ru/company/lsfusion/blog/463095/#commjppd
Но рекомендации 1С не join'ить с подзапросами вообще и они им следуют.

И вторая да, то что вы написали, что в PostgreSQL нет адаптивной оптимизации и при этом он жуткий оптимист (там реально есть константа, что если он не знает selectivity считает ее равной 0.3 и тупо перемножает ее если условий соединений много) :
https://habr.com/ru/company/lsfusion/blog/463095/#ao
Лечится только материализацией подзапросов во времянки. Но 1С как платформа этого делать не умеет, поэтому придется ручками оптимизировать (хотя в типовых они так и делают)

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

+(34) И кстати это одна из официальных рекомендаций от 1с..

(34) До 2013-2014 годов конфигурации бухгалтерии(БП, БГУ, особенно ранних редакций) только с отключенным nestloop и работали. Иначе - именно что колом.

На последней версии БГУ 1.0 опять ведомости ОС и НМА стали формироваться медленнее раз в 10(с enable_nestloop=on), чем на предшествующей. Версия PostgreSQL 9.6.7 от 1C и платформа 8.3.11.3034, работает с момента выхода версии платформы без нареканий. А на 11.5 и на 15-16-х платформах стало даже быстрее, причем ощутимо.
Сейчас в раздумьях, обновлять или нет...
(0) Версия БП какая?

"дисковая подсистема достаточно производительная" из (0) + "23,5 MB/c" из (17) = ржака

(35) Это как?
Вот идет SELECT FROM temptable JOIN sku ON temptable.id = sku.id;
Здесь можно и nested loop join по temptable и index scan по sku по индексу по id делать?
А можно hash и merger join 'ом но тогда придется по всем sku в любом случае пробежать. С такой опцией знаете что она сделает? Собственно навскидку nested loop join неизбежен только в LATERAL join'ах ЕМНИП.
(36) Ну такую рекомендацию можно давать либо если у вас база очень небольшая (и вся в память влазит), либо локально для отдельной операции. Целиком на базу ее включать это вилы будут.

Вот вам набор тест кейсов:
1) Установить разные версии посгри.
2) Поменять линкус, виртуалку, на виндус.
3) Поменять посгри на SQL экспресс, воспроизведется ли ошибка.
4) В файлом варианте как работает?
5) Поменять компьютер. Ошибка воспроизводится только на указанном сервере?

(40) Вы не в теме. По факту, база может полностью умещаться в память, но со включенным enable_nestloop дико тормозить по процессору, потому что быстродействие O(n*m), в отличие от например соединения слиянием, где О(n+m). Практика показывает, что с отключенным enable_nestloop база работает без зависаний, но в целом реактивность системы снижается. И каждый выбирает сам, что ему важнее.

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

Действительно тесты показывают удивительно маленькую скорость чтения/записи дисков. К сожалению доступа к гипервизору сейчас нет и посмотреть какие диски физически на нем установлены не могу. Так что для меня тоже вопрос, как были услышаны слова о том что нужно обратить внимание на скорость работы дисковой системы при выборе оборудования для настройки сервера. Хотя iotop при формировании отчетов какой-то запредельной нагрузки на диски не показывает. с этим вопросом будем разбираться.

(41) разные версии постгрес пробовал, разные версии платформы пробовал, на другом оборудовании проблем с базой нет ни в файловом режиме ни в клиент-серверном варианте. На этом оборудовании проблема наблюдается даже на демо-базе бухгалтерии 3.0. enable_nestloop=off тоже пробовал, результата не дало.

Пока основные подозрения на работу оборудования, частота процессора, скорость работы дисков и настройка виртуальной машины. Если есть предположения, что еще может быть причиной такой работы базы, буду рад проверить.

(46) может в конфиге pg conf что наворочено?

Может не телепатить,а вернуть оборудование где нет проблем

(47) и на стандартном конфиге все работать должно

(47) Проверял работу на другом сервере, не виртуальном, с теми же настройками pgconf, проблема не воспроизводится. Но там операционные системы не идентичны проблемному серверу и сервер 1С и Postgres разнесены.

(46) очередь дисков и померить iops, это прям до основных подозрений

(50) в Centos можно посмотреть текущий профиль производительность
tuned-adm list

и воткнуть максимальный

tuned-adm profile throughput-performance

Но имхо это виртуальная среда виновник

(45) ну тогда перебросить задачу Админам. При смене физического компьютера ошибка не воспроизводится. 1С работает корректно, проблема на стороне админов.

(42) Я с PostgreSQL очень много времени работал и работаю. Вы по ссылке заходили там все разжевано? Да O(nm) - это самая жесткая ошибка, но отключив enable_nested loop вы фактически всегда O(n+m) получите, в том числе там где было O(n * logm) где m очень большое (это использование индекса в nested loop). То есть на таблицах с 100к записей вместо 10мс, условную секунду. А если запросов будет много все заклинит.
(43) Онлайн статистика для временных таблиц это не критичная штука, так как отлично ANALYZE'ом после ее заполнения решалась.

(54) "Онлайн статистика для временных таблиц это не критичная штука, так как отлично ANALYZE'ом после ее заполнения решалась."
Вот только 1с не делает анализе при выполнении пакетных запросов с временными таблицами)

(55) Ок не критичная не для 1с :) Хотя емнип они это как раз патчили в постгрес.

Попросил админа покрутить настройки виртуальной машины. Ситуация со скоростью дисков исправлена, но отчеты все равно не формируются. Через оснастку администрирования сервера 1С заметил странную вещь, если в базе просто открывать проводить документы, то рабочий процесс сервера стабильно работает, если запустить формирование отчета рабочие процессы начинают отключаться и создаваться вновь, что видно по меняющемуся значению PID, при этом настройки кластера и рабочего сервера в оснастке выставлены по умолчанию, сервер 1C Предприятие 64 разрядный и память, судя по htop, на Centos особо не нагружена.

При этом в лог 1С сыпятся такие ошибки:
%
.30:52.856000-0,SYSTEM,3,process=rphost,p:processName=test,t:clientID=4,t:applicationName=1CV8C,t:computerName=Rahat-PC,t:connectID=24,SessionID=1,Usr=АбрамовГС (директор),AppID=1CV8C,level=ERROR,component=backend,class=ContainerAssembly
ChildAccess,line=105,file=./src/MetadataChildAccess.cpp,threadId=140426457655040,func=getMDChildCount,childClassID=274bf899-db0e-4df6-8ab5-67bf6371ec0b,Context='Форма.Вызов : Отчет.ОборотноСальдоваяВедомость.Форма.ФормаОтчета.Модуль.Сфор
мироватьОтчетНаСервере
Отчет.ОборотноСальдоваяВедомость.Форма.ФормаОтчета.Форма : 884 : ИнициализацияКомпоновщикаНастроек();
        Отчет.ОборотноСальдоваяВедомость.Форма.ФормаОтчета.Форма : 1302 : БухгалтерскиеОтчетыВызовСервера.ИнициализацияКомпоновщикаНастроек(ЭтаФорма, Истина);
                ОбщийМодуль.БухгалтерскиеОтчетыВызовСервера.Модуль : 36 : Форма.Отчет.КомпоновщикНастроек.Инициализировать(Новый ИсточникДоступныхНастроекКомпоновкиДанных(Форма.СхемаКомпоновкиДанных));'
Вот чего ему не хватает?

(58) Была такая шляпа один раз при добавлении доп базы к кластетру,сыпаться начали вообще все, убрал её и подцепил на выходных, подцепилась без проблем.
Не читал всю тему, но попробуйте все ядра которые идут на виртуалку перевести в режим всегда максимальной тактовой частоты, нам это сильно ускорило работы системы, тоже сервер на виртуалке.

(59) Админ сказал, что выставил этой виртульной машине максимальный приоритет. Может, кто-то знает, может ли такое поведение быть связано с тем, что частота процессора сервера всего 2ГГц? В руководсве от 1С в разделе аппаратные требования к серверу кластера указано, что для сервера X32 процессор не ниже Pentium/Xeon 2,4 ГГц, а для сервера X64 такого указания нет, просто: Процессор с архитектурой x86-64 (Intel с поддержкой Intel 64, AMD с поддержкой AMD64).

(57)[при этом настройки кластера и рабочего сервера в оснастке выставлены по умолчанию]
это не меняет очевидного факта перезапуска rphost по объёму занятой памяти

(60)[может ли такое поведение быть связано с тем, что частота процессора сервера всего 2ГГц] нет

Покажите, пожалуйста, atop при формировании долгого отчета.

(61) До перезапуска процесса он потребляет совсем немного памяти, т.е. объем памяти, который процесс потребляет при входе в базу, при загрузке базы из dt, при проведении документа, может быть выше, и при этом процесс не перезапускается.Сервер 1С x64, в настройках кластера ограничения на размер памяти для рабочих процессов не выставлены, памяти на сервере досточно, какими еще настройками по памяти может вызываться завершение rphost? Подскажите, я проверю.

(63) Сейчас нет к сожалению возможности запустить формирование отчета. Проблема наблюдается вообще при формировании всех отчетов, например, ОСВ за день. При запуске htop показывает нагрузку на ядро со стороны процесса сервера 1С до 100%, потом загрузка падает, затем начинает грузиться следующее ядро, и т.д., после удаления сеанса с сервера, нагрузка на процессор падает.

Взял компьютер, установил на нем такую же ОС, как и на виртуальной машине, CentOS 7.7, установил postgres и сервер 1С, на выходе получил ту же самую ошибку. Все снес, установил 18.04.3 LTS установил те же самые версии postgres и сервера 1С, ошибки нет, все отчеты формируются.

* Ubuntu Server 18.04.3 LTS

(66) CentOS 7.7 после установки обновлялся, yum update? С момента выхода 1908 ядро несколько раз уже обновлялось и еще куча всего. В /var/log/messages на предмет segmetation fault что-нибудь пишется, когда новые рабочие процессы создаются?
У нас на 1908 и бухгалтерия и зарплата, ничего не тормозит и не виснет.