MSSQL 34 попугая, а Postgres 47. Не пойму где я недоглядел. (Тест Гилёва)
Здравствуйте!
Машина - физическая 2012 R2
i7-9700К, DDR4-2400, Зеркало из 2x NMVE-970Samsung x4(TLC).
Система всё СУБД находятся на SSD. SSD потоковое чтение 3400Мс запись 2300Мс. По 4k читает и пишет 1700Мс (480000ёпсов)
С биосом поработал. В файловом режиме выдаёт 100 попугаев, MSSQL(2017) - 34,5, Postgres(11.2) 47.
Всё 64-x битное, кроме 1С(8.3.12.1855)
Постгрес -поставил тупо Pro - ничего не крутил.
MSSQL
0) Энергосбережение - выс произв.
1)добавил пользователя в лок политики (Выполнение задач по обслуживанию томов, блокировка страниц в памяти)
2) Максимальное число рабочих потоков 1024
3) Максимальный уровень параллелизма 1
4) tempdb 8 файлов(так было по умолчанию) исходный размер 512, шаг 512
5) База и журнал по умолч 1024 шаг по 512
6) Приоритет SQL - не включал (на одной машине)
7) Проверил - да, действительно 1С и MSSQL соединены через SharedMemory
8) Асинхронное автоматическое обновление статистики в базе включено
8)DFSS и прочее, связанное с ограничениями терминального сервера снято.
Вообще, больше 37 на MSSQL у меня нигде не получалось (X5690 - 34, E5-2637 v2 - 37) Ранее всё делал на MSSQL 2014. 2017 поставил впервые.
Глядя на - я полагал, что эти результаты достигнуты через разгон железа. Но сейчас понимаю, что похоже это не так. Есть, похоже, какая-то хитрость которую я обычно не делаю.
Сильно ли влияет размер кластера NTFS? Стоит 4kb, возможности поменять, похоже, уже нет.
Что я упустил? Спасибо!
Машина - физическая 2012 R2
i7-9700К, DDR4-2400, Зеркало из 2x NMVE-970Samsung x4(TLC).
Система всё СУБД находятся на SSD. SSD потоковое чтение 3400Мс запись 2300Мс. По 4k читает и пишет 1700Мс (480000ёпсов)
С биосом поработал. В файловом режиме выдаёт 100 попугаев, MSSQL(2017) - 34,5, Postgres(11.2) 47.
Всё 64-x битное, кроме 1С(8.3.12.1855)
Постгрес -поставил тупо Pro - ничего не крутил.
MSSQL
0) Энергосбережение - выс произв.
1)добавил пользователя в лок политики (Выполнение задач по обслуживанию томов, блокировка страниц в памяти)
2) Максимальное число рабочих потоков 1024
3) Максимальный уровень параллелизма 1
4) tempdb 8 файлов(так было по умолчанию) исходный размер 512, шаг 512
5) База и журнал по умолч 1024 шаг по 512
6) Приоритет SQL - не включал (на одной машине)
7) Проверил - да, действительно 1С и MSSQL соединены через SharedMemory
8) Асинхронное автоматическое обновление статистики в базе включено
8)DFSS и прочее, связанное с ограничениями терминального сервера снято.
Вообще, больше 37 на MSSQL у меня нигде не получалось (X5690 - 34, E5-2637 v2 - 37) Ранее всё делал на MSSQL 2014. 2017 поставил впервые.
Глядя на - я полагал, что эти результаты достигнуты через разгон железа. Но сейчас понимаю, что похоже это не так. Есть, похоже, какая-то хитрость которую я обычно не делаю.
Сильно ли влияет размер кластера NTFS? Стоит 4kb, возможности поменять, похоже, уже нет.
Что я упустил? Спасибо!
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(23) Гипер - включен. Ниже писал о нём. Турбобуст включен, но при ограничении C0 я так понял он не работает. Одновременно эти две вещи не работают. Или надо держать в тонусе все ядра, либо давать очень много на одно (Могу ошибаться, так как читал про эту технологию давно). По итогам прошлого опыта держать все ядра в тонусе, лучше по попугаям чем TurboBoost на одно ядро даже для однопоточного теста. Объяснить не могу, тестил много раз и вопрос для себя закрыл исходя из практики.
Сейчас все ядра постоянно работают примерно в 130% от максимальной частоты и не понижаются при простое. В целом это поведение как правило даёт больше всего попугаев.
Химичить с биосом не могу - нет доступа к машине. Ориентируюсь по частоте ядер, что всё в порядке с энергосбережением в биосе. (Ну и по файловым с Postgres попугаям)
Сейчас все ядра постоянно работают примерно в 130% от максимальной частоты и не понижаются при простое. В целом это поведение как правило даёт больше всего попугаев.
Химичить с биосом не могу - нет доступа к машине. Ориентируюсь по частоте ядер, что всё в порядке с энергосбережением в биосе. (Ну и по файловым с Postgres попугаям)
(24)Одновременно режим высокой производительности и турбобуст не работают. И к тому же в режиме высокой производительности процессор не поднимает частоту ядер до максимальной, держит частоту ниже максимальной, еще плюс идет разделение частоты на обслуживание гипетрединга. Еще добавляется то что MSSQL рассчитан на работу с серверными процессорами, где количество каналов памяти 4 и более.
(27) Точняк. Вот это поворот!
Гилёв на сайте пишет, что они достигли на таком оборудовании 50 попугаев. Дело получается не в HT, млин, неужели туда придётся ехать и крутить биос.
Не пойму, вы предлагаете обеспечить режим, где будет работать TB, то есть включить C-STATE? Я тестил на разных машинах, в том числе и на серверных - да частота становится немного выше, но попугаи от этого уменьшаются.
Я, кстати, снимал про это кино как-то. Вот оно
Гилёв на сайте пишет, что они достигли на таком оборудовании 50 попугаев. Дело получается не в HT, млин, неужели туда придётся ехать и крутить биос.
Не пойму, вы предлагаете обеспечить режим, где будет работать TB, то есть включить C-STATE? Я тестил на разных машинах, в том числе и на серверных - да частота становится немного выше, но попугаи от этого уменьшаются.
Я, кстати, снимал про это кино как-то. Вот оно
(28)Я не знаю как на десктопных материнках и процессорах работает тб, но когда тестировал на серверных, с балансировкой по ядрам между 1С и скл сервером, прирост был, но не в однопоточном режиме, вообще не вижу смысла в таком тестировании. MSSQL сервер это многопоточное приложение, где часть ядер исльзется для ввода вывода, часть для обслуживания запросов, запрос клиента может выполнятся на нескольких ядрах процессора.
(29)
Да нужен и однопоточный тест. Как раз для того, чтобы понять на что способно ядро этого конкретно процессора на этой конкретно матери с этим конкретно биосом в конкретной конфигурации. Например, чтобы быстро настроить производительность в биосе.
Вот на видео выше, например, серверная конфигурация. По идее включив C-STATE ядро должно быть быстрее за счет TB - но этого не происходит.
И многопоточная нагрузка в этом случае не пострадает, так как если одно ядро(2,3,4 но не все) уходит буст, и попугаи (а это количество отработанных операций за определённое время (ну или наеборот)) не увеличиваются, а увеличиваются когда ВСЕ ядра находятся на постоянной высокой частоте. (опять же, на конкретно этой матери, ну и на паре других, серверных)
Наоборот, производительность при многопоточности в случае отключения С-STATE по логике должна возрасти. (У всех ядер будут равные возможности)
Матери настолько разные, что похожие результаты можно достигать с настолько разными по поколениям процессорами, что каждый раз удивляешься.
Вообще складывается такое впечатление, что новые процессора по скорости недалеко уходят от старичков, они уходят далеко в энергосбережении и цене.
Да нужен и однопоточный тест. Как раз для того, чтобы понять на что способно ядро этого конкретно процессора на этой конкретно матери с этим конкретно биосом в конкретной конфигурации. Например, чтобы быстро настроить производительность в биосе.
Вот на видео выше, например, серверная конфигурация. По идее включив C-STATE ядро должно быть быстрее за счет TB - но этого не происходит.
И многопоточная нагрузка в этом случае не пострадает, так как если одно ядро(2,3,4 но не все) уходит буст, и попугаи (а это количество отработанных операций за определённое время (ну или наеборот)) не увеличиваются, а увеличиваются когда ВСЕ ядра находятся на постоянной высокой частоте. (опять же, на конкретно этой матери, ну и на паре других, серверных)
Наоборот, производительность при многопоточности в случае отключения С-STATE по логике должна возрасти. (У всех ядер будут равные возможности)
Матери настолько разные, что похожие результаты можно достигать с настолько разными по поколениям процессорами, что каждый раз удивляешься.
Вообще складывается такое впечатление, что новые процессора по скорости недалеко уходят от старичков, они уходят далеко в энергосбережении и цене.
(30)
Новые процессоры производительнее старых, вопрос только в приложения которые запускаются на них, и то насколько они поддерживают новые процессоры. 1С собирается так что она работает чуть ли не на всех процессорах, соответственно ожидать от нее повешения производительности заменив процессор не стоит.
Вообще складывается такое впечатление, что новые процессора по скорости недалеко уходят от старичков, они уходят далеко в энергосбережении и цене.
Новые процессоры производительнее старых, вопрос только в приложения которые запускаются на них, и то насколько они поддерживают новые процессоры. 1С собирается так что она работает чуть ли не на всех процессорах, соответственно ожидать от нее повешения производительности заменив процессор не стоит.
(30)
Такое поведение процессора, зависит от многих факторов, включая прошивку биоса, операционную систему, и временные интервалы нагрузки на ядро
И многопоточная нагрузка в этом случае не пострадает, так как если одно ядро(2,3,4 но не все) уходит буст, и попугаи (а это количество отработанных операций за определённое время (ну или наеборот)) не увеличиваются, а увеличиваются когда ВСЕ ядра находятся на постоянной высокой частоте. (опять же, на конкретно этой матери, ну и на паре других, серверных)
Такое поведение процессора, зависит от многих факторов, включая прошивку биоса, операционную систему, и временные интервалы нагрузки на ядро
(33)
Ну, спасибо. Стало намного спокойнее. Это не я не где-то недоглядел, это вот так и всё.
Гилёв правда, пишет что у них получалось на аналогичном оборудовании (i7-8700K) достичь результата, около 50:
Но, подробностей не рассказывает. Может они его разогнали, или ещё чего. Может мать такая, от матери прям сильно зависит результат.
А касательно примера - я так понял суть его должна заключаться в том, что вы попробовали вариант с TB и с выключенными C-STATE, сравнили и сделали вывод что вы будете использовать. Если вы это сделали - поделитесь результатами.
Померял ещё попугями Fragster'a, они хоть показывают что именно измеряется:
Результат показал примерно тоже самое что тест Гилёва, только развёрнуто. MSSQL лучше работает со временными таблицами а postgres со всем остальным.
Ну, спасибо. Стало намного спокойнее. Это не я не где-то недоглядел, это вот так и всё.
Гилёв правда, пишет что у них получалось на аналогичном оборудовании (i7-8700K) достичь результата, около 50:
Но, подробностей не рассказывает. Может они его разогнали, или ещё чего. Может мать такая, от матери прям сильно зависит результат.
А касательно примера - я так понял суть его должна заключаться в том, что вы попробовали вариант с TB и с выключенными C-STATE, сравнили и сделали вывод что вы будете использовать. Если вы это сделали - поделитесь результатами.
Померял ещё попугями Fragster'a, они хоть показывают что именно измеряется:
Результат показал примерно тоже самое что тест Гилёва, только развёрнуто. MSSQL лучше работает со временными таблицами а postgres со всем остальным.
(35)Вначале у сервера полная производительность стояла, все было хорошо, ядра работали примерно на 120% от номинальной, MSSQL выдавал 70тыс транзакций в секунду, 1С не проверял, толку мало, от этих тестов. Чудеса начались когда начали подключать дополнительные виртуальные машины на сервер, стала падать производительность mssql, включили тб, производительность выравнялась и достигала примерно таких же 70тыс транзакций в секунду.
(35)
Ну это ерунда.
(35)
MSSQL лучше работает со временными таблицами а postgres со всем остальным.
Ну это ерунда.
(37)
Это результат тестов.
(37)
Объективность этой методики хромает. Нельзя в этой ситуации утверждать, что включение TB повысило произоводительность системы в целом. Скорее остальные машины получили меньше ресурса процессора за счет TB на ядрах, на которых орудует MSSQL (возможно даже с приоритетом SQL).
Ну это ерунда.
Это результат тестов.
(37)
(35)Вначале у сервера полная производительность стояла, все было хорошо, ядра работали примерно на 120% от номинальной, MSSQL выдавал 70тыс транзакций в секунду, 1С не проверял, толку мало, от этих тестов. Чудеса начались когда начали подключать дополнительные виртуальные машины на сервер, стала падать производительность mssql, включили тб, производительность выравнялась и достигала примерно таких же 70тыс транзакций в секунду.
Объективность этой методики хромает. Нельзя в этой ситуации утверждать, что включение TB повысило произоводительность системы в целом. Скорее остальные машины получили меньше ресурса процессора за счет TB на ядрах, на которых орудует MSSQL (возможно даже с приоритетом SQL).
(38)На это и делался уклон, важно что бы все машины получали достаточно ресурсов на критически важных задачах. В последствии mssql и 1С выделил в отдельную группу, в этой группе сбалансировал выделение частот процессоров в пользу 1С, по крайне мере 1С стала резвее работать.
(28) вижу по видео нагрузку на Cpu не выше 5%. Сами считайте 16 потов. 1С-ка и MsSql Server в режиме паралелизма 1 видят только 1 поток 100/16 потоков итого не больше 6% CPU сможете утилизировать,
1. можно конечно MSSQL службе назначить параметр Numa1 тогда будет Скуль утилизировать другое ядро. Проще в настройка скуля cpu0 отжать галочку(Если у вас база на одном сервере).
2 А серверу предприятия выставить numa 2 и вырубить гипртрейдинг. Тогда нагрузка на CPU выростет до 20%
1. можно конечно MSSQL службе назначить параметр Numa1 тогда будет Скуль утилизировать другое ядро. Проще в настройка скуля cpu0 отжать галочку(Если у вас база на одном сервере).
2 А серверу предприятия выставить numa 2 и вырубить гипртрейдинг. Тогда нагрузка на CPU выростет до 20%
(45)
Та система, что на видео уже давно не у меня. Попробовать не смогу, но и не вижу причин, чтобы это не сработало. По поводу разделения по numa это конечно прекрасно, но вы хотите сказать, что имея на борту два cpu винда загрузит процессом 1С именно тот поток, которым загружен MSSQL? Даже при однопоточном тесте - эти две службы будут крутиться на разных как минимум потоках.
По гиперу, кстати, передумал. Если например одна большая база - то имеет смысл. Если много маленьких - то нет.
Как будет на руках что-нибудь подобное попробую покрутить и numa и HT.
Та система, что на видео уже давно не у меня. Попробовать не смогу, но и не вижу причин, чтобы это не сработало. По поводу разделения по numa это конечно прекрасно, но вы хотите сказать, что имея на борту два cpu винда загрузит процессом 1С именно тот поток, которым загружен MSSQL? Даже при однопоточном тесте - эти две службы будут крутиться на разных как минимум потоках.
По гиперу, кстати, передумал. Если например одна большая база - то имеет смысл. Если много маленьких - то нет.
Как будет на руках что-нибудь подобное попробую покрутить и numa и HT.
Добрый день, я практикую установку платформ 1С (одной версии) с сервером 1С предприятия (32 и 64) для связи с SQL 64, просто 32 битный Агент сервера 1С я отключаю как службу, а 64-х битный оставляю и он по специально заданному порту 100% работает в 64 битном режиме с SQL 64. Т.е. я могу применять одновременно и 32-х и 64-х битные платформы 1С но при этом связь с SQL всегда 64 бита - так эффективнее, к сожалению 32-х битную платформу 1С приходится применять из-за внутренних драйверов оборудования которых нет под 64 бита 1С.
Прикрепленные файлы:
Оочень смешно) Скорее Гилёв с ними договорился.
Вообще, конечно рано или поздно я приду к postgres, но категорически не нравится, что журнал транзакций ведётся для всего кластера бд. Зачем мне журнал транзакций копии? Как-нибудь придумаю схему резервного копирования (буду идти в сторону логической репликации), но пока нет столько времени на изучение postgres и пока хочу остаться на MSSQL, но вот эти цифры - будоражат воображение и не дают спать.
Я первый раз присел, когда получил небольшую разницу в приросте постгри перед новым годом. Сразу попробовал запустить тот же релиз на linux(и то и другое на linux и 1с на винде, а постгри на линуксе) - и получил не такие радужные результаты как на винде, это тоже показалось странным.
Потом накапливалось негодование от того, что x5560 - дал 33 попугая, x5690 - 35 попугаев, а E5-2637 v2 - 37.
Сейчас получил машину, которая работает на 4,5 Ггц и имеет на борту крутой NMVE, вот сейчас, подумал я, будет результат! (тем более файловый - 100!!!) Тест - 34. (ну должен же он быть выше, на таком то железе!)
Постгри поставил случайно, потому что было время и уже был прецендент. Вот, вчера присел ещё раз. Или тест гилёва - это ересь (протестил пару запросов - постгри отыграл чуть-чуть быстрее), или я неправильно настраиваю MSSQL.
P.S. Поставил 2014 sp3 - те же результаты. Включал -T1118 и -T4199 - тоже самое.
У кого-нибудь было более 40 попугаев на MSSQL?
Вообще, конечно рано или поздно я приду к postgres, но категорически не нравится, что журнал транзакций ведётся для всего кластера бд. Зачем мне журнал транзакций копии? Как-нибудь придумаю схему резервного копирования (буду идти в сторону логической репликации), но пока нет столько времени на изучение postgres и пока хочу остаться на MSSQL, но вот эти цифры - будоражат воображение и не дают спать.
Я первый раз присел, когда получил небольшую разницу в приросте постгри перед новым годом. Сразу попробовал запустить тот же релиз на linux(и то и другое на linux и 1с на винде, а постгри на линуксе) - и получил не такие радужные результаты как на винде, это тоже показалось странным.
Потом накапливалось негодование от того, что x5560 - дал 33 попугая, x5690 - 35 попугаев, а E5-2637 v2 - 37.
Сейчас получил машину, которая работает на 4,5 Ггц и имеет на борту крутой NMVE, вот сейчас, подумал я, будет результат! (тем более файловый - 100!!!) Тест - 34. (ну должен же он быть выше, на таком то железе!)
Постгри поставил случайно, потому что было время и уже был прецендент. Вот, вчера присел ещё раз. Или тест гилёва - это ересь (протестил пару запросов - постгри отыграл чуть-чуть быстрее), или я неправильно настраиваю MSSQL.
P.S. Поставил 2014 sp3 - те же результаты. Включал -T1118 и -T4199 - тоже самое.
У кого-нибудь было более 40 попугаев на MSSQL?
Была тоже примерно такая ситуация. Весь замут в платформе 1С которая не заточена под современные операционки (выше 2008 server). Суть в том что там толи тонкий клиент толи сам Hyper-V конфликтует. Остановили все процессы связанные с Hyper-V и скорость стала 74 попугаев, а с запущенной 34 попугая. Ну как-то так. Этим занимался наш сис админ.
Hyper-V не установлена. Вообще ничего не установлено. (антивируса тем более) Голая винда.
На платформу можно было бы бы спереть, если постгри не выдал гари.
(5) - загляните в биос, и выключите C-STATE (или ограничьте C0). В общем выключите энергосбережение процессора.
Ещё может чего нарисуется.
На платформу можно было бы бы спереть, если постгри не выдал гари.
(5) - загляните в биос, и выключите C-STATE (или ограничьте C0). В общем выключите энергосбережение процессора.
Ещё может чего нарисуется.
(7)
В голой 2012 винде по умолчанию MSE ставится на сколько я помню (типа Дефендера только хуже).
Его надо проверить для чистоты эксперимента.
И брендмауеры тоже можно вырурубить
yper-V не установлена. Вообще ничего не установлено. (антивируса тем более) Голая винда.
На платформу можно было бы бы спереть, если постгри не выдал гари.
На платформу можно было бы бы спереть, если постгри не выдал гари.
В голой 2012 винде по умолчанию MSE ставится на сколько я помню (типа Дефендера только хуже).
Его надо проверить для чистоты эксперимента.
И брендмауеры тоже можно вырурубить
(8) не стоит и его тоже
Короч запустил пару ключевых документов на перепроведение января.
При равных условиях доки проводились:
На MSSQL 19 мин 13 сек.
На Postgres 17 мин 58 сек.
Попробовал так же перепровести только последнюю неделю января.
Первый проход
MSSQL - 3:20
Postgres - 3:18
Второй проход
MSSQL 3:09
Posgtgres 3:18
Третий проход
MSSQL 3:11
Postgres 3:17
Короч разница в производительности не такая как в количестве попугаев.
Короч запустил пару ключевых документов на перепроведение января.
При равных условиях доки проводились:
На MSSQL 19 мин 13 сек.
На Postgres 17 мин 58 сек.
Попробовал так же перепровести только последнюю неделю января.
Первый проход
MSSQL - 3:20
Postgres - 3:18
Второй проход
MSSQL 3:09
Posgtgres 3:18
Третий проход
MSSQL 3:11
Postgres 3:17
Короч разница в производительности не такая как в количестве попугаев.
(40)
Конфигуратором Леопёрда потюнил, ничего не поменялось в лучшую сторону. Там вещи, которые на однопоточных попугаев не сильно влияют, влияют на длительную загрузку СУБД (чтобы использовал память в нужных пределах и т.д.)
Думаю команда postgres pro, выпуская программу Postgres Pro для 1С, побольше позаботилась о взаимодействии именно с 1С при заполнении дефолтного конфига, чем pgtune. Единственное, что они не могли знать, это размеры памяти, характеристики носителей и т.д.
Я читал много материала по postgres. И было даже время, когда у меня крутились на нём пару баз (лет 5 назад). Я был доволен, потом надо было переходить на MSSQL (не помню почему), и всё опыт применения забыт.
Проблема в том, что когда начинаешь углубляться в postgres, и чтобы где-нибудь его поставить не хватает времени/сил/ума, то через пол года всё вылетает из головы и всё, надо опять читать-вспоминать.
(До праздников вспоминал механизм периодических расчётов, после праздников уже надо вспоминать заново)
Просто вбивать конфиг из тюнера - это фу, надо хотя бы понимать, что ты делаешь и как это работает. А на это надо время.
Конфигуратором Леопёрда потюнил, ничего не поменялось в лучшую сторону. Там вещи, которые на однопоточных попугаев не сильно влияют, влияют на длительную загрузку СУБД (чтобы использовал память в нужных пределах и т.д.)
Думаю команда postgres pro, выпуская программу Postgres Pro для 1С, побольше позаботилась о взаимодействии именно с 1С при заполнении дефолтного конфига, чем pgtune. Единственное, что они не могли знать, это размеры памяти, характеристики носителей и т.д.
Я читал много материала по postgres. И было даже время, когда у меня крутились на нём пару баз (лет 5 назад). Я был доволен, потом надо было переходить на MSSQL (не помню почему), и всё опыт применения забыт.
Проблема в том, что когда начинаешь углубляться в postgres, и чтобы где-нибудь его поставить не хватает времени/сил/ума, то через пол года всё вылетает из головы и всё, надо опять читать-вспоминать.
(До праздников вспоминал механизм периодических расчётов, после праздников уже надо вспоминать заново)
Просто вбивать конфиг из тюнера - это фу, надо хотя бы понимать, что ты делаешь и как это работает. А на это надо время.
(11) Да пробовал я и 0 и 4 и 8. Всё то же. Судя по всему 11-ая postgres делает какую-то операцию применимую в тесте - быстрее.
Гипертрейдинг - это вы, возможно в сердце. Попробовать не могу, так как удалён от этой машины. Но если Гилёв на своём форуме укажет, что 50 попугаев он получает именно с выключенным гипертрейдингом, тогда 10 шеккелей ваши.
Он утверждает, что на аналогичном железе он получает около 50 (только не могу выбить из них, что речь идёт именно о MSSQL). Ну и в добавок к этому получается, что постгри как-то объ...вает тест Гилёва(хотя конечно надо изучать вопрос в отладчике, чтобы такое заключать, но извините уж), так как реального прироста, пропорционального количеству попугаев не наблюдается. Наблюдается почти паритет.
Конечно, выключение гипертрейдинга - это фу для моей задачи и большинства случаев, и работать так я конечно не оставлю. Если ставить во главу угла количество попугаев, то конечно HT надо выключать.
Эээх, я полагал, что найду какой-то момент в настройке MSSQL, который не знаю, а должен знать(для моего уровня). Но похоже, что секрета нет и это печально.
(12) Кстати, на линукс. Мало ли. Может пригодится кому. (Подходит для Intel)
В /etc/default/grub, в строку GRUB_CMDLINE_LINUX_DEFAULT в конец (перед кавычкой) нужно добавить intel_idle.max_cstate=0 processor.max_cstate=1, чтобы выглядело например вот так:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=0 processor.max_cstate=1"
после этого update-grub и reboot
Я применяю этот приём в proxmox. Это аналог высокой производительности энергосбережения в винде.
После этого как правило нарисовывается ещё несколько попугаев.
(Сейчас только вдумался, почему именно processor.max_cstate=1, надо попробовать 0, но пробовать пока негде)
Гипертрейдинг - это вы, возможно в сердце. Попробовать не могу, так как удалён от этой машины. Но если Гилёв на своём форуме укажет, что 50 попугаев он получает именно с выключенным гипертрейдингом, тогда 10 шеккелей ваши.
Он утверждает, что на аналогичном железе он получает около 50 (только не могу выбить из них, что речь идёт именно о MSSQL). Ну и в добавок к этому получается, что постгри как-то объ...вает тест Гилёва(хотя конечно надо изучать вопрос в отладчике, чтобы такое заключать, но извините уж), так как реального прироста, пропорционального количеству попугаев не наблюдается. Наблюдается почти паритет.
Конечно, выключение гипертрейдинга - это фу для моей задачи и большинства случаев, и работать так я конечно не оставлю. Если ставить во главу угла количество попугаев, то конечно HT надо выключать.
Эээх, я полагал, что найду какой-то момент в настройке MSSQL, который не знаю, а должен знать(для моего уровня). Но похоже, что секрета нет и это печально.
(12) Кстати, на линукс. Мало ли. Может пригодится кому. (Подходит для Intel)
В /etc/default/grub, в строку GRUB_CMDLINE_LINUX_DEFAULT в конец (перед кавычкой) нужно добавить intel_idle.max_cstate=0 processor.max_cstate=1, чтобы выглядело например вот так:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=0 processor.max_cstate=1"
после этого update-grub и reboot
Я применяю этот приём в proxmox. Это аналог высокой производительности энергосбережения в винде.
После этого как правило нарисовывается ещё несколько попугаев.
(Сейчас только вдумался, почему именно processor.max_cstate=1, надо попробовать 0, но пробовать пока негде)
Мы тут перешли на Постгрес.
Финальное ощущение, что забегало прилично быстрее.
Правда, стоит отметить, что пришлось в процессе достаточно повозиться со всякими левыми соединениями со срезами последних, на них Постгрес иногда просто умирал.
Финальное ощущение, что забегало прилично быстрее.
Правда, стоит отметить, что пришлось в процессе достаточно повозиться со всякими левыми соединениями со срезами последних, на них Постгрес иногда просто умирал.
(15) Может и MSSQL заработал бы пошустрее, если бы вы на него запросы переписали )))
(16) Да я и включал и отключал. По-разному пробовал. Вдруг оно. Постгрес постгресу оказывается рознь. Впервые я на 11-ом я получил чуть больший результат, чем на MSSQL в попугаях, а тут в 1,5 раза. А до этого постгри всегда был существенно позади. Может имеет смысл перетестить?
(16) Да я и включал и отключал. По-разному пробовал. Вдруг оно. Постгрес постгресу оказывается рознь. Впервые я на 11-ом я получил чуть больший результат, чем на MSSQL в попугаях, а тут в 1,5 раза. А до этого постгри всегда был существенно позади. Может имеет смысл перетестить?
(18) Ну, кстати, я тут подумал, та база, где был основной прирост производительности, мы заранее все запросы оптимизировали.
Так что нет, чисто переезд дал ощутимый прирост.
Причем это обычный Пострес 9.6, даже не про.
Правда, мы конфиг тюнили по советам из интернета. Возможно, MSSQL был хуже оттюнен.
Так что нет, чисто переезд дал ощутимый прирост.
Причем это обычный Пострес 9.6, даже не про.
Правда, мы конфиг тюнили по советам из интернета. Возможно, MSSQL был хуже оттюнен.
(15)
Posgres не умеет левое соединение делать нормально.
Это факт. Особенно он не любит конструкции Left join совместно с where [знач] IS not NULL.
Но заметно быстрее работает с оператором where [знач] in (sel ect [знач] fr om ... )
Бывает так же posgre sql не правильно отрабатывает механизмы в Иерархии(). Возможно это проблемы платформы 1С. Наблюдается только на Postges на винде
Под linux все норм
Мы тут перешли на Постгрес.
Финальное ощущение, что забегало прилично быстрее.
Правда, стоит отметить, что пришлось в процессе достаточно повозиться со всякими левыми соединениями со
Финальное ощущение, что забегало прилично быстрее.
Правда, стоит отметить, что пришлось в процессе достаточно повозиться со всякими левыми соединениями со
Posgres не умеет левое соединение делать нормально.
Это факт. Особенно он не любит конструкции Left join совместно с where [знач] IS not NULL.
Но заметно быстрее работает с оператором where [знач] in (sel ect [знач] fr om ... )
Бывает так же posgre sql не правильно отрабатывает механизмы в Иерархии(). Возможно это проблемы платформы 1С. Наблюдается только на Postges на винде
Под linux все норм
(16)
Это факт, особенно если ежедневно делать переиндексацию и пересчет статистики.
MSSQL не надо отрубать паралелизм- он сам на основе статистики решает паралелить запрос или нет. Особенно на новых серверах с 24 ядрами и SSD дисками
Есть такой параметр стоимость паралелизма(cost of paralllelism). К примеру стоимость выполнения стоит 1000 условных процессорных единиц.
А стоимость распаралеливания на 10 частей 100. Итого стоимость выполнения будет 1100уе вместо 1000уе.
При этом нагрузится 10 ядер вместо 1. Да тест Гилева может и будет похуже, но при работе 10 пользователей и выше вы нагрузите только одно едро тем самым замедлите сервер MSSQL
а запись не скажу, а в тяжелых запросах на выборку очень сильно рулит. Заруливая постгрес как ст
Это факт, особенно если ежедневно делать переиндексацию и пересчет статистики.
MSSQL не надо отрубать паралелизм- он сам на основе статистики решает паралелить запрос или нет. Особенно на новых серверах с 24 ядрами и SSD дисками
Есть такой параметр стоимость паралелизма(cost of paralllelism). К примеру стоимость выполнения стоит 1000 условных процессорных единиц.
А стоимость распаралеливания на 10 частей 100. Итого стоимость выполнения будет 1100уе вместо 1000уе.
При этом нагрузится 10 ядер вместо 1. Да тест Гилева может и будет похуже, но при работе 10 пользователей и выше вы нагрузите только одно едро тем самым замедлите сервер MSSQL
Так как это тестовый "сервер" и диск с базами обычный HDD(зелененький), использовал рамдиск. На HDD результат теста временных таблиц в разы меньше.
По идее, на i7-9700К должно быть быстрее, так как и частота и кэш процессора больше. И внутренняя архитектура процессора лучше оптимизирована, по сравнению с предыдущими поколениями(в обзорах каждой следующей модели так пишут).
В общем всем спасибо за участие. Касательно решения самой проблемы, думаю, что всё таки:
1) Низкая популяция попугаев обусловлена тем, что те, кого я попросил либо не крутили энергосбережение в биосе, либо недокрутили. Поехать к машине я смогу очень нескоро. Как доеду - проверю отпишусь (если это вообще произойдёт).
(То есть получается дело не в настройках MSSQL, так как если бы это было так, уважаемые инфостаровцы указали бы мне путь к попугаям.)
2) Postgres после этого, скорее всего тоже почуствует себя бодрее. И сопоставимых результатов как не крути не будет.
3) Надо включать в свой арсенал тест Fragster'a.
Посему свой вопрос считаю на этом закрытым. Обещанные шеккели раздам наиболее активным участникам.
Всем спасибо!
1) Низкая популяция попугаев обусловлена тем, что те, кого я попросил либо не крутили энергосбережение в биосе, либо недокрутили. Поехать к машине я смогу очень нескоро. Как доеду - проверю отпишусь (если это вообще произойдёт).
(То есть получается дело не в настройках MSSQL, так как если бы это было так, уважаемые инфостаровцы указали бы мне путь к попугаям.)
2) Postgres после этого, скорее всего тоже почуствует себя бодрее. И сопоставимых результатов как не крути не будет.
3) Надо включать в свой арсенал тест Fragster'a.
Посему свой вопрос считаю на этом закрытым. Обещанные шеккели раздам наиболее активным участникам.
Всем спасибо!
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот