1С без тормозов: архитектура, железо, настройки

Может быть, а может и нет — пока неизвестно. «Тормозит» само по себе ни о чём не говорит, и сразу бежать за новым сервером — значит с большой вероятностью потратить деньги впустую. Сначала надо понять три вещи: что у вас за 1С (конфигурация, файловая или клиент-серверная, сколько человек одновременно работает), что у вас за железо (что за сервер, какие диски, сколько памяти) и как всё настроено (питание, антивирус, нет ли лишних ролей, обслуживается ли база).

И только когда понятна реальная картина, есть смысл говорить о решении. Иногда это действительно сервер помощнее. Но гораздо чаще причина в другом: файловая база, которую гоняют по сети (тут не поможет никакое железо), настройки по умолчанию, отсутствие обслуживания базы или пара тяжёлых запросов. Так что грамотный подход — сначала диагностика, потом затраты, а не наоборот.

Работают оба, и выбор сводится к деньгам, скорости и тому, на чём вам комфортнее. MS SQL Server в тестах традиционно показывает очень хорошую скорость и многим админам привычен, но лицензируется отдельно и стоит заметных денег — для небольшой компании это ощутимая сумма.

А с PostgreSQL чуть сложнее, чем «бесплатно и всё». Есть бесплатная сборка под 1С — она работает, но из коробки настроена скромно и на тяжёлых базах обычно уступает MS SQL по скорости, ей нужен грамотный тюнинг. А есть коммерческие сборки PostgreSQL с доработками специально под 1С — они быстрее бесплатной, но тоже стоят заметных денег. Важный нюанс: PostgreSQL живёт на Linux — на Windows его ставить не стоит, скорость сильно проседает.

Для большинства задач малого и среднего бизнеса PostgreSQL — разумный выбор, и сама 1С активно развивает дружбу именно с ним. Но окончательно решает связка «бюджет + есть ли специалист, который умеет это нормально настроить и сопровождать».

Правда. Лицензия уровня ПРОФ — самая распространённая в малом и среднем бизнесе — позволяет серверу 1С использовать максимум 12 ядер. Можно поставить процессор на 64 ядра, но использоваться будут всё те же 12, а остальные просто простаивают.

И отсюда практический вывод: на лицензии ПРОФ нет смысла гнаться за числом ядер сверх двенадцати — лучше взять процессор с меньшим числом ядер, но более высокой частотой каждого. Снять ограничение можно только лицензией уровня КОРП, но она существенно дороже.

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

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

Бывает и такое — и тогда дело, скорее всего, уже не в железе и не в архитектуре. Дело в самой базе. Причины разные: база сильно разрослась, накопились неоптимальные запросы, не настроено регулярное обслуживание сервера баз данных, или дело в кривых доработках, которые когда-то внесли программисты.

Это уже отдельная история — диагностика и оптимизация конкретной базы, а не замена сервера. Покупка ещё более мощного железа здесь обычно не помогает: оно лечит нехватку ресурсов, но не проблемы внутри базы.

Особенно это заметно на больших системах — примерно от 100 пользователей и выше. Там на первый план выходит уже не железо. Выходит оптимизация самого кода 1С: как написаны запросы, отчёты, доработки. Это работа для программистов 1С, и никаким сервером её не заменить.

Вообще можно — и это не всегда компромисс. На мощном десктопном процессоре при не очень большом числе пользователей (условно до 30-40) 1С нередко работает даже быстрее, чем на серверном: у десктопных процессоров обычно выше частота одного ядра, а для 1С это как раз важнее всего.

Но есть жёсткое условие: диск под базу должен быть серверным SSD. Бытовые накопители рассчитаны на одного пользователя с редкими обращениями, а не на постоянную нагрузку базы данных — под ней они быстро изнашиваются и тормозят. Плюс у десктопа нет серверного запаса надёжности (память с коррекцией ошибок, питание под круглосуточную работу). А подробно про разницу десктопного и серверного железа — в главе про серверы.

Очень характерный симптом: тормозит не постоянно, а «пятнами» — например, каждый день в одно и то же время или при закрытии месяца. И почти всегда дело тут не в железе. Дело в том, что в этот момент в базе одновременно происходит что-то тяжёлое.

Типичные виновники: регламентные и фоновые задания, запущенные в рабочее время, массовые блокировки, когда пользователи ждут друг друга на одних и тех же данных, резервное копирование посреди дня, антивирус, который проверяет файлы базы. И лечится это разбором конкретной причины и переносом тяжёлых операций на нерабочее время — а не покупкой более мощного сервера.

