Представьте: звонок в пятницу, в полтретьего дня. На проводе главбух строительной компании «СтройАльянс». «Евгений, — говорит она, — 1С зависает на 20 секунд при открытии абсолютно любого документа. Бухгалтерия стоит, отчётность горит, а закрытие квартала — уже послезавтра». Мы тут же выезжаем. Приезжаем, смотрим, и что же видим? Сервер, выпущенный аж в 2012 году, с 8 ГБ оперативки, обычным HDD на 7200 оборотов. И на этом «хозяйстве» одновременно пытаются работать 15 пользователей. Ещё тут установлен SQL Server 2008 R2, файловая база на 12 гигабайт, и, конечно же, антивирус Касперского, который бдительно сканирует каждый чих, включая файлы базы данных.
Ну что тут скажешь, классика жанра! Такую картину, признаюсь, мы видим минимум раз в месяц. Компания активно растёт, пользователей становится всё больше, база раздувается до неимоверных размеров — а сервер-то всё тот же, что ставили «на первое время» целых шесть лет назад.
Но мы не растерялись. Всего за неделю мы полностью перевели «СтройАльянс» на новое, современное железо с SSD, обновили и подняли SQL Server 2019, тщательно настроили tempdb, добавили все необходимые исключения в антивирус и, конечно же, перевели базу в надёжный клиент-серверный режим. И какой же результат? Открытие документа теперь занимает всего 1.5 секунды вместо прежних 20! Оборотно-сальдовая ведомость за год формируется за 8 секунд, а не за 4 минуты. А закрытие месяца, которое раньше отнимало полтора часа, теперь укладывается в 12 минут.
В этой статье я собираюсь подробно разобрать 10 самых частых причин, по которым ваша 1С может тормозить, и, главное, расскажу, как устранить каждую из них. Мы будем говорить с вами только о конкретных цифрах, командах и рекомендациях, взятых прямо из нашей многолетней практики. Никакой заумной теории — только то, что реально работает на деле.
Причина 1 — Жёсткий диск HDD вместо SSD
Вот она, причина номер один! И знаете, дело совсем не в том, что она самая сложная. Просто она встречается чаще всего, и после её устранения вы получаете самый заметный, ощутимый эффект.
По сути, 1С — это бесконечный поток операций чтения и записи на диск. Открыли документ? Это чтение. Записали проводки? Запись. Сформировали отчёт? Это тысячи операций чтения из самых разных таблиц. Обычный HDD на 7200 оборотов, если честно, выдаёт всего 80-120 операций ввода-вывода в секунду (IOPS). А вот SSD — это уже от 20 000 до 100 000 IOPS. Разница, как видите, просто в сотни раз!
У «СтройАльянса» мы увидели вот что: диск был загружен на все 100% практически постоянно, а среднее время отклика в диспетчере задач показывало ужасающие 45 мс. Просто для сравнения, у хорошего SSD этот показатель составляет всего 0.1-0.5 мс.
Что делать:
- Минимум — SSD SATA (Samsung 870 EVO, Crucial MX500). Стоимость 1 ТБ — около 8 000 рублей
- Оптимально — NVMe SSD (Samsung 980 PRO, WD Black SN850). Стоимость 1 ТБ — 10-14 000 рублей
- Для серверов — серверные SSD с защитой от потери данных при отключении питания (Intel DC, Samsung PM883)
- Если бюджета на полный переход нет — перенесите на SSD хотя бы файлы базы данных SQL и tempdb. Остальное может остаться на HDD
Проверить загрузку диска просто: откройте Диспетчер задач → Производительность → Диск. Если активное время стабильно выше 80% — вот вам и узкое место.
-- Проверка задержек дисковой подсистемы в SQL Server
SELECT
DB_NAME(database_id) AS [База],
file_id,
io_stall_read_ms / NULLIF(num_of_reads, 0) AS [Avg чтение мс],
io_stall_write_ms / NULLIF(num_of_writes, 0) AS [Avg запись мс]
FROM sys.dm_io_virtual_file_stats(NULL, NULL)
ORDER BY io_stall_read_ms DESC;
Если средние задержки чтения больше 20 мс — дисковая подсистема однозначно тормозит вашу 1С.
Причина 2 — Мало оперативной памяти
А это, друзья мои, второй по частоте «убийца» производительности. SQL Server, если хотите знать, просто обожает оперативную память! Он кэширует в ней данные, чтобы лишний раз не приходилось лезть на медленный диск. Но когда памяти катастрофически не хватает, данные сбрасываются обратно на диск (в так называемый файл подкачки), и тут уж вся ваша 1С начинает работать со скоростью этого самого диска. Не очень-то быстро, согласитесь.
Типичная картина, которую я вижу постоянно: сервер с несчастными 8 ГБ RAM. На нём крутится Windows Server, которая сама по себе «съедает» 2-3 ГБ, потом SQL Server, сервер 1С, антивирус и ещё пара-тройка служб. В итоге SQL Server достаются жалкие 3-4 ГБ, и он вынужден постоянно сбрасывать свой кэш на диск, замедляя всё подряд.
Формула расчёта памяти для сервера 1С:
- ОС Windows Server: 4 ГБ
- SQL Server: минимум 4 ГБ, оптимально — чтобы вся база помещалась в RAM
- Сервер 1С (rphost): 1-1.5 ГБ на каждого активного пользователя
- Прочее (антивирус, мониторинг): 1-2 ГБ
Для 15 пользователей: 4 + 8 + 22 + 2 = 36 ГБ минимум. А я рекомендую 64 ГБ — с запасом на рост.
-- Ограничение памяти SQL Server (пример для 24 ГБ)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 24576;
RECONFIGURE;
Как проверить, хватает ли памяти:
-- Проверяем, сколько памяти SQL Server реально использует
SELECT
(physical_memory_in_use_kb / 1024) AS [SQL использует МБ],
(total_physical_memory_kb / 1024) AS [Всего RAM МБ],
(available_physical_memory_kb / 1024) AS [Свободно МБ]
FROM sys.dm_os_sys_memory
CROSS JOIN sys.dm_os_process_memory;
Если «Свободно МБ» стабильно меньше 500 — памяти не хватает. Добавляйте.
Причина 3 — Устаревший SQL Server
SQL Server 2008 R2. Не поверите, но мы до сих пор его встречаем у наших клиентов! Этот продукт, к слову, вышел из расширенной поддержки Microsoft ещё в далёком 2019 году. Это значит, что он не получает никаких обновлений безопасности, не умеет работать с современными механизмами оптимизации запросов, да и новые типы индексов и инкрементную статистику, увы, не поддерживает.
Каждая новая версия SQL Server приносит с собой серьёзные улучшения в оптимизаторе запросов. Например, SQL Server 2019 и 2022 используют так называемый Intelligent Query Processing — это целый набор автоматических оптимизаций, которые способны ускорить типичные запросы 1С на 15-40% вообще без единого изменения в коде! Представляете?
Конкретные улучшения, важные для 1С:
- Adaptive Joins (SQL 2017+) — оптимизатор выбирает оптимальный тип соединения таблиц на лету, а не при компиляции плана
- Memory Grant Feedback (SQL 2017+) — SQL Server учится на предыдущих выполнениях запроса и выделяет нужный объём памяти
- Batch Mode on Rowstore (SQL 2019+) — пакетная обработка данных даже для обычных таблиц, ускоряет аналитические отчёты в 2-5 раз
- Accelerated Database Recovery (SQL 2019+) — мгновенное восстановление после сбоя вместо долгого отката транзакций
Проверьте свою версию:
SELECT @@VERSION;
Если видите «2008», «2012» или «2014» — пора обновляться. Процедура миграции несложная: бэкап базы, установка новой версии, восстановление, обновление уровня совместимости базы.
Причина 4 — Файловая база вместо клиент-серверной
Файловая база 1С — это, по сути, один большой-пребольшой файл под названием 1Cv8.1CD. И к этому единственному файлу все пользователи лезут по сети одновременно. При каждой операции 1С читает и пишет данные прямо в этот файл через SMB. Это всё равно что 15 человек разом сидят и редактируют один-единственный документ Word, лежащий на сетевом диске. Работает ли? Формально, да. Быстро ли? Ну, нет, конечно.
Проблемы файловой базы при росте:
- Блокировки. 1С использует табличные блокировки. Пока один пользователь записывает документ, остальные ждут
- Сеть. Данные гоняются по сети туда-обратно. Запрос, который на SQL Server выполнится на сервере за 1 мс, в файловом режиме потребует передать мегабайты данных по сети
- Размер. При размере базы больше 4-5 ГБ файловый движок начинает откровенно тормозить
- Надёжность. Один скачок напряжения или обрыв сети во время записи — и база повреждена. Мы восстанавливали файловые базы после таких сбоев десятки раз. Не всегда успешно
Когда пора переходить на клиент-серверный вариант:
- Больше 3-5 одновременных пользователей
- Размер базы больше 2-3 ГБ
- Используются тяжёлые отчёты (оборотно-сальдовые за период, анализ субконто)
- Нужна надёжность — бэкапы SQL Server в разы удобнее и надёжнее копирования файла
Перевод базы на SQL Server — это совсем не страшно и делается штатными средствами 1С. Вам нужно лишь выгрузить данные в .dt-файл из файловой базы, а затем загрузить его в новую клиент-серверную. Сама процедура занимает от 30 минут до нескольких часов — тут уж всё зависит от размера вашей базы. И главное, данные при этом никуда не теряются, можете не переживать.
Причина 5 — Не настроен tempdb
А вот эта причина — одна из тех, о которых знают далеко не все, хотя эффект от правильной настройки, поверьте мне, огромный! Речь идёт о tempdb — это системная база SQL Server, которая используется для временных таблиц, сортировок, промежуточных результатов запросов и операций с версиями строк. А 1С, при формировании отчётов и проведении документов, плодит просто кучу временных таблиц — и все они, без исключения, идут через tempdb.
По умолчанию SQL Server создаёт tempdb всего с одним файлом данных. И вот тут-то и начинается самое интересное: когда несколько пользователей одновременно пытаются строить отчёты в 1С, они начинают конкурировать за этот единственный файл. Возникают так называемые блокировки на уровне распределения страниц (allocation contention) — и в итоге все просто ждут, пока очередь дойдёт.
Правильная настройка tempdb:
- Количество файлов = количеству ядер процессора, но не более 8. Для 4-ядерного сервера — 4 файла
- Одинаковый размер всех файлов. SQL Server распределяет нагрузку пропорционально размеру файла. Если файлы разные — распределение неравномерное
- Размещение на отдельном SSD, если есть возможность. Хотя бы не на том же диске, где основная база
- Начальный размер — достаточно большой, чтобы избежать автоувеличения. Для 1С рекомендую 1-4 ГБ на файл
-- Настройка tempdb: добавляем файлы (пример для 4 ядер)
-- Сначала проверим текущее состояние
SELECT name, physical_name, size/128 AS [Размер МБ]
FROM sys.master_files WHERE database_id = 2;
-- Если файл один, добавляем ещё три
ALTER DATABASE tempdb ADD FILE (
NAME = tempdev2, FILENAME = 'T:\tempdb\tempdev2.ndf', SIZE = 2048MB, FILEGROWTH = 512MB);
ALTER DATABASE tempdb ADD FILE (
NAME = tempdev3, FILENAME = 'T:\tempdb\tempdev3.ndf', SIZE = 2048MB, FILEGROWTH = 512MB);
ALTER DATABASE tempdb ADD FILE (
NAME = tempdev4, FILENAME = 'T:\tempdb\tempdev4.ndf', SIZE = 2048MB, FILEGROWTH = 512MB);
-- Не забываем привести первый файл к тому же размеру
ALTER DATABASE tempdb MODIFY FILE (
NAME = tempdev, SIZE = 2048MB, FILEGROWTH = 512MB);
Также включите флаг трассировки 1118 (для SQL Server до 2016) — он отключает смешанные экстенты в tempdb и снижает конкуренцию:
-- Для SQL Server 2014 и ранее
DBCC TRACEON (1118, -1);
В SQL Server 2016 и новее это поведение включено по умолчанию.
Причина 6 — Раздутая база (нужна реструктуризация)
Базы 1С имеют такую неприятную особенность: они иногда необоснованно растут. Мы как-то раз видели базу 1С:Бухгалтерии на 45 ГБ у компании, где работало всего 20 человек, и они вели учёт только три года! Начали разбираться: оказалось, 18 ГБ занимал журнал регистрации, 8 ГБ — версии объектов (то есть история изменений), а ещё 5 ГБ — удалённые, но почему-то не очищенные объекты. В итоге реальных, нужных данных там было всего 14 ГБ.
Что раздувает базу:
- Журнал регистрации. Записывает каждое действие каждого пользователя. За год может занять 10-20 ГБ. При этом никто его не читает
- История данных (версионирование). Если включено — каждое изменение документа сохраняет предыдущую версию. Удобно, но очень прожорливо
- Удалённые помеченные объекты. Пользователи «удаляют» документы, но 1С только помечает их. Физически они остаются в базе
- Итоги. Устаревшие рассчитанные итоги регистров, которые не пересчитывались годами
- Фрагментация. Индексы в SQL Server со временем фрагментируются, запросы выполняются медленнее
Что делать:
- Тестирование и исправление через конфигуратор:
Администрирование → Тестирование и исправление информационной базы. Отмечаем «Реструктуризация таблиц», «Сжатие таблиц», «Пересчёт итогов» - Удаление помеченных объектов: в режиме 1С:Предприятие —
Администрирование → Удаление помеченных объектов - Сокращение журнала регистрации: оставьте записи за последние 3-6 месяцев, остальное — в архив
- Пересчёт итогов:
Администрирование → Управление итогами— пересчитать и установить актуальный период - Обслуживание SQL: регулярная дефрагментация индексов и обновление статистики
-- Проверка фрагментации индексов в базе 1С
SELECT
OBJECT_NAME(ips.object_id) AS [Таблица],
i.name AS [Индекс],
ips.avg_fragmentation_in_percent AS [Фрагментация %],
ips.page_count AS [Страниц]
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE ips.avg_fragmentation_in_percent > 30 AND ips.page_count > 1000
ORDER BY ips.avg_fragmentation_in_percent DESC;
Рекомендую создать регламентное задание на обслуживание SQL Server — дефрагментация индексов и обновление статистики по ночам. В Management Studio это делается через Maintenance Plan за 15 минут.
Причина 7 — Антивирус сканирует базу 1С
Это, пожалуй, самая обидная причина тормозов. Обидная она потому, что устраняется буквально за две минуты, а эффект от этого порой бывает просто колоссальный!
Что тут происходит? Антивирус перехватывает каждую операцию чтения и записи файлов. А SQL Server, как вы понимаете, постоянно читает и пишет файлы базы (.mdf, .ldf), tempdb, файлы бэкапов. И каждый, абсолютно каждый из этих запросов антивирус, конечно же, проверяет. На загруженном сервере это выливается в десятки тысяч проверок в минуту!
С файловой базой дела обстоят ещё хуже. Файл 1Cv8.1CD постоянно меняется, и некоторые антивирусы при каждом таком изменении начинают пересканировать его целиком. Мы даже видели, как Kaspersky Endpoint Security умудрялся раздувать время проведения документа в 3-4 раза. Просто вдумайтесь!
Что исключить из проверки антивирусом:
- Папку с файлами баз данных SQL Server (обычно
C:\Program Files\Microsoft SQL Server\MSSQL*\MSSQL\DATA\) - Папку tempdb (если вынесена на отдельный диск)
- Папку с бэкапами SQL Server
- Папку с файловыми базами 1С (если используются)
- Процессы:
sqlservr.exe,ragent.exe,rphost.exe,rmngr.exe - Расширения файлов:
.mdf,.ndf,.ldf,.bak,.1CD
Для Kaspersky Endpoint Security нужно зайти в Настройки → Защита от файловых угроз → Область защиты → Исключения. А для Windows Defender — придётся запустить PowerShell от имени администратора:
# Исключения Windows Defender для SQL Server
Add-MpPreference -ExclusionPath "C:\Program Files\Microsoft SQL Server"
Add-MpPreference -ExclusionPath "D:\SQLData"
Add-MpPreference -ExclusionPath "T:\tempdb"
Add-MpPreference -ExclusionProcess "sqlservr.exe"
Add-MpPreference -ExclusionProcess "rphost.exe"
Add-MpPreference -ExclusionExtension ".mdf"
Add-MpPreference -ExclusionExtension ".ldf"
Add-MpPreference -ExclusionExtension ".ndf"
Причина 8 — Сетевые проблемы (для терминального доступа)
Если пользователи подключаются к 1С через терминальный сервер (RDP) или работают с файловой базой по сети — качество сетевого соединения напрямую влияет на скорость работы.
Для RDP-подключения критична не столько ширина канала, сколько задержка (latency). Можно иметь хоть гигабитный канал, но при задержке в 50 мс каждый ваш клик в 1С будет сопровождаться ощутимой паузой. Для по-настоящему комфортной работы задержка не должна превышать 20-30 мс.
А вот для файловой базы, работающей по сети, критичны обе характеристики. Файловая 1С гоняет по сети просто огромные объёмы данных — при формировании какого-нибудь отчёта в обе стороны может уходить несколько сотен мегабайт!
Что проверить:
- Пинг до сервера:
ping -n 20 server_ip. Смотрите не только среднее время, но и потери пакетов. Даже 1% потерь — это заметные тормоза - Скорость сети: скопируйте файл 500 МБ на сервер и обратно. Если скорость ниже 50 МБ/с в гигабитной сети — что-то не так
- Дуплекс сетевых карт: проверьте, что на сервере и коммутаторе установлен полный дуплекс (Full Duplex). Автосогласование иногда договаривается на Half Duplex
- Коммутатор: дешёвые неуправляемые коммутаторы за 2000 рублей иногда «захлёбываются» под нагрузкой. Для сервера 1С нужен хотя бы нормальный управляемый коммутатор
Для удалённых офисов, подключённых через VPN:
- Не гоняйте файловую базу через VPN. Только терминальный сервер или публикация на веб-сервере
- Проверьте MTU — неправильный MTU на VPN-туннеле вызывает фрагментацию пакетов и жуткие тормоза
- Рассмотрите тонкий клиент 1С вместо толстого — он передаёт меньше данных
Причина 9 — Устаревшая платформа 1С
1С регулярно выпускает обновления платформы — и это, поверьте, не просто очередная смена номера версии. В каждом крупном релизе разработчики добавляют оптимизации, которые реально ускоряют работу, а не просто для галочки.
Если у вас до сих пор стоит платформа 8.3.18 или какая-то ещё более старая — знайте, вы теряете в производительности! В более свежих версиях значительно улучшены механизмы блокировок, оптимизирована работа с временными таблицами, и, что немаловажно, ускорено формирование отчётов на СКД (системе компоновки данных).
Ключевые улучшения по версиям:
- 8.3.20 — оптимизация работы с временными таблицами, улучшенный механизм кэширования
- 8.3.21 — новый механизм управляемых блокировок, снижение количества deadlocks
- 8.3.22 — оптимизация СКД (отчёты формируются быстрее), улучшенная работа с большими списками
- 8.3.23 — параллельное выполнение фоновых заданий, ускорение интерфейса
- 8.3.24-8.3.26 — дальнейшие оптимизации движка запросов и работы с памятью
Обновление конфигурации — это, конечно, отдельная большая тема. Старые конфигурации (например, 1С:Бухгалтерия редакции 2.0) просто не оптимизированы под современные механизмы платформы. Если у вас стоит конфигурация 3-5-летней давности — мой совет, обновляйте! Разработчики 1С постоянно работают над оптимизацией типовых конфигураций: они ускоряют закрытие месяца, проведение документов и формирование отчётов.
А как проверить версию платформы? Всё просто: прямо в 1С нажмите Справка → О программе. Или же можно воспользоваться командной строкой:
:: Посмотреть установленные версии платформы 1С
dir "C:\Program Files\1cv8\" /AD /B
dir "C:\Program Files (x86)\1cv8\" /AD /B
Причина 10 — Плохо написанные отчёты и обработки
Бывает так: всё настроено идеально — SSD, 64 ГБ RAM, SQL Server 2022, tempdb на 8 файлов — а 1С всё равно тормозит. Но тормозит не вся, а при определённых операциях. Обычно это значит, что проблема в коде конкретного отчёта или обработки.
Типичные проблемы в коде 1С, которые убивают производительность:
- Запросы в цикле. Программист написал цикл по документам и внутри цикла выполняет запрос к базе. 1000 документов = 1000 запросов. Должен быть один запрос, который возвращает все данные сразу
- Отсутствие индексирования. Запрос фильтрует по полю, которое не проиндексировано. SQL Server вынужден сканировать всю таблицу. На таблице с миллионом записей это секунды ожидания
- Неоптимальные соединения. Соединение (LEFT JOIN) таблиц без условий или с условиями, которые не используют индексы. Результат — Cartesian product, миллиарды строк во временных таблицах
- Получение всех полей.
ВЫБРАТЬ * ИЗ Документ.РеализацияТовароввместо выборки конкретных полей. Передаются гигабайты ненужных данных - Неправильное использование СКД. Вложенные наборы данных, слишком сложные группировки, вычисляемые поля с подзапросами
Как найти проблемный запрос:
-- Топ-10 самых тяжёлых запросов в SQL Server
SELECT TOP 10
qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg время мс],
qs.execution_count AS [Выполнений],
qs.total_elapsed_time / 1000 AS [Общее время мс],
SUBSTRING(qt.text, 1, 200) AS [Запрос]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY qs.total_elapsed_time DESC;
Ещё полезнее — технологический журнал 1С. Включается в настройках сервера 1С и записывает все длительные запросы с полным текстом. Файл настройки:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\Logs\1C" history="24">
<event>
<eq property="name" value="DBMSSQL"/>
<ge property="Durationus" value="5000000"/>
</event>
<property name="all"/>
</log>
</config>
Этот конфиг записывает все SQL-запросы, которые выполняются дольше 5 секунд. Файл кладётся в C:\Program Files\1cv8\conf\logcfg.xml.
Бонус: чеклист ускорения 1С
Можете даже распечатать этот список и повесить где-нибудь рядом с сервером. Ну, или просто отправьте его своему сисадмину, он оценит.
- Диски: SSD для баз данных, tempdb и логов транзакций
- RAM: минимум 4 ГБ на ОС + 4 ГБ на SQL + 1.5 ГБ на каждого пользователя
- SQL Server: версия 2019 или 2022. Настроен лимит памяти
- Режим базы: клиент-серверный (не файловый) при 4+ пользователях
- tempdb: количество файлов = количеству ядер (до 8), одинаковый размер
- Реструктуризация: раз в 3-6 месяцев. Удаление помеченных объектов ежемесячно
- Антивирус: исключения для папок SQL и процессов 1С/SQL
- Сеть: задержка до сервера не более 20 мс, без потерь пакетов
- Платформа 1С: актуальная версия, совместимая с конфигурацией
- Код: нет запросов в циклах, проиндексированы поля фильтрации
- Обслуживание SQL: еженощная дефрагментация индексов и обновление статистики
- Бэкапы: не во время рабочих часов, на отдельный диск
- Регламентные задания 1С: тяжёлые задания перенести на ночь
- Модель восстановления SQL: для некритичных баз — Simple (не Full), чтобы не раздувать лог транзакций
Не обязательно делать всё и сразу, поверьте. Начните, например, с пунктов 1 (SSD) и 7 (антивирус) — именно они дают максимальный эффект при минимальных затратах. Потом займитесь tempdb и реструктуризацией. А дальше уже двигайтесь по списку, по мере необходимости.
Часто задаваемые вопросы
Сколько оперативной памяти нужно серверу 1С на 10-15 пользователей?
Минимум 16 ГБ, но оптимально, я считаю, 32 ГБ. Есть простая формула: 4 ГБ на ОС + 4 ГБ на SQL Server + по 1-1.5 ГБ на каждого активного пользователя. Для 15 пользователей, которые активно работают в 1С:Бухгалтерии и 1С:Зарплата, мы лично рекомендуем 32 ГБ с возможностью расширения до 64 ГБ. Только не забудьте ограничить максимальную память SQL Server через sp_configure, иначе он может забрать себе всё!
Файловая база 1С или клиент-серверная — что выбрать?
Файловая база подходит для 1-3 пользователей и баз до 2-3 ГБ. Если же у вас пользователей больше пяти или база перевалила за 4 ГБ — тогда однозначно переходите на клиент-серверную, будь то MS SQL Server или PostgreSQL. Переход на клиент-серверный вариант при многопользовательской работе обычно ускоряет всё в 3-5 раз, это проверено. Выгрузка/загрузка через .dt файл занимает от 30 минут до нескольких часов, в зависимости от объёма.
Как часто нужно делать реструктуризацию базы 1С?
Для активно используемых баз — раз в 3-6 месяцев. Просто зайдите в Конфигуратор → Администрирование → Тестирование и исправление. Если ваша база за квартал вдруг выросла на 20-30% без видимых на то причин — знайте, пора действовать! Помимо реструктуризации, ежемесячно не забывайте удалять помеченные объекты и раз в месяц сокращать журнал регистрации.
Можно ли ускорить 1С без замены оборудования?
Да, абсолютно! Настройка tempdb, добавление исключений в антивирусе, обновление платформы 1С, реструктуризация базы, оптимизация отчётов — всё это делается абсолютно бесплатно и даёт, между прочим, 20-40% прироста производительности. По нашему опыту, грамотная настройка SQL Server и исключения в антивирусе — это первое, что стоит сделать, прежде чем тратиться на новое дорогостоящее железо.
1С тормозит только у одного пользователя — в чём причина?
Если 1С тормозит конкретно локально, на одном компьютере, то проверьте следующее: канал связи (посмотрите пинг до сервера, нет ли потерь пакетов), локальный антивирус, нет ли забитого кэша 1С (папка %AppData%\1C), а также хватает ли RAM на рабочей станции. Причиной может быть и какой-то конкретный отчёт или обработка с плохим кодом, которыми пользуется именно этот сотрудник. Попросите его показать, что именно тормозит — очень часто всё упирается в одну определённую операцию.
Заключение
Знаете, 1С тормозит не просто так, без причины. За каждым «зависанием» всегда стоит конкретная проблема: будь то медленный диск, нехватка памяти, криво настроенный SQL Server, раздутая база или, увы, неоптимизированный код. И, что самое главное, у каждой такой причины есть своё конкретное решение.
Вернёмся к нашему «СтройАльянсу». Вот что мы сделали за неделю:
- Заменили HDD на SSD Samsung 870 EVO 1 ТБ — 10 000 руб.
- Добавили 16 ГБ RAM (было 8, стало 24) — 5 000 руб.
- Обновили SQL Server с 2008 R2 до 2019 Express — бесплатно
- Перевели базу с файловой на клиент-серверную — 3 часа работы
- Настроили tempdb (4 файла по 2 ГБ) — 15 минут
- Провели реструктуризацию (база сжалась с 12 до 7 ГБ) — 2 часа
- Добавили исключения в антивирус — 2 минуты
Итог этой истории: всего 15 000 рублей на железо и один день нашей работы. Время открытия документа сократилось с 20 секунд до невероятных 1.5 секунды! Бухгалтерия «СтройАльянс» закрыла квартал вовремя, а главбух, к нашему общему счастью, перестала звонить нам по пятницам.
Если ваша 1С тормозит, и вы совершенно не понимаете, с чего начать — мой вам совет: начните с SSD и добавления исключений в антивирусе. Это всего два действия, которые займут минимум вашего времени, но дадут максимальный эффект. А если вам нужен комплексный аудит и полноценная оптимизация, то мы в АйТи Фреш занимаемся этим каждый божий день.
Полезные ссылки: ИТС — Оптимизация производительности 1С, Microsoft Learn — Производительность SQL Server
ООО «АйТи Фреш» — аудит и оптимизация 1С
Мы проведём для вас комплексную диагностику: тщательно проверим сервер, SQL Server, базу данных, сеть и даже код. Найдём все узкие места и обязательно их устраним. Мы работаем абсолютно с любыми конфигурациями 1С — это и Бухгалтерия, и Зарплата, и Управление торговлей, и даже ERP. И, что важно, мы гарантируем измеримый результат: всегда замеряем скорость до и после оптимизации, чтобы вы видели реальную разницу.

Комментарии