Приветствую!

Коллеги, есть у моего заказчика проблема, которую подрядчики, занимающиеся 1С, пытаются решить "в лоб". Но, возможно, есть какие-то ещё варианты?

Дано:
Терминальный сервер на винде с толстыми клиентами
Linux c сервером 1С 8.3.13.1644 и postgresql 10.7.1 от postgres pro
Конфигурация КА2 2.4.8.84

В целом всё работает нормально, но у бухгалтера какие-то безумные проблемы. Проведение одного регламентного документа может занимать несколько минут (от 3 до 8!!!). Я не 1сник, я занимаюсь основной инфраструктурой, но так как спецы ничего сказать не могут, приходится пытаться решить проблему самостоятельно. Все возможные оптимизации уже сделаны, конфиг постгреса я изнасиловал уже всеми знакомыми и незнакомыми способами. Памяти навалом - раз в 5 больше, чем размер базы. В момент зависаний видно, что одно ядро полностью загружено процессом postgres, pg_top тоже показывает, что висит на UPDATE'ах и INSERT'ах (в основном на UPDATE).

Я грешил на скорость работы дисковой подсистемы, но на машине с точно такими же характеристиками (даже слабее - меньше памяти) на MS SQL всё работает вполне себе нормально. То, что характеристики одинаковы - 100%, это виртуальные машины, одна останавливается, другая запускается, хранилище образов дисков одно. Но MS SQL - это куча денег, которые клиент платить не хочет, а я не готов участвовать в использовании нелегального ПО. Да и вообще, что это за решение проблемы - потратьте кучу денег?

С заказчиком расставаться не хочется. Поэтому хочется решить проблему адекватным способом. Я знаю, что 1С:Fresh использует postgres, что Кнопка использует postgres, давно и успешно.

В какую стороную мне копать, подскажите, пожалуйста?

(125) после перепроведения итогов - нет. Из командной строки дольше.

(119) Попробуй http://catalog.mista.ru/public/978816/
Работает с сервером приложений 1С и PostgreSQL на Linux. Клиент 1С должен быть на Windows.

Вот это, я понимаю, триллер! Извините за оффтоп. Сами планируем переход с упп на ка. Сейчас более-менее сносно (я бы сказал, чуть менее, чем терпимо) работает на постгре 300+ юзверей.

(129) я не знаю, что это за регистр, к сожалению. у меня есть только название таблицы. Я понимаю, что это какой-то аналитический счёт, но и только. Как понять, к чему и где его найти в 1С - не знаю, извините.

(135) Вам либо сюда - (133), либо в 1С в консоли запросов написать запрос с выбором даты, как в (121).

Автор как успехи?

(122) у него постгри и там никаких сдвигов нет! Сдается мне там с границей пипец!

+ (138) а, не, это-ж актуальные итоги!

(139) да, сама именно эта строчка с датой - это актуальные итоги так вводятся

(127) Дай вывод строки
select _period, count(*) from _accrgat261025 group by _period

Автор вот кстати интересная статья: http://catalog.mista.ru/public/177171/ и не менее интересные комментарии 58 и 128

Коллеги, прошу прощения, вчера пришлось срочно переключиться на другие задачи.

(141)
test_ka2=# select _period, count(*) from _accrgat261025 group by _period;
       _period       | count
---------------------+-------
2019-07-01 00:00:00 |  7766
2019-04-01 00:00:00 |  7782
3999-11-01 00:00:00 |  7239
2018-12-01 00:00:00 |  5629
2019-03-01 00:00:00 |  7488
2019-05-01 00:00:00 |  7875
2019-06-01 00:00:00 |  7936
2019-02-01 00:00:00 |  7316
2019-01-01 00:00:00 |  7124
(9 строк)

Меня сильно смущает, что операция по обновлению записи в таблице с 66 тысячами строк выполняется больше секунды. И таких операций масса.

Мне пришлось сделать ещё одну копию базы, потому что я экспериментировал с документом в уже закрытом периоде, поэтому сейчас восстановлю её и замерю производительность в MS SQL и в PostgreSQL на то же базе на одном документе.

На новой базе сразу после восстановления и vacuum full analyze и reindex документ проводится 9,5 секунды. На той же самой базе в MS SQL - 0,956 секунды. Разница в 10 раз.
Сейчас доеду до другого места - продолжу.

