Пн–Пт: 09:00-18:00
1С тормозит: как ускорить систему и построить стабильную архитектуру
Когда сотрудники жалуются, что 1С тормозит, первая реакция руководителя обычно одна: «надо купить сервер помощнее». Иногда это действительно помогает. Но чаще новый сервер снимает проблему на несколько месяцев, а потом тормоза возвращаются, потому что причина сидела не в железе, а в том, как настроена и организована вся система целиком.
1С, особенно при большом числе пользователей и объеме данных, представляет собой не одну программу, а связку из нескольких слоев: оборудование, база данных, сам сервер 1С и код, которым пользуется компания.
Проблема может прятаться на любом из этих уровней, а выглядит для сотрудника всегда одинаково: «все зависает». При этом причины у небольшой компании на 10 человек и у холдинга с тысячей пользователей часто разные, поэтому разбираться стоит по порядку, от простого к сложному.
Разберем, что стоит проверить на каждом уровне и почему это в итоге влияет на работу всей компании, а не только на ИТ-отдел.
1С, особенно при большом числе пользователей и объеме данных, представляет собой не одну программу, а связку из нескольких слоев: оборудование, база данных, сам сервер 1С и код, которым пользуется компания.
Проблема может прятаться на любом из этих уровней, а выглядит для сотрудника всегда одинаково: «все зависает». При этом причины у небольшой компании на 10 человек и у холдинга с тысячей пользователей часто разные, поэтому разбираться стоит по порядку, от простого к сложному.
Разберем, что стоит проверить на каждом уровне и почему это в итоге влияет на работу всей компании, а не только на ИТ-отдел.
Файловая база: частая причина торможения у небольших компаний
Прежде чем разбирать сложные сценарии, стоит исключить самую распространенную причину медленной работы у малого бизнеса: использование файлового варианта базы вместо клиент-серверного на PostgreSQL или MS SQL.
Файловая база физически рассчитана максимум на 5–10 одновременных пользователей при небольшом объеме данных, и по мере роста компании замедление становится практически неизбежным.
Понять, что дело именно в этом, можно по нескольким признакам: торможение усиливается пропорционально числу одновременно работающих сотрудников независимо от конкретной операции, база весит больше 5–10 гигабайт, а проблема заметно слабеет поздно вечером или на выходных, когда работает меньше людей.
Если это похоже на ситуацию в компании, решение здесь одно: переход на клиент-серверный вариант. Это отдельный проект миграции, но при регулярной работе больше 5 пользователей он окупается кратным ростом скорости и снимает проблему полностью, а не временно.
Файловая база физически рассчитана максимум на 5–10 одновременных пользователей при небольшом объеме данных, и по мере роста компании замедление становится практически неизбежным.
Понять, что дело именно в этом, можно по нескольким признакам: торможение усиливается пропорционально числу одновременно работающих сотрудников независимо от конкретной операции, база весит больше 5–10 гигабайт, а проблема заметно слабеет поздно вечером или на выходных, когда работает меньше людей.
Если это похоже на ситуацию в компании, решение здесь одно: переход на клиент-серверный вариант. Это отдельный проект миграции, но при регулярной работе больше 5 пользователей он окупается кратным ростом скорости и снимает проблему полностью, а не временно.
Сначала диагностика, потом покупка
Прежде чем тратить деньги на оборудование, стоит понять, где именно теряется время. Хороший специалист может замерить, сколько сейчас занимают ключевые операции: открытие карточки клиента, проведение документа, формирование основного отчета.
Эти цифры до изменений и после позволяют объективно увидеть, сработало ли решение, вместо того чтобы полагаться на общее ощущение «вроде побыстрее стало».
Дополнительно помогает анализ технического журнала системы: он показывает, какие именно операции занимают больше всего времени, а не просто фиксирует общее недовольство пользователей.
Эти цифры до изменений и после позволяют объективно увидеть, сработало ли решение, вместо того чтобы полагаться на общее ощущение «вроде побыстрее стало».
Дополнительно помогает анализ технического журнала системы: он показывает, какие именно операции занимают больше всего времени, а не просто фиксирует общее недовольство пользователей.
Отсюда следует простое практическое правило: любое серьезное вложение в 1С должно начинаться с диагностики. Иначе компания рискует заплатить за оборудование, которое не решит реальную проблему, потому что причина была в другом месте.
Оборудование важно, но не любое
Часть проблем с быстродействием решается на уровне «железа» и базовых настроек операционной системы, еще до работы с самой 1С.
Здесь важны не мощные компоненты сами по себе, а правильное распределение нагрузки между ними: быстрые диски именно под данные, которыми активно пользуются сотрудники, отдельные диски под служебные и временные файлы базы, чтобы они не мешали друг другу, стабильный и быстрый канал связи между сервером 1С и сервером базы данных, потому что для 1С критична именно задержка сети, а не только ее пропускная способность.
Покупка «самого мощного сервера, какой есть в прайсе» не гарантирует результата. Гораздо важнее, чтобы специалист правильно распределил имеющиеся ресурсы под конкретную нагрузку компании.
Здесь важны не мощные компоненты сами по себе, а правильное распределение нагрузки между ними: быстрые диски именно под данные, которыми активно пользуются сотрудники, отдельные диски под служебные и временные файлы базы, чтобы они не мешали друг другу, стабильный и быстрый канал связи между сервером 1С и сервером базы данных, потому что для 1С критична именно задержка сети, а не только ее пропускная способность.
Покупка «самого мощного сервера, какой есть в прайсе» не гарантирует результата. Гораздо важнее, чтобы специалист правильно распределил имеющиеся ресурсы под конкретную нагрузку компании.
Настройки базы данных
База данных, в которой физически хранится вся информация компании, после установки почти всегда настроена на усредненный сценарий, а не под конкретный бизнес.
Большинство компаний годами работают на этих настройках, даже не подозревая, что теряют значительную часть производительности буквально бесплатно, без покупки нового оборудования. Речь идет о десятках параметров: сколько памяти база выделяет под кэш и промежуточные вычисления, как активно она чистит за собой устаревшие данные, стоит ли использовать параллельную обработку запросов или, наоборот, отключить ее, чтобы избежать нестабильности при высокой нагрузке.
Большинство компаний годами работают на этих настройках, даже не подозревая, что теряют значительную часть производительности буквально бесплатно, без покупки нового оборудования. Речь идет о десятках параметров: сколько памяти база выделяет под кэш и промежуточные вычисления, как активно она чистит за собой устаревшие данные, стоит ли использовать параллельную обработку запросов или, наоборот, отключить ее, чтобы избежать нестабильности при высокой нагрузке.
Проверить и настроить эти параметры под реальную нагрузку компании стоит одним из первых шагов, потому что это часто дает заметный прирост скорости без единого рубля вложений в оборудование.
Регламентные операции
Отдельная частая причина, почему 1С тормозит именно в определенные часы, а не постоянно: тяжелые фоновые задания вроде полного резервного копирования, обновления индекса поиска или синхронизации с внешними системами запускаются посреди рабочего дня и конкурируют с сотрудниками за ресурсы сервера.
Проверить это несложно: сопоставить расписание регламентных заданий с моментами, когда чаще всего поступают жалобы на торможение.
Решение обычно простое и не требует вложений: перенести тяжелые операции на ночное время или выходные, а частоту менее критичных фоновых обновлений в рабочие часы снизить до одного раза в 15–30 минут вместо ежеминутного запуска.
Проверить это несложно: сопоставить расписание регламентных заданий с моментами, когда чаще всего поступают жалобы на торможение.
Решение обычно простое и не требует вложений: перенести тяжелые операции на ночное время или выходные, а частоту менее критичных фоновых обновлений в рабочие часы снизить до одного раза в 15–30 минут вместо ежеминутного запуска.
Обновление 1С
Компании часто откладывают обновление 1С из опасения что-то сломать, хотя устаревшая версия годами может работать на неоптимальных алгоритмах, которые уже исправлены в актуальных релизах платформы.
Новые версии регулярно включают оптимизации производительности на уровне ядра системы, которые не требуют от компании ничего, кроме собственно перехода на них.
Новые версии регулярно включают оптимизации производительности на уровне ядра системы, которые не требуют от компании ничего, кроме собственно перехода на них.
Перед обновлением стоит проверить совместимость всех доработок с новой версией на тестовой копии базы, чтобы возможные проблемы не затронули рабочую систему, и заранее посмотреть описание изменений релиза: иногда там напрямую упоминаются улучшения производительности, которые касаются именно тех узких мест, с которыми сталкивается конкретная компания.
Кластер серверов 1С: почему один процесс становится узким местом
Когда в компании много пользователей, обычно ставят не один сервер 1С, а кластер из нескольких серверов, которые работают вместе.
Проблема в том, что сам факт наличия кластера ничего не гарантирует: если он настроен «из коробки», без учета реальной нагрузки, разница с одним сервером может оказаться минимальной.
Правильная настройка предполагает несколько рабочих процессов с ограничением по памяти вместо одного огромного процесса, вынос тяжелых фоновых операций на отдельный сервер, чтобы они не мешали работе сотрудников, и разделение служебных функций вроде журнала событий и поиска по базе так, чтобы они не боролись за ресурсы с обычными пользователями.
Здесь важно понимать: покупка второго или третьего сервера имеет смысл только вместе с грамотной настройкой их совместной работы. Иначе компания просто платит за железо, которое не используется эффективно.
Проблема в том, что сам факт наличия кластера ничего не гарантирует: если он настроен «из коробки», без учета реальной нагрузки, разница с одним сервером может оказаться минимальной.
Правильная настройка предполагает несколько рабочих процессов с ограничением по памяти вместо одного огромного процесса, вынос тяжелых фоновых операций на отдельный сервер, чтобы они не мешали работе сотрудников, и разделение служебных функций вроде журнала событий и поиска по базе так, чтобы они не боролись за ресурсы с обычными пользователями.
Здесь важно понимать: покупка второго или третьего сервера имеет смысл только вместе с грамотной настройкой их совместной работы. Иначе компания просто платит за железо, которое не используется эффективно.
Порядок в самой базе данных
Со временем в любой базе накапливается «мусор»: устаревшие версии документов, разросшиеся служебные журналы, старые архивные периоды, которые компании давно не нужны, но которые база все равно просматривает при каждом отчете.
Это похоже на шкаф, который годами не разбирали: формально в нем можно найти нужную вещь, но на это уходит все больше времени.
Регулярное наведение порядка включает добавление нужных индексов там, где их не хватает, удаление лишних индексов, которые только замедляют запись новых данных, регулярный пересчет накопленных итогов и, при большом объеме устаревших данных, их архивирование или свертку.
Такая «уборка» часто дает ощутимый эффект без всяких вложений в оборудование, просто за счет наведения порядка в том, что уже есть.
Это похоже на шкаф, который годами не разбирали: формально в нем можно найти нужную вещь, но на это уходит все больше времени.
Регулярное наведение порядка включает добавление нужных индексов там, где их не хватает, удаление лишних индексов, которые только замедляют запись новых данных, регулярный пересчет накопленных итогов и, при большом объеме устаревших данных, их архивирование или свертку.
Такая «уборка» часто дает ощутимый эффект без всяких вложений в оборудование, просто за счет наведения порядка в том, что уже есть.
Качество кода: где чаще всего теряется скорость
Многие компании со временем дорабатывают типовую 1С под себя: добавляют отчеты, автоматизации, интеграции с другими системами. Если это делается быстро и без должного контроля качества, именно доработки чаще всего становятся главным источником тормозов, и никакая настройка сервера эту проблему не решит.
Типичная ошибка выглядит так: программист пишет код, который для каждой строки документа отдельно обращается к базе данных, вместо того чтобы запросить все нужные данные один раз. Внешне доработка работает и проходит тестирование на небольшом объеме данных, но на реальных объемах компании начинает работать в разы медленнее, чем должна.
Если компания регулярно заказывает доработки 1С, разумно закладывать в этот же бюджет проверку качества написанного кода независимым специалистом. Это дешевле, чем потом разбираться, почему «быстро сделанная» доработка тормозит всю систему.
Типичная ошибка выглядит так: программист пишет код, который для каждой строки документа отдельно обращается к базе данных, вместо того чтобы запросить все нужные данные один раз. Внешне доработка работает и проходит тестирование на небольшом объеме данных, но на реальных объемах компании начинает работать в разы медленнее, чем должна.
Если компания регулярно заказывает доработки 1С, разумно закладывать в этот же бюджет проверку качества написанного кода независимым специалистом. Это дешевле, чем потом разбираться, почему «быстро сделанная» доработка тормозит всю систему.
Архитектура: как разделить разные типы нагрузки
В любой компании есть два разных вида работы с 1С: оперативная работа сотрудников с документами и тяжелая аналитика вроде больших отчетов и выгрузок. Если и то и другое выполняется на одном и том же сервере одновременно, тяжелый отчет одного сотрудника может заметно замедлить работу всех остальных в этот момент.
Решается это разделением: тяжелую отчетность выносят на отдельную копию базы, которая обновляется по расписанию, а фоновые операции вроде синхронизации с другими системами переносят на нерабочее время, чтобы они не конкурировали с сотрудниками за ресурсы в течение дня.
Решается это разделением: тяжелую отчетность выносят на отдельную копию базы, которая обновляется по расписанию, а фоновые операции вроде синхронизации с другими системами переносят на нерабочее время, чтобы они не конкурировали с сотрудниками за ресурсы в течение дня.
Для бизнеса это означает, что грамотное разделение нагрузки часто снимает проблему без покупки дополнительного оборудования, просто за счет того, что разные задачи перестают мешать друг другу.
Масштабирование: закладывать рост заранее
Компании, которые начинают задумываться о запасе мощности только тогда, когда система уже не справляется, почти всегда сталкиваются с более дорогой и сложной доработкой, чем те, кто заранее закладывает возможность роста в два-три раза.
Устойчивая архитектура сразу учитывает возможность добавить сервер в кластер без переделки всей схемы, продуманную структуру базы и регулярный контроль производительности по мере роста компании.
При планировании ИТ-бюджета имеет смысл спросить у специалиста не только «как ускорить систему сейчас», но и «что будет с производительностью, если компания вырастет в два раза за год».
Итог
Заниматься только одним уровнем, будь то файловая база, покупка нового сервера, настройка базы данных или доработка кода, почти никогда не дает устойчивого результата, потому что проблема редко лежит в одном месте.
Рабочий подход выглядит так: сначала диагностика, чтобы понять, где реально теряется скорость, затем точечные изменения с измеримым результатом на каждом шаге, и архитектура, изначально рассчитанная на рост компании, а не донастраиваемая в аварийном режиме, когда система уже перестала справляться.
Рабочий подход выглядит так: сначала диагностика, чтобы понять, где реально теряется скорость, затем точечные изменения с измеримым результатом на каждом шаге, и архитектура, изначально рассчитанная на рост компании, а не донастраиваемая в аварийном режиме, когда система уже перестала справляться.
Хотите быть уверены, что резервное копирование сработает в критический момент и защитит ваши данные от потери?