Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз

Публикация № 1023353

Администрирование - Производительность и оптимизация (HighLoad)

124
В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

В Amplitude наша цель — предоставить простую в использовании интерактивную аналитику продуктов, чтобы каждый мог найти ответы на свои вопросы о продукте. Чтобы обеспечить удобство работы, Amplitude должен быстро предоставить эти ответы. Поэтому, когда один из наших клиентов пожаловался на то, сколько времени потребовалось для загрузки раскрывающегося списка свойств события в пользовательском интерфейсе Amplitude, мы приступили к детальному изучению проблемы.

Отслеживая задержку на разных уровнях, мы поняли, что одному конкретному запросу PostgreSQL потребовалось 20 секунд для завершения. Для нас это стало неожиданностью, так как обе таблицы имеют индексы в соединяемом столбце.

image

Медленный запрос


План выполнения PostgreSQL для этого запроса был для нас неожиданным. Несмотря на то, что в обеих таблицах есть индексы, PostgreSQL решил выполнить Hash Join с последовательным сканированием большой таблицы. Последовательное сканирование большой таблицы занимало большую часть времени запроса.

image

План выполнения медленого запроса


Я изначально подозревал, что это может быть из-за фрагментации. Но после проверки данных я понял, что в эту таблицу данные только добавляются и практически не удаляются оттуда. Так как очистка места с помощью VACUUM здесь не очень поможет, я начал копать дальше. Затем я попробовал этот же запрос на другом клиенте с хорошим временем ответа. К моему удивлению, план выполнения запроса выглядел совершенно иначе!

image

План выполнения того же запроса на другом клиенте


Интересно, что приложение A получило доступ только к 10 раз большему количеству данных, чем приложение B, но время отклика было в 3000 раз больше.

Чтобы увидеть альтернативные планы запросов PostgreSQL, я отключил хеш-соединение и перезапустил запрос.

image

Альтернативный план выполнения для медленного запроса


Ну вот! Тот же запрос завершается в 50 раз быстрее при использовании вложенного цикла вместо хэш-соединения. Итак, почему PostgreSQL выбрал худший план для приложения A?

При более тщательном рассмотрении предполагаемой стоимости и фактического времени выполнения для обоих планов предполагаемые соотношения стоимости и фактического времени выполнения были очень разными. Основным виновником этого несоответствия была оценка стоимости последовательного сканирования. PostgreSQL подсчитал, что последовательное сканирование было бы лучше, чем 4000+ сканирований индекса, но в действительности сканирование индекса было в 50 раз быстрее.

Это привело меня к параметрам конфигурации random_page_cost и seq_page_cost. Значения PostgreSQL по умолчанию 4 и 1 для random_page_cost, seq_page_cost, которые настроены для HDD, где произвольный доступ к диску дороже, чем последовательный доступ. Однако эти затраты были неточными для нашего развертывания с использованием тома gp2 EBS, которые являются твердотельными накопителями. Для нашего развертывания случайный и последовательный доступ практически одинаков.

Я изменил значение random_page_cost на 1 и повторил запрос. На этот раз PostgreSQL использовал Nested Loop, и запрос выполнялся в 50 раз быстрее. После изменения мы также заметили значительное снижение максимального времени отклика от PostgreSQL.

image

Общая производительность медленного запроса значительно улучшилась


Если вы используете SSD и используете PostgreSQL с конфигурацией по умолчанию, я советую вам попробовать настроить random_page_cost и seq_page_cost. Вы можете быть удивлены сильным улучшением производительности.

От себя добавлю, что я выставил минимальные параметры seq_page_cost = random_page_cost = 0.1, чтобы отдать приоритет данным в памяти (кэш) над процессорными операциями, так как у меня выделено большое количество ОЗУ для PostgreSQL (размер ОЗУ превышает размер базы на диске)

Оригинал статьи Источник на хабре