(145) Это сейчас сами сервера 1С одинаковые? Эти две СУБД подцеплены к одному и тому же серверу или это разные сервера 1С в разных ОС ?

(145) Как я вижу ситуацию:
1.В таблице accrgat261025 накопились записи с нулевыми значениями, чем это черевато можно прочитать в этой статье: http://catalog.mista.ru/public/177171/ что делать озвучено в комментарии 128 к этой статье.
2.Посе того как записи с нулевыми значениями были удалены (Тестирование и исправление - Пересчет итогов) и обновления статистики vacuum full analyze стало лучше но
3.Запросы из 1с postgres выполняет по неоптимальному плану, при наличии записей с нулевыми значениями разница запроса из 1с и запроса из консоли доходила до 1000 раз(миллисекунды и секунды)
4.Возможные решения: переписать код запроса, обновить конфигурацию(возможно в обновлении код запроса исправлен)
или играться с параметрами postgresa отвечающие за план запроса

Поправьте меня если я не прав.

как бы есть мысль, что было бы неплохо проверить еще влияние параметра "Количество ИБ на процесс"
У меня такое подозрение складывается, что производительность именно в постгри очень сильно от него зависит.
В этой ветке эту особенность настройки еще не проверяли

(146) до этого были разные сервера 1С. Сейчас подцепил пострес на linux к тому же серверу 1С, через который подключен ms sql - абсолютно такой же результат, как и с линукса, 9.5 секунд.

Сейчас запущу перепроведение итогов на вновь загруженной базе. Посмотрю результат после этого.

Щас почитал про Postgree.
В нем нет профайлера в понимании SQL
Ты должен, как последний раб на галерах, собрать лог файл, найти в нем запрос и запустить его через EXPLAIN.
Выкиньте эту херню.

(148) количество информационных баз на процесс по-умолчанию - 8. Соединений - 128. Но я сейчас вообще один на этом сервере 1с.

(151) это ты один, а базы крутятся в регламентных заданиях и их там у тебя уже не одна.
Переключи ради интереса. Это же не долго. Даже перезагрузка не потребуется, чтоб увидеть будет ли эффект.

(152) переключить на сколько? одна база - один процесс?

База сейчас на сервере одна, по сути, одна. Вернее, в постгресе одна, на сервере больше.

Меня сильно смущает то, что такая производительность при работе с базой, которая находится на диске в памяти. В новой базе в указанном справочнике 270 тысяч строк. Посмотрим, сколько останется после пересчёта итогов.

(147) Да, сейчас пересчитаю итоги и попробую разобраться с нулевыми значениями. Но неужели настолько неэффективнее postgres получается? Ведь на той же самой базе, прямо один в один, скорость в ms sql выше в десять раз на конкретной операции проведения одного и того же документа. При этом в ms sql база на хранилище, а не в памяти.

(153) тебя принципиально ломает установить хотя бы для тестирования 1 база на процесс?

(155) сам постгресс эффективен в той же степени, как и сиквел.

// Я знаю, что 1С:Fresh использует postgres, что Кнопка использует postgres, давно и успешно.
Это же твои слова :-)

В данном конкретном случае у тебя в базу вкачали переносами или чем-то подобным всякую бяку. Ну и запросы вероятно попадаются кривоватые, т.к. 1С-конфигурация в базе программистами изменена.

Кстати, если сейчас сработает эффект от Количества ИБ на процесс, то этот баг будет уже не в СУБД (у нас же в этом примере сейчас всего одна ИБ в наличии), а в платформе по сути.

(156) не-не, я поставил. Я уже хватаюсь за любые предположения. Только это не изменило ничего.

(157) Так одинаковые данные в ms sql и в постгрес.

Занимательная статистика: до пересчёта в таблице была 227451 строка, стало 65785 строк. Сейчас закончится вакуум и реиндексация после пересчёта (для чистоты эксперимента) - запущу ещё раз оценку производительности.

Перепроведение итогов уменьшило время проведения документа до 4.38 секунды, вдвое.

Сейчас буду разбираться с нулевыми значениями.

Автор, попробуй еще это:

plantuner
plantuner.fix_empty_table = 'on'
Исправляет чрезмерную пессимистичность оптимизатора посгтреса на пустых, недавно созданных таблицах.

