Система 1С занимает доминирующее положение на рынке автоматизации малого и среднего бизнеса. Если компания выбрала учетную систему 1С, то обычно в ней работают практически все сотрудники, начиная от рядовых специалистов и заканчивая руководством. Соответственно, от скорости работы 1С зависит скорость бизнес-процессов компании. Если 1С работает с неудовлетворительной скоростью, то это напрямую сказывается на работе всей компании и на получении прибыли.
Фактически существует три метода ускорения 1С:
- Увеличение аппаратных мощностей.
- Оптимизация настроек операционной системы и СУБД.
- Оптимизация кода и алгоритмов в 1С.
На текущий момент мы предлагаем возможность провести бесплатный тест производительности базы 1С в нашем эталонном облаке.
Первый метод требует покупки оборудования и лицензий, третий – больших трудозатрат программистов и, как следствие, оба пути выливаются в значительные финансовые затраты. В первую очередь нужно обратить внимание на программный код, так как никаким увеличением мощностей сервера невозможно компенсировать неверный код. Любой программист знает, что с помощью всего нескольких строчек кода возможно создать процесс, который полностью загрузит ресурсы любого сервера.
В случае, если компания уверена в оптимальности кода программы, а она по-прежнему работает медленно, обычно руководство принимает решение увеличить серверные мощности. В этот момент возникает логичный вопрос: чего не хватает, сколько и что необходимо в итоге добавить.
Компания 1С на вопрос о том, сколько нужно ресурсов, дает достаточно расплывчатый ответ, о нем мы писали ранее в наших постах. И поэтому приходится самостоятельно проводить эксперименты и разбираться, от чего же зависит производительность 1С. Ниже описаны эксперименты с производительностью программы в компании EFSOL.
При работе с 1С 8.2, особенно с конфигурациями, которые используют управляемые формы, был замечен странный факт: 1С работает быстрее на рабочей станции нежели на мощном сервере. Причем все характеристики рабочей станции хуже, чем у сервера.
| № | Характеристика | Рабочая станция | Сервер |
| 1 | Процессор | Intel Core i5 3,0 Ghz | 2*intel xeon E5620 2,4 Ghz |
| 2 | Сокет | LGA 2011 | LGA 1366 |
| 3 | Память | 16 Gb DDR3 1333 Mhz | 48 Gb DDR3 1066 Mhz |
| 4 | Дисковая подсистема | Один диск SSD Intel 520 240 Gb | IBM Storage, SAS15K RAID 10 подключен по 1 Gbit iSCSI |
| 5 | Производительность по тесту Гилева | 44,64 | 17,53 |
| 6 | Версия СУБД | MSSQL 2008R2 | |
| 7 | Платформа 1С | 8.2.18.109 | |
Таблица 1 – Конфигурации, на которых проводилось первоначальное тестирование
Рабочая станция показывает производительность на 155% больше, чем сервер 1С с превышающими характеристиками. Мы начали разбираться, в чем дело и сужать круг поисков.
Рисунок 1 – Замеры производительности на рабочей стации тестом Гилева
Первое подозрение было, что тест Гилева неадекватен. Замеры открытия форм, проведения документов, формирования отчетов и т.д инструментами КИП показали, что тест Гилева выдает оценку пропорциональную реальной скорости работы в 1С.
Количество и частота ОЗУ
Анализ доступной в интернете информации показал, что многие пишут о зависимости производительности 1С от частоты памяти. Именно от частоты, а не от объема. Решили проверить эту гипотезу, так как у нас на сервере частота ОЗУ 1066 Mhz против 1333 Mhz на рабочей станции, а объем ОЗУ на сервере и так значительно выше. Решили поставить сразу не 1066 Mhz, а 800 Mhz для того, чтобы эффект зависимости производительности от частоты памяти был нагляднее. Результат – производительность упала на 12% и составила 39,37 единиц. На сервер поставили память с частотой 1333 Mhz вместо 1066 Mhz и получили незначительный прирост производительности – около 11%. Производительность составила 19,53 единицы. Соответственно, дело не в памяти, хотя ее частота дает небольшой прирост.
Рисунок 2 – Замеры производительности на рабочей станции после понижения частоты ОЗУ
Рисунок 3 – Замеры производительности на сервере после повышения частоты ОЗУ
Дисковая подсистема
Следующая гипотеза была связана с дисковой подсистемой. Сразу возникло два предположения:
- SSD лучше, чем SAS диски, пусть даже они в 10 рейде.
- iSCSI работает медленно или некорректно.
Поэтому в рабочую станцию поставили обычный SATA-диск вместо SSD, то же самое сделали и с сервером – базу разместили на локальном SATA-диске. В результате, замеры производительности никак не изменились. Скорее всего, это происходит, поскольку есть достаточное количество ОЗУ и диски практически никак не задействованы при выполнении теста.
Процессор
Процессоры на сервере, конечно, мощнее и их два, но частота немного ниже, чем на рабочей станции. Решили проверить влияние частоты процессора на быстродействие: для сервера процессоров с большей частотой под рукой не оказалось, поэтому снизили частоту процессора на рабочей станции. Снизили сразу до 1,6, чтобы корреляция проявлялась ярче. Тест показал, что производительность упала значительно, но даже с процессором 1,6 рабочая станция выдавала почти 28 единиц, что практически в 1,5 раза больше чем на сервере.
Рисунок 4 – Замеры производительности на рабочей стации с процессором 1,6 Ghz
Видеокарта
В интернете встречается информация о том, что на производительность 1С может влиять видеокарта. Мы пробовали использовать интегрированное видео рабочей станции, профессиональный адаптер Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5, старую видеокарту GeForce 16MbSDR. Во время проведения теста Гилева какой-либо значительной разницы не заметили. Возможно, видеокарта все-таки влияет, но в реальных условиях, когда нужно открывать управляемые формы и т.д.
В данный момент существует два подозрения, почему рабочая станция работает быстрее даже с заметно худшими характеристиками:
- Процессор. Тип процессора на рабочей станции лучше подходит 1С.
- Чипсет. При прочих равных условиях наша рабочая станция имеет более новый чипсет, возможно, дело в нем.
Мы планируем закупить необходимые комплектующие и продолжить тесты, чтобы окончательно выяснить, от чего же в большей степени зависит производительность 1С. Пока идет процесс согласования и закупки, мы решили выполнить оптимизацию, тем более, что это ничего не стоит. Были выделены следующие этапы:
Этап 1. Настройка системы
Для начала выполним следующие настройки в BIOS и операционной системе:
- В BIOS сервера отключаем все настройки по экономии электропитания процессора.
- Выбираем в операционной системе план «Максимальная производительность».
- Процессор также настраиваем на максимальную производительность. Это можно сделать с помощью утилиты PowerSchemeEd.
Этап 2. Настройка SQL сервера и сервера 1С:Предприятия
Вносим следующие изменения в настройки сервера СУБД и 1С:Предприятия.
- Настройка протокола Shared Memory:
Shared Memory включится только на платформе начиная с 1С 8.2.17, на более ранних релизах включится Named Pipe – несколько уступающий в скорости работы. Данная технология работает только если службы 1С и MSSQL установлены на одном физическом или виртуальном сервере.
- Рекомендуется перевести службу 1С в режим отладки, как не парадоксально это дает прирост производительности. По умолчанию отладка на сервере выключена.
- Настройка SQL сервера:
Нам нужен только сервер, остальные службы, которые к нему относятся и, возможно, кто-то ими пользуется, только тормозят работу. Останавливаем и отключаем такие службы как: FullText Search (у 1С собственный механизм полнотекстового поиска), Integration Services и т.д.- Устанавливаем максимально отведенное серверу количество памяти. Это необходимо для того, чтобы sql-сервер рассчитывал на этот объем и чистил память заблаговременно.
- Устанавливаем максимальное количество потоков (Maximum worker threads) и выставляем повышенный приоритет сервера (Boost priority).
Этап 3. Настройка рабочей базы данных
После того, как сервер СУБД и 1С:Предприятия оптимизированы, переходим к настройкам баз. Если база еще не развернута из .dt файла, и вы знаете примерный ее размер, то первичному файлу размер инициализации лучше сразу указать «>=» размера базы, но это дело вкуса, он все равно вырастет при развертке. А вот Автоувеличение размера надо обязательно указать: примерно по 200 МБ на базу и по 50 МБ на лог, т.к. значения по умолчанию – рост по 1МБ и по 10% очень сильно тормозят работу сервера, когда ему при каждой 3й транзакции надо файл увеличивать. Также хранение файла базы и файла лога лучше указать на разных физических дисках или RAID группах, если используется RAID массив, и ограничить разрастание лога. Рекомендуется выносить файл Tempdb на высокоскоростной массив, так как СУБД к нему довольно часто обращается.
Этап 4. Настройка регламентных заданий
Регламентные задания создаются довольно просто с помощью Maintenance Plan в разделе Management, используя графические инструменты, поэтому подробно описывать, как это делается не будем. Остановимся на том, какие операции необходимо выполнять для повышения производительности.
- Дефрагментацию индексов и обновление статистики нужно производить ежедневно, т.к. если фрагментированность индексов > 25%, это резко снижает производительность сервера.
- Дефрагментация и обновление статистики – делается быстро и не требует отключения пользователей. Также рекомендуется делать ежедневно.
- Полная реиндексация – делается с блокировкой БД, рекомендуется делать хотя бы раз в неделю.
В итоге, с помощью тонких настроек системы, SQL сервера и рабочей базы, нам удалось повысить производительность на 46%. Замеры были проведены с помощью инструмента 1С КИП и с помощью теста Гилева. Последний показал 25,6 единиц против 17,53 которые были изначально.
Краткий вывод
- Производительность 1С не сильно зависит от частоты ОЗУ. При достижении достаточного ее объема дальнейшее наращивание памяти не имеет смысла, так как не приводит к увеличению производительности.
- Производительность 1С не зависит от видеокарты.
- Производительность 1С не зависит от дисковой подсистемы при условии, что не происходит превышения очереди чтения или записи дисков. Если установлены SATA диски и у них не превышена очередь, то установка SSD не приведет к повышению производительности.
- Производительность довольно сильно зависит от частоты процессора.
- При грамотной настройке операционной системы и MSSQL-сервера возможно добиться увеличения производительности 1С на 40-50% без каких-либо материальных затрат.
ВНИМАНИЕ! Очень важный момент! Все замеры были выполнены на тестовой базе с использованием теста Гилева и инструментов 1С КИП. Поведение реальной базы с реальными пользователями может отличаться от полученных результатов. Например, в тестовой базе мы не обнаружили зависимости производительности от видеокарты и объема ОЗУ. Данные выводы достаточно сомнительны и в реальных условиях эти факторы могут оказывать существенное влияние на производительность. При работе с конфигурациями, использующими управляемые формы, видеокарта важна и мощный графический процессор ускоряет работу с точки зрения прорисовки интерфейса программы, визуально это проявляется в более быстрой работе 1С.
Ваша 1С работает медленно? Закажите ИТ-обслуживание компьютеров и серверов специалистами компании EFSOL с многолетним стажем или перенесите свою 1С на мощный и отказоустойчивый виртуальный сервер 1С.
Читайте также:
- Сравнение производительности типовой конфигурации 1С 8.2 при использовании бесплатных СУБД: PostreSQL, IBM DB2
- Сравнение производительности виртуальных машин Hyper-V 1-го и 2-го поколения на примере работы 1С
- Сравнение производительности 1С при использовании СУБД PostgreSQL и MS SQL
- Кластер серверов 1С – построение высоконагруженных систем
- Сравнение производительности 1С на MS Server SQL 2012, 2014, 2019
- Сравнение производительности 1С на платформах MS Server (SQL) и Unix (PostgreSQL)
- Тестирование производительности 1С на СУБД MS SQL и PostgreSQL (50, 100 и 200 пользователей)
- Анализ производительности различных версий платформ 1С