124

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. spectre1978 50 18.03.19 17:03 Сейчас в теме
Респект и звезда! Утащу к себе.
2. user-z99999 21 18.03.19 17:11 Сейчас в теме
Для повышения рейтинга можно копировать статьи Хабр?
))
SerVer1C; Plotks2017; SavR11; genayo; +4 Ответить
4. w.r. 468 18.03.19 18:22 Сейчас в теме
(2) статья не моя, а перевод мой - с копирайтами все впорядке, не переживайте
3. capitan 1281 18.03.19 17:18 Сейчас в теме
Ну то есть Pavan Patibandla получал планы запросов и курил мануалы )
Это не оно случайно ?
Прикрепленные файлы:
igee12; bajiepka; Plotks2017; TODD22; +4 1 Ответить
5. w.r. 468 18.03.19 18:31 Сейчас в теме
(3) то, что описывают 1С - частные случаи, не всегда приводящие к выигрышу в производительности. Например, рекомендуют отключать Nested Loops. А что получается, когда поиск значений для соединения таблиц идёт с помощью их хэшей (Hash Join) - видно в статье - замедление работы почти в 50 раз по сравнению с поиском с помощью вложенных циклов (Nested Loops). Есть очень хорошая статья на хабре по базам данных https://habr.com/ru/company/mailru/blog/266811/ доходчиво и очень понятно написано
mickey.1cx; +1 Ответить
6. Dream_kz 93 18.03.19 19:51 Сейчас в теме
(5) Ну вообще как бы да, эти настройки описаны в мануалах
https://kb.1c.ru/articleView.jsp?id=91
random_page_cost = 1.5-2.0 для RAID, 1.1-1.3 для SSD
Стоимость чтения рандомной страницы, на которую будет опираться оптимизатор (по-умолчанию 4). Практическое значение параметра должно зависеть от «seek time» дисковой системы: чем он меньше, тем меньше должно быть значение random_page_cost (но не менее 1.0) . Излишне большое значение параметра увеличивает склонность PostgreSQL к выбору планов с сканированием всей таблицы (PostgreSQL считает, что дешевле последовательно читать всю таблицу, чем рандомно индекс). Оценка стоимости последовательного чтения делается, в свою очередь, с учетом параметра seq_page_cost, который равен по умолчанию 1.


https://postgrespro.ru/docs/postgrespro/9.5/runtime-config-query
Произвольный доступ к механическому дисковому хранилищу обычно гораздо дороже последовательного доступа, более чем в четыре раза. Однако по умолчанию выбран небольшой коэффициент (4.0), в предположении, что большой объём данных при произвольном доступе, например, при чтении индекса, окажется в кеше. Таким образом, можно считать, что значение по умолчанию моделирует ситуацию, когда произвольный доступ в 40 раз медленнее последовательного, но 90% операций произвольного чтения удовлетворяются из кеша.

Если вы считаете, что для вашей рабочей нагрузки процент попаданий не достигает 90%, вы можете увеличить параметр random_page_cost, чтобы он больше соответствовал реальной стоимости произвольного чтения. И напротив, если ваши данные могут полностью поместиться в кеше, например, когда размер базы меньше общего объёма памяти сервера, может иметь смысл уменьшить random_page_cost. С хранилищем, у которого стоимость произвольного чтения не намного выше последовательного, как например, у твердотельных накопителей, так же лучше выбрать меньшее значение random_page_cost.
mickey.1cx; smit1c; Dach; headMade; +4 Ответить
8. w.r. 468 19.03.19 07:58 Сейчас в теме
(6) это все понятно. Просто вы знали, что именно изменение этих параметров может настолько увеличить производительность PG? Я вот лично не знал
9. Dream_kz 93 19.03.19 08:40 Сейчас в теме
(8) Там изменение любого параметра может влиять на производительность в самых неожиданных местах, причем как ускорять отдельные запросы, так и замедлять другие. Настройка в соответствии с документацией решает половину проблем
10. w.r. 468 19.03.19 09:47 Сейчас в теме
(9)
Там изменение любого параметра может влиять на производительность в самых неожиданных местах