online_analyze
online_analyze.table_type = 'temporary'
Автоматически анализировать временные таблицы при их изменении. Фоновый analyze может заметно отставать, и, как результат, планер ошибается.
online_analyze.verbose = 'off'
Отключение излишней болтливости автоматического analyze.

(161) Отсюда https://github.com/postgrespro

(161) это всё сделано, разве что стоит online_analyze.table_type = 'all', а не только на временные.

(161) любопытно. переключение онлайн-анализатора _только_ на временные таблицы уменьшило время проведения документа до 1 - 1.4 секунд (несколько раз проверил, даже не завершая сессию менял значение и перезапускал постргес). Причём вариант анализировать все таблицы я не сам придумал, а где-то вычитал, типа, у Гилёва, если мне память не изменяет.

Вот как бы теперь сделать, чтобы время было 1 секунда, а не 1.4 - и будет практически ms sql. Правда, неизвестно, что там будет со скоростью, если и на нём итоги пересчитать. И неизвестно, как через какое-то время после пересчёта итогов будет развиваться ситуация.

(164) Скинь конфиг я посмотрю.

(164) вообще это спорный рецепт к использованию онлайн-анализа на абсолютно все таблицы, как минимум
Например :

- делаем один запрос (а ведь до него были уже изменения в данных - стартует анализ - а ведь это ест время и подвешивает старт основного запроса)

- по итогам обработки результатов запроса вносим измененные данные

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

В стратегии работы с СУБД получается, что в online_analyze.table_type = 'all' может натолкнуться на спорное прикладное решение, которое использует итерации или циклы или рекурсивные обращения данным с их перезаписью.

Было бы забавно выяснить, откуда ноги растут у этого тестового примера, кто писал процедуру проведения документа.

(165) в (18) есть ьтло что он называет конфигом... я хз, там за 600 строк и многие параметры встречаются многократно с разными значениями, например max_connections=50 и max_connections=100

(167) но с тех пор многое поменялось

(164) Отключи online-analyze совсем, заодно и fsync и full_page_writes. Посмотри, что изменится. Возгласы о том, что "целостность базы данных в опасности!" к твоему(тестовому) случаю не имеют отношения. Ничего там не сломается.
Также(об этом уже здесь писали) обновиться до всего самого последнего, может, оптимизировали  или сам запрос или его трансляцию. Вчера еще одно обновление вышло PostgreSQl, версия 10.8-18.1С, там все свои патчи правят.

В очередной раз убеждаюсь, что выбор постгреса как субд для 1с был неудачным, ввиду плохой детерминированности поведения при разборе сложных запросов с подзапросами и временными таблицами, которые так характерны для 1с. Лучше бы они поддержку ib/fb сделали.

(170) А что, иб/фб лучше?

(170) // Лучше бы они поддержку ib/fb сделали.

Чтоб нырнули с головой?

Ты хоть на концептуальные отличия в этих СУБД обращал внимание?
Подсказываю: почему ни одна из известных СУБД не может охватить весь рынок целиком?

з.ы. Я вижу, что постепенно подходят к полному обособлению или поднятию уровня собственного решения до полноценной СУБД в виде сейчас пока еще "файловой версии".

(170) зацени вот эту хрень
Один нумератр для документов и справочников

Что с этим будет делать СУБД, с какой скорость обрабатывать?

(169) ээээ, как обновить трансляцию если у постгри кэш запроса существует только иногда и только в пределах одного сеанса, разве не так? Если так - каждый раз план запроса пилится заново.

(174) Да, так. Но в плане оптимизации трансляции кое-что делается - https://dl03.1c.ru/content/Platform/8_3_15_1565/1cv8upd_8_3_15_1565.htm#83bf2cb5-14ce-11e9-a3f7-0050569f678a
Так и пишут(например):
"Оптимизировано исполнение запроса, содержащего константные значения в списке выборки. Константные значения, находящиеся в теле запроса, реализуются параметрами запроса. Это приводит к уменьшению количества перекомпиляций планов в СУБД, и как следствие, увеличению производительности таких же запросов, если они отличались только значением константы."
Или "Оптимизировано использование регистра бухгалтерии при работе с использованием СУБД PostgreSQL"
Хотя, для теста(Гилева) в режиме совместимости пока все наоборот, "оптимизация" приводит к видимому уменьшению результата, процентов на 15. Может в самом тесте уже что-то надо подправить, а то он с момента выхода 8.3 и не менялся совсем. Так сказать, реалий времени уже не учитывает.
А использования в 1С кэша запросов PostgreSQL, конечно, не хватает.

