если вы не планируете увольняться из-за того что бэкап pg не поднимется, то сидеть до упора на MS SQL Server из-за нормальных бэкапов, и лучше переходить последним если в будущем когда то совсем без вариантов будет, только dt периодически тоже выгружайте
видел не раз как люди метнулись на pg, и потом вернулись на ms sql server
тем кто утверждает что там всё замечательно просто махайте рукой, мол всего вам доброго, хорошего настроения и здоровья
не буду ходить по кругу и повторять про некорректность но будучи ИТ-директором описываемой вами компании бы как минимум дал задачу провести тестирование работоспособности того что предполагается к тестированию и выяснил что ваш релиз платформы 8.3.20.1838 плохо пригоден именно для связки с PG, так как только в релизе 8.3.21.1508 исправлена ошибка 60001790 (отсутствие подходящего индекса в итогах между счетами регистра бухгалетрии) , связанная с отсутствием подходящего индекса для внутриплатформенного метода апдейта данных, приводящей к таким проблемам как долгое «закрытие месяца» (упоминаемое вами) , что для промышленного предприятия, которое вы приводите в качестве портрета крайне чревато последствиями поскольку вы приводите в пример реальную практику, то у меня теперь ещё больше вопросов
хотелось бы увидеть адекватное зрелое тестирование, а не давайте потестим что тут нагуглили сходу...
вы берете разные железки у разных провайдеров, с разной средой виртуализации, не сравнивая бюджет и пытаетесь получить какие то технические тесты в качестве сравнения
это не корректно
вы либо возьмите что можно арендовать за один и теже деньги у разных провайдеров
либо тестируйте одно и то же железо у разных провайдеров, и желательно с одинаковыми гипервизорами
либо четко скажите, что выбираете наилучшее технические предложения от каждого провайдера
либо другой четкий критерий
а сейчас вы теплое с мягким сравниваете и максируете это в том числе моим тестом
большая часть 62хх голдов в диапазоне 2.5-3.5 тысяч долларов стоят для вас это новость? про какие абстрации вы тут разгоняете волну?
при чем у мтс автор статьи берет Intel Xeon Gold 6248R CPU @ 3.00GHzSSD, а у селектела Gold 6240R CPU @ 2.40GHz - для меня это выглядит если не странным, то точно не корректным сравнением, тем более у селектела есть более подходящие для 1с модели процессоров (если автор хочет ориентироваться на наилучшие предложения провайдера)
и главное, нахрена вы втихаря минус ставите, аргументировать не можете?
судя по описанию она должна хуже работать чем postgres pro ent там фактически ванильный pg плюс патчи 1с, по идее будет на уровне сборки pg с сайта 1с, но при этом ещё и денег захотят
поверю в преимущества когда тантор хотя бы покажет внятный бэкапер с мониторингом RPO/RTO без убогой командной строки, целостности бэкапов, контролем места под бэкапы и потерей не более 30 секунд на одном экземпляре без установки кучи "левых" пакетов c наглядным восстановлением на новом железе, а не переупаковку старых продуктов в новую обертку
активность снаружи в windows можно посмотреть через процесс монитор марка русновича
раз вы говорите что статистика временных таблиц много съедает, то
1. давайте поставим 8.3.12, там платформа этого еще делать не умела вот и выясним верность гипотезы а со стороны субд уменьшим количество выборки за проход
ALTER SYSTEM SET default_statistics_target TO 20;
2. -- в отличии от скуля мы можем сказать оптимизатору запросов, что процессор дорогой ALTER SYSTEM SET cpu_operator_cost TO 0.0001; --а диски дешевые чтобы попробовать сместить планы запросов ALTER SYSTEM SET seq_page_cost TO 0.1; ALTER SYSTEM SET random_page_cost TO 0.4;
3. --отключим синхронность записи ALTER SYSTEM SET bgwriter_delay TO 200;
ALTER SYSTEM SET synchronous_commit TO off;
ALTER SYSTEM SET full_page_writes TO off;
ALTER SYSTEM SET fsync TO off;
ALTER SYSTEM SET checkpoint_segments TO 200; ALTER SYSTEM SET checkpoint_timeout TO 1800;
ALTER SYSTEM SET autovacuum_naptime TO 200;
ALTER SYSTEM SET commit_delay TO 10000; --увеличим размер лога ALTER SYSTEM SET max_wal_size TO '1024 MB'; --уберем лишние модули ALTER SYSTEM SET shared_preload_libraries TO 'plantuner';
не увидел без подсказки закладки снизу но лишь утвердился в причинах, ну так то и на скуле можно параллелизм задрать вообщем идея лишний параллелизм выключить исключительно для оценки влияния на общую утилизацию процессоров то что рекомендованно 1с должно быть прежде всего осмысленно ПОЧЕМУ в данном случае online_analyze.enable = on включает СИНХРОННУЮ статистику может она в данном конкретном случае и не сыграет роли, но она удлиняет транзакции, помоему проще проверить, чем спорить еще для третьте волны экспериментов ALTER SYSTEM SET geqo_threshold TO 8; ALTER SYSTEM SET join_collapse_limit TO 8; на сложных запросах раньше будут будет срабатывать более быстрая генерация плана запроса, но менее точная на запросах меньшим числом таблиц это не скажется ни как при чем играться тут можно в обе стороны, дефолтовое 12
а у вас случаем многопоточная обработка запросов не включена, а то если да то выключите ALTER SYSTEM SET max_parallel_workers_per_gather TO 1; ALTER SYSTEM SET max_parallel_workers TO 1; ALTER SYSTEM SET max_parallel_maintenance_workers TO 1; ALTER SYSTEM SET autovacuum_max_workers TO 2;
ALTER SYSTEM SET ssl TO off;
ALTER SYSTEM SET online_analyze.enable TO off; SELECT pg_reload_conf();
а если не поможет то ALTER SYSTEM SET cpu_operator_cost TO 0.0001; -- поднять стоимость процессорного ресурса
видимо мы по-разному понимаем подход к работе вы за процесс, я за результат забор интенсивных логов по локалке точно также может помешать работе пользователей нормальным людям манипуляции с метриками на дополнительном сервере ради разовых вещей по поиску узких мест не нужна, это еще ради этого сервер покупать, а сейчас и сервер не купить! или у вас значения счетчиков загруженности оборудования и текстов запросов стали чем представляющим ценность для "врагов"... зачем же вы глупости такие пишите
" Я не смог найти информацию на вашем сайте о том, как установить серверную часть вашего комплекса в локальном окружении. " Опять манипуляции. Так у нас и не написано как делать не надо. Метрики обсчитываются в облаке. Чтобы отправить их туда ЛОКАЛЬНО ставится база 1С-клиент с открытым кодом. http://www.gilev.ru/setupquerytj/ инструкция есть. Смысл нагружать боевые сервера сторонней нагрузкой, достаточно большой в пике и способной помешать реальной работе пользователей. Кто вносит значительную паразитную нагрузку на сервер с продуктивом - сам себе злобный буратино... Мы специально устранили недостатки ЦУП, который роняет продуктив...
наши сервисы http://www.gilev.ru/querytj/ логируют постгрес в платной версии хранят логи длительный период мы специально сделали бесплатный вариант и открытую клиентскую часть чтобы не говорили "невозможность внедрить утилиту во внутреннее облако" но как говориться если есть желание самостоятельно изобретать велосипед, то не надо говорить про "развитие" какие реально фичи в нашей деятельности нам нужны - мы добавляем
У вас явно нет понимания области применения синтетических и индивидуально написанных тестов под конкретную базу. Ни какой синтетический тест не будет отражать вашу индивидуальную операцию 1 в 1, да это и не требуется. Задача синтетического теста сделать первую быструю экспресс оценку без вкладывания больших сил и денег.
Тест однопоточный потому что большинство OLTP операций в 1С выполняются однопоточно и тест достаточно показателен для большинства баз небольшого размера.
Есть другие тесты, например "объемные тесты", которые решают схожие задачи, но они тоже достаточно индивидуальный, и нет цели всем налево и направо их делать.
Понятно, что вы в 1С можете написать вообще уникальный код и говорить что он не коррелирует с нашим тестом. Но тут же вопрос репрезентативности выводов. Ну и толку что вы оцените свою уникальную операцию, да для вас это будет полезно, а остальным сильно интересно знать скорость операции, которая у них никогда выполняться не будет?
"на сайте авторов имеются рекомендации, хотя и неполные и отчасти устаревшие" — давайте конкретней, чего нет? многие вещи мы отвечаем в форуме, я сомневаюсь что вы его целиком перечитали.
"Как можно увидеть, значительного выигрыша в результатах теста Гилева увеличение количества виртуальных процессоров не даёт." — вы явно не понимаете область применения теста
если вы хотите тестировать количество соединений/сеансов, количество одновременных фоновиков и т.п. то вам надо делать не синтетический тест, так как он все равно не будет учитывать блокировок в вашей реальной базе, а индивидуально написанный тест.
но даже в этом случае нашим тестом вы видите скорость одного потока, и если там скажем 8 баллов то и многопоточный тест на такой железки хороших результатов не выдаст
"Как можно увидеть, увеличение памяти не даёт ощутимого влияния на результаты теста." — вот тут очень спорное утверждение — если вы нарезаете в виртуалке гигабайт и он физически выделаяется на той же планке памяти то с какого перепугу будут изменения? их не будет. А вот если вы втыкаете к существующим планкам еще новые — наши замеры показывают ухудшение скорости. И это связано с падением частоты на планках памяти что можно объективно замерить вне нашего теста специализированными инструментами.
Ну и напоследок по замерам на вашем ноутбуке. Внедряйте апдекс и демонстрируйте реальные цифры. Я уверен что ваши реальные операции ведут себя по разному по отношению к друг другу. Может быть так что одни значительно ускорятся, другие очень мало, а третьи вообще не ускорятся. Вы же делаете очень субъективную оценку с далеко идущими выводами.
Многие тестируют нашим тестом потому что остальные жмутся что то сделать достойное и бесплатно.
И да, вы ругаете тест, но альтернативы не предлагаете. Поверьте, я тоже так могу )))
если вы не планируете увольняться из-за того что бэкап pg не поднимется, то сидеть до упора на MS SQL Server из-за нормальных бэкапов, и лучше переходить последним если в будущем когда то совсем без вариантов будет, только dt периодически тоже выгружайте
видел не раз как люди метнулись на pg, и потом вернулись на ms sql server
тем кто утверждает что там всё замечательно просто махайте рукой, мол всего вам доброго, хорошего настроения и здоровья
очень интересно посмотреть как вы будете оптимизировать базы 1с под вашу субд
если описать статью одной картинкой
формально это что то делает, но применить результаты на практике бесполезно
даю циклом статей начинающихся с http://www.gilev.ru/vmware_astra/
не буду ходить по кругу и повторять про некорректность
но будучи ИТ-директором описываемой вами компании бы как минимум дал задачу провести тестирование работоспособности того что предполагается к тестированию и выяснил что ваш релиз платформы 8.3.20.1838 плохо пригоден именно для связки с PG, так как только в релизе 8.3.21.1508 исправлена ошибка 60001790 (отсутствие подходящего индекса в итогах между счетами регистра бухгалетрии) , связанная с отсутствием подходящего индекса для внутриплатформенного метода апдейта данных, приводящей к таким проблемам как долгое «закрытие месяца» (упоминаемое вами) , что для промышленного предприятия, которое вы приводите в качестве портрета крайне чревато последствиями
поскольку вы приводите в пример реальную практику, то у меня теперь ещё больше вопросов
хотелось бы увидеть адекватное зрелое тестирование, а не давайте потестим что тут нагуглили сходу...
не очень понятно про какой лоб вы пишите
вы берете разные железки у разных провайдеров, с разной средой виртуализации, не сравнивая бюджет и пытаетесь получить какие то технические тесты в качестве сравнения
это не корректно
вы либо возьмите что можно арендовать за один и теже деньги у разных провайдеров
либо тестируйте одно и то же железо у разных провайдеров, и желательно с одинаковыми гипервизорами
либо четко скажите, что выбираете наилучшее технические предложения от каждого провайдера
либо другой четкий критерий
а сейчас вы теплое с мягким сравниваете и максируете это в том числе моим тестом
большая часть 62хх голдов в диапазоне 2.5-3.5 тысяч долларов стоят
для вас это новость? про какие абстрации вы тут разгоняете волну?
при чем у мтс автор статьи берет Intel Xeon Gold 6248R CPU @ 3.00GHzSSD, а у селектела Gold 6240R CPU @ 2.40GHz - для меня это выглядит если не странным, то точно не корректным сравнением, тем более у селектела есть более подходящие для 1с модели процессоров (если автор хочет ориентироваться на наилучшие предложения провайдера)
и главное, нахрена вы втихаря минус ставите, аргументировать не можете?
да тот же порядок цен, чем вам тот же 6244 не угодил, особенно если взять выделенный сервер, включить турбобуст
взяв в аренду на gold 6244 физический сервер можно получить достойные цифры 55-60 на ms sql server
что касаемо PG - там настройки могут значительно влиять от 5% до 30%
что касаемо 20й убунты
sudo systemctl disable ondemand
sudo reboot
выглядит как неумелое продвижение услуг Cloud :)
судя по описанию она должна хуже работать чем postgres pro ent
там фактически ванильный pg плюс патчи 1с, по идее будет на уровне сборки pg с сайта 1с, но при этом ещё и денег захотят
поверю в преимущества когда тантор хотя бы покажет внятный бэкапер с мониторингом RPO/RTO без убогой командной строки, целостности бэкапов, контролем места под бэкапы и потерей не более 30 секунд на одном экземпляре без установки кучи "левых" пакетов c наглядным восстановлением на новом железе, а не переупаковку старых продуктов в новую обертку
активность снаружи в windows можно посмотреть через процесс монитор марка русновича
раз вы говорите что статистика временных таблиц много съедает, то
1. давайте поставим 8.3.12, там платформа этого еще делать не умела
вот и выясним верность гипотезы
а со стороны субд уменьшим количество выборки за проход
ALTER SYSTEM SET default_statistics_target TO 20;
2.
-- в отличии от скуля мы можем сказать оптимизатору запросов, что процессор дорогой
ALTER SYSTEM SET cpu_operator_cost TO 0.0001;
--а диски дешевые чтобы попробовать сместить планы запросов
ALTER SYSTEM SET seq_page_cost TO 0.1;
ALTER SYSTEM SET random_page_cost TO 0.4;
3.
--отключим синхронность записи
ALTER SYSTEM SET bgwriter_delay TO 200;
ALTER SYSTEM SET synchronous_commit TO off;
ALTER SYSTEM SET full_page_writes TO off;
ALTER SYSTEM SET fsync TO off;
ALTER SYSTEM SET checkpoint_segments TO 200;
ALTER SYSTEM SET checkpoint_timeout TO 1800;
ALTER SYSTEM SET autovacuum_naptime TO 200;
ALTER SYSTEM SET commit_delay TO 10000;
--увеличим размер лога
ALTER SYSTEM SET max_wal_size TO '1024 MB';
--уберем лишние модули
ALTER SYSTEM SET shared_preload_libraries TO 'plantuner';
и рестарт постгреса
не увидел без подсказки закладки снизу
но лишь утвердился в причинах, ну так то и на скуле можно параллелизм задрать
вообщем идея лишний параллелизм выключить исключительно для оценки влияния на общую утилизацию процессоров
то что рекомендованно 1с должно быть прежде всего осмысленно ПОЧЕМУ
в данном случае online_analyze.enable = on включает СИНХРОННУЮ статистику
может она в данном конкретном случае и не сыграет роли, но она удлиняет транзакции, помоему проще проверить, чем спорить
еще для третьте волны экспериментов
ALTER SYSTEM SET geqo_threshold TO 8;
ALTER SYSTEM SET join_collapse_limit TO 8;
на сложных запросах раньше будут будет срабатывать более быстрая генерация плана запроса, но менее точная
на запросах меньшим числом таблиц это не скажется ни как
при чем играться тут можно в обе стороны, дефолтовое 12
а у вас случаем многопоточная обработка запросов не включена, а то если да то выключите
ALTER SYSTEM SET max_parallel_workers_per_gather TO 1;
ALTER SYSTEM SET max_parallel_workers TO 1;
ALTER SYSTEM SET max_parallel_maintenance_workers TO 1;
ALTER SYSTEM SET autovacuum_max_workers TO 2;
ALTER SYSTEM SET ssl TO off;
ALTER SYSTEM SET online_analyze.enable TO off;
SELECT pg_reload_conf();
а если не поможет то
ALTER SYSTEM SET cpu_operator_cost TO 0.0001; -- поднять стоимость процессорного ресурса
видимо мы по-разному понимаем подход к работе
вы за процесс, я за результат
забор интенсивных логов по локалке точно также может помешать работе пользователей
нормальным людям манипуляции с метриками на дополнительном сервере ради разовых вещей по поиску узких мест не нужна, это еще ради этого сервер покупать, а сейчас и сервер не купить!
или у вас значения счетчиков загруженности оборудования и текстов запросов стали чем представляющим ценность для "врагов"...
зачем же вы глупости такие пишите
" Я не смог найти информацию на вашем сайте о том, как установить серверную часть вашего комплекса в локальном окружении. " Опять манипуляции. Так у нас и не написано как делать не надо.
Метрики обсчитываются в облаке. Чтобы отправить их туда ЛОКАЛЬНО ставится база 1С-клиент с открытым кодом. http://www.gilev.ru/setupquerytj/ инструкция есть. Смысл нагружать боевые сервера сторонней нагрузкой, достаточно большой в пике и способной помешать реальной работе пользователей. Кто вносит значительную паразитную нагрузку на сервер с продуктивом - сам себе злобный буратино...
Мы специально устранили недостатки ЦУП, который роняет продуктив...
вы яростно манипулируете "Вы берете всю информацию из ТЖ" - так он для этого и предназначен
важно не откуда кто что берет, а какой результат!
наши сервисы http://www.gilev.ru/querytj/ логируют постгрес
в платной версии хранят логи длительный период
мы специально сделали бесплатный вариант и открытую клиентскую часть чтобы не говорили "невозможность внедрить утилиту во внутреннее облако"
но как говориться если есть желание самостоятельно изобретать велосипед, то не надо говорить про "развитие"
какие реально фичи в нашей деятельности нам нужны - мы добавляем
приходите на наши курсы, расскажем-покажем
считайте это ответом и вам и автору статьи
У вас явно нет понимания области применения синтетических и индивидуально написанных тестов под конкретную базу. Ни какой синтетический тест не будет отражать вашу индивидуальную операцию 1 в 1, да это и не требуется. Задача синтетического теста сделать первую быструю экспресс оценку без вкладывания больших сил и денег.
Тест однопоточный потому что большинство OLTP операций в 1С выполняются однопоточно и тест достаточно показателен для большинства баз небольшого размера.
Есть другие тесты, например "объемные тесты", которые решают схожие задачи, но они тоже достаточно индивидуальный, и нет цели всем налево и направо их делать.
Понятно, что вы в 1С можете написать вообще уникальный код и говорить что он не коррелирует с нашим тестом. Но тут же вопрос репрезентативности выводов. Ну и толку что вы оцените свою уникальную операцию, да для вас это будет полезно, а остальным сильно интересно знать скорость операции, которая у них никогда выполняться не будет?
"на сайте авторов имеются рекомендации, хотя и неполные и отчасти устаревшие" — давайте конкретней, чего нет? многие вещи мы отвечаем в форуме, я сомневаюсь что вы его целиком перечитали.
"Как можно увидеть, значительного выигрыша в результатах теста Гилева увеличение количества виртуальных процессоров не даёт." — вы явно не понимаете область применения теста
если вы хотите тестировать количество соединений/сеансов, количество одновременных фоновиков и т.п. то вам надо делать не синтетический тест, так как он все равно не будет учитывать блокировок в вашей реальной базе, а индивидуально написанный тест.
но даже в этом случае нашим тестом вы видите скорость одного потока, и если там скажем 8 баллов то и многопоточный тест на такой железки хороших результатов не выдаст
"Как можно увидеть, увеличение памяти не даёт ощутимого влияния на результаты теста." — вот тут очень спорное утверждение — если вы нарезаете в виртуалке гигабайт и он физически выделаяется на той же планке памяти то с какого перепугу будут изменения? их не будет. А вот если вы втыкаете к существующим планкам еще новые — наши замеры показывают ухудшение скорости. И это связано с падением частоты на планках памяти что можно объективно замерить вне нашего теста специализированными инструментами.
Ну и напоследок по замерам на вашем ноутбуке. Внедряйте апдекс и демонстрируйте реальные цифры. Я уверен что ваши реальные операции ведут себя по разному по отношению к друг другу. Может быть так что одни значительно ускорятся, другие очень мало, а третьи вообще не ускорятся. Вы же делаете очень субъективную оценку с далеко идущими выводами.
Многие тестируют нашим тестом потому что остальные жмутся что то сделать достойное и бесплатно.
И да, вы ругаете тест, но альтернативы не предлагаете. Поверьте, я тоже так могу )))