Меня это как-то немного смущает. А вас?
11. Dream_kz 93 19.03.19 10:00 Сейчас в теме
(10) Нюансы тонкой настройки, есть в этом плюсы, что можно настроить как душе угодно, и минусы, что теряется простота и универсальность. Как по мне, оптимизатор запросов в MS SQL "умнее", но из-за этого им сложнее управлять. Но нельзя говорить что в PG он плохой, просто рассчитан на специалиста.
12. w.r. 468 19.03.19 10:05 Сейчас в теме
(11) тут даже сравнивать не стоит. MS, IBM и Oracle - это автоматическая коробка передач, а PG - механика. PG не плохой, просто мне лично из документации не сильно понятна степень влияния каждого параметра на производительность системы в целом. По хорошему за такое должна отвечать автоматика, но трудно требовать такого от свободного ПО, которое пишет некое сообщество
13. capitan 1281 19.03.19 16:59 Сейчас в теме
(12)
MS, IBM и Oracle - это автоматическая коробка передач
Вы просто не представляете сколько есть аналогичных настроек у MS. С аналогичным эффектом
7. ansh15 19.03.19 02:01 Сейчас в теме
Я понимаю, что название публикации также является переводом заголовка оригинала статьи, но некоторая броскость фразы "улучшило производительность медленных запросов в 50 раз" может дать и обратный эффект.
Народ, особенно, недавно приобщающийся к миру PostgreSQL(тоже пафос...), начнет выключать hash join для любых конфигураций - типовых. нетиповых, "в хлам переписанных", оригинальных самописных. Через некоторое время будет получать просадку производительности(зависания) в тех местах, где этого в принципе не должно было бы быть. Особенно может быть весело, если все типы конфигураций присутствуют одновременно. После чего будут раздаваться обиженно-гневные возгласы - ""Ваш этот Постгрес..." и далее все многообразие "непереводимых идиоматических выражений". "Да лучше бы мы MS SQL купили!"
Я это к тому, что результат изысканий автора статьи надо рассматривать с той точки зрения. что в ряде частных случаев изменение тех или иных параметров(или их совокупности), влияющих на оптимизацию работы СУБД может оказаться приемлемым. Для конкретной базы данных и конкретного запроса к ней. Как и в случае с 1С.
wowik; monkbest; fancy; w.r.; +4 Ответить
22. Crazy_Max 55 28.06.19 13:41 Сейчас в теме
(7) Те, кто поступит именно так, как вы описали, пусть на самом деле покупают MS SQL. Всё абсолютно верно!
23. w.r. 468 28.06.19 18:47 Сейчас в теме
(22)

Купил, поставил и не паришься ) Если денег много - почему нет? )
Crazy_Max; +1 Ответить
14. a.doroshkevich 491 19.03.19 17:03 Сейчас в теме
seq_page_cost = random_page_cost = 0.1
Так делать нельзя ни в коем случае.
seq_page_cost = 1 не просто так, а потому что является ориентиром всех остальных коэффициентов.
15. w.r. 468 19.03.19 18:37 Сейчас в теме
(14) 1C сами рекомендуют понизить seq_page_cost до 0.1 и random_page_cost до 0.4

https://its.1c.ru/db/metod8dev/content/4692/hdoc

А вы говорите так делать нельзя ни в коем случае. Каковы основания доверять вашим словам?
Crazy_Max; +1 Ответить
17. a.doroshkevich 491 20.03.19 12:57 Сейчас в теме
(15)Прочитайте документацию разработчика БД по этому параметру.

Переменные стоимости, описанные в данном разделе, задаются по произвольной шкале. Значение имеют только их отношения, поэтому умножение или деление всех переменных на один коэффициент никак не повлияет на выбор планировщика. По умолчанию эти переменные определяются относительно стоимости чтения последовательной страницы: то есть, переменную seq_page_cost удобно задать равной 1.0, а все другие переменные стоимости определить относительно неё. Но при желании можно использовать и другую шкалу, например, выразить в миллисекундах фактическое время выполнения запросов на конкретной машине.

Т.е. если вы изменили seq_page_cost, то должны пересмотреть все параметры планировщика опираясь на новый показатель.
Почти наверняка было бы достаточно выставить random_page_cost в 1 или 1,1 и получите то же самое, только не нарушая общую работу планировщика во всех других запросах.

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

Общий посыл такой - нет волшебной пули, есть комплекс настроек которые нужно применять в комплексе
19. w.r. 468 20.03.19 13:44 Сейчас в теме
(17)

Я проводил тесты и в этих тестах получал уменьшение времени выполнения запроса при снижении seq_page_cost с 1.0 до 0.1. Так что давайте оставим этот теоретический спор

И я писал выше, что у меня большие ресурсы выделены на кэш (effective_cache_size=16GB)
16. Gorus 43 20.03.19 10:50 Сейчас в теме
У меня также снижение параметра seq_page_cost = 0.1
привело к существенному повышению общей производительности. Правда
random_page_cost я ставил 0.4, сохраняя отношение одного к другому. Размер базы уже больше ОЗУ, но производительность не падает.
И спасибо за перевод)
18. a.doroshkevich 491 20.03.19 13:00 Сейчас в теме
Если посмотреть рекомендации 1С поновее чем 2012 год, то:

https://kb.1c.ru/articleView.jsp?id=91

Стоимость чтения рандомной страницы, на которую будет опираться оптимизатор (по-умолчанию 4). Практическое значение параметра должно зависеть от «seek time» дисковой системы: чем он меньше, тем меньше должно быть значение random_page_cost (но не менее 1.0) . Излишне большое значение параметра увеличивает склонность PostgreSQL к выбору планов с сканированием всей таблицы (PostgreSQL считает, что дешевле последовательно читать всю таблицу, чем рандомно индекс). Оценка стоимости последовательного чтения делается, в свою очередь, с учетом параметра seq_page_cost, который равен по умолчанию 1.
20. inomaratadeath 21.03.19 10:35 Сейчас в теме
нубский вопрос... В тестах от Гилёва смена этих параметров на количество попугаев никак не влияет, чем бы ещё проверить профит?
21. w.r. 468 21.03.19 13:31 Сейчас в теме
(20)

Проверьте наиболее часто используемые запросы в вашей конфигурации в консоле запросов
a.doroshkevich; +1 Ответить
Оставьте свое сообщение

См. также

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С 5

Статья Системный администратор Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

вчера в 09:48    228    EugeneSemyonov    2       

Мониторинг высоконагруженной системы 37

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование данных 1С

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    3518    Repich    4       

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux 72

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    6997    Sloth    11       

Анализ производительности APDEX 65

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    2681    93    YPermitin    7       

Неочевидные проблемы производительности: важность системного подхода при анализе 50

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    4199    Филин    12       

Ловля блокировок на связке "Microsoft SQL server - 1С" 38

Статья Системный администратор Программист Нет файла v8 v8::blocking MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    3579    fhqhelp    0       

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным 57

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    6050    igordynets    119       

Ускорение чтения правил обмена в УПП 1.3 в 20 раз! 66

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    4152    YPermitin    16       

Хотите снизить нагрузку на процессор сервера в 2 раза? 21

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В статье рассмотрено влияние частого запуска регламентных заданий на процессор сервера 1С.

27.06.2019    4147    Дмитрий74Чел    6       

Непридуманные истории по оптимизации. История 1 82

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    7369    Repich    117       

Оптимизация: неэффективные запросы 6

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка

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

13.06.2019    2657    slayer-ekb    10       

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С 90

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Статистика базы данных Производительность и оптимизация (HighLoad)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    7230    ivanov660    5       

Не думать о секундах свысока... 55

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    4402    vasilev2015    21       

Альтернативная стратегия управления блокировками 45

Статья Программист Архив с данными v8 v8::blocking 1cv8.cf Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    3781    zhichkin    15       

Как работают управляемые блокировки 121

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

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

29.04.2019    13180    comol    198       

Странное потребление места на диске С 33

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    10626    kuzyara    12       

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С 50

Статья Системный администратор Программист Нет файла v8 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    8212    Elf1k    27       

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С 201

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В этой статье мы разберем механизм использования конфигурации "Анализ технологического журнала" на практике, и всего через 15 минут работы вы получите функциональный, удобный инструмент мониторинга проблем производительности базы 1С.

18.04.2019    17902    ivanov660    40       

Как разбить базу на файлы и не сойти с ума 108

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    8703    YPermitin    29       

Простое программное решение проблем с блокировками SQL 17

Статья Системный администратор Программист Нет файла v8 v8::blocking 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    5880    dmitrydemenew    38       

Производительность сервера 1С и фоновые задания 63

Статья Системный администратор Нет файла v8 1cv8.cf Россия Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В падении производительности сервера 1С зачастую виноваты не регламентные / фоновые задания, они выполняют полезную работу. Но задания нельзя оставлять «наедине» с базой.

05.02.2019    10781    user715208    38       

Новый режим реструктуризации (обновление базы данных на сервере в режиме v2) 168

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная статья скорее является заметкой и отчетом об успешном использовании нового механизма реструктуризации баз данных 1С. Актуально для больших баз данных.

31.10.2018    18449    Dach    46       

Нетривиальные подходы в решении всем известных проблем: ускорение «больших» документов в 1С и ускорение поиска по подстроке. Как добиться эффекта в разы? 62

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто у пользователей 1С поиск информации по большим спискам данных по подстроке занимает продолжительное время. Павел Баркетов рассматривает причины торможения запросов с поиском по подстроке и описывает возможности и подходы к их оптимизации и ускорению. Также в статье разобраны причины длительного проведения «больших» документов (более 10 000 строк) и даны рекомендации по ускорению этих операций.

30.08.2018    10857    gallam99    31       

Кейс: как мы разрабатывали систему автоматизации анализа ошибок, связанных со скоростью работы 1С 43

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Бурмистров Андрей рассказывает о создании инструмента по автоматизации анализа неоптимальных запросов в коде 1С. Он поднимает вопрос о предпосылках создания этого инструмента, рассказывает о возникших форс-мажорных ситуациях, с которыми столкнулась команда в процессе разработки, и о том, как они с ними справлялись.

27.08.2018    7487    Andreynikus    20       

3000 пользователей на трехъядерном Athlon – сверхтонкий веб-клиент для 1С 97

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Юрий Лазаренко поделится опытом ускорения 1С нестандартными методами, в том числе с помощью http-сервисов. Он расскажет, как с помощью сверхтонкого клиента для 1С и интеграции с сайтом удалось добиться ускорения 1С на порядок. Также в статье приведена статистика по отчету о нагрузочном тестировании сверхтонкого клиента для 1С:ITIL.

16.08.2018    11348    TitanLuchs    28       

Когда условие в срезе последних даже вредит 20

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Спойлер: оптимизатор MSSQL видит внешние, по отношению к срезу, условия, и строит план с их учетом.

05.08.2018    7747    nicxxx    105       

Оптимизация без оптимизации: как мы ускорили 1С в 10 раз без трудоемкой оптимизации запросов и алгоритмов. Практический опыт 80

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Можно ли ускорить 1С, не оптимизируя запросы, не разбивая транзакции и не наращивая оборудование? В статье Аверьянова Алексея рассмотрены три практических кейса повышения производительности системы без трудоемкой оптимизации: отложенное резервирование «в один поток», отложенное создание и проведение реализаций.

26.07.2018    13143    avryanovalexey    100       

Альтернативные технологии нагрузочного тестирования серверной части кода прикладных решений на платформе 1С 56

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Евгений Филиппов знакомит с альтернативными технологиями нагрузочного тестирования серверной части кода прикладных решений на платформе 1С. Он рассказывает об узких местах традиционной технологии нагрузочного тестирования и методах их обхода путем переноса работы с клиентских соединений на фоновые задания и изменения способа управления сеансами. Также автор приводит примеры с реальных проектов, подтверждающие жизнеспособность предложенных технологий.

12.07.2018    8247    jf2000    10       

Архитектура ИТ-системы на базе 1С в крупной организации. Часть 2. Чудес не бывает 81

Статья Системный администратор Нет файла v8 УТ11 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Развернуто отвечаю, как мы боремся с зависаниями системы и вообще решаем проблемы. С примерами, но без слайдов.

04.07.2018    12193    Repich    74       

Архитектура ИТ-системы на базе 1С в крупной организации 101

Статья Системный администратор Нет файла v8 УТ11 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

В данной статье я хотел бы очень крупными мазками обрисовать архитектуру ИТ системы на базе 1С в крупных (более 1 тысячи пользователей) организациях. Она не несет какой либо образовательной цели, это просто попытка показать – «а как у нас».

02.07.2018    14732    Repich    112       

Взгляд на ошибки и платформу через призму HI-Load 53

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Поговорим об ошибках в целом и их влиянии на Hi-Load системы в частности. Может ли тут помочь платформа 1С? (да и должна ли в принципе?) Немного про сам Hi-Load на примере крупной БД. PS Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

18.06.2018    10011    Sergey.Noskov    27       

Простые регулярные выражения 59

Статья Программист Архив с данными v8 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Шпаргалка к экзамену "Эксперт по технологическим вопросам".

30.04.2018    11706    3    vasilev2015    30       

Неоптимальная работа запроса 128

Статья Программист Нет файла v8::Запросы Бесплатно (free) Производительность и оптимизация (HighLoad)

Шпаргалка к экзамену "Эксперт по технологическим вопросам".

27.04.2018    16992    vasilev2015    32       

Неоптимальности вида «план исполнения запроса "испортился"» - поиск и исправление 69

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Рассматривается один из частых типов проблем в рабочих базах (второй после блокировок, пожалуй... впрочем, часто и тесно с ними связанный). Материал относится к базам данных на связке «1С - MS SQL Server».

05.02.2018    13741    fhqhelp    20       

Пример поиска неоптимальности при загрузке SQL-сервера по CPU на 100% 83

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Вечер пятницы, ничто не предвещало.. Звонок из техподдержки: "центральная база розничной сети лежит". Далее расследование причин.

23.12.2017    15316    fhqhelp    32       

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте 129

Статья Системный администратор Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    24274    MrWonder    38       

Вопросы разработки, анализа производительности и оптимизации приложений 1С под управлением СУБД ORACLE 16

Статья Системный администратор Программист Нет файла v8 Oracle Бесплатно (free) Производительность и оптимизация (HighLoad)

Я являюсь сотрудником Комсомольского-на-Амуре филиала компании «Сухой». Наше предприятие производит боевую авиационную технику и комплектующие для гражданской авиационной техники. В статье я вам расскажу про свой опыт работы со связкой 1С и СУБД ORACLE.

05.09.2017    10456    user597755_vices2015    2       

Оптимизируй это! Или MS SQL и Экспертный подход творят чудеса! 207

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

В статье речь пойдет про взаимодействие сервера 1С с MS SQL. Мы очень часто слышим, как важно оптимизировать все критические участки системы заблаговременно, в плановом режиме, как надо, «от и до» во всех деталях. Но в реальной жизни бывает по-другому. Очень часто клиенты обращаются к нам, когда система уже не дает работать: «спасите, помогите, болит очень сильно, надо решать». Об одном из таких случаев я и хотел бы вам сегодня рассказать.

11.07.2017    28986    R.Tsarenko    32       

Планы запросов - это просто! 291

Статья Программист Нет файла v8::Запросы Бесплатно (free) Производительность и оптимизация (HighLoad)

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

04.07.2017    31229    Evil Beaver    58       

PostgreSQL на Windows – реальная альтернатива для высоконагруженных систем на базе 1С 157

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Многие интересуются PostgreSQL, но не знают, насколько хорошо будет она работать с уже существующими системами. «Инфософт» - одна из первых компаний, кто опробовал PostgreSQL на Windows. О своем опыте перехода рассказывает руководитель отдела информационных технологий компании.      

23.06.2017    37187    a.doroshkevich    113       

Ускорение в 100 раз. Решаем проблему блокировок 330

Статья Программист Нет файла v8 v8::УФ 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Я являюсь автором и тренером курсов по оптимизации и повышению производительности в 1С. Большинство людей приходят ко мне на обучение, желая разобраться со своими проблемами, и я очень часто слышу от них: «эти блокировки замучили, достали, жизни нет, что делать – не знаем. Технологический журнал включали, галочки ставили, форумы читали – ничего не помогает». Я уверен, что эта тема актуальна для многих из вас, поэтому в статье, не вдаваясь глубоко в подробности, я хочу вам дать некоторые конкретные рекомендации, которые вы сможете применить у себя и сразу получить ощутимый эффект. Например, если у вас запрос из-за блокировок выполняется 15 секунд, то после оптимизации он начнет выполняться за 15 миллисекунд. Это обычная практика, никакой фантастики – все это можно сделать.

13.06.2017    60372    Andreynikus    34