(175) В режиме осутствия совместимости с более ранними версиями.

(167) это конфиг после экспериментов. так как меня в конце концов задолбало править в тексте, я их вынес в конец. Используются, естественно, только последние значения.

(165) спасибо, сейчас приведу к более читаемому виду и выложу.

(165) Полный конфиг: https://pastebin.com/YaZ6msEd
Только раскоментированные\изменённые значения: https://pastebin.com/Y4DUcBZ5

(169) Базу я размещал и на диске в памяти, и на хранилище, разницы в скорости нет ни малейшей. Т.е. это явно не ввод\вывод оказывает влияние. А софт я уже обновил: 1c 8.3.15.1565 и PG PRO 1C 11.5

(175) делается... вот у постгрипро - делается! Слышал есть там модулёк, который помогает хорошо так оптимизировать план... настолько что это даёт выигрыш в скорости на единицы и десятки % (скорее всего сверх того и ресурсов расхищает куда как меньше).

(178) >1c 8.3.15.1565 и PG PRO 1C 11.5
жёстко! Хорошо хоть не эксперементальные версии.

Для оценки конфига необходимо так-же знать что за диски (хдд/ссд, вот только не надо рамы!!!), сколько памяти всего и сколько их них доступно всегда под постгри.
Надеюсь никаких выкрутасов по безопасности ведь нет? В смысле pg_ident - пустой, pg_hba из 2 строк (остальные закомментированы):
host    all             all             0.0.0.0/0            md5
host    all             all             ::1/128                 md5

(179) Ты это имеешь ввиду Adaptive query optimization for PostgreSQL: https://github.com/postgrespro/aqo ?

(181) ага, именно про эго.

или эко или эйко  - запутали меня эти сакасы

(180) Памяти всего на машине 32ГБ этой останется, но там ещё сервер 1С живёт. По хранилищу лучше расчитывать на производительность в 2000-3000 iops'ов. Т.е. это не локальный SSD, конечно, но прилично быстрее HDD.
По безопасности выкрутасов нет.

(180) тс выше пояснял, что у него виртуальные машины.

(179) Он(модуль) еще и продается, в составе Postgres Pro Enterprise, за приличные деньги. Портировать в бесплатную версию, скорее всего, никто не собирается.
А так, там столько всего, что глаза разбегаются https://postgrespro.ru/docs/enterprise/11/intro-pgpro-vs-pg
А профайлера нет... Такого, чтобы помимо плана запроса, предлагал бы еще пути его оптимизации, а лучше, чтобы оптимизация давалась сразу в терминах 1С. Далеко еще до такого, наверное.

(186) >Такого, чтобы помимо плана запроса, предлагал бы еще пути его оптимизации, а лучше, чтобы оптимизация давалась сразу в терминах 1С.

Было расширение hypoindex или что-то типа того, Лустин про него несколько лет назад упоминал. Вполне себе норм идея строить индексы на основании статистики запросов и тех индексов что не хватает при выполнении их. Но что-то проект вроде помер.

(185) вот дерьмо-то! Ненавижу виртуалки под сервера СУБД и 1С, ну кроме сервера лицензирования!

(0) >>> что это за решение проблемы - потратьте кучу денег?

Если вы методом тыка пришли к выводу, что SQL работает быстрее, то думайте сами, стоят ли оно этих денег... :)

(186) этот модуль можно самостоятельно бесплатно скомпилировать. Но его же учить нужно. Можно, конечно, скрипт написать. Ну, и вопрос в том, какие запросы 1С отправляет нормализованными (параметризованными). Так как оптимальный план запроса сохраняется по хэшу запроса, это становится критичным.

Но, вообще, любопытно попробовать из интереса.

