Как проверить скорость sql 1с
Тест создает множество фоновых сеансов и выполняет ими одинаковые действия, например создание элементов справочников или запись наборов записей регистров. Он позволяет оценить, насколько "производительна" данная связка 1с - субд, а также насколько она "масштабируема", т.е. количество активных пользователей, при котором система еще будет работать, но "низенько-низенько".
Эмпирическим путем получено число в 400-500 попугаев на поток (не учитывая временные таблицы), при котором работа терпима. Благодаря механизму "глобального обмена" можно повторить тест с чьии-то настройками и сравнить результаты.
Полный тест выполняется от получаса до часа на стандартных настройках, примерно в 2 раза меньше на "быстрых" и в 2 раза дольше на "точных". Естественно, проводить не все тесты, то время пропорционально уменьшится.
Планы
Работа на файловых базах.
Обмен "через файлы", для случай, когда на на сервере нет интернета
Версия 2.0.012
Исправлена невозможность обмена, если указано более 2-х серверов
Версия 2.0.011
Если вы делаете обновление, то теперь возможно обновление только с версии >= 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 и на линуксе тоже.
Доработана обработка "проверка синхронизации". Теперь она показывает, через сколько миллисекунд (условия для работы как в предыдущем пункте) пришел сигнал от "мастера" до "потоков" о том, что пора начинать "работать".
Доработан интерфейс, например отчеты перенесены в меню "создать на основании", а также через это меню возможно окрыть более одного окна :)
Начата работа над возможностью запуска в файловой версии. К сожалению, это потребовало убрать старый механизм фонового обновления информации, теперь окно подвисает на время выполнения теста.
Версия 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 везде.
Версия 1.0.000
Добавил сохранение результатов
Немного изменил алгоритм проведения документов, добавил в него выборку данных.
Добавил отчет по тестам с красивыми графиками :)
Добавил вызов веб сервиса, прошу протестировать (пока там только пустышка). В ближайшие пару-тройку дней добавлю сохранение результатов и вывод статистики на отдельную страничку. Возможно добавлю "засасывание" результатов с этой страницы, чтобы можно было стравнить прямо в конфигурации результаты разных людей встроенным отчетом.
Первая версия, она же альфа:
Начал писать тест для оценки производительности сервера в режиме параллельной работы. Нулевая версия, просто выполняет теств1/2/4/8/16 потоков, не накапливая статистику. Пока работает только в клиент-серверном варианте.
Недавно столкнулся с необычным случаем, у заказчика отвратительно работал сервер 1с, чтобы было понятно о чем идет речь, приведу такой пример — запуск толстого клиента мог занимать десяток минут. Когда измерили тестом Гилева, то результат был ниже худшего. Посмотрев ближайшие результаты замеров других пользователей, я понял, что это не единственный случай.
Речь не идет об оптимизации, когда надо поднять на 10-20% производительность, речь идет о поиске причин низкой производительности, и её устранению. Согласитесь это несколько разные вещи. На просторах интернета множество статей как раз о повышении производительности, которые ограничиваются только настройкой сервера 1с и (или) настройкой сервера баз данных. А вот статей, рассматривающих случаи низкой производительности, особенно если причин несколько, и эти причины находятся на разных уровнях, я не встречал.
Обычно администраторы бросаются смотреть результаты мониторинга. Тот случай, с которым я столкнулся, показывал практически нулевую загрузку процессора, наличие свободной ОЗУ, отсутствие очереди у сетевого интерфейса, и только очередь к диску показывала, что не все в порядке. Пришлось устроить проверку по полной программе, это, конечно, занимает много времени, требует исключения сервера из рабочего процесса, но зато дает результат. Возможно для кого-то подобный подход недопустим, более того, некоторые считают это непрофессиональным подходом, но им я ничем помочь не смогу.
Аппаратный уровень
Звучит банально, но именно с проверки работоспособности железа стоит начать. Дело в том, что можно только догадываться о проблемах с оборудованием, если смотреть на уровне операционной системы. В моем случае, не работал один из дисков в дисковом массиве. Как ни странно жесткий диск оказался исправным и, после водворения его на место, заработал, правда пришлось подождать некоторое время, пока не синхронизируются все данные (видать давно он был отключен). Если бы всё этим и закончилось, тогда бы и не было этой статьи. На всякий случай сервер подвергся аппаратному тестированию (стресс-тесты, тест памяти, физической проверки дисков и контроллеров), которые не выявили каких-либо проблем.
Уровень операционной системы
- привести в порядок файловую систему;
- отключить ненужные службы, удалить ненужные и, самое главное, вредоносные программы;
- проверить оптимальность настроек операционной системы.
- проверке логической структуры диска;
- удалении временных и ненужных файлов;
- дефрагментации файловой системы.
Уровень служб
В моем случае сервер 1с находился вместе с сервером баз данных MS SQL на одной машине, но аппаратная конфигурация сервера вполне обеспечивала их совместную деятельность, а вот настройки этих двух служб были совсем не оптимальными. Этим настройкам посвящено множество статей, например, эта, здесь мы сфокусируем внимание только на тех, что не требуют дополнительных вложений, например, приобретение жесткого диска.
Для сервера MS SQL в каждой базе были увеличены значения параметра авторасширения базы до 500 Мб, так как базы 1С являются быстрорастущими. Также был настроен ежедневный план обслуживания, в котором кроме создания дампа базы добавлено обновление статистики, очистка процедурного кэша и дефрагментация индексов. В моем случае, это заметно уменьшило количество операций записи. В качестве дополнительных мер можно порекомендовать еженедельно производить дефрагментацию базы и реорганизации индексов.
Для сервера 1С были изменены параметры «Количество ИБ на процесс» и «Количество соединений на процесс» рабочего сервера, первый получил значение 1, а второй 25. Подобные советы больше похожи на «танцы с бубном», но они дают результат. В рассматриваемом случае изменение этих параметров привело к значительному уменьшению операций чтения-записи на сервере, и он заработал в ожидаемом режиме. Тест Гилева также подтвердил прирост производительности.
Уровень баз
Сделав замеры под рабочей нагрузкой и после выхода пользователей, я столкнулся со странным результатом — под нагрузкой тест Гилева показывал лучшие результаты, чем при простое! Было также замечено огромное количество фоновых заданий выполняемых на тестовых базах. Тестовые базы использовались сисадминами для проведения различных тестовых задач. Я попросил удалить их — и все встало на свои места. Следует ли держать тестовые базы на рабочем сервере, решать конечно вам, но лучше для этого найти какое-то другое решение, например, использовать файловый вариант.
У одной из баз не удавалось уменьшить журнал транзакций, а у другой базы не пересоздавались индексы. Для обоих случаев есть одно простое и эффективное решение. Прежде чем его описать, следует уточнить, что здесь имеет место одинаковое наименование разных объектов: базы 1С и базы MS SQL, первые могут быть не базами MS SQL, а, например, базами PostgreSQL. В свою очередь вторые не обязательно будут базами для 1С. Исходя из этого резервные копии баз 1С (dt-файл) могут быть развернуты и на других СУБД, но ни кто не запрещает вам из этой же копии развернуть на MS SQL. Снимаем резервные копии баз 1С средствами 1С, после чего удалить 1С-базы из сервера 1С, а потом создать их вновь, залив содержимое из dt-файла.
Приведя все базы в порядок, мне уже не к чему было придраться: сервер работал ровно, дисковая подсистема работала в штатном режиме, пользователи радовались быстрой работе в 1с, администраторы удивлялись как теперь быстро проходят обновления.
Заключение
Если использовать только один уровень для поиска причин низкой производительности, то можно оставить без внимания причины, лежащие на других уровнях, то есть результат будет не достигнут. Приведенный пример наглядно показывает, что причин может быть несколько, и каждая из них может лежать на своем уровне. Надеюсь, что данный материал поможет кому-то побороть проблему низкой производительности 1С-сервера.
При размещении 1С в облачной инфраструктуре и среде виртуализации наиболее важными и непростыми задачами являются повышение скорости работы платформы «1С» и настройка СУБД. Для достижения максимальной производительности инфраструктуры 1С рекомендуется правильно выбирать архитектуру инфраструктуры, режимы работы, проверить и выполнить ряд важных настроек.
В зависимости от количества пользователей, размера баз данных и ограничений бюджета (с учетом стоимости дополнительных лицензий на сервер «1С:Предприятие 8» и лицензий на СУБД) платформа «1С» может работать в файловом и клиент-серверном вариантах (на основе трехуровневой архитектуры «клиент-сервер» (рис. 1): клиентское приложение, кластер серверов «1С:Предприятия 8», СУБД).
Рис. 1
Как правильно выбрать вариант/режим работы 1С: файловый или SQL?
Обычно для 1-10 пользователей выбирается файловый режим
От 10 и более пользователей выбирается режим работы с использованием SQL
В файловом варианте все пользователи могут работать на одной виртуальной машине в облаке, например на терминальном сервере.
Для клиент-серверного варианта лучше выбрать не менее двух виртуальных машин:
Сервер с клиентским приложением, например терминальный сервер с клиентской частью «1С» (толстый клиент)
Сервер «1С» и СУБД (MS SQL или PostgreSQL)
Как рассчитать мощности сервера для 1С в файловом режиме работы?
В обоих вариантах: файловом и SQL, для работы с пользовательским приложением 1С в классическом режиме, например, «удаленного рабочего стола» (так называемый «толстый клиент»), необходимы следующие минимальные ресурсы виртуального сервера:
Количество виртуальных ядер CPU = 1 или 2 для ОС + 0,25 * количество пользователей
Объем памяти RAM = 1 или 2 ГБ для ОС + 0,5 ГБ * количество пользователей
Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (0,1-10) ГБ * количество пользователей. Для ОС и 1С рекомендуется использовать самые быстрые диски
Как рассчитать мощности сервера для 1С в варианте работы с SQL?
В клиент-серверном варианте работы 1С, в котором используется СУБД SQL, рекомендуется разместить 1С Сервер и сервер SQL на отдельном виртуальном сервере в общей с клиентским сервером локальной подсети. Необходимы следующие минимальные мощности для этого виртуального сервера:
Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (10-1000) ГБ в зависимости от объема и количества баз данных. Для ОС и СУБД рекомендуется использовать самые быстрые диски
------------
ОС - операционная система, например, Windows Server
Здесь Сервер 1С - ПО "сервер "1С:Предприятия 8"
Наиболее важными и непростыми задачами являются повышение продуктивности использования платформы «1С» в облаке и настройка СУБД. Типичные проблемы при развертывании и эксплуатации облачной инфраструктуры для «1С» следующие:
Неправильный выбор мощностей
Неквалифицированная настройка сервисов виртуальной инфраструктуры
Недостаточное внимание к тестированию производительности платформы «1С»
Для достижения максимальной производительности рекомендуется проверить и выполнить ряд настроек. Прежде всего необходимо исключить свопинг, для чего с помощью системы мониторинга следует обязательно удостовериться в том, что объем оперативной памяти достаточен для работы ВМ. Кроме того, файл подкачки ОС, профили пользователей, файлы баз данных, файлы логов транзакций (SQL) и tempDB (SQL) лучше разместить на дополнительных SSD-дисках, а для файла подкачки установить фиксированный размер.
На SQL-сервере необходимо выключить все ненужные службы, например FullText Search и Integration Services, установить максимально возможный объем оперативной памяти, максимальное количество потоков (Maximum Worker Threads) и повышенный приоритет сервера (Boost Priority), задать ежедневную дефрагментацию индексов и обновление статистики, настроить автоматическое увеличение файла базы данных (не менее 200 Мбайт) и файла лога (не менее 50 Мбайт), а также полную реиндексацию не реже одного раза в неделю. При размещении серверов SQL и «1С:Предприятие» на одной ВМ следует включить протокол Shared Memory.
Следуя перечисленным выше рекомендациям, можно добиться увеличения быстродействия платформы «1С» в облаке в 1,5–2 раза.
Квалифицированное размещение ИТ-сервисов, в том числе «1С», на облачной платформе позволяет:
Существенно сократить расходы
Повысить уровни безопасности (доступ к данным, резервное копирование, антивирусная защита и др.) и технического обслуживания
Обеспечить централизованное администрирование и мониторинг
Организовать эффективную и безопасную удаленную работу
Воспользоваться гибкими возможностями масштабирования, лицензирования и оперативного перехода на необходимые версии конфигураций «1С»
ЧЕК-ЛИСТ ПО ОПТИМИЗАЦИИ ИНФРАСТРУКТУРЫ 1С С MS SQL
1. Включить возможность мгновенной инициализации файлов (Database instant file initialization)
Это позволяет ускорить работу таких операций как:
Создание базы данных
Добавление файлов, журналов или данных в существующую базу данных
Увеличение размера существующего файла (включая операции автоувеличения)
Восстановление базы данных или файловой группы
Для включения настройки:
На компьютере, где будет создан файл резервной копии, откройте приложение Local Security Policy (secpol.msc)
Разверните на левой панели узел Локальные политики, а затем кликните пункт Назначение прав пользователей
На правой панели дважды кликните Выполнение задач по обслуживанию томов
2. Включить параметр «Блокировка страниц в памяти» (Lock pages in memory)
Эта настройка определяет, какие учетные записи могут сохранять данные в оперативной памяти, чтобы система не отправляла страницы данных в виртуальную память на диске, что может повысить производительность.
Для включения настройки:
В меню Пуск выберите команду Выполнить. В поле Открыть введите gpedit.msc
В консоли Редактор локальных групповых политик разверните узел Конфигурация компьютера, затем узел Конфигурация Windows
Разверните узлы Настройки безопасности и Локальные политики
Выберите папку Назначение прав пользователя
Политики будут показаны на панели подробностей
На этой панели дважды кликните параметр Блокировка страниц в памяти
В диалоговом окне Параметр локальной безопасности — блокировка страниц в памяти выберите «Добавить» пользователя или группу
В диалоговом окне Выбор: пользователи, учетные записи служб или группы добавьте ту учетную запись, под которой у вас запускается служба MS SQL Server
Чтобы изменения вступили в силу, перезагрузите сервер или зайдите под тем пользователем, под которым у вас запускается MS SQL Server
3. Включить каталоги с файлами базы данных в правила исключения для антивируса.
Если антивирус будет сканировать файлы базы, это может сильно замедлить работу СУБД.
Для опытных администраторов: антивирус на сервер СУБД лучше не устанавливать.
4. Включить каталоги с файлами базы данных в список исключений для системы автоматического копирования.
Если на сервере установлена система автоматического копирования файлов, то, когда она будет копировать файлы базы, это может привести к замедлению работы. Копии базы необходимо делать средствами самой СУБД.
5. Отключить механизм DFSS для дисков.
Механизм Dynamic Fair Share Scheduling отвечает за балансировку и распределение аппаратных ресурсов между пользователями. Иногда его работа может негативно сказываться на производительности 1С.
Чтобы отключить его только для дисков, нужно:
Найти в реестре ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk
Установить значение параметра EnableFairShare в 0
6. Отключить сжатие данных для каталогов, в которых лежат файлы базы.
При включенном сжатии ОС будет пытаться дополнительно обрабатывать файлы при модификации, что замедлит сам процесс записи, но сэкономит место.
Чтобы отключить сжатие файлов в каталоге, необходимо:
Открыть свойства каталога
На закладке Общие нажать кнопку Другие
Снять флаг «Сжимать» содержимое для экономии места на диске
7. Установить параметр «Максимальная степень параллелизма» (Max degree of parallelism) в значение 1.
Данный параметр определяет, во сколько потоков может выполняться один запрос. По умолчанию параметр равен 0, это означает, что сервер сам подбирает число потоков. Для баз с характерной для 1С нагрузкой рекомендуется поставить данный параметр в значение 1, т.к. в большинстве случаев это положительно скажется на работе запросов.
Для настройки параметра необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Дополнительно
Установить значение параметра равное единице
8. Ограничить максимальный объем памяти сервера MS SQL Server.
Необходимо ограничить максимальный объем памяти, потребляемый MS SQL Server, особенно это критично, если роли сервера 1С и сервера СУБД совмещены. Максимальный объем памяти, рекомендуемый для MS SQL Server, можно рассчитать по следующей формуле:
Память для MS SQL Server = Память всего – Память для ОС – Память для сервера 1С
Например, на сервере установлено 64 ГБ оперативной памяти, необходимо понять, сколько памяти выделить серверу СУБД, чтобы хватило серверу 1С.
Для нормальной работы ОС в большинстве случаев более чем достаточно 4 ГБ, обычно – 2-3 ГБ.
Чтобы определить, сколько памяти требуется серверу 1С, необходимо посмотреть, сколько памяти занимают процессы кластера серверов в разгар рабочего дня. Этими процессами являются ragent, rmngr и rphost, подробно данные процессы рассматриваются в разделе, который посвящен кластеру серверов. Снимать данные нужно именно в период пиковой рабочей активности, когда в базе работает максимальное количество пользователей. Получив эти данные, необходимо прибавить к ним 1 ГБ – на случай запуска в 1С «тяжелых» операций.
Чтобы установить максимальный объем памяти, используемый MS SQL Server, необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Память
Указать значение параметра Максимальный размер памяти сервера
9. Включить флаг «Поддерживать» приоритет SQL Server (Boost SQL Server priority).
Данный флаг позволяет повысить приоритет процесса MS SQL Server над другими процессами.
Имеет смысл включать флаг только в том случае, если на компьютере с сервером СУБД не установлен сервер 1С.
Для установки флага необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Процессоры
Включить флаг «Поддерживать приоритет SQL Server (Boost SQL Server priority)» и нажать Ок
10. Установить размер авто увеличения файлов базы данных.
Автоувеличение позволяет указать величину, на которую будет увеличен размер файла базы данных, когда он будет заполнен. Если поставить слишком маленький размер авторасширения, тогда файл будет слишком часто расширяться, на что будет уходить время. Рекомендуется установить значение от 512 МБ до 5 ГБ.
Для установки размера авторасширения необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства нужной базы и выбрать закладку Файлы
Напротив каждого файла в колонке Автоувеличение поставить необходимое значение
Данная настройка будет действовать только для выбранной базы. Если вы хотите, чтобы такая настройка действовала для всех баз, нужно выполнить эти же действия для служебной базы model. После этого все вновь созданные базы будет иметь те же настройки, что и база model.
11. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.
В этом случае работа с файлами может идти не последовательно, а практически параллельно, что повышает скорость работы дисковых операций. Лучше всего для этих целей подходят диски SSD.
Для переноса файлов необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства нужной базы и выбрать закладку Файлы
Запомнить имена и расположение файлов
Отсоединить базу, выбрав через контекстное меню Задачи – Отсоединить
Поставить флаг Удалить соединения и нажать Ок
Открыть Проводник и переместить файл данных и файл журнала на нужные носители
В Management Studio открыть контекстное меню сервера и выбрать пункт Присоединить базу
Нажать кнопку Добавить и указать файл mdf с нового диска
В нижнем окне сведения о базе данных в строке с файлом лога нужно указать новый путь к файлу журнала транзакций и нажать Ок
12. Вынести файлы базы TempDB на отдельный диск.
Служебная база данных TempDB используется всеми базами сервера для хранения, промежуточных расчетов, временных таблиц, версий строк при использовании RCSI и многих других вещей. Обычно обращений к этой базе очень много, и если она будет лежать на медленных дисках, это может замедлить работу системы.
Рекомендуется хранить базу TempDB на отдельном диске для повышения производительности работы системы.
Для переноса базы TempDB на отдельный диск необходимо:
Запустить Management Studio и подключиться к нужному серверу
Создать окно запроса и выполнить скрипт:
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'Новый_Диск:\Новый_Каталог\tempdb.mdf')
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'Новый_Диск:\Новый_Каталог\templog.ldf')
Перезапустить MS SQL Server
13. Включить Shared Memory, если сервер 1С расположен на том же компьютере, что и сервер СУБД.
Протокол Shared Memory позволит общаться приложениям через оперативную память, а не через протокол TCP/IP.
Для включения Shared Memory необходимо:
Запустить диспетчер конфигурации SQL Server
Зайти в пункт SQL Native Client – Клиентские протоколы – Общая память – Включено
Поставить значение Да и нажать Ок
Протокол Именованные каналы нужно выключить аналогичным образом
14. Перезапустить службу MS SQL Server
Внимание! Когда все настройки выполнены, необходимо перезапустить службу MS SQL Server
Россиянин за границей пытается купить презервативы в аптеке.
Естественно - языковой барьер, не знает как объяснить. Видит - аптекарь мужик.
Достает свое хозяйство, кладет на прилавок и рядом 10$.
Аптекарь не долго думая, достает свое и со словами:- Не уверен - не играй! забирает все деньги.
Что вам даст прочтение этой статьи:
- Возможность общаться на одном языке с провайдерами всего мира, предоставляющими облачный хостинг серверов, при выборе места для сервера 1С.
- Новый подход к тестированию быстродействия существующего оборудования.
Скажу сразу и жирным шрифтом:
Я не против решения всего и вся на 1С, а перед теми кто их создает, вообще снимаю шляпу.
Но иногда робко спрашиваю зачем ?
После того как об меня сломалось очередное копье, долгими осенними вечерами написал я эту статью.
По большому счету любой DBA, находящийся за пределами 1С, ничего нового в ней не откроет.
Теоретически, он может даже сказать: Все, расходимся, нас обманули. И спокойно продолжить слушать музыку у сервера (или музыку сервера, кому как угодно).
Но в сообществе 1С и неожиданно у некоторых облачных провайдеров, публикующихся на Хабре, обнаружилось непонимание темы.
Масла в огонь подлил журнал "Системный администратор" (!) №5 за 2017 г. с вопросом:
Сервер набрал примерно 17 баллов, в то время как десктоп – более 40. Так что же, сервер 1С лучше разворачивать на бюджетном железе, купленном в ближайшем киоске?
Продолжу для них.
Зачем собственно пробовать что-то еще, если есть чудесный тест Гилева ©:
Еще раз внимание!
Не против я этого теста, в конце концов можно мерить чем угодно, если это измерение дает повторяемость на различных конфигурациях софта/железа.
Переходим к теме:
Де-факто метод тестирования крупных провайдеров предоставляющих облачный хостинг (Alibaba Cloud к примеру или Google Cloud , на котором кстати, самое подробное описание работы) и удобная вещь в хозяйстве - HammerDB .
Описаний по использованию - предостаточно, в том числе русскоязычных.
Поэтому подробно расписывать ее не буду, опишу в общих чертах и больше про те грабли на которые наступил.
Самые большие - программа не работает с версиями MS SQL ниже 2008.
Читайте также: