Записки оптимизатора 1С (ч.16). Риски падения Postgres: потребление и высвобождение памяти процессами postgres

Статья родилась в ходе наблюдения за одной из систем на Postgres, что у нас на поддержке. Результаты наблюдения несколько удивили, поэтому делюсь, ибо причинно-следственные связи далеко не очевидны. Триггером к изучению, можно сказать, даже к расследованию, послужило событие, когда однажды утром сервер PG завалился, потому что процессы postgres заняли всю память.

https://habr.com/ru/companies/softpoint/articles/1016828/

#postgres #perfexpert #падение_postgres #потребление_памяти_postgresql #work_mem #мониторинг_сервера #мониторинг_postgresql #1c_и_postgresql

Записки оптимизатора 1С (ч.15). Параллелизм запросов 1С в PostgreSQL

Продолжим разбирать тему параллелизма для баз 1С, но сегодня разговор будет не о MS SQL, а о PostgreSQL. Принципы работы тут отличаются, поэтому нужно пояснение.

https://habr.com/ru/companies/softpoint/articles/1005446/

#perfexpert #qprocessing #max_parallel_workers_per_gather #max_parallel_workers #max_worker_processes #max_degree_of_parallelism #параллелизм #cxpacket #параллелизм_в_PostgreSQL #записки_оптимизатора_1с

Как перевести 40 распределенных баз 1С из MSSQL в PostgreSQL

Продолжаем публиковать некоторые детали проектов по миграции больших баз данных 1С с MS SQL Server на PostgreSQL. В прошлый раз речь шла о миграции только одной 10+ Тб базы данных 1С с MS SQL на PostgreSQL. Сегодня речь пойдет о проекте миграции на PostgreSQL сразу сорока с лишним распределенных информационных систем 1C с базами размером от 50 Гб до 2 Тб каждая.

https://habr.com/ru/companies/softpoint/articles/984716/

#db_replication #perfexpert #миграция_на_свободное_по #миграция_бд_на_postgresql #распределенные_системы #распределённые_ис #переход_на_российское_по #переход_на_postgresql

Записки оптимизатора 1С (ч.14.3). Отличия в обслуживании статистик в MS SQL и в PostgreSQL

Переходим к заключительной третьей части регламентного обслуживания баз данных. И сегодня акцент сделаем на обслуживании статистик в СУБД PostgreSQL. Актуальные статистики в PG важны ничуть не менее, чем в MS SQL, но разница в настройках и алгоритмах есть, соответственно, подходы будут чуть различаться.

https://habr.com/ru/companies/softpoint/articles/971974/

#perfexpert #статистики_vacuum #статистики #autovacuum #autoupdate #default_statistics_target #analyze #AUTO_UPDATE_STATISTICS

Записки оптимизатора 1С (ч.14.2). Пересчет индексов на SSD–дисках. Делаем или игнорируем?

В предыдущей статье обсуждали регламентное обслуживание с акцентом на пересчет статистик. Операция крайне полезная, необходимая и чем интенсивнее меняются данные в базе, тем важнее актуальные статистики. Сегодня поговорим про еще одну регламентную операцию – пересчет индексов. Как всегда с акцентом на высоконагруженные системы 1С. "Нужно?", "Не нужно?", "А если у меня SSD-диск?", "А какой эффект от перестроения индексов?", "А я не успеваю за ночь. Что делать?" Разберем подробно все нюансы.

https://habr.com/ru/companies/softpoint/articles/961356/

#SSD #пересчет_индексов #дефрагментация_индексов #производительность #perfexpert #очереди_к_диску #разбиение_страниц #обслуживание_баз_данных #1с #индексы

Записки оптимизатора 1С (ч.13). Что не так в журнале регистрации 1С в формате SQLite?

Хочу вернуться к старой проблеме с хранением журнала регистрации 1С в формате SQLite. История стара как мир, но мы нет-нет, а продолжаем с ней сталкиваться, поскольку очень часто большие информационные системы работают далеко не на самых свежих версиях платформы 1С, а администраторы системы не уследили за форматом хранения журнала регистрации (ЖР). Наглядно посмотрим к чему может приводить ЖР в формате SQLite в многопользовательской нагруженной системе, а также выясним как администраторам и разработчикам понять, что проблема просадки производительности связана с чтением ЖР.

https://habr.com/ru/companies/softpoint/articles/941666/

#журнал_регистрации #lgd #sqlite #1c #perfexpert #записки_оптимизатора_1с

Немного о кластеризации СУБД в высоконагруженных системах 1С

Для чего используют кластеризацию серверов СУБД? Вопрос не совсем праздный, особенно для крупных компаний. Если с кластеризацией/масштабированием серверов приложений, терминалов, web-серверов и т. д. все понятно и прозрачно, то вот с СУБД не всё так просто. Особенно для 1С систем.

https://habr.com/ru/companies/softpoint/articles/932480/

#кластер_postgresql #кластер_баз_данных #балансировка_нагрузки #отказоустойчивость #qprocessing #data_cluster #perfexpert #горизонтальное_масштабирование

1C: Предприятие. СрезПоследних в PostgreSQL. Почему же так долго?

Этой проблеме уже не менее 15 лет. На входе: большая база на PostgreSQL. Вполне себе типовые отчеты с не менее типовыми запросами 1C, содержащие обращение к виртуальной таблице СрезПоследних какого-нибудь регистра сведений с большим количеством строк, выполняются неприлично длительное время. Вплоть до нескольких часов. Причина – оптимизатор строит неверный план запроса. Причем тот же запрос на MS SQL выполняется быстро и оптимизатор не ошибается. Сейчас будем разбираться в чем ошибается оптимизатор и какие пути решения тут возможны.

https://habr.com/ru/companies/softpoint/articles/914956/

#СрезПоследних #запросы_sql #perfexpert #qprocessing #долгие_sqlзапросы #1C_срез_последних #PostgreSQL_и_1C

Записки оптимизатора 1С (ч.11). Не всегда очевидные проблемы производительности на серверах 1С

Продолжаем обсуждать серверы в контуре высоконагруженных 1С-систем. В предыдущей статье я рассматривал типичные проблемы с серверами СУБД, а сегодня перейдем к серверам 1С. Причем не хочется, чтобы пост превратился в очередной универсальный перечень настроек сервера 1С на все случаи жизни. Поэтому будем смотреть на задачу через призму производительности системы. Главное, сначала увидеть картину целиком, понять причину и, исходя из этого, менять пусть те же самые настройки 1С. Цель статьи – подсветить несколько достаточно распространенных, но не всегда очевидных проблем производительности ИТ-системы, находящихся на стороне сервера(ов) 1С. Естественно, я не планирую разбирать очевидные вещи из серии «Хьюстон у нас проблемы. Нагрузка на CPU – 100%, пользователи в истерике». Но начну как раз с процессора :-). Тут есть что рассказать.

https://habr.com/ru/companies/softpoint/articles/905380/

#perfexpert #сервер_1С #настройки_сервера_1С #утечка_памяти_rphost #NUMAузлы #нагрузка_на_процессор

Записки оптимизатора 1С (ч.10): Как понять, что процессор — основная боль на вашем сервере СУБД MS SQL Server?

Назрел пост, связанный нагрузкой на процессор сервера СУБД MS SQL Server. Вроде бы чего тут обсуждать, всё же очевидно – есть системные счетчики, показывающие нагрузку в процентах. Смотрим на них и понимаем, всё ли у нас замечательно с сервером, хорошо ли утилизируются ресурсы, аль не хватает. Когда нагрузка на процессоре ~100%, огромные очереди к нему, то тут действительно всё просто и обсуждать особо нечего. Сценарий простой: либо ищем что его нагружает, либо система переросла процессор и ему пора накинуть мощностей. А вот когда нагрузка держится на среднем уровне, но при этом есть очереди и ожидания, то здесь далеко не все так очевидно.

https://habr.com/ru/companies/softpoint/articles/891640/

#perfexpert #нагрузка_на_процессор #очереди_к_процессору #виртуализация #numa #softnuma #hyperthreading