(189) в результате-то не работает _настолько_ быстрее. Просто нужно было потратить время на то, чтобы разобраться. Люди, которые за это деньги получают, разбираться не стали (похоже, просто не умеют), а предложили потратить ещё больше денег на лицензии или их просто украсть. По мне - крайне неэффективный подход. В результате пришлось заниматься проблемой мне, хотя я именно к 1С имею весьма далёкое отношение. Но в результате всех этих телодвижений время проведения конкретного типа документов (даже конкретного документа) сократилось в 6-8 раз.

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

(191) Ты будешь улыбаться, но 1С-ники тоже к Посгрессу не имеют отношения :)

+ Это как если бы Админа попросили установить Линух и настроить... А до этого он только Форточками занимался. :)

Я тут этой веткой вдохновился и полез на ютуб. Однако, нашел кое-что - весьма красиво подводящее резюме под эту ветку.
очень-очень рекомендую

https://www.youtube.com/watch?v=lbpRjUwHSn8


INFOSTART.RU
Опубликовано: 17 дек. 2018 г.

PostgreSQL не так давно появился на российском рынке, поэтому у многих специалистов появляются сомнения, насколько удобно с ним работать, учитывая специфику 1С. Антон Дорошкевич, руководитель IT-отдела и направления оптимизации 1С компании «ИнфоСофт» (г. Новосибирск), рассказал о своем опыте применения этой СУБД. Тема его доклада звучала провокационно: «1С-батл между MS SQL 2016 и PostgreSQL версии 9 и версии 10».

Обсуждение и текстовый вариант доклада: http://catalog.mista.ru/public/962876/

Если конкретно по тому параметру, который сильнее всего себя проявил - это после 20-ой минуты примерно

Конкретно вот по этому моменту

(164)
// любопытно. переключение онлайн-анализатора _только_ на временные таблицы уменьшило время проведения документа до 1 - 1.4 секунд

вот копипаста из статьи по ссылке в (194)
---
Ради интереса отключили OnlineAnalyze. Получили результат тестирования в 17 раз хуже. Мы прождали несколько дней, она у нас все-таки посчитала, результаты упали в 17 раз.

К сожалению, в своей практике сталкиваюсь очень часто и даже на очень крупных предприятиях, на которых есть Postgres и которые уже поискали ответы в интернете на запрос «1С + Postgres тормозит», что люди следуют этим 2 вредным рекомендациям. А тем временем в самом конце конфигурационного файла есть строчка OnlineAnalyze.enable = off. Но если поправим настройку на on, все взлетает.

Я вас призываю, если у вас уже стоит Postgres, посмотрите свои конфигурационные файлы. И включите патч, включите! Это очень крутая вещь.

И еще один момент. В последней сборке Postgres, опубликованной на сайте 1С, к сожалению, этого патча нет. Его просто нет в строчке предкомпилированных библиотек, он в настройках есть и даже внизу включен, но его нет в строчках предкомпилируемых библиотек. Надо добавить. Внимательно отнеситесь: патч должен быть, патч должен быть включен. И будет резкий рост производительности.
---

(196) Весело обстоят дела)

(192) так проблема не в настройках Postgres'а в вакууме, а в связке 1С - Postgres. Если бы дело было только в PG, всё бы давно уже решилось. Но тонкие места именно с точки зрения 1С могут знать только люди, с 1С работающие. Элементарно та же активная работа с временными таблицами - уже особенность.

(194) Отличное выступление, спасибо, очень любопытно.

(198) ну с PG работают 0 целых 0 десятых 1с-ников. Поэтому подавляющее большинство 1с-ников к посгресу отношения не имеют.

(198) Это называется dba

(199) И очень жаль что 0 целых 0 десятых, скилловый разработчик обязан разбираться в postgresе, и не важно на чем он пишет java, python или 1с.

Автор после всех манипуляций какие итоги? с 3 минут до полутора секунд, я правильно понимаю?

(199) Ты живешь в другой Вселенной.

(202) не совсем так. У меня нет возможности проверить на том же документе, что и раньше, поскольку он в закрытом периоде.

Но я выбрал другой документ, чтобы сравнить производительность с MS SQL. Изначально сразу после загрузки текущей базы проведение этого документа занимало 9.5 секунд. На MS SQL - 0,956 секунды. После перепроведения итогов время уменьшилось до 4.38 секунд. А после манипуляций с конфигом (насколько я понимаю, из-за переключения online_analyze с 'all' на 'tmp') стало 1 секунду (это я прямо сейчас перепроверил).

