Почему 1С тормозит: взгляд инфраструктурщика

Программисты 1С не разбираются в инфраструктуре, и это нормально. Их задача – расширить функционал по техническому заданию, а не устранять тормоза на уровне сервера. Они не видят, что процессор загружен на 100% из-за фоновых заданий. Не знают, что база давно переросла файловый режим. Не мониторят оперативную память.

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

Поэтому когда вам говорят «1С тормозит – надо оптимизировать код», это только часть правды. Вторая часть – под капотом сервера.

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

Самый частый виновник. 1С постоянно читает и записывает данные, и если база лежит на обычном HDD – каждый запрос ждет очереди.

Разница в цифрах: HDD выдает около 120 МБ/с при последовательном чтении. SATA SSD – 500-560 МБ/с, это в 4-5 раз быстрее. А NVMe SSD – от 2000 МБ/с и выше. Но еще важнее показатель IOPS, количество операций в секунду. У HDD это 100-200. У NVMe SSD – десятки тысяч. Для базы данных, где идут тысячи мелких случайных запросов, это разница между «работает» и «все ждут».

На практике перенос базы с HDD на SSD – одно из самых заметных ускорений. Проведение документов начинает работать в разы быстрее, без каких-либо изменений в коде.

Когда RAM не хватает, система сбрасывает данные на диск. Даже если диск быстрый, это все равно в десятки раз медленнее оперативной памяти. Результат: 1С «замирает» на несколько секунд без видимой причины, процессор при этом может быть не нагружен.

Практическая формула: примерно 1,5 ГБ на каждого одновременного пользователя плюс 8 ГБ на операционную систему и СУБД. Для 20 человек – 38 ГБ, значит ставим 64. Для 50 – уже 83 ГБ, нужно 128. Звучит много, но экономия на памяти обходится дороже: сотрудники простаивают, бухгалтер закрывает период в два раза дольше.

1С может работать в двух режимах:

• Файловый – вся база в одном файле к которому каждый пользователь обращается напрямую.

• Клиент-серверный (SQL) – запросы пользователей обрабатывает сервер баз данных.

Файловый режим комфортно работает при 3-5 пользователях. При 5-7 уже заметны задержки, при 10+ работа становится мучительной: каждый запрос конкурирует за доступ к одному файлу. Бухгалтер ждет, пока менеджер закончит проводку. Менеджер ждет, пока отработает отчет.

Мы переводим базы в SQL при 10 и более одновременных пользователях или при объеме базы от 4 ГБ. Но это условная граница. Если пользователи работают интенсивно (много документов, постоянные поиски по базе), переход нужен раньше.

Не все процессоры одинаково подходят для 1С. Серверный Xeon с 24 ядрами, но низкой частотой 1,8 ГГц – хуже для 1С, чем настольный процессор с 8 ядрами на 3,6 ГГц. Для формирования отчетов и проведения документов важна частота одного ядра. Многопоточность тут не спасает.

При этом лицензия 1С:Предприятие ПРОФ ограничивает использование 12 ядрами. Покупать 24-ядерный процессор под такую лицензию – неразумная трата денежных средств.

Ориентиры по нагрузке: для 5 пользователей хватит 4 ядер с частотой от 3 ГГц. Для 20-30 нужны 8 ядер с частотой 3,0-3,5 ГГц. Для 50+ – два процессора и более процессоров с высокой частотой, но тут уже считаем под конкретный профиль нагрузки.

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

Проблема в том, что по умолчанию многие из них запускаются одновременно и в рабочее время. Мы регулярно видим ситуацию: сервер загружен на 100% в 10 утра, пользователи жалуются на тормоза, а причина – три обмена с внешними базами и пересчет итогов, запущенные параллельно.

Еще опаснее задания, которые блокируют доступ к данным. Пока выполняется такая операция, другие пользователи не могут работать с теми же таблицами. Вся работа встает, и никто не понимает почему.

Со временем база накапливает устаревшие закэшированные данные, временные таблицы, незавершенные транзакции. Объем растет, запросы замедляются. Это не бросается в глаза – тормоза нарастают постепенно, и к ним привыкают.

«Она всегда так работала» – самая частая фраза, которую мы слышим. Нет, не всегда. Просто деградация шла месяцами, и каждый день было чуть медленнее, чем вчера. Регулярная чистка и реиндексация возвращают базу к нормальной скорости. Иногда разница ощущается сразу после первого обслуживания.

Мы не меняем все сразу. Устраняем узкие места последовательно, от самого критичного к менее значимому.

Начинаем с мониторинга. Ставим Zabbix, снимаем показатели: загрузка CPU, потребление RAM, IOPS дисков, количество активных сессий 1С, фоновые задания. Без данных любое ускорение – гадание на кофейной гуще.

По графикам находим узкое место. Иногда это очевидно: RAM загружен на 97%, при этом SSD активен. Иногда нет – "тормоза" возникают только в определенные часы дня, и тогда дело скорее всего в фоновых заданиях или пиковой нагрузке 1С.

Дальше устраняем. Начинаем с того, что даст максимальный результат при минимальных затратах. Часто это замена HDD на SSD или добавление памяти. Иногда – перенос базы в SQL-режим. Реже – замена сервера целиком.

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

Две вещи, которые мы рекомендуем каждому клиенту.

Мониторинг на постоянной основе. Без него вы узнаете о проблеме, только когда бухгалтерия придет жаловаться. С мониторингом мы видим тренды: память заполняется, дисков не хватает, нагрузка растет. И решаем проблему до того, как она станет аварией. 80% заявок мы закрываем менее чем за 2 часа, но лучше, когда заявок не возникает вовсе.

Периодический аудит. Раз в полгода – проверка: соответствует ли сервер текущей нагрузке, не пора ли переходить на SQL, не появились ли новые «тяжелые» конфигурации. Бизнес растет, а сервер, купленный три года назад, об этом не знает.

Тормозящая 1С – это редко одна причина. Обычно это комбинация: медленный диск + нехватка памяти + файловый режим, из которого давно пора вырасти. Программист 1С видит свою часть, мы – свою. И когда обе части работают вместе, 1С перестаёт быть проблемой.

Если узнали свою ситуацию, свяжитесь с нами. Расскажем, что можно сделать для сервера вашего размера.