1С на странице https://its.1c.ru/db/metod8dev/content/5837/hdoc пишет, что дефрагментацию после реиндексации делать НЕ нужно, а Вы пишите, что нужно делать. В чем заключается фундаментальное различие?
Да, Вы правы. После реиндексации не требуется выполнять дефрагментацию. Исправляем ошибку в статье
При работе с конфигурациями, использующими управляемые формы, видеокарта важна и мощный графический процессор ускоряет работу с точки зрения прорисовки интерфейса программы, визуально это проявляется в более быстрой работе 1С.
—————————————————-
Первый раз слышу что бы сервер отрисовывал пользовательский интерфейс.
Под этим словосочетанием имеется ввиду графическое отображение сеанса удаленного рабочего стола RDS. Уточните Ваш вопрос или замечание.
Добрый день!
Я так и не понял, каковы результаты Ваших экспериментов, производительность сервера увеличилась, но она всё равно ниже чем у рабочей станции.
У Вас оптимизация шла SQL сервера, но к потрясающим результатам это не привело.
У меня ситуация. есть Сервер windows server 2016 + mssql 2016 + 1C.
При запуске 1С на сервере огромный отчёт формируется 27 минут, при подключении к нему с рабочей станции i3 7100 4Gb тот же отчёт формируется 53 минуты, при подключении с терминального сервера xeon e5-2620 32Gb этот же отчёт формируется 80 минут.
Код оптимизирован, сложный отчёт с большим количеством картинок(файл Excel получается пару Gb), поэтому долго, дело не в этом. Вопрос – почему терминал работает настолько медленней рабочей станции, где копать. Условия равные, нагрузка 1 пользователь на базу, во всех случаях.
Заранее спасибо за умные идеи.
Это довольно старая статья, с тех пор много что поменялось. Более свежие статьи можно найти в правой колонке. Для разбора Вашей ситуации можно провести аудит производительности https://efsol.ru/promo/performance-1s.html
Столкнулся с подобной ерундой. После преезда со старого псевдосервера на новый гораздо более мощный сервер начались серьёзные затыки по быстродействию. Причём по метрикам непонятно в каком месте, так как никакие ресурсы не подходят даже близко к предельной по загрузке. Ситуация ещё усугбляется тем, что это на виртуалке крутится. И никто точно не знает в чём дело, куда копать и что настраивать. Похоже, даже сама 1С…
Добрый день! Можем предложить Вам провести аудит производительности 1С https://efsol.ru/promo/performance-1s.html
Результаты теста Гилева напрямую зависят от производительности ОДНОГО ядра. Тест одноядерный, однопоточный. Зависимость “гилевских попугаев” от тактовой частоты – прямо пропорциональная.
И да – еще необходимо полностью отключить все режимы энергосбережения процессора – всякие там Turbo Boost и иже с ними. Вячеслав об этом писал
А теперь поменяйте местами операционные системы и повторите тест. Результат вас сильно удивит )))
Дел в том, что серверные ОС по умолчанию ограничивают выделение ресурсов одной задаче или службе, это так называемое “честное распределение ресурсов”, которое в ОС начиная с 2008R2 полностью отключить невозможно. Если сравнивать производительность по 1с77, то в отличии от 2003-го сервера на 2008-м она падает в 1,5-2 раза, на 2008R2 в 2-4, на 2012R2 – в 4-6 раз. Замеры производились на действующей базе на одном оборудовании путем переиндексации и перепроводки документов.
Максим, очень интересное наблюдение касательно поведения 1С 7.7 на разных серверных ОС.
Мы с этой редакцией давно уже не сталкивались, сказать ничего не можем. По поводу 1С 8.X, у нас клиенты работают на разных серверных ОС и разницы в производительности мы не замечали.
Скажите, а база у Вас была СУБД или файловая? Если СУБД – то на всех WinServer ставили одну и туже версию СУБД и какую?
Здравствуйте! За счёт чего режим отладки повышает производительность? Ведь по факту система подгружает ещё и отладчик.
Добрый день, Александр! Собственно, мы так в статье и пишем, что явление парадоксальное. Выявлено сугубо практическим путем: включаем отладку и тест показывает прирост пару %, отключаем – тест показывает снова старые значения. Проверяли на разных системах – везде такая зависимость производительность от отладки. Теорией пока это странное явление подкрепить не можем.
Здравствуйте!
Актуален ли “прирост” производительности на платформах выше 8.3.10.
Проводили ли замеры основных операций по Apdex и были ли корреляции?
https://efsol.ru/articles/performance-1s-8.html вот здесь тесты разных версий платформ.
как вы думаете не является ли причиной регистровая память?
Думаем, что нет. Отличие регистровой памяти в том, что она снижает электрическую нагрузку на микросхемы и это позволяет избежать ошибок и масштабировать ОЗУ, а не в повышении производительности.
Регистровая память медленнее, вообще-то
а не пробовали на сервере включить на время тестирования кеширование записи на дисках? Интересно на сколько оно влияет.
Анатолий, во время тестов кеширование записи на RAID-контроллере не включали. Теоретически, при высоких нагрузках кеш будет играть роль буфера, снимая пик загрузки ресурсов. Тем самым улучшая картину производительности. Сейчас у нас в проработке статья с серией сравнительных тестов клиент-серверной архитектуры 1С – учтем Вашу рекомендацию, спасибо.
Продолжение статьи будет или согласовать закупку оборудования не удалось?
Артём, продолжать статью планируем, но пока этот вопрос отложен.
Еще я бы посоветовал увеличить количество файлов в tempdb по количеству ЦП, и разнести их по разным дискам, ну и создавать их одинакового размера, также при выделении памяти SQL серверу использовать минимальное значение фиксированным и использовать AWE для резервирования памяти.
Николай, касательно файлов TempDB – полностью с Вами согласен, это отвечает рекомендациям Майкрософт, по возможности проверим какой прирост в производительности 1С даст такая оптимизация.
Касательно AWE, на сколько я знаю, данный механизм актуален только для 32-битных ОС(https://technet.microsoft.com/ru-ru/library/ms190673(v=sql.105).aspx).
У нас использовалась ОС Windows 2012R2