(0) не буду еще раз это все объяснять, ставь MS SQL + 64 server. или ...

проверено тестами хуестами и прочими сравнениями, линукс и постгре говнина ...

(204) Было бы интересно выяснить деградацию постгресса при росте нулевых записей в таблице итогов с параметром online_analyze 'tmp', нет возможности развернуть бэкап где еще не было перепроведения итогов и замерить время проведения?

(207) есть, сейчас сделаю.

(206) Ты понимаешь что с такими выражениями: "тестами хуестами, линукс и постгре говнина.." ты на рано или поздно никому не нужный на бирже труда окажешься?

(207) а вот сейчас я в большом недоумении.

Сразу после загрузки данных время проведения документа - 1.1 секунды. Я даже залез проверить, сколько строк в справочнике - мало ли, куда-то не туда базу загрузил.

После vacuum full analyze время _увеличилось_ до 1.28-1.3 секунд.

После перепроведения итогов время проведения документа - 0.92-0.95 секунд.

Я могу объяснить это только тем, что сменилась версия PG - в начале была 10.7, сейчас - 11.5.

Кстати, я вспомнил ещё одно изменение, которое сделал в конфиге - я уменьшил после видео выше default_statistics_target. Там говорили, что тормоза какие-то при больших значениях. Но возврат значения в 10000 скорость не изменил.

(210) Получается с online_analyze 'tmp' нет особой деградации при росте нулевых записей, интересно и непонятно!

(196) Для тех информационных систем, с которыми автор доклада имеет дело http://forum.infostart.ru/forum86/topic200178/message2053519/#message2053519
скорость устаревания статистики, видимо, очень большая. Поэтому, держать online analyze включенным(в том числе и для всех таблиц) в подобных случаях, скорее всего, полезно, при общем уменьшении скорости работы не позволит уйти полностью в ступор.
Впрочем, держать включенным для временных таблиц, уместно будет для любых баз и любой интенсивностью работы с ними, так как autovaccuum для временных таблиц статистику не обновляет.

(210) т.е. 4 мин + -> 1 сек?

(213) наверняка можно сказать, что время уменьшилось с 9.5 секунд до 0.92 секунды, это на текущей выгрузке из рабочей базы и на новом документе. Перепровести на новой базе тот документ, который проводился 417 секунд, я не могу, потому что он в закрытом периоде.

Восстановил старую базу данных из архива. Проведение документа, который раньше проводился 417 секунд, теперь и ДО, и ПОСЛЕ пересчёта итогов занимает 0.72-0.7 секунды. Я посмотрел по логам, запросы, которые выполнялись 5 с лишним секунд, сейчас выполняются 0.5-1 МИЛИсекунду. Я в замешательстве полном. Изменились версии 1С, PG. И обновилось ядро, но это не должно влиять.

(211) ну, вот получается, что нет. Уже несколько раз проверил - сейчас старую базу загрузил, до пересчёта итогов 218К строк, после - 66К. Время проведения абсолютно одинаковое, разница в пределах погрешности.

(214) > Я в замешательстве полном.
здесь может быть фактор "здравствуйте, я ваш виртуальный диск в облаке"

Диски бы потестить на иопсы и общую скорость чтения записи когда тормозило, но сейчас уже поздняк.

У меня такое было, что искал ведьм в настройках, а в итоге заменил один sata-кабель. Он хотел - работал нормально, хотел - отваливался, но не до конца. Но там были доказательства: в dmesg ругань на таймауты в железе.

(215) 417 секунд было на базе, которая лежала на ram-диске. Перенос базы с хранилища в память и обратно скорость не менял и не меняет вообще.

(216) на рам-диске виртуальной машины, ещё раз ВИРТУАЛЬНОЙ машины. На ней ни замеров сделать (замеры хоста - кусочек целого, а нужно целое) и понять куда что сейчас переносится/мигрирует (если конечно всё это удовольствие не заблокировано, ну или если машинка тривиальная но тогда совсем нет смысла в виртуальности).

(217) Контроль над облаком, где всё запущено, у меня полный. Я _знаю_, что там происходит. Под этот тест был выделен отдельный хост, на котором кроме данной задачи не выполнялось ничего. Т.е. я могу утверждать, что результаты были бы точно такими же, если бы всё запускалось в системе хоста, а не гостя. Вообще, это уже давно миф - о том, что _вычислительная_ часть работает как-то хуже, потому что давно не используется эмуляция, а полноценная аппаратная виртуализация. Да, какие-то накладные расходы есть, но это максимум проценты.

Что действительно работает медленнее - это виртуальное _локальное_ хранилище. Но в данном случае хранилище распределённое сетевое, ему всё равно, откуда его подключают - с аппаратной машины или из виртуалки, блочное IO всё равно по сети осуществляется.

Более того, я пробовал ставить сервер PG прямо на железо и локальный SSD, результаты не менялись даже на пару сотен милисекунд.

(218) ладно, ладно, уговорил.

расскажи хоть, на связке какой платформы и pg все летает теперь - все такую дружно будем ставить.

(219) Последние результаты - 1С 8.3.15.1565 и PG PRO 1C 11.5 (http://repo.postgrespro.ru/1c-archive/pg1c-11.5/) на Ubuntu 18.04.3 с ядром 5.0.0-25.

(220) > PG PRO 1C 11.5

я что то так и непонял с этим PG PRO 1C сейчас какая ситуация. Можно легально его использовать бесплатно?

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

По итогу: бухгалтерия с...ся от радости, vheathenу премию, одинэсников на мороз. А если серьезно то у меня проекты намечаются на КА2, MS SQL в бюджетах ну совсем не заложен, так что спасибо автору и ветке за прояснение ситуации.

(221) Похоже, что всё-таки нельзя:

Лицензия Postgres Pro Standard
Portions Copyright (c) 2015-2019, Postgres Professional
Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
Portions Copyright (c) 1994 Regents of the University of California

Предоставляются права на использование, копирование, изменение и распространение данного программного обеспечения и его документации для целей тестирования, разработки ПО, ознакомления с функциональностью СУБД,  использования в образовательном процессе бесплатно и без подписания какого-либо соглашения, при условии что для каждой копии будут предоставлены данное выше замечание об авторских правах, текущий абзац и четыре следующих абзаца. Использование в других целях, встраивание в другие продукты, тиражирование и прочие действия требуют приобретения отдельной лицензии.

===

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

Т.е. если не для тестирования, разработки и ознакомления с функциональностью и не в образовательном процессе, то нужна лицензия.

(216) я забыл одну важную детальку: если размер RAM-диска + объем, занятый процесами + текущий fs_cache  превышает размер оперативки, то все это дружно падает в своп в случайном порядке.

После запуска 1С объем fs_cache примерно равен объему базы на диске. Предположим, у тебя база 10G, тогда на диске занято 10G + fs_cache только под postgres еще 10G, а еще процессам где-то надо жить (в т.ч. тот же postgres).

В какой-то момент достигается точка, когда для того, чтобы прочитать с диска, надо сначала рабочую область процесса отправить в своп, потом чтобы процесс воспользовался информацией - диск в своп, процесс из свопа поднимаем, и такой cluster fuck по кругу.

Я первичную оценку текущей ситуации всегда делаю с помощью htop - в цветном виде лучше воспринимается, и видно на барах сколько fs_cache, а сколько настоящего.

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

(226) для виртуалок кстати здравое решение своп не выделять, поддерживаю
не хватает оперативки - нажми кнопку и увеличь

(222) раньше сборка для 1С бесплатна была доступна. Сейчас, выходит, что нет.

(220) на эту ссылку как вышел ?
http://repo.postgrespro.ru/1c-archive/pg1c-11.5/

(228) У них раньше этот репозиторий был доступен "бесплатно, без регистрации и смс" (с) прямо из Загрузок на сайте, из мастера выбора версии\ОС.

У меня был pg1c-10.5 прописан, я решил ради интереса посмотреть, что уровнем выше, нашёл более свежие сборки.

(224) годик назад их было 4, причём 2 бесплатных, один из которых вполне работал с 1С... видимо внутренняя конкуренция сборок убила его

(230) я не заглядывал раньше в лицензию, к сожалению, не знаю, что было сказано. Знаю об этих сборках давно, но что-то ленился посмотреть лицензию.

По сути, сейчас 5 вариантов: Pro Standard 1C (который собирается, но ссылки на него выпилены везде, похоже), Pro Standard, Enterprise и два последних варианта с сертификацией.