Настройка быстродействия сервера 1с
Основная цель написания статьи — чтобы не повторять очевидные нюансы тем администраторам (и программистам), которые еще не набрали опыта с 1С.
Вторичная цель, если у меня будут какие-то недочеты, — на Инфостарте мне это укажут быстрее всего.
Неким стандартом "де факто" уже стал тест В. Гилева. Автор на своем сайте дал вполне понятные рекомендации, я же просто приведу некоторые результаты, и прокомментирую наиболее вероятные ошибки. Естественно, что результаты тестирования на Вашем оборудовании могут отличаться, это просто для ориентира, что должно быть и к чему можно стремиться. Сразу хочу отметить, что изменения надо делать пошагово, и после каждого шага проверять, какой результат это дало.
На Инфостарте подобные статьи есть, в соответствующих разделх буду ставить на них ссылки (если пропущу что-то - просьба подсказать в комментариях, добавлю). Итак, предположим у вас тормозит 1С. Как диагностировать проблему, и как понять кто виноват, администратор или программист?
Тестируемый компьютер, основной подопытный кролик: HP DL180G6, в комплектации 2*Xeon 5650, 32 Gb, Intel 362i , Win 2008 r2. Для сравнения, сопоставимые результаты в однопоточном тесте показывает Core i3-2100. Оборудование специально взял не самое новое, на современном оборудовании результаты заметно лучше.
Для тестирования разнесенных серверов 1С и SQL, сервер SQL: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.
Для проверки 10 Gbit сети использовались Intel 520-DA2 адаптеры.
Файловая версия. (база лежит на сервере в расшаренной папке, клиенты подключаются по сети, протокол CIFS/SMB). Алгоритм по шагам:
0. Добавляем на файловый сервер тестовую базу Гилева в ту же папку, что и основные базы. С клиентского компьютера подключаемся, запускаем тест. Запоминаем получившийся результат.
Подразумевается, что даже для старых компьютеров 10 летней давности (Pentium на 775 socket ) время от нажатия на ярлык 1С:Предприятие до появления окна базы должно пройти меньше минуты. ( Celeron = медленная работа).
Если у Вас компьютер хуже, чем пентиум на 775 socket с 1 гб оперативной памяти, то я Вам сочувствую, и комфортной работы на 1С 8.2 в файловой версии Вам будет добиться тяжело. Задумайтесь или об апгрейде (давно пора), или о переходе на терминальный (или web, в случае тонких клиентов и управляемых форм) сервер.
Если компьютер не хуже, то можно пинать администратора. Как минимум — проверить работу сети, антивируса и драйвера защиты HASP.
Если тест Гилева на этом этапе показал 30 "попугаев" и выше, но рабочая база 1С все равно работает медленно - вопросы уже к программисту.
1. Для ориентира, сколько же может "выжать" клиентский компьютер, проверяем работу только этого компьютера, без сети. Тестовую базу ставим на локальный компьютер (на очень быстрый диск). Если на клиентском компьютере нет нормального ССД, то создается рамдиск. Пока, самое простое и бесплатное — Ramdisk enterprise.
Для тестирования версии 8.2 вполне достаточно 256 мб рамдиска, и! Самое главное. После перезагрузки компьютера, с работающим рамдиском, на нем должно быть свободно 100-200 мб. Соответственно, без рамдиска, для нормальной работы свободной памяти должно быть 300-400 мб.
Для тестирования версии 8.3 рамдиска 256 мб хватит, но свободной оперативной памяти надо больше.
При тестировании нужно смотреть на загрузку процессора. В случае, близком к идеальному(рамдиск), локальная файловая 1с при работе загружает 1 ядро процессора. Соответственно, если при тестировании у вас ядро процессора загружено не полностью — ищите слабые места. Немного эмоционально, но в целом корректно, влияние процессора на работу 1С описано здесь. Просто для ориентира, даже на современных Core i3 с высокой частотой вполне реальны цифры 70-80.
Наиболее часто встречающиеся ошибки на этом этапе.
а) Неправильно настроенный антивирус. Антивирусов много, настройки для каждого свои, скажу лишь то, что при грамотной настройке ни веб, ни касперский 1С не мешают. При настройках "по умолчанию" - может отниматься примерно 3-5 попугаев (10-15%).
б) Режим производительности. Почему-то на это мало кто обращает внимания, а эффект - самый весомый. Если нужна скорость - то делать это обязательно, и на клиентских и на серверных компьютерах. (Хорошее описание у Гилева. Единственный нюанс, на некоторых материнских платах если выключить Intel SpeedStep то нельзя включать TurboBoost).
Если коротко - во время работы 1С происходит очень много ожиданий ответа от других устройств (диск, сеть и пр). Во время ожидания ответа, если режим производительности включен сбалансированный, то процессор понижает свою частоту. Приходит ответ от устройства, надо работать 1С (процессору), но первые такты идут с пониженной частотой, потом частота повышается - а 1С снова ждет ответа от устройства. И так - много сотен раз в секунду.
Включать режим производительности можно (и желательно) в двух местах:
- через BIOS. Отключить режимы C1, C1E, Intel С-state (C2, C3,C4). В разных биосах они называтся по разному, но смысл один. Искать долго, требуется перезагрузка, но если сделал один раз - потом можно забыть. Если в BIOS все сделать правильно, то скорости добавится. На некоторых материнских платах настройками BIOS можно сделать так, что режим производительности Windows роли играть не будет. (Примеры настройки BIOS у Гилева). Эти настройки в основном касаются серверных процессоров или "продвинутых" BIOS, если Вы такое у себя не нашли, и у вас НЕ Xeon - ничего страшного.
- Панель управления - Электропитание - Высокая производительность. Минус - если ТО комптютера давно не проводилось, он будет сильнее гудеть вентилятором, будет больше греться и потреблять больше энергии. Это - плата за производительность.
Как проверить, что режим включен. Запускаем диспетчер задач - быстродействие - монитор ресурсов - ЦП. Дожидаемся, пока процессор ничем не занят.
Это - настройки по умолчанию.
В BIOS C-state включены,
режим энергопотребления сбалансированный
В BIOS C-state включены, режим высокой производительности
Для Pentium и Core на этом можно остановиться,
из Xeon еще можно выжать немного "попугайчиков"
В BIOS C-state выключены, режим высокой производительности.
Если не использовать Turbo boost - именно так должен выглядеть
сервер, настроенный на производительность
А теперь цифры. Напомню: Intel Xeon 5650, ramdisk. В первом случае тест показывает 23.26, в последнем - 49.5. Разница - почти двухкратная. Цифры могут варьироваться, но соотношение остается практически таким же для Intel Core.
в) Turbo Boost. Сначала надо понять, поддерживает ли Ваш процессор эту функцию, например здесь. Если поддерживает, то можно еще вполне легально получить немного производительности. (вопросы разгона по частоте, особенно серверов, касаться не хочу, делайте это на свой страх и риск. Но соглашусь с тем, что повышение Bus speed со 133 до 166 дает очень ощутимый прирост как скорости, так и тепловыделения)
Как включать turbo boost написано, например, здесь. Но! Для 1С есть некоторые нюансы(не самые очевидные). Сложность в том, что максимальный эффект от turbo boost проявляется тогда, когда включены C-state. И получается примерно такая картинка:
Обратите внимание, что множитель - максимальный, частота Core speed - красивейшая, производительность - высокая. Но что же будет в результате с 1с?
Core speed (частота), GHz
CPU-Z Single Thread
Тест Гилева Ramdisk
Тест Гилева Ramdisk
Без Turbo boost
C-state off, Turbo boost
53.19
40,32
C-state on, Turbo boost
1080
53,13
23,04
А в итоге получается, что по тестам производительности ЦПУ вариант с множителем 23 впереди, по тестам Гилева в файловой версии - производительность с множителем 22 и 23 одинаковая, а вот в клиент-серверной - вариант с множителем 23 ужас ужас ужас (даже, если C-state выставить на уровень 7, то все равно медленнее, чем с выключенным C-state). Поэтому рекомендация, проверьте оба варианта у себя, и выберите из них лучший. В любом случае, разница 49,5 и 53 попугая - достаточно значительная, тем более это без особых усилий.
Вывод - turbo boost включать обязательно. Напомню, что недостаточно включить пункт Turbo boost в биосе, надо еще посмотреть и другие настройки (BIOS: QPI L0s, L1 - disable, demand scrubbing - disable, Intel SpeedStep - enable, Turbo boost - enable. Панель управления - Электропитание - Высокая производительность). И я бы все-таки (даже для файловой версии) остановился на варианте, где c-state выключен, хоть там множитель и меньше. Получится как-то так.
Достаточно спорным моментом является частота памяти. Например вот тут частота памяти показывается как очень сильно влияющая. Мои же тесты - такой зависимости не выявили. Я не буду сравнивать DDR 2/3/4, я покажу результаты изменения частоты в пределах одной линейки. Память одна и та же, но в биосе принудительно ставим меньшие частоты.
И результаты тестирования. 1С 8.2.19.83, для файлового варианта локальный рамдиск, для клиент-серверного 1С и SQL на одном компьютере, Shared memory. Turbo boost в обоих вариантах выключен. 8.3 показывает сопоставимые результаты.
Разница - в пределах погрешности измерений. Я специально вытащил скрины CPU-Z чтобы показать, что со сменой частоты меняются и другие параметры, те же CAS Latency и RAS to CAS Delay, что нивелирует изменение частоты. Разница будет тогда, когда физически будут меняться модули памяти, с более медленных на более быстрые, но и там цифры не особо значительные.
2. Когда с процессором и памятью клиентского компьютера разобрались, переходим к следующему очень важному месту - сети. Про тюнинг сети написаны многие тома книг, есть статьи на Инфостарте (1, 2 и другие), здесь я на эту тему заострять внимание не буду. Перед началом тестирования 1С просьба убедиться, что iperf между двумя компьютерами показывает всю полосу (для 1 гбит карточек - ну хотя бы 850 мбит, а лучше 950-980), что выполнены советы Гилева. Потом - самой простой проверкой работы будет, как это ни странно, копирование одного большого файла (5-10 гигабайт) по сети. Косвенным признаком нормальной работы на сети в 1 гбит будет средняя скорость копирования 100 мб/сек, хорошей работы — 120 мб/сек. Хочу обратить внимание, что слабым местом (в том числе) может быть и загруженность процессора. SMB протокол на Linux достаточно плохо параллелится, и во время работы он вполне спокойно может «скушать» одно ядро процессора, и больше не потреблять.
И еще. С настройками по умолчанию windows клиент лучше всего работает с windows server (или даже windows рабочая станция) и протоколом SMB/CIFS, linux клиент (debian, ubuntu остальные не смотрел) лучше работает с linux и NFS (с SMB тоже работает, но на NFS попугаи выше). То, что при линейном копировании вин-линукс сервер на нфс копируется в один поток быстрее, еще ни о чем не говорит. Тюнинг debian для 1С - тема отдельной статьи, я к ней еще не готов, хотя могу сказать, что в файловой версии получал даже немного бОльшую производительность, чем Win вариант на этом же оборудовании, но с postgres при пользователях свыше 50 у меня пока еще все очень плохо.
Самое главное , о чем знают "обжегшиеся" администраторы, но не учитывают начинающие. Есть очень много способов задать путь к базе 1с. Можно сделать \\server\share, можно \\192.168.0.1\share, можно net use z: \\192.168.0.1\share (и в некоторых случаях такой способ тоже сработает, но далеко не всегда) и потом указывать диск Z. Вроде бы все эти пути указывают на одно и то же место, но для 1С есть только один способ, достаточно стабильно дающий нормальную производительность. Так вот, правильно делать надо так:
В командной строке (или в политиках, или как Вам удобно) - делаете net use DriveLetter: \\server\share. Пример: net use m: \\server\bases. Я специально подчеркиваю, НЕ IP адрес, а именно имя сервера. Если сервер по имени не виден - добавьте его в dns на сервере, или локально в файл hosts. Но обращение должно быть по имени. Соответственно - в пути к базе обращаться к этому диску (см картинку).
А теперь я на цифрах покажу, почему именно такой совет. Исходные данные: Карты Intel X520-DA2, Intel 362, Intel 350, Realtek 8169. ОС Win 2008 R2, Win 7, Debian 8. Драйвера последние, обновления применены. Перед тестированием я убедился, что Iperf дает полную полосу (кроме 10 гбит карточек, там получилось только 7.2 Gbit выжать, позже посмотрю почему, тестовый сервер еще не настроен как надо). Диски разные, но везде SSD(специально вставил одиночный диск для тестирования, больше ничем не нагружен) или рейд из SSD. Скорость 100 Mbit получена путем ограничения в настройках адаптера Intel 362. Разницы между 1 Gbit медь Intel 350 и 1 Gbit оптика Intel X520-DA2 (полученной путем ограничения скорости адаптера) не обнаружено. Максимальная производительность, турбобуст выключен (просто для сопоставимости результатов, турбобуст для хороших результатов добавляет чуть меньше 10%, для плохих - вообще может никак не сказаться). Версии 1С 8.2.19.86, 8.3.6.2076. Цифры привожу не все, а только самые интересные, чтобы было с чем сравнивать.
При размещении 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
Недавно столкнулся с необычным случаем, у заказчика отвратительно работал сервер 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С-сервера.
Постоянно сталкивался с высказываниями ИТ специалистов «сеть нагружена на 20%… процессоры на 50%… очередей к дискам мало… Значит сеть и сервера справляются… смотрите код в 1С проблемы исключительно там».
На самом деле происходило следующее ( сервер 1С и SQL разнесены на разные компьютеры): сеть практически использовалась по максимуму(эти "20% загрузки сетевого интерфейса" = «20% полезные данные» + «80% потеря на служебной обработке»). И соответственно из-за малой ширины канала обмена «полезными» данными — SQL сервер с «Сервером 1С» постоянно ожидали друг друга, что вело к малой утилизации ресурсов CPU и дисковой системы.
Ведение: Сначала хочу заострить внимание на том что же такое 1С платформа?.
Программист в среде 1С — пишет объектную логику, а за сборку/разборку и запись объектов в «плоский вид» по таблицам базы данных отвечает сама платформа.
Основные "+" и "-" с точки зрения ORM:
"+" Программист в среде ORM получает преимущество в скорости разработки приложения из-за уменьшения количества кода и его простоты по сравнению с исключительно реляционным программным кодом (пример SQL запросы). А также освобождается от написания кода работающего непосредтсвенно с записями в таблицах Реляционной СУБД.* 1
"-" Сложности для создателей «платформ» ORM и проблемы производительности:
Использование реляционной базы данных для хранения объектно-ориентированных данных приводит к «семантическому разрыву», заставляя программистов писать программное обеспечение, которое должно уметь как обрабатывать данные в объектно-ориентированном виде, так и уметь сохранить эти данные в реляционной форме. Эта постоянная необходимость в преобразовании между двумя разными формами данных не только сильно снижает производительность, но и создает трудности для программистов, так как обе формы данных накладывают ограничения друг на друга.
*1«Уточнение». Несмотря на то, что 1С 8.х позволяет работать с реляционно-подобным кодом (только чтение) в объекте 1С «Запрос» — это все-таки не напрямую один-в-один транслируемый в реляционную СУБД запрос к таблицам хранения данных, а прежде всего «Объектный запрос» — также не минующий стадию сборки разборки объектов. Поэтому зачастую вместо много-тысяче строчных «Объектных запросов» — наиболее оптимально по быстродействию кода и скорости разработки — написать объектный не ряляционно-подобный код.
Глава 1: Расмотрим модель клиент-серверной 1С 8.х
Отмечу основные «узкие» места влияющие на производительность:
1) Первое узкое место — это коммуникационная среда передачи данных.
На рисунке стрелками показаны потоки обмена данными, где «красные» — это Реляционная СУБДОбъектная СУБ, «оранжевые» — синхронизация между Объектными СУБД.
Т.к. при использовании отдельных серверов для СУБД и кластеров 1С – коммуникационная среда это сетевые соединения – то существуют существенные задержки в передаче данных многочисленными мелкими порциями – как из-за латентности самой физической реализации интерфейсов, так и из-за латентности узлов в этой сети.
Рассмотрим на примере сетевого стандарта Ethernet Gigabit (график зависимости скорости передачи данных… ниже)
на примере работы Сервера 1С с MS SQL (по умолчанию размер коммуникационных пакетов 4 кб):
На графике видно, что при использовании пакетов ДАННЫХ =4 кб пропускная способность рассмотренной сети всего 250 Мегабит/с. (как правильно заметили в комментария к публикаци: это не пакеты протоколов например уровня TCP, а пакеты ДАННЫХ которые генерируют приложения участвующие в обмене)
…
Из практики: такое разнесение на Два отдельных сервера
MS SQL (сервер №1) < — Ethernet Gigabit --->«Сервер 1С»(сервер №1)
проигрывало по скорости работы платформы
на 50% варианту MS SQL (сервер №1) < — Shared Memory (без сети через участок памяти) --->«Сервер 1С»(сервер №1)… и это уже «на одном высоконагруженном пользовательском сеансе»
2) Узкое место — это количество отдельных компьютеров «кластеров 1С», чем их больше тем больше затраты на синхронизацию и как следствие уменьшение производительности системы.
3) Узкое место — количество отдельных процессов сервера 1с, чем их больше тем больше затрат на их синхронизацию… Но тут скорей всего необходимо найти «золотую середину» — для обеспечения стабильности. 2*
2* «Уточнение» — для MS Windows существует такое правило:
Процессы дороже чем потоки, что означает применительно к данному случаю на практике следующее: скорость обмена между двумя потоками внутри одного процесса значительно превышает, скорость обмена между потоками находящихся в разных процессах.
Поэтому например «Файловая 1С 8.х» всегда превышает по скорости однопользовательской работы платформы в клиент-серверном варианте. Все просто т.к. в случае «Файловой 1С 8.х» поток «Реляционной СУБД» общается с потоком «Объектной СУБД» внутри одного единого процесса.
4)Узкое место – одно-поточность пользовательского сеанса, т.к. каждый отдельно взятый — пользовательский сеанс не распараллеливается платформой на несколько, то его работа ограничивается использованием ресурсов одного ядра CPU => следовательно желательна максимальная скорость каждого ядра, в этом случае быстродействие платформы 1C например на 10-ядерном CPU по 1 ггц — будет значительно уступать быстродействию платформы на 4-ех ядерном CPU по 3 Ггц – естественно до определенного количества потоков.
Глава 2(Итог): Рассмотрим не масштабируемый и масштабируемый варианты — наиболее эффективных схем для платформы 1с 8.х. для OS Windows (пологаю для Linux ситуация аналогична)
1-Вариант(не масштабируемый). В расчете на 100 «высоконагруженных пользовательских сеанса»
1) эффективен обычный 2-ух сокетный сервер с 4-ех ядерными CPU по 3 Ггц.
2) быстрая дисковая система на SSD
2-Вариант(масштабируемый). начиная со 100 «высоконагруженных пользовательских сеанса» и далее….
Тут логичней всего пойти по пути немецкой 1с-ки «Sap HANA»))
Собирать модульный «Супер-компьютер» от фирмы SGI – состоящий из «лезвий» на 2-х сокетных материнских платах, каждое лезвие соединяется друг с другом сложной топологией сверх-быстрого интерконнекта на основе NUMA-чипов, и все находится под управлением единой OS. Т.е. программы внутри такого сервера по определению имеют доступ к ресурсам любого «лезвия».
1) добавляем «лезвия» по необходимой нагрузке… из расчета примерно одно «лезвие» на 100 пользователей.
Долго гадал, почему из трех практически идентичных компьютеров Core I7 одного и того же поколения 1С на двух работает быстро, а на третьем существенно медленнее.
Так как там серверная БД, пришлось серьезно вникать в анализ производительности БД, купил даже курс
"Ускорение и оптимизация систем на 1С:Предприятие 8.3" и кстати не сочтите за рекламу - очень доволен остался. Парни просто профи в вопросе и умении излагать материал.
По советам из этого курса внедрил подсистему, фиксирующую время выполнения операций и стал изучать на 3х секундном процессе открытия определенной формы сколько тратится на запрос БД /процессорную обработку / Передачу данных на клиент.
Начал анализировать, у каких пользователей, в какое время, с какого сервера/клиента получается быстро или медленно.
Конечно же, поменял сервера местами, снова измерил время работы и выяснил что одинаковые сервера с чрезвычайно похожими сетапами дают разное время открытия формы. Хоть тресни.
Пошел к бородатому и чрезвычайно толковому сисадмину, рассказал про этот парадокс и он дал ответ, от которого во мне что-то перевернулось.
А я говорит, в одном сервере на днях в настройках электропитания поставил режим "Высокой производительности". Ну или в дополнительных параметрах питания, нашел раздел "Управление питанием процессора" - "Минимальное состояние процессора" - и поставил настройку 100%
Каково же было мое удивление, когда я замерил скорость открытия формы.
Я думаю, пояснять этот график не надо.
Конечно, грамотный айтишник скажет, что еще в БИОС надо выставлять максимальную производительность процессора, что бы в Windows уже не требовалось за этим следить. Но для сервера лезть в БИОС это целая история, причем ночная. А изменить сделать предложенную настройку настолько просто и очевидно - что стало стыдно за то, что потребовалось так много лет, что бы дойти до этой простой истины.
Ну и на всякий случай перечислю другие рекомендации, что записал для себя как обязательные..
- Использование скоростного SSD (можно SATA3, можно M.2)
- Запас оперативной памяти
- Windows тоже ставить на SSD или же обязательно переносить на SSD диск
- файл подкачки
- КЭШ сервера 1С (в реестре отредактировать команду запуска сервера)
- Терминальных пользователей вынес в отдельную виртуальную машину (тоже на SSD)
- Если используем решения на "обычных формах" - то никакой PostgreSQL - только MS SQL (Реагирую на гневный комментарий. - дело, конечно не в формах, а в технологии запросов, которые применялись в старых конфигурациях, когда допускалось соединение виртуальных таблиц без их предварительной записи во временную таблицу).
- Если решение на управляемых формах, то используем Web сервер для доставки приложения. Особенно заметно на файловых базах - ускорение получается даже на том компьютере, где лежит эта база (что казалось бы парадокс). А у сетевых клиентов - просто космос.
- Регулярное тестирование БД с пересчетом итогов.
- Если SQL - не забываем про регламентное обслуживание SQL базы.
Специальные предложения
SerVer1C; papami; vadimlp77; Дмитрий74Чел; mirco; sevushka; WellMaster; user921389; kuzyara; 24rus; dandykry; akimych; starik-2005; + 13 – Ответить
Кэп, кэп, кэп. Про это уже написано, рассказано. много много.
Перепечатка курса?
Про pg vs ms хрень полная. Автор выставляет себя дилетантом. И как можно путать формы, режим приложения и режим блокировок?
Про Postgre vs MS не хрень. Выполнение запросов в старых конфигурациях, где не используют временные таблицы, а делают сразу объединение виртуальных таблиц на postgre делается неэффективно и по времени в 3-5 раз медленнее. Это зафиксировано в официальной документации и хорошо видно при формировании прайс листа в УТ 10 в двух разных sql.
(4) Попробую угадать. Вам не понравилось упоминание о неэффективности использования PostGre на приложениях с обычными формами. Что ж. Это понятно. Здесь, вероятно, надо было указать длинную цепочку событий:
Обычные формы -> это старые конфигурации -> 1С в старых конфах использовала старую методологию в запросах -> В таких конфигурациях не редкость объединение виртуальных таблиц без их предварительного выделения во временные -> PostGre медленно работает, если использовалась эта "старая" методология. -> в старых конфах PostGre не эффективен.
(5) только наверно не объединение, а соединение)
Я за точность высказываний. Чтобы человек, не понимающий темы не делал смысловой привязки к формам. Потому что этим человеком может оказаться заказчик, который увидит ОФ и сделает абсолютно идиотский вывод плохой работе ПГ.
Спасибо за исправление. Извините за резкость и "гневность")))
Я рад, что у вас глубокие знания и опыт. Но нужна ответственность перед более неопытными коллегами за каждое свое слово. Поэтому давайте не оставлять за кадром такие важные моменты, тем более в статье.
Справедливости ради замечу, что такой сильной корреляции между формами и качеством запросов я не замечал. Наверно потому что в УФ ПГ тоже часто отказывается работать. Соединения со срезами, по два полных соединения в запросе и т.д. Последние конфигурации для РФ вроде хороши, но локализованные решения или сильно отстают, или сделаны некачественно. Поэтому для меня нет такой аналоги с формами и не будет никогда.
Делается уже на автомате, когда в плане энергосбережения ставишь Высокая производительность, чтобы компьютер не засыпал.
(8) Я только ЗА.
Если кто-нибудь напишет утилиту или скрипт позволяющий делать подобные настройки на этапе установке сервера 1С в автоматическом режиме, было бы замечательно.
(9) Если кто-нибудь напишет утилиту. Остальные будут бояться ее запускать. Особенно в эпоху вирусов-шифровальщиков.
Капитан очевидность, приветствую тебя
Надо было для начала стартовать 1С с дискеты, тогда в заголовке можно было написать - Элементарный способ ускорить вашу 1С в миллион раз!
Спасибо автору, наткнулся на публикацию буквально в тот момент, когда у меня выполнялась ресурсозатратная операция. Настроил сервер - сэкономил время.
Может конечно и очевидные вещи. И уже об этом говорилось ранее.
Но я пробовал изменял параметры энергосбережения и не могу сказать, дало мне это изменение какой-то эффект или нет.
Автор провел практическую работу, сделал замеры и говорит, что есть положительный эффект.
Поэтому публикация однозначно +.
Бородатый админ - маст хэв!
Вообще, про режим высокой производительности я пишу в комментариях примерно раз в неделю - до сих пор, оказывается, есть народ, который не знает, почему это 1С (и не только) начинает работать быстрее раза этак в два. Автор, ты-то хоть знаешь, почему?
(18)А на файловых базах поможет? Часто для скорости приходится что-то тестировать до того, как на сервер обновления загружат.
Поможет, если алгоритм написан неоптимально. Т.е. процесс обработки данных сменяется процессом получения данных из хранилища. Если такое поведение в алгоритме частое (пример - запрос в цикле), то даже на файловой системе данная операция повысит производительность (хоть и не в два раза). Если же сначала все данные выбираются, потом обрабатываются, потом записываются в систему, то изменения будут не такими большими, но тоже будут - интерфейс начнет реагировать быстрее на действия пользователя.
Интересная и полезная статья. Новый, достаточно сложный материал изложен грамотно и доходчиво! Автор, огромное спасибо.
. Читая автора сложилось впечатление, что курс только куплен, но не пройден (с домашними заданиями), т.к. в данном курсе о данной настройке так же говориться.
PS Я, про "Этот курс" . Спасибо за курс Андрею и всей команде портала за его доступность, как в денежной, так и в интеллектуальной составляющей.
А сколько Алексея ждет открытий когда он научится план запроса анализировать, да виртуалку настраивать.
Спасибо за статью! В жизни всегда так - пока сам не разберешься, никто помочь не может, а как разберешься так сразу баян! Никого не слушай, особенно тех кто про баяны поет. Правильно сделал, что статью написал.
Мастерство заголовка, блин.
"Где можно натупить с настройкой сервера и просесть в производительности в два-три раза" - было бы ближе к телу.
На всякий случай. M2 это форм-фактор диска(даже семейство форм-факторов), а sata - протокол. Есть, и не мало, ssd в форм-факторе m2, которые работают по протоколу sata.
Более быстрый протокол называется NVM.
В принципе все очевидно, но напомнить никогда не мешает. Статья кратенько так написана, в самый раз чтобы вспомнить. Автору плюс. По PG vs MS можно подробнее, где и что написано, кто проводил замеры?
Замеры проводил я лично. А где написано - искать надо. Год назад это очень внимательно изучал. Теорию уже не найду, а практику - очень легко воспроизвести самому.
(40) Это значит, что в реестре нужно найти ветку [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent] в которой лежит команда запуска сервера ImagePath = "C:\Program Files (x86)\1cv8\8.3.13.1644\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files (x86)\1cv8\srvinfo" -debug
Кстати именно в ней мы ставим флаг -debug.
Посмотрев внимательно на эту строку увидим такой поддекст: -d "C:\Program Files (x86)\1cv8\srvinfo". В этом каталоге вы как раз и найдете "серверный" кэш всех использовавшихся вами баз.
(41) обычно debug я ставлю в такой последовательности, и отладка работает: "C:\Program Files\1cv8\8.3.13.1644\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -debug -d "C:\Program Files\1cv8\srvinfo"
Имеется ввиду что кэш можно перенести на другой диск ускорив тем самым работу сервера?
(42) Сам по себе перенос кэша имеет смысл только если системный диск перегружен, а диск на который переносите - способен работать в разы быстрее.. Что касается порядка команд - это едва ли имеет значение.
Когда я работал серваком ИТС в давние, но, не очень, времена, у одного клиента комплексная автоматизация 1.1 на ноутбуке(впарили чуваку на одно рабочее место, а, он кроме накладных в ней ничего и не делал, что, впрочем, на время обновления не влияло, поскольку, ноутбук был не из дорогих и быстрых), обновлялась около часа
Ну, обновлялась бы и обновлялась, у клиента положено быть не больше часа, пить кофе и болтать, так что укладывался во время. Но, райончик был "густонаселенным" клиентами, а, работа сдельная, сколько оббежишь столько и твое. И, вот, как в сабже, от нечего делать, копался винде во время зависшего процесса обновления и в диспетчере случайно обнаружил что двухгигагерцевый процессер работает на частоте 0,9 ГГц. мне это не понравилось и, малость нагуглив, узнал что это из - за экономичного плана питания. Недолго думая, залез и выставил наилучшую производительность, подняв вышеупомянутый параметр состояния процессора до 100%
Частота тут же подпрыгнула к 2ГГц как положено, а, зависший процесс обновления отвис буквально через несколько минут(перешел к следующему действу"обновить конфигурацию базы данных?"), а, еще минут через пять с конфигурацией базы данных благополучно справился и предложил принять изменения. ну, клиенту не сказал ничего про эту находку, а, повесил лапшу что новые обновления теперь ставятся быстрей чем раньше
Ну и после обновления питание вернул на место, чтобы, на всякий случай клиент не офигел от быстрого разряда батареи)))
Так короче и делал, приходил, включал перформанс, уходил - выключал
И не только у этого клиента
(44) Спасибо, может пригодится. Но я бы рекомендовал таки оставлять "100% перфоманс". Клиент, уверен, будет только в выигрыше.
спасибо полезная статья."тошнотики" и "умники" как всегда отличились.У кого корона шире так и не поняли,за то все умные учителя-"дилетант","капитан очевидность",прочие задросткие выражения ботаников самоучек.
Автор спасибо за статейку!
А вот, кстати, додавил переход на Linux у нас в конторе для отдельного чудо-"сервера" (машинка с 64-мя гигами на райзене 3600-м с памятью 3333). Сегодня коллега протестил - в Гилеве 120. Ладно, думаю, протестирую на клиент-сервере (режим сбалансированной производительности) - 45! (это постгрес + убунту сервер последний + xRDP и авторизация в домене).
До этого машина работала под вендой эссенциал, пускала, соответственно, двух юзеров всего. В Гилеве из-за старого ядра винды проц не аиделся толком и показывал в файловой 74 в Гилеве (у меня дома 1600-й показывал 89). Кароче, народ, крайне рекомендую новые райзены (ZEN+) в качестве "недосерверов". Надо будет завтра включить режим высокой производительности - должен серверный под 60 попугаев скакнуть.
Кстати, вот протестил несколько раз Гилевским тестом:
1. Снял режим совместимости - 104-110.
2. Оставил режим совместимости - 120.
А вот тут притесался Хеон Голд за дохрена денег с дохрена памяти, но, увы, всего 60 в файловой ))) У меня RYZEN 3600 за 12к с воздушным обдувалом. И это все в режиме ONDEMAND, т.е. "сбалансированная производительность", на SQL 44 попугая. Даже не представляю, сколько будет, если включу PERFORMANCE! )))
не слушайте глупого дядю, что вам скажет выставлять минимальное состояние процессора 100% - перегреваться будет процессор очень сильно, и сервак будет аварийно вырубаться. а поставить более мощьное охлаждение вам влетит в копейку, и не на все матери его можно прикрутить нормально. процессор сам нагрузится как ему нужно и во время простоя будет охлаждаться.
(51) Игорь, вероятно, вы очень трепетно относитесь к своей технике и не позволяете ей работать "сверхмеры". Это очень трогательно. Уверен, ваш ноутбук вас боготворит!
Тема хорошая и дискуссия тоже, автору плюс.
Включил режим высокой производительности на сервере с файловыми базами, опубликовал базы на IIS, завтра буду пользователей запускать, надеюсь поможет )
Читайте также: