В настоящее время часто возникает вопрос импортозамещения внутри компании. Много факторов, которые влияют на принятие такого решения, начиная с отсутствия поддержки и обновлений от вендора, возникающих проблем с совместимостью с устаревшими серверными решениями, а также риск уязвимости с точки зрения информационной безопасности. После проделанной работы силами внутреннего ИТ-отдела или привлекая специальные компании, необходимо провести аудит СУБД, чтобы проверить работоспособность программного обеспечения, степень его защиты от внутренних и внешних угроз, а также эффективность работы. Однако бывает недостаточно сил ИТ-отдела компании и требуются узкоспециализированные специалисты.
В этой статье мы хотим поделиться опытом специалистов компании DBI, рассказать, как выполнили аудит СУБД и серверных мощностей по запросу от компании «Дневник.ру» — поставщика saas-решения для образования.
Итак, рассмотрим:
Наш заказчик принял решение о миграции своих СУБД с MSSQL на PostgreSQL и выполнил ее силами своего IT-отдела. После проведения миграции СУБД встал вопрос об аудите проделанной работы узкопрофильными специалистами по PostgreSQL.
Основной задачей для специалистов компании DBI стало проведение аудита инфраструктуры и СУБД с целью улучшения производительности СУБД PostgreSQL.
В дополнение к основному запросу целью аудита было:
1. Выявление наличия критичных проблем, угрожающих доступности кластера PG.
2. Выявление недостатков и упущений в организации обслуживания БД и выполнения регламентных работ и подготовка рекомендаций по их устранению.
3. Формирование рекомендаций по устранению выявленных недостатков в функционировании кластера PG.
Ниже описаны технические шаги, которые были выполнены в процессе аудита.
Работа на уровне сервера:
1. Проверка версии PG и установленных расширений
2. Анализ конфигурации PG
3. Проверка наличия бэкапов и их менеджмент
4. Проверка crontab заданий PG
5. Проверка логов кластера PG
6. Проверка общей нагрузки на сервере
Здесь проблем обнаружено не было, нагрузка на cpu в среднем не более 50%, использование RAM так же.
Критических ошибок в логах PG кластера не выявлено. Значит необходимо более глубоко рассматривать сами СУБД и запросы в них.
Работа на уровне СУБД:
1. Проверка конфигурации autovacuum’а (в том числе операций сбора статистики)
Рекомендация по изменению параметра автовакуума для ускорения процесса и тем самым более эффективной борьбы с увеличением объема таблиц.
2. Проверка размещения файлов кластера PG на сервере
3. Проверка настроек планировщика
4. Анализ bloat таблиц и индексов
Рекомендация по реиндексу для перепаковки индексов.
5. Анализ неиспользуемых и дублирующих индексов
Составили список дублирующихся индексов и неиспользуемых объектов.
6. Составление списков самых длительных и частых запросов, занимающих наибольший процент времени работы кластера PG (по DB Time и по количеству выполнений)
7. Анализ запросов на предмет возможных оптимизаций.
На данном этапе для ускорения работы наши специалисты рассмотрели top-10 запросов максимально загружающих систему.
В зависимости от проблемы в запросе рекомендовалось: применить создание и изменение существующих индексов, учитывая специфику таблицы и самого запроса, создание MATERIALIZED VIEW, а также полное изменение структуры запроса с применением других SQL операторов.
В конечном итоге нашей работы клиент получил полный список рекомендаций по настройке своей системы. После согласования мы произвели нужные изменения, что достаточно быстро дало результат, СУБД и приложение вышло на плановые показатели скорости отклика и нагрузки.
Если вы планируете провести аудит или миграцию СУБД, специалисты нашей компании готовы проконсультировать и помочь в решении вашей проблемы. Напишите нам — будем рады ответить!
Load avarege «до»
Load avarege «до»