Многопоточное тестирование производительности сервера 1С - СУБД
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Описание
Тест создает множество фоновых сеансов и выполняет ими одинаковые действия, например создание элементов справочников или запись наборов записей регистров. Он позволяет оценить, насколько "производительна" данная связка 1с - субд, а также насколько она "масштабируема", т.е. количество активных пользователей, при котором система еще будет работать, но "низенько-низенько".
Эмпирическим путем получено число в 400-500 попугаев на поток (не учитывая временные таблицы), при котором работа терпима. Благодаря механизму "глобального обмена" можно повторить тест с чьии-то настройками и сравнить результаты.
Полный тест выполняется от получаса до часа на стандартных настройках, примерно в 2 раза меньше на "быстрых" и в 2 раза дольше на "точных". Естественно, проводить не все тесты, то время пропорционально уменьшится.
Планы
Снова сделать просмотр результатов на сайте. Сделано: https://fragster.ru/performanceTest/testResults
Работа на файловых базах.
Новые тесты.
Обмен "через файлы", для случай, когда на на сервере нет интернета
Многое другое :)
Версия 2.0.012
Исправлена невозможность обмена, если указано более 2-х серверов
Версия 2.0.011
Устранена несовместимость с 8.3.9 (из-за изменения http://downloads.v8.1c.ru/content//Platform/8_3_9_1648/1cv8upd.htm#f092f970-ec4b-11e5-a3f7-0050569f678a)
Версия 2.0.010
Исправлена ошибка несоздания узла обмена для обмена результатами.
Версия 2.0.009
Изменен способ старта фоновых заданий, теперь менее вероятна ошибка "Не получилось синхронизировать потоки за ХХ секунд!"
Исправлены ошибки невозможности выбора параметра в отчетах "Отчет по тесту" и "Профиль результата"
Изменены варианты ответов на запрос заполнения информации о серверах на более понятные.
Версия 2.0.008
Теперь при запуске в режиме "Толстый клиент управляемое приложение" обработка обмена работает целиком на клиенте, и в таком случае точно не нужен интернет на сервере.
Версия 2.0.007
В результатах тестов убрана колонка "номер потока", теперь результаты хранятся только в разрезе количества потоков теста. Это в десятки раз сократило количество строк в ТЧ Результаты и Профиль Результата, так что теперь собственные тесты открываются с такой же скоростью, как и тесты, полученные из интернета (ранее была задержка в несколько секунд, в результатах интернета для сокращения трафика изначально информация о номере потока была опущена изначально). Также немного ускорилось формирование отчетов.
Исправлены ошибки при запуске в режиме "Толстый клиент управляемое приложение". При запуске в этом режиме интернет на сервере не обязателен для обмена.
Если вы делаете обновление, то теперь возможно обновление только с версии >= 2.001 (при попытке обновления версии 1.х.ххх будет ошибка). Возможно позже сделаю поставку, чтобы корректно это контролировать.
Версия 2.0.006
Очистка результатов после выполнения тестов теперь также проходит многопоточно, это значительно снизило паузы при проведении тестирования.
Также при очистке данных регистров накопления и сведений теперь выключаются итоги.
Версия 2.0.005
Обработка "Обмен результатами" теперь получает все результаты в цикле (в связи с ограничением хостинга недавно пришлось ввести "порционный обмен" результатами, в более ранних версиях приходилось несколько раз нажимать кнопку обмена)
Добавлен отчет "сравнение результатов", колонки - тесты, строки - результаты. Предложения по работе доработке этого и других отчетов приветствуются.
Форма списка справочника тестов, теперь она же является формой выбора/подбора.
Разрешен множественный выбор в форме списка - можно быстро сформировать отчет сравнения, выделив несколько строчек и выбрав его в меню "сформировать на основании"
Обработка "проверка синхронизации" заменена соответствующим отчетом (ради показа графика с распределением времени прихода сигнала синхронизации к потокам теста)
Во все отчеты по тестам добавлен быстрый отбор по видам тестов (по кнопке "настройки").
Сообщения от потоков теперь приходят через регистр сведений (подготовка к реализации файлового варианта теста).
Потоки теперь стартуют порциями с паузами между ними (вроде как должно повысить стабильность).
Проведена чистка кода, удалены неиспользуемые функции.
Немного причесан интерфейс, теперь все окна открываются единообразно.
Версия 2.0.004
Исправлена ошибка, существующая на платформе < 8.2.15
Версия 2.0.003
Исправлена ошибка доступа к таблице "профиль результатов" при выполнении теста
Версия 2.0.002
Исправлена ошибка с тем, что у загружаемых по глобальному обмену тестов не проставляется код.
Добавлена обработка одновления конфигурации для пеернумерации ранее загруженных резульатов, т.е. новую конфигурацию делать не надо, достаточно обновить текущую.
Переработана форма обмена - место на форме используется более рационально.
Из формы теста убрана таблица с профилем результатов - это ускорило открытие формы в несколько раз для завершенных тестов (там очень много строк, что существенно замедляло то самое открытие).
Версия 2.0.001
Новая версия. Старшая цифра изменилась, поскольку изменились алгоритмы работы - больше сделан упор именно на производительность СУБД.
Основные изменения:
Изменен алгоритм тестов (основной упор на запись наборов)
Добавлен тест "Временные таблицы" - он должен показать "чистую" производительность без блокировок (спасибо за идею Гилеву Вячеславу).
Добавлены настройки тестов - количество потоков и размер создаваемых объектов (100, 1000, 5000 строк)
Изменен отчет "Отчет по тесту" - добавлен показатель "средняя производительность одного потока"
Добавлен отчет "Профиль выполнения" - показывает распределение времени записи одного объекта (в мс), т.е. сколько объектов записалось за 16 мс, сколько за 32 и тд. Для платформы < 8.2.17 информация собирается только на вин-сервере, при релизе платформы >= 8.2.17 и на линуксе тоже.
Доработана обработка "проверка синхронизации". Теперь она показывает, через сколько миллисекунд (условия для работы как в предыдущем пункте) пришел сигнал от "мастера" до "потоков" о том, что пора начинать "работать".
Вместо публикации на сайте теперь глобальный обмен результатами, соответственно, создана обработка для него. Из-за того, что очень сильно доработана конфигурация - просмотр на сайте http://fragster.ru/perfomanceTest/ временно отключен, чужие тесты можно увидеть только через обмен, а он требует доступа к интернету на сервере 1с предприятия.
Доработан интерфейс, например отчеты перенесены в меню "создать на основании", а также через это меню возможно окрыть более одного окна :)
Начата работа над возможностью запуска в файловой версии. К сожалению, это потребовало убрать старый механизм фонового обновления информации, теперь окно подвисает на время выполнения теста.
Версия 1.0.004
Добавил обработку для проверки механизма синхронизации: указываете, сколько потоков запустить, она показывает сколько потоков в какой момент получили сигнал синхронизации.
Дорботал интерфейс - на рабочий стол поместил список тестов, перенес отчет и новую обработку с панели действий на панель навигации (с верхней на левую).
Версия 1.0.003
Исправил синхронизацию потоков - теперь все потоки запускаются действительно одновременно, ранее на большом количестве потоков некоторые потоки "съезжали" по времени на время до 7 секунд (для 112 потоков, особенно на слабых серверах), что вызывало "флуктуации" в сторону аномального увеличения производительности результатов для большого количества потоков.
Информация о сервере 1с теперь заполняется при открытии формы, а не после выполнения теста.
Версия 1.0.002
Добавил автозаполнение информации о сервере 1с.
Изменил алгоритм синхронизации потоков - теперь используется ЗапуститьПриложение вместо бесконечного цикла для ожидания запуска других потоков, что не грузит процессор и дает время для запуска других потоков. Также увеличил время на синхронизацию до 30 секунд.
Теперь тесты выполняются в 1, 2, 4, 8, 16, 32, 48, 64, 80, 96, 112 потоков.
Обновил WS-ссылку, добавил версию платформы в результаты.
Добавил запрос на публикацию результатов теста при изменении (Внимание! Для успешной публикации должен быть разрешен интернет на сервере 1с!)
Версия 1.0.001
Добавил автосохранение после выполнения теста. (Отчет по текущему тесту теперь работает сразу после выполнения теста).
Добавил версию конфигурации в результаты теста.
Обновил WS-ссылку, подчистил WSDL, убрал anyType везде.
Убрал заглушку на кнопке "Опубликовать", теперь результаты публикуются на http://fragster.ru/perfomanceTest/ , можно сравнить с другими.
Версия 1.0.000
Причесал интерфейс
Добавил сохранение результатов
Немного изменил алгоритм проведения документов, добавил в него выборку данных.
Добавил отчет по тестам с красивыми графиками :)
Добавил вызов веб сервиса, прошу протестировать (пока там только пустышка). В ближайшие пару-тройку дней добавлю сохранение результатов и вывод статистики на отдельную страничку. Возможно добавлю "засасывание" результатов с этой страницы, чтобы можно было стравнить прямо в конфигурации результаты разных людей встроенным отчетом.
Первая версия, она же альфа:
Начал писать тест для оценки производительности сервера в режиме параллельной работы. Нулевая версия, просто выполняет теств1/2/4/8/16 потоков, не накапливая статистику. Пока работает только в клиент-серверном варианте.
Вступайте в нашу телеграмм-группу Инфостарт
См. также
Информационная безопасность Удаленное управление Сервера Системный администратор Разработчик 1С 8.3 Абонемент ($m)
Один запуск на сервере, где работают 1С и СУБД, и видно, какие двери открыты: RDP и подбор паролей, пароли и учётки Windows, порты, папки с бэкапами и паролями, SQL Server, обновления и антивирус. 34 проверки с вердиктом, отчёт в Markdown для нейросети и HTML, обработка 1С для чтения отчёта. К мерам приложены восемь скриптов исправления с пробным режимом и откатом.
10 стартмани
вчера в 12:30 195 2 nedomolkov.ivan 0
Мониторинг Сервера Системный администратор 1С 8.3 Бесплатно (free)
Шесть блоков технического отчёта по кластеру 1С: площадка, процессы, нагрузка, диск, копии, журналы за названный период — и открытые вопросы. Цифры из двух реальных прогонов на Windows Server 2019 (srvinfo 119 ГБ, 444 бэкапа и ни одного по нужной базе, висящий сеанс с лицензией). Что собирать, чего не делать, и где агент ошибся.
02.11.2026 258 netbka 0
Нейросети Сервера Бесплатно (free)
Работаю с MacBook, а виртуалки, сервисы и локальные модели запускаю на домашнем сервере с Proxmox. Рассказываю, как устроено моё облако и как нейросети помогли его собрать.
25.10.2026 812 RockRock 20
HighLoad оптимизация Технологический журнал Сервера Запросы Системный администратор Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Составной отчет формировался 15 минут. Вместо перебора разделов одна команда rac показала, что сеанс занят запросом к СУБД, а временный техжурнал с порогом 20 секунд за один прогон назвал виновника: один SQL на 240 секунд и точную строку модуля. В статье четыре разные картины «висит» и как их различить: идет запрос в СУБД, клиент ждет невидимое модальное окно, зомби-вызов после закрытого клиента, зависшее фоновое задание. Пример logcfg.xml, разбор события DBMSSQL с полем Context, замер пакета запросов по временным таблицам, регламентное задание, которое «выполнено», а данные стоят, и шпаргалка по диагностике.
16.10.2026 1033 Konstmax13 6
Архивирование (backup) Инструменты администратора БД Администрирование СУБД Сервера Системный администратор 1C:Бухгалтерия 1С:Предприятие 8. Транспортная логистика, экспедирование и управление автотранспортом КОРП 1C:ERP 1С:ЗУП 1С:УНФ 1С:Розница Отраслевые Россия Бесплатно (free)
Кроссплатформенная утилита на Go-lang для резервного копирования информационных баз 1С:Предприятие. Основная задача программы — выгрузка информационных баз 1С в файлы *.dt с автоматическим удалением устаревших копий.
15.10.2026 400 32 bigboy 0
Сервера Системный администратор 1С 8.5 1С:Управление торговлей 11 Россия Бесплатно (free)
Когда запускается новейший 16-ядерный флагман AMD Ryzen 9 9950X (микроархитектура Zen 5 с паспортным бустом до 5.7 ГГц), скоростные накопители NVMe PCIe 5.0 x4 и быстрый комплект DDR5, подсознательно ждешь феноменальных результатов «из коробки». Мы развернули монолитный вычислительный комплекс «All-in-One» (сервер приложений «1С:Предприятие 8.5.1» + СУБД Microsoft SQL Server 2022 Enterprise на Windows Server 2025) внутри гипервизора Proxmox VE 9.2. Запускаем однопоточный синтетический тест Гилёва (TPC-1C) и видим на экране холодный душ: 35.46 балла. Ниже — детальная хроника инженерного расследования, в ходе которого мы шаг за шагом сняли скрытые инфраструктурные барьеры на каждом слое системы (BIOS, гипервизор KVM, ядро Windows, СУБД, платформа 1С) и разогнали сервер с 35.46 до 79.37 баллов (+123.8% чистой скорости проведения документов), сделав виртуальную машину абсолютным лидером среди KVM-систем в глобальном датасете 1С 8.5.1.
15.10.2026 2237 YA_93013054 18
Технологический журнал Сервера EDT Обновление 1С Системный администратор Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Конфигуратор и агент EDT тихо вылетают на 0 % «Обработки структуры базы данных», EDT пишет «Потеряно соединение с агентом конфигуратора», а модель проекта при этом чистая. Разбор двух аварий на большой серверной базе БП КОРП: какие факты снимать (журнал Windows, техжурнал нужной версии, хвост лога процесса), почему инкрементальная выгрузка EDT ломается после сбоев, как довести обновление пакетно через /UpdateDBCfg -Server, как опознать свои rphost среди нескольких кластеров и снять агент EDT, который сам поднимается и держит базу. Протокол одного дня по минутам и порядок диагностики из восьми шагов.
15.10.2026 421 Konstmax13 0
Администрирование СУБД Сервера Системный администратор Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Примеры скриптов для работы с автономным сервером (ibsrv).
09.10.2026 1058 hexhoc 6
Под 8.3 тоже имя объекта РУКАМИ менять?
Линукс у нас есть. Ключей защиты на всех хватит )
А вот с этого места пожалуйста подробнее? Что именно и где? а то нужно админам передать, я ж в самой настройке зелень, аки.... кузнечека )
Из графиков можно судить, как просядет производительность при энном количестве активных пользователей. Почему взялись провалы - сказать, на самом деле трудно, тем более, что они, как я понял, повторяются в нескольких прогонах теста.
Ваши графики не похожи на те, что в публикации - потому что в публикации график сделан на тестовом "сервере" - коре дуо первого поколения (двухъядерном) и 2 ГБ нешустрой (866 ДДР2) оперативной памяти.
Кстати, на этих выходных у меня таки получилось допилить SOAP сервер на php таким образом, чтобы он передавал сложные структуры таким образом, чтобы 1с их кушала нормально. Соответственно, скоро будет версия теста с глобальным обменом результатами.
На чем обработку запускать? На любой рабочей БД? Это безопасно для ее данных? На чистой, пустой БД? На какой-то типовой?
Стоит ли смотреть какую инфу она публикует на сервере результатов? Или вам можно доверять в плане адресов и паролей? )))
приемлемая нижняя граница производительности - это 500 на поток, ниже - уже совсем некомфортно работать, но это верно для так называемых "активных пользователей", в общем случае момент количество пользователей можно увеличить на 10 (т.е. 10% активности) а то и больше :)
производительность менее 500 в тесте 1 потока - говорит, что либо что-то с железом, либо оно совсем старое.
Платформа: 1С:Предприятие 8.2 (8.2.14.519)
Конфигурация:
Режим: (сжатие: усиленное)
Приложение:
Локализация: Информационная база: русский (Россия), Сеанс: русский (Россия)
Ошибки:
--------------------------------------------------------------------------------
10.04.2013 12:44:21
{ОбщийМодуль.ОбщиеФункции.Модуль(17,55)}: Слишком много фактических параметров (ЗапуститьПриложение)
ЗапуститьПриложение("ping -n 2 127.0.0.1", , Истина, <<?>>КодВозврата); // windows
{ОбщийМодуль.ОбщиеФункции.Модуль(21,55)}: Слишком много фактических параметров (ЗапуститьПриложение)
ЗапуститьПриложение("ping -c 2 127.0.0.1", , Истина, <<?>>КодВозврата); // linux
ЧЯДНТ?
Также непонятно, почему временные таблицы почти не отличаются от реальных, надо посмотреть temp_buffers (увеличить?), да и вообще, посмотрите рекомендации (Вячеслав почему-то убрал статью, но в сети куча подобных статей, например , после чего заново прогоните тест. Умолчательные значения ориентированы больше на веб-серверную специфику (простые маленькие запросы).
А диски какие? Также можно поэкспериментировать с fsync = off у постгре.
С fsync = off потестирую сегодня попозже, как серверный ключ освободится. Кстати, насколько помню, на рабочей базе fsync крайне не рекомендуют же выключать, если бэкапса управляемого нету?
А что нам даст тестирование db2?
Было бы у меня время и оборудование - я бы с удовольствием провел бы кучу экспериментов, но, к сожалению, нет времени ни того, ни другого :(
Тестирование db2 - оно даст полное сравнение 3-х СУБД на одинаковом железе (такого исслдедования я еще не видел).
1. Этот файл конфигурации объединять с тестируемой конфигурацией?
2. Обязательно запускать тест на работающей конфигурации или можно развернуть бэкап и запускать на нем? Т.е. симулируется ли работа?
3. Поддерживаются варианты: файловый и клиент-серверный? По комментариям выходит, что оба - просто уточнить.
Спасибо.
p.s. хотим сравнить скорость работы в обоих вариантах, т.к. база весит пока что около 2 гигов.
Пока поддерживается только клиент-серверный вариант из-за сложности организации многопоточности в файловом варианте.
Конкретно это поле - сколько пользователей работает на данном сервере в "боевом режиме".
Написать подробную справку/инструкцию пока руки не доходят :(
Т.е. по тесту БД1 производительней, а по времени выполнения результат обратный. Как это понять ?
17.09.2013 8:36:08 Старт теста Регистры бухгалтерии в 1 потоков
17.09.2013 8:36:02 Старт теста Регистры накопления в 1 потоков
17.09.2013 8:35:55 Старт теста Регистры сведений в 1 потоков
17.09.2013 8:35:49 Старт теста Справочники в 1 потоков
17.09.2013 8:35:41 Старт теста Временные таблицы в 1 потоков
сообщает об ошибке -
{ОбщийМодуль.Тестирование.Модуль(139)}: Ошибка при вызове метода контекста (ОжидатьЗавершения)
ФоновыеЗадания.ОжидатьЗавершения(МассивЗаданий);
по причине:
Выполнение одного или нескольких заданий завершилось с ошибкой
Тест падает стабильно на запуске в два потока (или на очистке после одного потока)? База, я надеюсь, клиент-серверная?
уточню симптомы проблема возникает
- при любом кол-ве потоков (возникала при одном двух четырех восьми шестнадцати), результаты предыдущих выполненнх этапах остаются видны, результаты очень низкие.
- работа с мсскл стабильна, проблемы только с посгрес
- иногда тест на посгрес завершается без ошибок.
подключение клиент серверное.
Опять же смущает отсутствие записей в ЖР. Можно попробовать еще проанализировать техножурнал, чтобы выяснить причину ошибок.
По поводу производительности - вы хотите сказать, что разница между MS SQL и Postgres по синтетическим тестам есть, а по реальной работе на том же железе - нет (или она противоположная)?
...
17.09.2013 15:01:31 Данные. Удаление Зафиксирована Справочник. Справочник
T_SERV5 17.09.2013 15:01:31 (6193126)
Фоновое задание 430 Элемент
17.09.2013 15:01:31 Данные. Удаление Зафиксирована Справочник. Справочник
T_SERV5 17.09.2013 15:01:31 (6193470)
Фоновое задание 430 Элемент
17.09.2013 15:01:31 Фоновое задание. Успешное завершение
T_SERV5 Справочник.Справочник
Фоновое задание 430
17.09.2013 15:01:31 Сеанс. Завершение
T_SERV5
Фоновое задание 430
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 435
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 435
17.09.2013 15:01:32 Фоновое задание. Запуск
T_SERV5 Справочник.Справочник
Фоновое задание 435
17.09.2013 15:01:32 Фоновое задание. Успешное завершение
T_SERV5 Справочник.Справочник
Фоновое задание 435
17.09.2013 15:01:32 Сеанс. Завершение
T_SERV5
Фоновое задание 435
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 438
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 437
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 438
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 437
17.09.2013 15:01:32 Фоновое задание. Запуск
T_SERV5 Документ.РегистраторРС
Фоновое задание 437
17.09.2013 15:01:32 Фоновое задание. Запуск
T_SERV5 РегистрНакопления.РН
Фоновое задание 438
17.09.2013 15:01:32 Фоновое задание. Успешное завершение
T_SERV5 Документ.РегистраторРС
Фоновое задание 437
17.09.2013 15:01:32 Сеанс. Завершение
T_SERV5
Фоновое задание 437
17.09.2013 15:01:32 Фоновое задание. Успешное завершение
T_SERV5 РегистрНакопления.РН
Фоновое задание 438
17.09.2013 15:01:32 Сеанс. Завершение
T_SERV5
Фоновое задание 438
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 441
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 441
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 443
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 442
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 443
17.09.2013 15:01:32 Сеанс. Начало
T_SERV5
Фоновое задание 442
17.09.2013 15:01:32 Фоновое задание. Запуск
T_SERV5 РегистрБухгалтерии.РБ
Фоновое задание 441
17.09.2013 15:01:32 Фоновое задание. Запуск
T_SERV5 РегистрСведений.РС
Фоновое задание 443
17.09.2013 15:01:32 Фоновое задание. Запуск
T_SERV5 Документ.РегистраторРБ
Фоновое задание 442
17.09.2013 15:01:32 Фоновое задание. Успешное завершение
T_SERV5 Документ.РегистраторРБ
Фоновое задание 442
17.09.2013 15:01:32 Сеанс. Завершение
T_SERV5
Фоновое задание 442
17.09.2013 15:01:32 Фоновое задание. Успешное завершение
T_SERV5 РегистрСведений.РС
Фоновое задание 443
17.09.2013 15:01:32 Сеанс. Завершение
T_SERV5
Фоновое задание 443
17.09.2013 15:01:33 Фоновое задание. Успешное завершение
T_SERV5 РегистрБухгалтерии.РБ
Фоновое задание 441
17.09.2013 15:01:33 Сеанс. Завершение
T_SERV5
Фоновое задание 441
По поводу PostgreSQL: по моему опыту 1С заметно быстрее работает с постгри, установленном на Linux. Не сочтите за спам, моя статья раскрывает вопрос установки PGSQL для 1С Сервера. В представленной реализации Постгри держал до 40 пользователей одновременно, в 100 разных базах 1С 8.2, включая до 25 пользаков в одной основной большой кастомизированной базе на основе конфигурации Бухгалтерия. В отчетные периоды бухгалтерия не особо радовалась производительности, но решение с постгри успешно применялось.
На практике и субъективно, 1С Сервер с MSSQL работает гораздо быстрее, начиная с загрузки информационной базы, заканчивая закрытиями периодов (второе может выполниться быстрее в 2-3 раза).
ОС SERVER 2012
MS SQL 2012
ОЗУ 16 ГБ
Процессор - XEON E3 - 1230 V2 3.3GHz
Sql настраивал по этой статье
На серваке пока никто не работает.
Как считаете сервер+настройки завалили тест? Есть ли инструкция к настройке SQL 2012 к работе с 1с?
ОС SERVER 2012
MS SQL 2012
ОЗУ 32 ГБ
Процессор - Intel i7-3770K HT off
HDD Raid10 Seagate SV35 2 TB
Количество потоков Результат Результат на поток
Временные таблицы 59818,80 7377,29
1 16806,00 16806,00
2 39101,00 19550,50
4 73622,00 18405,50
8 72973,00 9121,63
16 65719,00 4107,44
32 68686,00 2146,44
48 64961,00 1353,35
64 64193,00 1003,02
96 66725,00 695,05
112 65402,00 583,95
Во время теста работали 20 пользователей п.э. были ошибки и провалы производительности. Но очередной раз убедился, что мой сервак за 50000 оставляет в глубокой опе ваши поллямные ксеоны. И вот только не надо мне говорить про надежность. При прямых ручках надежность не страдает. Сервак год стоит без единого глюка.
И ещё. Я не продавец какой-то крутой техники, я такой же админ и программист (сейчас, правда, директор по ИТ, но не суть), уже скоро как 30 лет в теме. И знаешь, когда-то я тоже страдал таким же юношеским максимализмом, как и ты. Ну это когда у меня в конторе было 20-30 компов, и сервером я, если надо, мог хоть всю ночь заниматься. Когда же у тебя на предприятии 2000 человек, когда у тебя база УПП под терабайт, и когда у тебя минута простоя - это уже катастрофа, то вот эти самоделки на ответственных участках - это просто смешно. И именно тогда начинаешь понимать, ЧТО ИМЕННО стОит этих дополнительных денег в нормальных серверах. А калькулятор для программистов (я имею в виду машинку под сервер 1С для разработки) мы и сами делаем на i5, лишь бы частота ядра повыше была.
Так что молодец, развивайся, расти, но не считай себя самым умным во всём.
P.S. А ещё мне очень интересно, как ты собираешься на i7 собрать приличный SQL-сервер, учитывая, что i7 не работает в многопроцессорных конфигурациях.
Коротко: i7-4930@4GGz(105*38) HT on, RAM 64Gb, Debian7@ssd, db@hw raid10(4x300@15k sas hdd), long test/big tables, fsync on, 1C x64 8.2.19.68, Postgre x64 9.2.1-eter1debian
Конфа Тестирование параллельной работы (2.0.010)
{ОбщийМодуль.Тестирование.Модуль(139)}: Ошибка при вызове метода контекста (ОжидатьЗавершения)
ФоновыеЗадания.ОжидатьЗавершения(МассивЗаданий);
по причине:
Выполнение одного или нескольких заданий завершилось с ошибкой
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 10.0: Объект был открыт.
HRESULT=80040E05,
1с 8.2.19.90 / AuthenticAMD AMD64 Family 16 Model 8 Stepping 0 2100 MHz / 56,00 ГБ / Windows x86-64 (version 6.1 Service Pack 1 (Build 7601))
SQL 2012 24 core 2.8 Ghz Six-Core AMD opteron 8439 SE Windows x64 2012 / 64 Гб ОЗУ
при любых настройках больше 8 потоков падает
8.3.6.2237 / GenuineIntel Intel64 Family 6 Model 44 Stepping 2 2400 MHz / 31,94 ГБ (Intel SR1630BCR)
6 ядер 24 потока, SQL здесь же, база SQL на SSD, но контроллер простой (на мамке)
Сервер 1С - x64
Похоже на аналоги, или где-то просадка?
Тест запускает параллельную запись в одну таблицу - справочника, регистра сведений, накопления и бухгалтерии (+ регистраторы регистров). Соответственно, можно увидеть, насколько проседает производительность при увеличении нагрузки, соответственно, можно высчитать "емкость" или "запас прочности" сервера из расчета (в зависимости от специфики работы пользователей) 3-20 пользователей на поток.
Это справедливо при решенных проблемах блокировок в конфигурации.
Иначе неудобно, когда тест выполнялся почти час, упал на 96 или 112 потоков по какой-нибудь ошибке, и не сохранил вообще ничего. И даже непонятно, на каком количестве потоков упал (протокол на экране же не помещается, проскроллировать его нельзя, т.к. модальное окно с ошибкой, а после его закрытия конфа вылетает).
Обмен между "своими" тестами через файлы был бы очень кстати, т.к. не хотелось бы кучу промежуточных результатов с непонятно какими комментами выкидывать на ваш сервер.
Вам спасибо.
Что касается обмена результатами, и если уж речь зашла о пожеланиях :-)
Файловый обмен никак не противоречит онлайн обмену. Я вон только на одном сервере 10 раз прогнал тесты, пока игрался с настройками. Результаты когда-то отличались, а когда-то были почти идентичны. Внятными для всех комментариями я себя, разумеется, не утруждал. И вот представьте, что это вам все ссыпалось типа "1с 8.2.19.130 / GenuineIntel Intel64 Family 6 Model 62 Stepping 4 3000 MHz / 32,00 ГБ / Windows x86 (version 6.1 Service Pack 1 (Build 7601))" / "попробовал irqbalance после перезагрузки и сделал ядер меньше". Оно Вам надо? А если надо, то тут же нигде не написано, что оно не босиком на металле, а рядом с PSQL на Linux, все это на виртуалке xen, над lvm, drbd, mdadm, и на ssd, и сколько ядер я запилил - тоже нигде нет :-)
Поэтому я столкнулся с тем, что:
1) попытка закачать метрики с сайта приводят к тому, что я не понимаю реальных техусловий, и не вижу, что у людей за оборудование.
2) публиковать свои драфты я стесняюсь, т.к. не хочу засирать Вам базу.
3) с сравнением своего железа между собой я обламываюсь, потому как файлового обмена нет, и пункт 2.
Я бы с удовольствием обменялся своими тестами файловым пакетом, сравнил бы между собой, сделал выводы и потер. А Вам бы отдал на сайт только репрезентативные с каждого из своих серверов. Отметив предварительно галочкой, что именно я хочу опубликовать, и хорошо описав.
Техусловия.
Для упорядочения онлайн-обмена было бы неплохо побудить пользователя в описании техусловий использовать более формальный рубрикатор (в отдельных колонках: платформа, проц, частота, ядра, HyperThreading, память, частота памяти, тип HDD под базой, наличие и технология виртуализации, ОС сервера баз и т.п.), и требовать заполнения всех полей для публикации теста. Да, множество пользователей хрен положит что-то публиковать. Зато результаты будут репрезентативней.
Отчет о сравнении
Было бы неплохо отчет о сравнении дополнить диаграммой по каждому типу теста, где сериями являются ссылки на тест, точками - количество потоков. Очень удобно сверять визуально. Я сам легко это настраиваю, но каждый раз неудобно, да и пользователям было бы полезно. Могу прислать скрин того, что имею ввиду.
Было бы неплохо иметь возможность с Ctrl выделить несколько тестов и отправить в отчет о сравнении, но это уже так - "хочу быть столбовою дворянкой".
Еще немножко непонятен отчет "профиль выполнения". Там много цифр, я не очень понимаю, как его читать, и что за шкала такая "время" (делится по цветам в диаграммах). Я догадываюсь, что он показывает количество потоков, от которых достигается предел производительности, но было бы очень интересны Ваши пояснения по нему. Или я может где-то пропустил его обсуждение на форуме, не сочтите за труд ткнуть меня туда лицом.
Ну как-то так. Еще раз спасибо, что вы вообще этот инструмент разрабатываете, что на общественных началах.
1. про файловый обмен мысль понятна. На самом деле предполагалось, что будет использоваться одна база, выгружаемая и загружаемая через DT. там даже есть константа с ГУИД, который генерируется при первом запуске и который выгружается на сайт (т.е. с помощью него можно сгруппировать тесты на сайте (и внутри базы можно редактировать только тесты с этим ГУИДом, например менять комментарии)).
про галочку "выгружать" тоже понятно. Поскольку я все-таки планирую прикрутить авторизацию и форумы/обсуждения к сайту - возможно это превратится в галочку "публичный доступ", или еще в подобную. Таким образом как бы заставить пользователей, которые хотят подобного "локального" обмена регистрироваться. Немного нехорошая уловка, но что поделать :)
2. Техусловия. Формальное описание техусловий я так и не смог сформулировать. Возможно возьму болванку с но все равно надо подумать.
3. Отчет о сравнении - скриншот, конечно, нужен. Про контрол мысль понятна. Если честно, я думал, что оно так и работает :)
4. Описание отчета в описании к версии 2.0.0.1:
Добавлен отчет "Профиль выполнения" - показывает распределение времени записи одного объекта (в мс), т.е. сколько объектов записалось за 16 мс, сколько за 32 и тд. Для платформы < 8.2.17 информация собирается только на вин-сервере, при релизе платформы >= 8.2.17 и на линуксе тоже.
Но подробного описания не хватает конечно.
И ещё я не понял, количество потоков это соответствие количеству предполагаемых пользователей?
Как мне например понять, как будет работать сервер с 300 пользователями?
С пользователями все сильно сложнее. Этот тест синтетический, по этому прямого вывода о количестве пользователей сделать нельзя (так как пользователя, все-таки, большую часть времени ничего с базой не делают).
Косвенный вывод можно сделать по количеству одновременных соединений в консоли администрирования 1с. Примерное среднее количество сеансов с назначенными соединениями и есть условное количество одновременных потоков теста. Если речь идет об онлайн кассах в гипермаркете - то соотношение будет примерно 1:1, если же про офисных работников - то от 1:20 до 1:5.
Ну и, конечно, нужно победить блокировки.
Ну не знаю, как сервис с API. Но по идее из реестра можно вытащить HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProces
Через командную строку можно получить используя winsat cpu -v
Заодно увидим и физическое количество процессоров и количество ядер и количество потоков и размер кешей
Это, конечно, понятно. Я не программист 1С, но разве нельзя сделать проверку на Linux/Windows? Просто сами идентификаторы процессора не дают конкретного понятия о его модели, особенно при настроенных планах энергосбережения в BIOS и разгоне. Может получиться так, что процессор просто невозможно идентифицировать. А Вы не смотрели каким образом происходит определение процессора у Гилева?
Windows Server 2008 Standart SP2 + PostgreSQL 9.1.2
Intel Xeon E5620 - 2394 MHz
ОЗУ 31,94 ГБ
1с 8.3.10.2580
RAID 10 SSD
Количество пользователей в тесте 15
Удовлетворительность 4
Остальные настройки стандартные
Как понять во что упирается? где узкое место?
Очень похоже на то, что тест вы проводили при активно работающих пользователях в базе :)
В любом случае очень медленно. Либо оборудование перегружено (см. показатели производительности очереди к диску и к процессору, среднее значение должно быть меньше одного), либо сильно накосячено с конфигами. Еще такое может быть, если это виртуалка, где на хосте крутится этих самых виртуалок много.
"Количество пользователей" и "Удовлетворительность" - это не настройки теста, а описание системы, типа сколько сейчас у вас на этом сервере (этих серверах) пользователей работает и насколько они жалуются на производительность системы.
Обновили версию Postgres до 9.6 и снова протестировали (без пользователей).
Результаты лучше, но всё равно не фонтан)
Подскажите по настройке теста, что такое:
1. Их удовлетворенность ?
2. Сервер 1С / Сервер СУБД ?
Сколько сейчас работает пользователей на ваших серверах
(149)
и насколько они удовлетворены производительностью 1с.
(149)
дело в том, что серверов может быть более одного. информацию 1с может получить только с текущего. галочки означают, является ли сервер, указанный в этой строке, сервером 1с или сервер субд также на этой машине.
более того, серверов 1с может быть более одного, но информацию о них в общем случае никак не получить. равно как и информацию про сервер субд.
1. Баланс точность/время - что есть точность и как распределяется баланс?
2. Размеры создаваемых объектов - что здесь имеется ввиду запись, таблица или что-то еще?
выбор, сколько времени будет выполняться тест. при выборе "короткой" программы погрешность бОльше из-за того, что относительное время, когда все задания работают одновременно, меньше. В принципе, разброс по времени вступления всех заданий в работу можно посмотреть с помощью обработки "поверка синхронизации". В стандартном варианте каждый подтест выполняется по 10 секунд, в коротком - 5, в длинном - 20.
размер одного записываемого объекта (количество строк табличной части, количество записей в наборе, количество строк во временной таблице: 100, 1000, 10000).
Версия сервера: 8.12.1529
MS SQL 2012
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
В схеме базы данных нет таблицы с именем ExtensionsInfoNGS
Запустил тест GILV и MPC на 2-х серверах - рабочий и разработчиков. В тесте Гилева тоже есть многопоточное тестирование.
На dev сервере этот параметр примерно совпадает между тестами GILV и MPC.
GILV - 42, MPC - между 32 и 48. Ну условно тоже 42
На рабочем сервере он значительно больше по GILV. И не меняется по MPC. Рабочий сервер и правда значительно мощнее.
GILV - 70, MPC - также между 32 и 48
GILV сразу показывается рекомендуемое количество пользователей - наверное активных.
в MPC исходил из рекомендации 500 ед. производительности на один поток, поэтому смотрю пересечение количества потоков и 500.
Почему не меняется показатель в MPC на разных серверах? Я м.б. не так интерпретирую результаты?
Многопоточная же часть теста Гилева направлена на максимальную загрузку дисковой подсистемы, у меня же - на массивно-параллельную запись объектов (что напрягает в большей степени менеджер кластера, процессор и скорость обмена с оперативкой). В моем многопоточном тесте при равном количестве ядер процессора скорее всего будут очень похожие результаты. Могут быть выявлены артефакты при неправильной настройке на многопроцессорных (NUMA) системах, но в целом корреляция будет такая - линейный рост до количества физических ядер, затем некоторый рост до достижения количества "гиперядер", затем пропорциональное снижение. Ну, если в другом месте не будет горлышка (например сеть при расположении на разных машинах, тогда линейный рост может продолжаться дольше из-за внесения задержки на сети, когда процессорные ядра будут простаивать).
железо 2*xeon E5 2620, 96 g DDR3, SSD
ОС win server 2016,
сервер 1с и posgresql на винде - результаты не очень, но по крайней мере логичные, второй вариант - 1с сервер на винде и на виртуалке стоит ubuntu 16.04 с Postgresql. Почему так происходит ума не приложу.
(159) Объясните пожалуйста каким образом это видно из графика на 2-м рисунке?
{Обработка.ОбменРезультатами.Форма.Форма.Форма(295)}: Ошибка при вызове метода контекста (resultsExchange)
ОбъектРезультаты = Прокси.resultsExchange(ОбъектУзел, ОбъектТесты);
по причине:
При вызове веб-сервиса произошла ошибка. Ошибка вызова операции сервиса: {}:fragster:resultsExchange()
по причине:
При вызове веб-сервиса произошла ошибка. Неизвестная ошибка. Ошибка преобразования данных XDTO:
Чтение объекта типа: {}TestResult - [5,178908]
Проверка свойства 'serversInfo':
форма: Элемент
имя: {}serversInfo
тип: {}TestServerConfig
по причине:
Ошибка преобразования данных XDTO:
Чтение объекта типа: {}TestResult - [5,178908]
Проверка свойства 'serversInfo':
форма: Элемент
имя: {}serversInfo
тип: {}TestServerConfig
по причине:
Ошибка проверки данных XDTO:
Структура объекта не соответствует типу: {}TestResult
Проверка свойства 'serversInfo':
форма: Элемент
имя: {}serversInfo
тип: {}TestServerConfig
Количество значений свойства (3) больше заданного в модели (2)
Интересный тест.
Ошибка при обмене результатами.
Почему-то я ограничил количество серверов двумя - один для 1с, второй для СУБД :)
Когда-то во времена 8.2 запускал на кластере из нескольких серверов 1с и имел большое количество проблем с синхронизацией потоков. Сейчас, вероятно, стало получше. Себе отметил необходимость расширить возможное количество серверов.
Таблицы особо не расшифруешь, и что значит "Очень много" у результатов справочника?
Как понимаю, после количества потоков >48 уже становится нереально работать активным пользователям?
MS SQL 2014/1с 8.3.12.1685 / GenuineIntel Intel64 Family 6 Model 79 Stepping 1 3396 MHz / 95,87 ГБ / Windows x86-64 (version 6.3 (Build 9600))
То есть получается, что при каких-то условиях запись в справочник происходит крайне долго?
У вас можно это как-то более детально расшифровать?
Или какие настройки SQL могут делать отсечку по приросту?
Ограничивающие есть такие настройки:
И где в базе отображаются суммарные оценки для 1 и 96 потоков, которые видны на сайте?
если есть потребность - я её запишу и возможно ;) реализую при следующем исправлении конфигурации теста.
Просто отображение на сайте проще запилить - и оно поменяется сразу у всех.
Доброго дня!
Будьте добры, прокомментируйте результаты тестов:
Тест1. "Железная" Система: 1с 8.3.15.1830 / x86_64 / 62,80 ГБ / Linux x86-64 (Linux 4.15.3-1-generic #astra13 SMP Wed Jul 25 16:37:04 UTC 2018) Дисковая подсистема на RAID1 на SAS HDD; 2х ЦПУ Xeon E5-2620v4
Тест2. Виртуальная машина: 1с 8.3.15.1830 / x86_64 / 58,92 ГБ / Linux x86-64 (Linux 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020)
Тестирование проводилось в 8 потоков, т.к. больше линуксовый сервер 1с без лицензии не позволяет, в состоянии когда оба сервера были без нагрузки.
Верно ли понимаю, что "железный" сервер несколько медленнее виртуального?
Так же интересует, в абсолютных цифрах, насколько все плохо?
Больше 10 сенсов нагнать не получился из-за ограничений линуксового сервера 1с)
Все верно, гипервизор развернут на отдельной более мощной железке.
Про кривость конфигураций, сказать не могу, хотя там дописывали много и активно.
Подскажите пожалуйста, с ростом количества сеансов, результаты тестирования, вашим тестом, соответственно должны упасть, верно понимаю?
Очень уж не хватает внятной инструкции с эталонными значениями, что бы было понятно когда плохо, когда хорошо и когда нормально.
Очень уж много вопросов к тесту без ответов.
Очень странный график
Временных таблиц много, всех остальных объектов очень мало
Сервер приложений CPU 32 Ядра RAM 128GB
Сервер базы CPU 32 Ядра RAM 256GB
Сеть 10G
ESXI
Бывает сетка 10G глючит, если сетевые разные (из личного опыта).
На сервере приложения надо задавать маску схожести для rmngr и rphost, чтобы на ядрах в пределах одного процессора были и приоритет был у rmngr выше среднего, можно высокий. Можно rphost на один проц, rmngr на другой, протестить. Если что то будет затухать с увеличением потоков, то перенести сервис транзакционных блокировок на тот же проц, где rphost
У меня два сервера на ubuntu (1c сервер) и debian (постгри) и есть файл perfomanceTest_2.0.0.12.cf
можно с картинками что и как сделать ? Мне нужно измерить производительность разных СУБД с одним и тем же железом
в следующем окне "создание новой базы" -> "далее"
"создание без конфигурации..." -> "далее"
Заполнить название, "на сервере 1С:предприятия" -> "далее"
Заполнить параметры, далее.
Потом запустить для этой базы конфигуратор, в нем в меню выбрать "Конфигурация -> открыть конфигурацию" (если не открыта), затем "Конфигурация" -> "Загрузить конфигурацию из файла", выбрать файл, потом, когда загрузится, "Конфигурация" -> "Обновить конфигурацию из файла".
После этого закрыть конфигуратор и запустить клиента.
В клиенте создать тест, заполнить информацию о серверах (при желании) и параметры теста. Нажать кнопку "выполнить тест".
>минимально приемлемый результат возле каждого значения на основании собранной статистики
да фиг его знает, если честно. на самом деле в 80% все упирается в прикладной код )
тут можно оценить по относительному изменению при изменении настроек СУБД, но вообще тест сильно синтетический. те же nested loops или размеры буферов для postgre надо на реальных даже не конфигурациях, а на данных конфигураций мерить. т.е. могут быть разные рекомендации даже для одной конфигурации но с разным "профилем данных" и надо мониторить apdex для ключевых операций (лучше асинхронно внешней системой) и далее с техножурналом профилировать, анализировать и устранять основные медленные части или вообще менять подходы.
>оценивать свою систему по однопоточному тесту Г.
в однопоточном тесте Г. тоже есть многопоточная часть, к которой я году в 2013 приложил руку. Тогда она работала на максимальную загрузку дисковой подсистемы.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 173394
Создание 12.02.13 19:06
Обновление 06.12.22 13:50
Просмотры 119948
Загрузки 935
Рейтинг
240
Комментарии 201
Код открыт Да
Рубрики Сервера
Кому
Системный администратор
,
Разработчик
Тип файла Конфигурация (md, cf)
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
