Еще один тест 1C: Postgres SQL 11 Pro Enterpise против MSSQL 14 под Windows 2012 Server R2
База данных - HighLoad оптимизация
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
| Наименование | Скачано | Купить файл | По подписке PRO |
|---|---|---|---|
|
Файл настроек 11 при котором все тормозит (Стандартные по умолчанию) postgresql.conf
.conf 24,29Kb
14
|
14 | 2 500 руб. Купить | 1 SM Скачать |
|
Файл настроек Postgres SQL 10-11 при котором все работает быстро (под сервер 16-32 RAM)postgresql.conf
.conf 23,18Kb
66
|
66 | 2 500 руб. Купить | 1 SM Скачать |
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
В качестве теста решил использовать:
- Тест 1 - знаменитый всем тест Гилева
- Тест 2 - загрузка базы данных из dt файла. база - 1C Бухгалтерия предприятия 3.0 (3.0.72.70). Критерий оценки время на удаление
- Тест 3 - Обработка по поиску и удалению данных по одной организации в 1C Бухгалтерия предприятия 3.0 (3.0.72.70) (база данных плюс минус на 15 гигабайт). Критерий оценки время на удаление
- тест 4. Перепроведение всех Документов базы с начала. 1C Бухгалтерия предприятия 3.0 (3.0.72.70). Критерий оценки Время на проведение
- тест 5 - тест fragster.ru
По моим наблюдениям, несомненным плюсом Postgres является тот факт, что Postgres более оптимально использует ресурсы (Память, CPU, накопитель)
Поэтому я умышленно установил лишь 8Gb памяти для того чтобы дать фору Postgres
В Качестве подопытного ПК Будем использовать машину, о которой я писал в статье //infostart.ru/public/992238
Характеристики подопытного ПК:
- Intel Xeon E3 1270 3,4 ГГц LGA1155 8 MB 4 ядра Процессор процессор E3-1270 SR00N (полный серверный аналог i7 2600K без встройки gpu) В разгоне 3,8Ghz
- 8G RAM 1333Mhz,
- SSD samsung 860 pro 250gb,
- Видеокарта - 6970 2 gb GPU с выходом mini DP
- Добротный блок питания 850Ватт Corsair HX850i
- 1C Сервер предприятия x64 v8.3.12.1790
- 1C клиент x64 v8.3.12.1790
- ОСь Windows 2012 Server R2
Итак, начнем тесты:
1. Первый тест - тест Гилева:
Результаты по Postgres 11
Результаты по MSSQL 14
Результаты теста Гилева:
- в пользу MSSQL 14 в одно-поточном режиме 29 попугаев MSSQL против 23 Postgres.
- 188Mb/сек в пользу Postgres против 140Mb/сек MSSQL в много-поточном режиме без опции SNAPSHOT_ISOLATION ON
Важное замечание. Если MSSQL перевести в режим SNAPSHOT_ISOLATION ON (Изоляция снимков, версионирование) - то MSSQL начинает хранить снимки баз до транзакции в памяти и дико выедает всю доступную оперативную память, отказываясь использовать файл подкачки.
Для этого снимаем конфигурацию Гилева с поддержки и снимаем режим совместимости, так как изоляция снимков работает только начиная с 11-12 платформы. После чего выполняем скрипт на базе.
В результате тест Гилева в много-поточном режиме вываливается с ошибкой из за нехватки памяти ОЗУ(RAM)
Если увеличить память машины до 16-32GB в режиме SNAPSHOT_ISOLATION ON Postgres так же обходит MSSQL .
Так что первый тест за Postgres
Тест 2: загрузка базы данных из dt файла.
Время на загрузку базы из *.dt файла
- MSSQL 1 минута 49 секунд
- Postgres - 2 минуты 20 секунд
Второй тест в копилку MSSQL Server 
Тест 3: Обработка по поиску и удалению данных по одной организации в 1С Бухгалтерия 3.0 (база данных плюс минус на 15 гигабайт).
Обработка находится тут //infostart.ru/public/1013709
Результаты отладки по MSSQL:
Результат MSSQL - 6422 секунды или почти 2 часа.
Результат Postgres - 61756 секунды или 17 с лишним часов
Итого MSSQL отрабатывает результат почти в 10 раз быстрее. Почему? Возможно в том, что Функция НайтиСсылкиНаСервере отправляет кучу мелких запросов, а MSSQL работает в режим Shared Memory, а Postgres в протоколе TCP/IP, из за чего возникает задержка между сервером предприятия 1С и СУБД. В связи с чем получаем дикую просадку по скорости.
Для Posgres Shared Memory так же настраивал, но увы скорости не прибавилось, так как этот параметр отвечает за совсем другую функциональность и не влияет на протокол обмена. Возможно руки кривые или лыжи не едут, так что критика тут уместна.
# PostgreSQL configuration file
shared_buffers = 3GB
Вывод - если вы используете Сервер предприятия на одной машине с MSSQL сервер - используйте протокол Shared Memory и еще один попугай в пользу Майкрософт.
Тест 4. Перепроведение всех Документов базы. Ссылка на обработку //infostart.ru/public/1117962/
Результаты MSSQL - 58 минут 47 секунд
Результаты Postgres- 8 часов 39 минут 47 секунд
Почему так долго не знаю. Параметры двигал туда сюда, не помогает, все равно долго.
Любопытные могут скачать настройки Postgres за 1 инфо-шейкель в описании.
Еще один жирный попугай в пользу Майкрософт
Update Важное дополнение: В режиме TCP MSSQL проводил документы 1 час 17 минут. Почему так тормозит Postgres SQL 11 PRO - не знаю.
Тест 5 - тест fragster.ru
Результаты тестов:
| Временные таблицы | Справочники | Регистры сведений | Регистры накопления | Регистры бухгалтерии | |||||||||||
| Тест | Postgres | MSSQL | Разница | Postgres | MSSQL | Разница | Postgres | MSSQL | Разница | Postgres | MSSQL | Разница | Postgres | MSSQL | Разница |
| 13 935,27 | 72 885,73 | 58 950,46 | 12 561,00 | 12 271,91 | -289,09 | 9 123,00 | 9 489,09 | 366,09 | 8 941,00 | 9 363,00 | 422,00 | 8 567,82 | 9 112,45 | 544,63 | |
| 1 | 5 096,00 | 12 938,00 | 7 842,00 | 3 035,00 | 2 879,00 | -156,00 | 2 055,00 | 2 221,00 | 166,00 | 2 004,00 | 2 247,00 | 243,00 | 1 929,00 | 2 137,00 | 208,00 |
| 2 | 8 282,00 | 28 725,00 | 20 443,00 | 6 177,00 | 5 920,00 | -257,00 | 4 453,00 | 4 533,00 | 80,00 | 4 304,00 | 4 423,00 | 119,00 | 4 082,00 | 4 302,00 | 220,00 |
| 4 | 11 927,00 | 54 045,00 | 42 118,00 | 10 968,00 | 10 112,00 | -856,00 | 7 923,00 | 7 764,00 | -159,00 | 7 716,00 | 7 727,00 | 11,00 | 7 320,00 | 7 321,00 | 1,00 |
| 8 | 13 680,00 | 78 023,00 | 64 343,00 | 15 356,00 | 14 564,00 | -792,00 | 11 179,00 | 11 356,00 | 177,00 | 10 839,00 | 11 135,00 | 296,00 | 10 196,00 | 10 804,00 | 608,00 |
| 16 | 16 691,00 | 78 931,00 | 62 240,00 | 14 634,00 | 14 418,00 | -216,00 | 10 941,00 | 11 249,00 | 308,00 | 10 767,00 | 11 340,00 | 573,00 | 10 439,00 | 11 077,00 | 638,00 |
| 32 | 16 676,00 | 79 000,00 | 62 324,00 | 14 843,00 | 14 681,00 | -162,00 | 10 842,00 | 11 151,00 | 309,00 | 10 637,00 | 11 176,00 | 539,00 | 10 186,00 | 10 861,00 | 675,00 |
| 48 | 16 056,00 | 78 930,00 | 62 874,00 | 14 782,00 | 14 612,00 | -170,00 | 10 757,00 | 11 273,00 | 516,00 | 10 342,00 | 10 895,00 | 553,00 | 9 808,00 | 10 816,00 | 1 008,00 |
| 64 | 15 866,00 | 78 677,00 | 62 811,00 | 14 361,00 | 14 522,00 | 161,00 | 10 451,00 | 11 250,00 | 799,00 | 10 513,00 | 11 073,00 | 560,00 | 9 896,00 | 10 760,00 | 864,00 |
| 80 | 16 084,00 | 78 670,00 | 62 586,00 | 14 561,00 | 14 426,00 | -135,00 | 10 103,00 | 11 229,00 | 1 126,00 | 10 206,00 | 11 034,00 | 828,00 | 10 150,00 | 10 727,00 | 577,00 |
| 96 | 16 520,00 | 78 493,00 | 61 973,00 | 14 814,00 | 14 426,00 | -388,00 | 10 808,00 | 11 215,00 | 407,00 | 10 456,00 | 10 956,00 | 500,00 | 10 111,00 | 10 712,00 | 601,00 |
| 112 | 16 410,00 | 155 311,00 | 138 901,00 | 14 640,00 | 14 431,00 | -209,00 | 10 841,00 | 11 139,00 | 298,00 | 10 567,00 | 10 987,00 | 420,00 | 10 129,00 | 10 720,00 | 591,00 |
По таблице видно что Postgres незначительно выигрывает в работе со справочниками, но примерно в 10 раз медленнее работает с временными таблицами. Так как в MSSQL поздних версий временные таблицы кешуруются в ОЗУ(RAM). Результаты по регистрам примерно одинаковы в обеих СУБД, с небольшим преимуществом MSSQL. Этот тест так же в копилку Мйкрософт
Счет 1-5 в пользу Майкрософт.
Так что 11-ый слон по прежнему медленный, но в случае возникновения блокировок - слон как всегда более проходимый чем Лошадь от Microsoft.
От себя: Исходя из личного опыта сделал вывод:
- Если железо мощное нет узких мест в ресурсах = то Лучше MSSQL
- Так же с переходом на Postgres, gjxnb забыл о злощасных мертвых блокировках от которых в MSSQL невозможно Избавиться(SNAPSHOT_ISOLATION ON отчасти решают проблему но не всегда, особенно в типовых релизах).
- Так же при переходе на Postgres необходимо переписывать запросы суммирования ISNULL(значение1)+ISNULL(значение2), не то получим отчет с NULL. Соответствующей настройки "объединение со значением NULL дает NULL off" - в Postgres не нашел.
- Если ваш сервер трещит по швам, не хватает памяти или прочих ресурсов, денег на новый сервер нет - держитесь за Postgres SQL на Linux
Update 08.09.2019
Установил версию Postgres SQL 10.8-18.1C с сайта 1c.ru. Настройки postgres выставил те что во вложении.
Итого получил результат по тесту перепроведения документов:
- Время начала: 08.09.2019 20:24:04
- Время окончания: 08.09.2019 21:49:28
- Итого время 1 час 25 минут, что всего на пол часа больше чем MSSQL и на 7 часаов быстрее чем Postgres 11 версии (со стандартными настройками с сайта www.postgresql.org)
Чуть позже применил эти же на стройки на Postgres Pro 11 и получил результат по тесту перепроведения документов:
- Время начала: 08.09.2019 22:16:55
- Время окончания: 08.09.2019 23:38:29
1 час 22 минуты при настройках во вложении.
Вступайте в нашу телеграмм-группу Инфостарт
См. также
HighLoad оптимизация Разработчик 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free)
Использование оператора «В» для полей или данных составного типа (например, Регистратор) может приводить к неочевидным проблемам.
10.11.2025 15898 ivanov660 48
HighLoad оптимизация Разработчик 1С:Предприятие 8 1C:ERP Бесплатно (free)
Приведем примеры использования различных в динамических списках и посмотрим, почему это плохо.
18.02.2025 16501 ivanov660 39
HighLoad оптимизация Системный администратор Разработчик 1C:ERP Бесплатно (free)
Не всегда индексирование с дополнительным упорядочиванием полезно.
04.02.2025 15142 ivanov660 21
HighLoad оптимизация Разработчик Россия Бесплатно (free)
А вы знали, что сервер 1С при соединении с базой на сервере PostgreSQL самостоятельно устанавливает некоторые параметры? Это важно знать при настройке сервера и отладке долгих запросов. Предлагаю разобраться.
27.08.2024 10412 soulner 10
HighLoad оптимизация Технологический журнал Системный администратор Разработчик Бесплатно (free)
Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.
24.06.2024 19143 ivanov660 13
HighLoad оптимизация Разработчик 1С:Предприятие 8 Бесплатно (free)
Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.
06.06.2024 24987 Evg-Lylyk 73
HighLoad оптимизация Механизмы платформы 1С Системный администратор Разработчик Стажер 1С:Предприятие 8 Бесплатно (free)
Сравним «Регистры сведений» с «Сервисами интеграции» и узнаем, кто быстрее!
28.03.2024 14636 dsdred 27
HighLoad оптимизация Разработчик 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)
Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.
13.03.2024 14628 spyke 29
делаются специально.
Чтобы удобно было сравнивать мягкое с квадратным.
Желательно акцент делать на характеристиках и настройках баз данных + ОС.
Потому что сейчас вы продемонстрировали результат, который непонятно откуда произошел.
Добавил в описание.
делаются специально.
То что Postgres не умеет работать на Shared Memory я не виноват - выжимал из настроек по максимуму и там и там.
Лично сам болел за слона - но увы эксперимент есть эксперимент.
Позже сделаю тест без Shared Memory, чтобы не дискредитировать слонов, но все равно не думаю что будет 17 часов проводиться. Мой прогноз не более 3 часов.
Так же скоро будет подобный тест, но уже на новом 32-ух ядерном сервере. Но это уже будет другой тест
Ну не правда. Посмотрите на формат строки подключения к PostgeSQL:
Там ясно указано:
Таким образом, если сервер приложений системы "1С: Предприятие 8" и PostgresSQL будут размещены на одном компьютере под управлением Linux, то в настройках подключения к БД можно будет указать путь к файлу сокета и системы будут передавать данные друг другу без использования сетевого стека.
Тут согласен - если Слона поместить в Linux, особенно в последнюю версию Ubuntu и настроить подключение под Unix-сокет Слоник начинает быстрее бегать.
Тем не менее более 90% всех серверов 1С работают на виндовозе. Не понимаю почему в Posgres нет норм настроек по Мастдайные сервера?
"для приёма подключений открыт Unix-сокет "/tmp/.s.PGSQL.5432""
local all all trust
Как-то не горит желания 1с запускаться ((
is the server running locally and accepting connections on unix domain socket /localhost/.s.PGSQL.5432 ?
Не понимаю как поженить tmp и localhost и нужно ли. На /tmp 1с подключаться не хочет (
UPD: допер! на /tmp была ошибка уже по авторизации. Не закоментил local all all peer
UUPD: любопытно, что тест гилева на локальной видовой машине показал в КС 19 попугаев, а в тормознутом VirtualBox на linux (1c+pg) 23 что на сокете, что на IP (localhost). И все на дефолтных настройках.
Тест Гилева он только попугаев и считает.
local all all trust
localhost - это tcp, а не сокет. Забыл уже как вбивал... то ли /tmp, то ли полностью как выше.
hba: так как выше - точно работает
Доступное и понятное изложение проблемы
Это в лог файлах смотреть? Есть ли опыт по устранению?
Так что, можно приобрести Postgres Prо, одну из редакций, или использовать Linux.
Собственный "опыт по устранению"(вернее, его отсутствие) - применение среды Linux и для PostgreSQL и для 1С. Если бы не жалобы на форумах и это видео, я бы и не знал о такой проблеме.
переименование/удаление спокойно выполняет запущенные или изменяемые в текущий момент файлы
например удаление техжурнала сервера в момент работы ведет к очень интересному поведению)
Не знаю, не пробовал. Не было такой необходимости.
В "поведенческой модели" Linux(Unix) предполагается, что специалист, использующий ее(операционную систему), обычно ответственен за свои действия и обладает достаточным пониманием того, что делает, а не "тычет мышкой куда попало".
Сделал настройки исключительно под этот тест в результата увеличилась скорость проведения больше чем в 2 раза
max_connections = 20
shared_buffers = 512MB
effective_cache_size = 12GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 500
random_page_cost = 1.1
work_mem = 67720kB
min_wal_size = 4GB
max_wal_size = 8GB ПоказатьПроведение документов уменьшилось до 6 часов 31 минут
Данные настройки рассчитаны на работу 20 соединений исходя из параметров моего старого серверочка 16GB RAM
В Бухе 3-ей по умолчанию стоят управляемый режим блокировок данных
Поэтому ничего удивительного.
В автоматическом режиме платформа ставит блокировки сама, хотя ставить их и не имеет смысла.
А в управляемом вы это отключаете.
С монопольным режимом еще можно поиграться
Никогда не поверю что настолько постгри тормознутее скуля.
С другой стороны ставить постгри на винду на больших базах - то еще извращение, постгри родная стихия это линукс.
И рекомендация конечно тоже супер.
Расскажите ее 1С-ам у них же фреш на постгри крутится.
Итого получил результат по тесту перепроведения документов:
Время начала: 08.09.2019 20:24:04
Время окончания: 08.09.2019 21:49:28
Итого время 1 час 25 минут, что всего на пол часа больше чем MSSQL и на 7 часаов быстрее чем Postgres 11 версии
Время начала: 08.09.2019 22:16:55
Время окончания: 08.09.2019 23:38:29
1 час 22 минуты при настройках во вложении (всего 3 минуты в режиме TCP ).
В итоге почти догнали MSSQL 14 ( режиме TCP MSSQL проводил документы 1 час 17 минут.)
Отсюда мораль - надо думать перед тем как шашкой махать.
На самом деле можно ничего не измерять, а просто порассуждать логически.
Пишется один и тот же объем данных +- 5%
Обе базы реляционные с одинаковой структурой таблиц.
Если обоим хватает ресурсов, то с чего бы получилась разница.
За счет того что постгри версионник, а скуль блокировочник дольше идет работа с временными таблицами.
В вашем варианте тестов они практически не используются и опять же - это происходит потому что постгри упирается в файловую систему винды.
На линуксе и быстрых дисках все будет ровнее.
На Ubuntu PGSQL все работает ровно. Заметил лишь то что соединения с временными таблицами работают ну дико медленно -
1 . если нет индекса временной таблы.
2 Если этот индекс делать то тоже медленно.
MSSQL - тоже стал версионником, только 1С с этим не всегда правильно работает.
происходит потому что постгри упирается в файловую систему винды.Думаю слоны упираются в то что слоны разрабатывались для Linux, а пользуются спросом в РФ 1С Windows
PGSQL мотивируют это тем что:
1. 1C с его большим количеством таблиц для него агрессивная среда.
2. Виндовоз для него тоже Агрессивная среда.
Тогда возникает вопрос для кого слоны создавались?
Так ведь шашкой никто не машет, а вот на стандартной конфигурации PG пол России тупит. За 2 месяца перенастроил много баз PG 10 и все стало работать быстрее.
Что касается 9-ой версии PG - на ней не надо было менять настройки - скачал с сайт 1С и все работает нормально.
До 3.22 версии были у Дельфина ограничения по объему баз.
до 5-ой версии были торможения при базах свыше 10 Гиг и тормоза с большими запросами(Union All с группировками итп).
На сегодняшний у дельфина вообще проблем нет.
Во Веб приложениям дельфин - это как Ferrari и слонам там места не оставили.
Да в системах документооборота с использованием версионирования слоны, при правильной ахитектуре таблиц в несколько раз превосходят MSSQL.
опять же зависит от многих факторов, в базах в несколько 10тб уже условия другие будут
Вопрос есть ли такие рабочие базы 1С? Максимум я работал с 1 ТБ базой ERP на MSSQL 14.
Перевести ее на Postgree для теста не могу, так как при выгрузке базы в *.dt файл вываливается с ошибкой.
Так что будет до конца дней жить в майрософте.
Читал на форуме "Слоноводов" - то что в 11 Ent данную проблему решили и мол даже получили выигрыш над Оракулом и Мелкомягкими.
Проверить пока что не могу. Пишу конвертацию по полной выгрузке базы 1ТБ базы. Пока что не получилось получить 100% аналог.
вот одна из картинок.
В одиннадцатой версии системы ускорили формирование индексов, а также внедрили покрывающие индексы и улучшили индексный поиск по JSON. Также оптимизировали механизмы одновременного исполнения запросов и секционирования таблиц. Повысилось удобство создания SQL-запросов, оконные функции теперь полностью покрывают стандарт языка SQL:2011. Транзакциями в процедурных языках, которые поддерживает решение, можно управлять вручную.
Postgres Pro Enterprise 11 получил расширенную поддержку управления доступом пользователей, в частности, на уровне отдельных записей. Интегрировали в решение и ключевые криптографические функции семейства SHA2, призванные вывести на новый уровень надежность хранения хешей паролей. В новой версии поддерживаются автономные транзакции и есть нативный планировщик заданий.
А у вас имеются опыт по работе с большими данными в PG 11 Pro Ent?
Вот еще немного цитат из рекламных буклетов:
Да данный функционал, очень хорошо приживается к 1С. К Вебу больше нужна скорость отдачи данных, никто не будет ждать пока сайт открывается 20 и более секунд.
Единственно что она может быть критична к конфигурации сервера потому что все тащит в память как скуль или не критична как мускуль
В принципе все это регулируется настройками, потому что каждый создатель СУБД хочет и старается чтобы ее везде использовали
например для постгри есть сайт леонард ин уа и там как раз можно взять нормальные настройки под любой вариант использования.
Поэтому рассказывать что какая то СУБД из первой пятерки в разы превосходит какую то из первой же пятерки - это просто кривые настройки 99%
Есть профессиональное тестирование TPC и у него есть сайт на котором все СУБД гордятся собой там можно все это увидеть
Как правило все проф тесты - есть маркетинг. Никаких реальных данных там нет.
Сам по себе данный топик был после того как на сайте Postgres(на Инфостарте есть перевод статьи) увидел рекламу в которой обещали двукратный прирост скорости по сравнению с 10-ой версии. После 2 недель различных изнурительных тестов с разными настройками 10 и 11 версии - никакого роста не увидел, сплошь маркетинг для недалеких домохозяек.
Видать надо было как то обосновать траты на покупку Postgres SQL 11 Ent. При чем я скажу стоимость там не детская и даже выше чем у MSSQL, даже с учетом цен на операционку Windows Server 20**
Из чего складываются цены на Postgres SQL 11 Ent не понятно.
При чем я так понимаю в связи с использованием Postgres SQL - возникают риски что на какой нибудь 19 платформе 1С КОРП, надо будет купить лицензии Postgres Enterprise - не то там какие нибудь ядра перестанут функционировать.
А пока то продолжаю пользовать 10-у версию слона с сайта users.v8 доп настройками под 1С.
Иногда есть и нормальные исследования, но нигилистам этого не понять
И маленько уже подзадолбали эти рассказы про купить лицензии Postgres Enterprise
Уже стерся отвечать - для 1С постгри бесплатный
Точка
Если интересно - здесь же уже раз 100 отвечал можно погуглить
Полностью согласен - еще бывает пропаганда и агитация.
Если есть ссылки на норм проф исследования pg на 1С то пожалуйста выложите.
Все же чутка подприкупили лицензий pg 11 pro ent для одного Муниципалитета(централиз бухгалтерия), чтобы разбавить Заморские продукты с "Аля Российскими". Есть требование к гос. закупкам - процентное соотношение Российское-Заморское ПО - для гос компаний.
Массовую закупку слонов - не планируем.
В обосновании на покупку так и написали:
Да согласен. Под типовые решения от 1С БУХ 3.0, УТ 11, ЗУП 3.1
небходимы особые настройки
Как мимнимум
autovacuum = on
online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable = on
online_analyze.verbose = off
online_analyze.local_tracking = on
online_analyze.min_interval = 10000
online_analyze.table_type = 'temporary' - спорный иногда необходим online_analyze.table_type = 'all' (Если база маленькая)
Эта настройка под Linux как турбина для Лады калины при выполнении больших запросов, особенно заметно на динамических списках.
shared_preload_libraries = 'online_analyze, plantuner'По моим скромным наблюдениям - под Виндовозом данный параметр - эффекта не дает
random_page_cost = 1.1seq_page_cost = 0.1fsync = offrow_security = offНа хорошем аппаратном RAID контроллере с кэшем в 1-4 ГБ и модулем защиты кэша
fsync = on и full_page_writes=on почти не приводят уменьшению производительности. Оно наблюдается, в основном, на обычных SATA HDD. Хотя, и не так сильно как на более ранних версиях PostgreSQL лет 7-8 назад. То есть, выключить можно, но смысла нет.
fsync = on и full_page_writes=on почти не приводят уменьшению производительности. Оно наблюдается, в основном, на обычных SATA HDD. Хотя, и не так сильно как на более ранних версиях PostgreSQL лет 7-8 назад. То есть, выключить можно, но смысла нет.
На одной большой базе:
1 ERP база почти 2 TB
2. Контроллер HPE P440/4G Smart Array (чтение/запись с суперконденсатором)
3. SSD 480 Gb Intel DC S4600 - 8 шт
4. Vmware ESXi
5 Wind Server 2018
Кеш не справляется. Видно это по счетчикам: %WAIT и %VMWAIT утилиты esxtop.
Если вешаю базу на отдельный 4 Tb SSD диск без Хранилки на sata порт без Raid контроллера (SSD 3.84 Tb SATA D3-S4610 ) - то скорость выпростает почти в 1.5 раза.
Правда база на MSSQL.
Похоже пора хранилку покупать с кешем 10gb и выше
SSD 400 - 1200 Gb SAS 12Gb/s вполне подойдут для такой высоконагруженной системы, они уже и не очень дорого стоят.
Скорость чтения До 2150 Мб/сек
Скорость записи До 2120 Мб/сек
IOmeter, скорость записи 4Кб файлов, глубина очереди=32 320000 IOPS
Это заявляется для Western Digital Ultrastar DC SS530 800 Гб
При интенсивном чтении/записи/перезаписи какова нагрузка на CPU? Процентов 90 или меньше?
причем тут дисковый массив и эти счетчики, эти счетчики показывают сколько вообще ждет машина ресурсов. У вас может балансировка кривая или банально не хватка памяти на хосте, загонят в свопинг машины.
Сначало делали 2 виртуалки + Сервер 1С и Скуль.
Сейчас одна виртуалка. Балансировать нечего. Смысл в том что на одном ssd все быстре фурышчит.
Вывод сделал что рейд контролер слабый. Счетчиков-статистики использования памяти Raid контроллера не нашел
Памяти 512gb. Я так краем уха слышал что SSD плохо работают с RAID контроллерами.
Говорят под них надо покупать специализированные SSD полки
Потом забил на это дело. Начал выгружать доки в XMLб только времени не хватает - лучше так и жить в Майкроскуле
Хорошая идея - сделаю план обмена типовой по Организации и попробую выгрузить ;-)
Встречаются два приятеля.
Один хвастается: "Купил слона! Так здорово! Он теплый такой, дом согревает, с детьми играет, огород поливает!"
Второй приятель: "Продай слона!"
Первый: "Нет! Слон такой хороший! На хоботе у него можно покачаться, в жаркий день он фонтаном работает! Нет, не продам слона!"
В конце концов второй уговорил продать ему слона.
Встречаются на следующий день.
Второй приятель: "Слушай, твой слон мне всю мебель переломал, кучу сделал, детей напугал!"
Первый: "Ну-у с таким настроением ты слона не продашь!"
1 - если размер базы больше чем доступная память, online_analyze.enable = on, начинаются тормоза и блокировки.
2 - По MSSQL - та же история при включенном версионировании снимков.(Snapshot Level). Видно по первому тесту гилева с вываливание ошибки при нехватке оперативной памяти
для себя сделал рекомендации по памяти RAM под БД с уровнем комфорта 5+:
1 Posgres - Объем рабочих баз умножить на 1
effective_cache_size - размер рабочих баз /2 и при этом не меньше половина от памяти RAM
2. MSSQL с включенным версионированием снимков в режиме совместимости ядра 8.3.12 и выше - Объем рабочих баз умножить на 1,5
#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------
# - Connection Settings -
listen_addresses = '*' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
# (change requires restart)
port = 5432 # (change requires restart)
max_connections = 100 # (change requires restart)
#------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------
# - Memory -
shared_buffers = 4128MB # min 128kB
shared_preload_libraries = 'online_analyze, plantuner' # (change requires restart)
#------------------------------------------------------------------------------
# QUERY TUNING
#------------------------------------------------------------------------------
effective_cache_size = 12512MB
#------------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#------------------------------------------------------------------------------
# - Where to Log -
log_destination = 'stderr' # Valid values are combinations of
# This is used when logging to stderr:
logging_collector = on # Enable capturing of stderr and csvlog
# - What to Log -
log_line_prefix = '%t ' # special values:
# %t = timestamp without milliseconds
log_timezone = 'Asia/Yakutsk'
# - Locale and Formatting -
datestyle = 'iso, dmy'
timezone = 'Asia/Yakutsk'
# These settings are initialized by initdb, but they can be changed.
lc_messages = 'Russian_Russia.1251' # locale for system error message
# strings
lc_monetary = 'Russian_Russia.1251' # locale for monetary formatting
lc_numeric = 'Russian_Russia.1251' # locale for number formatting
lc_time = 'Russian_Russia.1251' # locale for time formatting
# default configuration for text search
default_text_search_config = 'pg_catalog.russian'
#------------------------------------------------------------------------------
# LOCK MANAGEMENT
#------------------------------------------------------------------------------
max_locks_per_transaction = 150 # min 10
# (change requires restart)
#------------------------------------------------------------------------------
# CUSTOMIZED OPTIONS
#------------------------------------------------------------------------------
online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable = off
online_analyze.verbose = off
online_analyze.min_interval = 10000
online_analyze.table_type = 'temporary'
plantuner.fix_empty_table = true
в общем так
Рейтинг: 433
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1117806
Создание 05.09.19 15:00
Обновление 03.10.23 16:21
Просмотры 27656
Загрузки 80
Рейтинг
19
Комментарии 107
Код открыт Да
Рубрики HighLoad оптимизация
Тип файла Архив с данными
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Windows
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