Без диагностики ответа нет. «Тормозит» — это симптом, а не диагноз, и апгрейд «вслепую» с высокой вероятностью не даст эффекта. Сначала фиксируется исходная картина по трём направлениям: архитектура и нагрузка (конфигурация, файловая / клиент-серверная, число одновременных сессий, способ подключения), аппаратная часть (CPU и его реальная частота под нагрузкой, дисковая подсистема — время отклика и очереди, объём и загрузка памяти) и конфигурация окружения (схема питания и BIOS, исключения антивируса, посторонние роли, регламентное обслуживание СУБД).

А решение принимается по результатам замеров. Иногда это действительно наращивание оборудования (при небольшой нагрузке нарастить железо нередко дешевле, чем оптимизировать код). Но чаще узкое место — файловый доступ по сети (не лечится мощностью), дефолтные настройки питания / BIOS, отсутствие обслуживания базы, неоптимальные запросы или блокировки. Корректный порядок — сначала измерение и диагностика, затем целевое вложение.

Подходят оба, разница — в стоимости, производительности и сопровождении. MS SQL Server в нагрузочных тестах традиционно в числе лидеров (особенно на операциях с временными таблицами), но требует отдельных лицензий с существенной стоимостью владения.

А PostgreSQL существует в нескольких вариантах. Бесплатная сборка под 1С (с патчами 1С) рабочая, но дефолтная конфигурация слабая — требует тюнинга, и на тяжёлых профилях обычно уступает MS SQL. Коммерческие сборки (например, PostgresPro для 1С) оптимизированы под платформу и ближе по скорости, но это платный продукт с заметной стоимостью. Эксплуатация — на Linux: PostgreSQL под Windows даёт значительную просадку и на практике не применяется.

Тренд — углубление интеграции платформы 1С именно с PostgreSQL. Для большинства нагрузок малого и среднего бизнеса он достаточен. Критерий выбора — бюджет (лицензии MS SQL против платной сборки PG против тюнинга бесплатной) и наличие квалификации для настройки и сопровождения.

Да. Лицензия уровня ПРОФ (наиболее распространённая) ограничивает сервер 1С двенадцатью ядрами. Процессор с бóльшим числом ядер будет задействован лишь частично — остальные простаивают.

Практический вывод: на ПРОФ наращивать ядра сверх двенадцати нецелесообразно — выгоднее меньше ядер с более высокой частотой. Снятие ограничения — только лицензия уровня КОРП, существенно более дорогая.

Файл работающей базы нельзя копировать «как есть»: при активных сессиях копия получается неконсистентной (битой), и дефект выявляется только при восстановлении.

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

Вероятно, причина не в железе и не в архитектуре. Дело в состоянии базы: разрастание данных, неоптимальные запросы, отсутствие регламентного обслуживания СУБД, неэффективные доработки.

Это задача диагностики и оптимизации конкретной базы, а не апгрейда сервера. Дополнительная мощность закрывает дефицит ресурсов, но не устраняет проблемы внутри базы — поэтому обычно не помогает.

На крупных инсталляциях — ориентировочно от 100+ активных пользователей — определяющим становится уже не железо. На первый план выходит оптимизация прикладного кода: запросы, отчёты, механизмы доработок, работа с блокировками. Это зона ответственности программистов 1С, и наращиванием оборудования она не закрывается.

Да, и это рабочий вариант. На мощных десктопных процессорах при умеренном числе пользователей (ориентировочно до 30-40) 1С нередко быстрее, чем на серверных: десктопные CPU обычно дают более высокую частоту одного ядра, а однопоточная производительность для 1С определяющая.

Обязательное условие — серверный SSD под базу. Бытовые накопители рассчитаны на единичного пользователя с редкими обращениями, а не на постоянную нагрузку СУБД: ресурс вырабатывается быстро, растёт время отклика. Также у десктопа нет серверного запаса по надёжности (ECC-память, питание под 24/7). Детальный разбор десктопного и серверного железа — в главе про серверы.

Групповые (общесистемные) замедления, привязанные ко времени или событию, обычно не связаны с нехваткой железа. Причина — одновременная тяжёлая активность в базе в конкретный момент.

Типовые источники: регламентные и фоновые задания в рабочее время, массовые блокировки (конкуренция за одни данные, пользователи ожидают друг друга), резервное копирование днём, антивирус без исключений для файлов базы. Решение — диагностика конкретного источника и перенос тяжёлых операций в нерабочее окно, а не апгрейд сервера.