Как заставить сервер c 2xE5-2630 v4, 128GB, raid ssd грузить процессор на 100% (тест Гилева 21,65)?

Question

[NNS]

Здравствуйте все! Как загрузить сервер за 300к?
У нас есть сервер с вот такой конфигурацией:

4xRAID1 SSD:

• (240 intel): Система, SQL, 1С
  
• (512 samsung evo pro) Основные базы 1С
  
• (512 samsung evo pro)Дополнительные базы от разных программ, тестовые базы 1С
  
• (1024 samsung evo) Виртуальные машины
  

Из ПО основное это: WS2012, MS SQL 14.0.2027.2, Сервер 1C Предприятие 8.3.16.1814, Hyper-v (все машины не ресурсоёмкие).
Сервер RDP отдельная машина, из которой идет подключение на этот сервер
Вот 8:30 рабочего дня, сервер предприятия 1с показывает 43 активных сеанса. Со вчерашнего вечера (уже более 10 часов) на сервере выполняется план обслуживания SQL:
Проверка целостности базы данных-->Реорганизация индекса-->Обновление статистики-->DBCC FREEPROCCACHE-->Резервное копирование На текущий момент завершена только Проверка целостности базы данных.
Вот его загрузка в разгар плана обслуживания и рабочего дня:

Ночью, когда никто не работает производительность такая же.
Схема электропитания "Высокая производительность"

Настройка памяти SQL:

Ставил параллелизм:

Но такая нагрузка была и когда все было по умолчанию, это уже эксперименты.
Результат теста Гилева:

Вообще не понятно что делает sql так долго если никто не работает в базах, и ресурсов ему хватает.
Но самое главное из-за чего это все началось, это жалобы пользователей на производительность 1С, а именно долгий отклик на простые открытия вкладок в самой программе, не говоря уже об отчетах. Для проверки, в момент жалоб, я запускал 1С прямо на этом "мощном" сервере, действительно все открывается медленно. Проблема плавающая, т.е. низкая производительность появляется периодами, и совершенно непонятна причина, стабильна только низкая нагрузка по всем параметрам.

Comments

[АртемЪ]

А что по загрузке дисковой подсистемы?
RAID в сочетании с samsung evo это достаточно печально выглядит.
Да еще и в сочетании с виртуализацией.

[NNS]

АртемЪ, диск отдыхает, а что не так с evo?

[АртемЪ]

NNS, SSD ставить в массив это вообще достаточно сложный и опасный процесс, а уж если это диски не энтерпрайз класса, ситуация усугубляется.
Можно получить кучу проблем.

[NNS]

АртемЪ, Там стоит server raid m5210 с дополнительным модулем кэш памяти памяти, брали в сервермолле, изначально туда ставили (продавцы) под систему 2 intel диска raid 1, вроде ребята не шарлатаны т.е. как бы от производителя можно сказать, потом уже мы ставили samsung.

[Sasha Odarchuk]

АртемЪ, в чем печаль?

[Sasha Odarchuk]

АртемЪ, Какие могут быть проблемы? Чем энтерпрайз_ССД отличаются от неэнтерпрайз_ССД в плане работы в рейде?

[АртемЪ]

Sasha Odarchuk, По поводу отличий - основное отличие энтерпрайз SSD это шустрый процессор и достаточный объем оперативки, и отсутствие агрессивного кэширования. В итоге сборщик мусора там может прекрасно работать в фоновом режиме параллельно с основной работой и не мешая ей, да и работы у него поменьше.

В обычных дисках такое нафиг не нужно, на мощный процессор не тратятся, поэтому сборка мусора идет во время простоя. Там принцип или сборка мусора, или основная работа - что-то одно работает.
Это потенциально создает проблемы в режиме RAID.

Answer 1

[Михаил Е]

1. Загрузить процессор на MSSQL можно так :
- Должна быть задача на SQL серваке, которая потребует этих ресурсов (в простое или при малых задачах SQL проц не загрузит)
- Ставим параллелизм = количеству ядер
- Ставим Стоимостной порог в 0.
После завершения текущих проверок, советую вернуть MAXDOP/MaxThreshhold на (1/4 или 1/8 от количества ядер а порог выявить методом проб и замеров). Дело в том, что загрузка проца 100% не значит что всё будет быстрее (только в некоторых случаях типа проверки целостности). Т.к. при распараллеливании запросов по ядрам, появляются "Накладные расходы" на распараллеливание и сбор обратно результатов воедино. Это будет выглядеть как ожидания CXPACKET и Latch. (См "закон Амадала" + CXPACKET в гугле)
2. "Проверка целостности базы данных" - на ежедневной основе смысла не имеет, особенно если база достаточно крупная. Её имеет смысл делать или при возникновении проблем, или раз в квартал/месяц ... зависит от размеров базы. UPD: Лучше всё же её делать, если позволяет размер и тех. окно. Т.к. можно упустить ошибку целостности и перенести её в бэкап.
3. Если есть проблемы с производительностью, это вопрос не простой, и требует кучу опыта. Навскидку рекомендую сначала проверить :
- Нагрузку на дисковую подсистему, и если там будет проблема (Очередь к диску более 2 в среднем) выполнить разнесение *.mdf, *.log, tempdb, инстанс кластера 1c серверов на отдельные диски.
- Нагрузку на оперативку от MSSQL (можете гуглить это может вызывать большую активность IO на дисковую подсистему)
- Проверить способ коннекта к MSSQL ("Shared memory" должно быть "on" и использоваться, если 1с сервак и mssql сервак физически на одно машине .. это +10% к производительности.
ну и куча чего ещё ... в одном посте всего не расписать.
и т.д. вариантов очень много.
главный совет: решайте проблемы , только если она есть и мешает, если это лично ваше мнение, а пользователям не мешает, лучше делайте настройки по дефолту (см. APDEX, анализ производительности)
UPD: И да, виртуалки для 1C + MSSQL = зло, и не потому что "фирма 1С плохая", а потому что у вас не сможет 1С и MSSQL не сможет общаться через оперативку, и между оператором чтения на MSSQL до железа сервера будет 4 прослойки (SQLOS, OS виртуалки, Гипервизор, OS сервера, вместо SQLOS + OS сервера).

Comments

[NNS]

Спасибо большое за развернутый ответ, сказанное Вами требует изучения.
На вскидку скажу что Shared memory был включен, а 1С живет на том же сервере.

Выставил параллелизм и стоимостной порог:

Я так понимаю что для применения нет необходимости перезапуска службы, если это так, результат остается прежним.

Проверка целостности завершилась почти сразу, а реорганизация индекса идет почти сутки. При очень низкой загрузке ЦП

[Михаил Е]

NNS , а можете показать вкладку "Процессы" , в мониторе активности MSSQL, с отборами:
- "Команда" = "Не пустые"
- "Тип ожидания" = "Не пустые" ?

[Михаил Е]

NNS да, перезагрузка не требуется, но распараллеливание начнётся со следующей транзакции (т.е. текущая транзакция реиндекса дойдёт со старыми настройками, реиндекс след. таблицы пойдёт по новому плану.
В любом случае, направление в котором вы можете "Копать" в сторону ускорения примерно следующее :
1. Определить узкое место (железо, блокировки 1с/SQL, ожидания исполнения команд по типам)
2. Исправление узких мест (причем исправление одного может вызвать выстрел другого места, это цикличный процесс).
По вкладке ожидания ресурсов, вроде проблем быть не должно. Возможно сам запрос реиндекса не оптимальный, его часто делают не через "План обслуживание" а через "Регл задание сервера" с произвольным запросом. т.е. ребилдить не всё что есть, а то что требует ребилда/дефрага. В инете куча SQL запросов для определения что сейчас конкретно необходимо в конкретной ситуации. (до 30% фрагментации = дефраг индекса, более = ребилд индекса) если менее 15% то можно пока что не трогать.

[NNS]

Михаил Е, Совсем не возьму в толк как там сделать сортировку, там просто можно свернуть или развернуть вкладки. Я отсортировал по "Команда" , а Тип ожидания везде 0

[NNS]

Михаил Е, Эхх.. чертовщина, начался процесс "Обновление статистики", и прошлый процесс в журнале отмечен как выполненный за 37 мин)


А еще я нашел запрос который показывает выполнение задачи, я надбавлял туда записей, как истинный профан, и жамкал много раз выполнить, там есть столбец dop который как раз говорит о степени параллелизма. и там всегда 1. хотя задача точно выполнялась после применения настроек.

[Михаил Е]

NNS
Отборы ставятся так :

На тему DOP, с помощью настройки вы можете "Косвенно" влиять на загрузку ЦП, т.е. изначаль сам MSSQL решает сколько ресурсов для выполнения того или иного запроса, а параметрами MAXDOP и Cost threshold (Степень параллелизма и стоимостной порог) вы можете ему ограничить эти хотелки. Если поставить 0 (Крайне не рекомендуется) чтобы снять ограничения, но использовать все ядра или нет , все равно решать будет ядро MSSQL. если стоит DOP 1 тогда или в запросе обслуживания стоит хинт "With maxdop (1)" (См свойства задания, и сгенерированный скрипт настроенного плана) или таблицы настолько маленькие, что распараллеливать их нет смысла.

[NNS]

Михаил Е,

[NNS]

NNS, Были бы жалобы от него чего ему не хватает, вот так смотришь, вроде прямо стоит и курит сервер. Понятно что знания скудные в этой области, но все же..

[Михаил Е]

NNS на самом деле если мы вернемся к изначальной теме вопроса, "Пользователи жалуются что медленно" и "Я сам вижу что тормозит", я бы вам посоветовал в первую очередь смотреть не на MSSQL а на 1С. Т.к. обычно основные тормоза именно в коде 1С.
Как пример можете "Косвенно" повлиять на разнесение пользователей на разные процессы (временно).
Т.е. если дело в 1С тогда это может помочь разобраться в проблеме. порядок такой :
1. Вы обнаружили что вот прям щас происходит серьёзная просадка по производительности. (Необычно долго отрабатывают стандартные действия, с падением производительности более 30% от стандартного времени выполнения.

2. Заходите в консоль кластера 1С.
3. Переходите на вкладку рабочие процессы вашего кластера, запоминаете PID и смотрите на колонку "Включен" , там скорее всего будет значение "Да".


4. Правый клик по кластеру, => свойства.


5. Ставите "Интервал перезапуска рабочих процессов" некоторый период, например 100 сек.
жмете "Ок". переходите на вкладку рабочие процессы, и жмете обновить пока ваш изначальный рабочий процесс (С PID который вы запомнили) не получит значение в колонке "Включен" = "Нет".

6. Правый клик по кластеру, => свойства. => ставите обратно интервал перезапуска рабочих процессов = 0.
ОК.
картинка на раб процессах будет примерно такая :


Таким образом если в текущий момент у вас выполняется какая-то длительная и сложная операция, которая мешает пользователям, она останется на старом процессе, и как только она завершится, старый процесс отвалится. Пользователи в это время (как только старый будет помечен как не включен) будут "Переезжать" на новый процесс, при этом в системе будет подвисание всех на 1-10 сек. после того как пользователи переедут на новый процесс, (Можно увидеть на вкладке "Сеансы" по колонке "Процесс", там будет у живых пользователей PID нового процесса) Проверьте производительность. Если "Станет лучше" тогда смотрите вкладку сеансы и ищите, кто остался со старым PID. Скорее всего это будет какое-то регл. задание типа расчета себестоимости или распределение взаиморасчетов или ещё что. Это и есть виновник тормозов. дальше уже что с ним делать вопрос 2-й ...

Это один из вариантов определения тормозных операций в 1С.
P.S.: при этом возможна сложность - люди , сидящие под толстым клиентом, или те, кого сервер не сможет пересадить на новый процесс, могут получить сообщение "Сеанс завершен администратором". Это нужно учитывать. Но если никакого криминала они не делают, всё должно быть Ок.

[NNS]

Михаил Е, Огромнейшее Вам спасибо, получился целый мануал. Теперь буду пробовать. Если честно надо перечитать утром (+6мск.) на свежую голову. Но я так понимаю это очень хитрый костыль который позволяет НЕ перезапуская сервер предприятия 1С и не выкидывая большую часть пользователей перекинуть их в другой процесс.

[Михаил Е]

NNS ну да, можно назвать и так ) ... в любом случае это всё, только вершина айсберга, темы "Анализ и оптимизация производительности 1С + MSSQL" ... интересуйтесь, пробуйте, потенциал большой. (Если всё это не оч поможет, почитайте про "Тех журнал 1С", ожидания на блокировках, Запросы и планы запросов в 1С и MSSQL ... всё это поможет понять "Почему эта гадина тормозит" )))

[NNS]

Михаил Е, Я не терял надежды получить ответ на тостере и явно не напрасно), не ожидал столько информации получить за один день. Еще раз спасибо!

[unfilled]

2. "Проверка целостности базы данных" - на ежедневной основе смысла не имеет, особенно если база достаточно крупная. Её имеет смысл делать или при возникновении проблем, или раз в квартал/месяц ... зависит от размеров базы.

Ого, я более вредного совета ещё не встречал. И что будет делать человек, если узнает в конце месяца, что у него БД повреждена? И это повреждение во всех имеющихся бэкапах будет сохраняться?

[Михаил Е]

unfilled, я же написал "Особенно если база крупная" , если у вас БД, размером 3ТБ+ checkdb происходит 16+ часов (Если повезет). при этом блокируя таблицы на час и более. Вы серьёзно в таком состоянии будете держать продакшн на ежедневной основе ? и по какой причине у вас будет повреждение БД, если на работе пользователей это не сказывается и проблем нет ? Checkdb - это довольно ресурсоёмкая операция, и на ежедневной основе на крупных базах, смысла особого не имеет. Ну и обычно если какие-то проблемы с таблицами есть, они проявятся в работе запросов, или при перестроении индексов и решаться они будут или "AllowdataLoss" или бэкапом предыдущего периода.

[unfilled]

Михаил Е, для VLDB особенно важно проводить проверку целостности часто. Да, целиком в maintenance window оно не влезет, поэтому эту операцию обычно дробят.
Когда запрос наткнётся на повреждённые данные, может быть уже слишком поздно и бэкапа с неповреждёнными данными может не быть и, действительно, останется только вариант с потерей данных. Если для вашей "крупной базы" это не проблема - ну, повезло, что сказать. Но раздавать такие советы - опасно (не для вас, конечно, только для тех кто им последует).

[Михаил Е]

unfilled, думаю соглашусь, если она не сказывается на производительности и влезет в тех. окно, то от неё будет польза, тут наверно мой опыт больших баз немного переклинил. Согласен, неправ. Лучше делать, но опять же зависит от обстоятельств.

[Михаил Е]

NNS на тему загрузки ресурсов при планах обслуживания:
1. У вас в планах обслуживания стоит шаг "Реорганизация индекса". Тут есть тонкость :
Инструкция, которая при этом выполняется "ALTER INDEX ... REORGANIZE" - она всегда однопоточная, и не умеет в много ядер.
(Подтверждение от Microsoft)
Именно поэтому её применяют только если степень фрагментации индекса <30%.
Если Степень фрагментации >30% применяют "ALTER INDEX ... REBUILD" который умеет в многопоточность, но он более ресурсоёмкий, по сути это полное перестроение индекса.
(Определение фрагментации и выбор способа обслужива...)
Чтобы работало корректно без динамик sql тут не обойтись. (Не обязательно именно этот использовать, это лишь первый из поиска, можно поискать другие.
Проверил на тестовых базах REORGANIZE - реально всегда однопоточный, и если создавать план обслуживания с ИТС (Реорганизация индекса) , он, похоже, всегда будет в 1 поток.

[NNS]

Михаил Е, Еше REBUILD блокирует таблицы вроде (хотя не ясно что это значит в практическом смысле), и чтобы не мешат пользователям рекомендуется делать его 1 раз в неделю, когда никого нет. а в будние дни делать так:
А по поводу скриптов, надо мне видимо изначально подтянуть матчасть. Потому как я фундаментально не понимаю многих действий которые произвожу, просто перетаскиваю плиточки "Реорганизация", бац стрелочка "обновление статистики".

[Михаил Е]

NNS да, ребилд блокирует,
(в практическом смысле, никто не сможет выполнить ниодного запроса к таблице, пока эта операция не завершится).
Но если напостоянку (раз в 15-30 минут пускать скрипт по проверке фрагментации индексов, и при появлении фрагментации больше 10% но меньше 30% пускать реорганайз, тогда до ребилда вроде как дело дойти не должно (только в случаях очень массового изменения данных, типа перепроведения года). а если фрагментация больше 30% оставлять для вечернего обслуживания с ребилдом ...

Answer 2

[GilevVyacheslav]

На не правильный вопрос нельзя получить правильный ответ. В формулировке вопроса вы связываете 100% загруженности сервера с повышением производительности. В действительности же наоборот, чем выше нагрузка тем больше шансов словить операциями ожидания оборудования и замедлится. Т.е. первое что вы должны сделать это отказаться от концепции "загрузить под 100% процессор" чтобы улучшить производительность.

Для вашего процессора результаты нашего теста могут достигать 40 баллов.

Тест интегральный, то есть показывает суммирующий результат всех факторов. Таких факторов много. Именно поэтому это не тест для конкретного компонента. Чистую скорость отдельного компонента тест не покажет. Влияние дисков оценить можно но не надо например замерять скорость дисков этим тестом. Влияние дисков на общую скорость 1С и скорость дисков это не одно и тоже.

Ну и очевидный не для всех момент - тест надо делать когда нет нагрузки на сервер.

На результаты теста могут влиять
процессор (частота)
BIOS (turboboost и т.п.)
планки памяти (частота, расположение по каналам)
Гипервизор - схема электропитания, динамические ресурсы, приоритеты
ОС Windows - схема электропитания, квотирование dfss | Linux - Power saving
версии платформы 1С:Предприятие 8
версии субд
скорость диска, где размещена база
скорость диска, где размещена tempdb (если MS SQL Server)
скорость диска, где размещены кластер 1С, профиль учетки службы 1С, темпы
канал взаимодействия между 1С и субд: Shared memory | скорость сети
зеркалирование

Соответственно по списку начните с настройки биоса и убедитесь с помощью CPU-Z что частота процессора работает стабильно работает в турбобусте.

Если же Вы наблюдаете только периодическое замедление любых операций, то замерьте скорость реакции в свойствах рабочего процесса. Например при достижении 80% оперативной памяти в редакции ПРОФ сервера 1С происходит общее торможение. Подобные эффекты бывают при рестарте рабочих процессов или падении (поищите поиском *.mdmp файлы как признак падения). Наконец можно общее замедление словить запустив много фоновиков (сбросьте все фоновики в момент подвисания или вообще заблокируйте их старт). Выключите антивирус если есть.

Comments

[NNS]

Безусловно я смешал в этом вопросе мух котлет и вообще все что можно, начиная рассматривать производительность SQL, закончил первопричиной жалоб. Но что мне истинно не было понятно и не понятно сейчас, почему столь оптимизированная (по сравнению с 1С конечно) вещь sql не хочет рационально поглощать ресурсы сервера. Я понимаю что на нежелании 1С править косяки годами, строится индустрия и можно писать диссертации об этом, но вроде sql не про это. Скорее всего я где то затупил, что то не настроил. Фактически в самой SQL есть БД, есть много ЦП, много ОЗУ, много дисковой скорости, бери и делай свой же план обслуживания. Но нет же. Иными словами я не совсем связываю 100% загрузку с повышением производительности, я просто хочу понять почему у сервера есть задание на 100% всех его ресурсов, для которого не надо связываться с другими программами (такими как 1С), просто нужно единолично все сделать быстро и всё тут.

[NNS]

Соответственно по списку начните с настройки биоса и убедитесь с помощью CPU-Z что частота процессора работает стабильно работает в турбобусте.

Да, ЦП работает на пониженной частое, даже когда в том же cpuz запускаешь стресс тест, получается 2.4 максимум. Тут я согласен надо в биосе поправить, спасибо! Только не ясно зачем ему турбо 3.5 если ни rphost (который тащит 50 пользователей) ни sql (который делает план обслуживания ) суммарно не потребляют 10-15% ЦП (остальные ресурсы будто вообще не нужны).

[GilevVyacheslav]

NNS, ещё раз внимательно прочтите исходный пост
чем больше занято ресурсов, тем меньше шансов у системы будет сразу начать выполнять новую операцию - чем выше загруженность, т.е. занятость, тем выше вероятность попасть в очередь на ожидания этих самых ресурсов
скорость одного конкретного потока - операции будет определять способность оборудования выполнять количество микроопераций в единицу времени
для процессора таковым является частота процессора, чем выше частота, тем больше микроопераций способен выполнить процессор
если какая то конкретная операция утилизирует ВСЕ ресурсы, то это очень плохая операция хотя бы потому что вторую такую вы одновременно с первой уже запустить не сможете

не понятно?

[NNS]

GilevVyacheslav, Понятно. Просто хотелось бы абстрагироваться от 1С, я уже понял что 1С питается исключительно тактовой частотой, ядра она не любит. Но в половине моего вопроса 1С вообще не причем. Есть 10 БД (часть из них вообще не от 1С), есть план обслуживания SQL, созданный через конструктор, план применяется ко всем 10 БД. ОК, пускай он последовательно выполняет запрос над каждой БД. Но неужели SQL берет 1 ядро, берет 1 базу, и берет 1 этап плана обслуживания и начинает все это выполнять. При этом остальные 9 БД и 19 ядер стоят и курят. Как на картинке про 1 работягу в яме и 10 прорабов. Надо заметить что это происходит при абсолютно спокойной обстановке, ресурсы сервера вообще никто не задействует.

Еще вот такой пример, уже из 1С
Вот есть у меня 2 базы Касперский и стахановец, размер 11ГБ и 1,5ГБ. Произвожу над ними план обслуживания созданный в sql: Проверка целостности базы данных-->Реорганизация индекса-->Обновление статистики-->DBCC FREEPROCCACHE Продолжительность выполнения 3 мин.

Беру еще 1 базу уже 1С, Управление ИТ отделом (0,5 ГБ ) выполняю те же операции что и с двумя базами выше Продолжительность выполнения 7 мин

При этом 2 базы, которые не 1С, используются их программами постоянно, а база ИТ отдел просто висит и вообще не используется, и этот же план обслуживания применялся к ней вчера...Тут мои поверхностные и умозрительные заключения заходят в тупик.
p.s.

Ну и очевидный не для всех момент - тест надо делать когда нет нагрузки на сервер.

Для меня лично он очевиден, поэтому я делал тест и глубокой ночью и в разгар рабочего дня, разница не существенная.

[GilevVyacheslav]

Вопрос то какой? Почему создали последовательный план действий и он выполняется последовательно? Ну так вы сказали ему так работать.
1С действительно не при чем. Любая хорошая операция должна потреблять как можно меньше ресурсов, а не больше. Если задача положить сервер - сделайте для каждой базы данных отдельный экземпляр скуля, там сделайте свой регламент, при чем чтобы по времени эти регламенты стартовали одновременно. Дурное дело не хитрое.
И да, 1С вполне многопоточна. Разные сеансы работают на разных ядрах. А если руки растут откуда надо то можно и фоновики запрограммировать, а асинхронные вызовы.
Вам не абстрагироваться надо, а четко формулировать решаемую задачу. И не выдуманную, а с практической пользой.

[NNS]

GilevVyacheslav,
Четко сформулированная задача:
Не приобретая ни единого болтика для расширения мощностей, как выполнить план обслуживания над 26 БД, хотя бы за ночь. Совокупный вес баз 299 ГБ. Самая большая весит 34ГБ, самая маленькая 0,5.

Что там 26, пусть хоть 2 основные ЗуП (18ГБ) и бухгалтерию (34ГБ) провернет через себя. При этом не сложит сервер на колени, но хотя бы обрабатывая 2 базы в принципе хоть как то работать. Ведь он ничего не делает совершенно,

хотя в этом возможно мне поможет убедится ваш продукт, я его очень хотел еще до того как начал этот пост писать, я бы даже пришел на курс не разделяй нас 7500 км, онлайн возьмите:).

А так жаль что руки растут не откуда надо, но это не про меня, а у создателей платформы 1С). С этим фактом можно спорить, но работа с этой программой причиняет только боль, хотя без этого не было бы сети франчайзи и оптимизаторов... И нормальные продукты я видел, поэтому про 1С так говорю, взять тот же Veeam, это чистый кайф, а их "ИТС"? да она просто решает твои проблемы, а не предлагает костыли, не для этого ли она нужна, поддержка)...

[GilevVyacheslav]

NNS, у вас на скриншотах нет задач, выполняющихся больше 10 минут
если брать среднеарифметическое, то чтобы уложиться за 8 ночных часов регламенты одной базы должны выполняться порядка 20 минут
не рассматривайте выполнение регламентов в куче, а проанализируйте каждый в отдельности
если у вас нормальные NVMe диска типа intel p4600, то все регламенты должны проходить за час
если у вас старые SAS/SATA диски, то регламенты по обсчету статистики могут идти долго
особенно потому что когда происходит расспараллеливание запросов к дискам, на них начинаются очереди и вместо ускорения получается ухудшение, визуально его можно наблюдать в мониторе производительности диспетчера задач по долгим откликам дисков, если посмотреть на типы ожиданий скуля, то отчасти подтверждается суммарными весами
т.е. вам не просто надо создать параллельные задания на обслуживания, но и один раз вживую пронаблюдать отклик системы в момент выполнения таких заданий, не топят ли диски ваши регламенты
планы обслуживания должны быть параллельные, а не один общий, и количество одновременных планов надо подбирать вручную следя за поведением железа

[NNS]

GilevVyacheslav, Прямо сейчас над этой базой выполняется обновление статистики, на работе уже никого нет, длится это точно более 30 мин.

Не знаю тут ли загрузка которая нужна, но выделена именно та база над которой идет обработка плана, я к сожалению пока не умею настроить сборщик производительности.

Диски samsung evo pro 2xRaid1, через Raid контроллер с кэшем.
Что касается скриншотов в нашей ветке, это просто для примера маленькая база 1С и 2 большие (относительно 1С-ной) базы, и разница во времени 2 раза, может это ничего не значит вообще.

[GilevVyacheslav]

NNS, ну вы половину ответа на свой вопрос уже знаете - вам нужно разрулить обсчет статистики в базах
первое что бросается в глаза - это нетипичное имя приложения - вы как вызываете этот самый регламент?
второе - обычно при обсчете статистики присутствуют ожидания CXPacket, у вас maxop=1?
третье - как у вас настроен регламент, вы полностью во всех баз обсчитываете все таблицы подряд с полным сканированием что ли?
включите для всех ваших баз асинхронное обновление статистики
ALTER DATABASE YourDatabaseName SET AUTO_UPDATE_STATISTICS_ASYNC ON
GO

также для вашей базе вручную выполните exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'
он должен пролетать для небольших баз очень быстро
напишите за сколько выполнился у вас
если он выполняется десятками минут, то надо выполнить тест дисков
ставлю пиво что вы "раскурчили" диски и они на запись выдают СУЩЕСТВЕННО меньше чем заявлено у вендора, скачайте www.gilev.ru/wp-content/uploads/2017/01/CrystalDis... и сделайте скриншот с результатов теста, в нормальном состоянии по линейной записи диск пишет 500 МБ/c . У Вас и 250 не выдает, я прав?

[NNS]

GilevVyacheslav,
1. Вызываю план через контекстное меню:

2. Был maxdop = 5, сейчас поставил 1
3. Похоже что так (я как профан, хотя вроде по методике 1С)

А в общем цепочка такая:

Результат тестов (почему то разный слева по вашей ссылке, справа новая версия)

xec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN' над самой большой базой (34ГБ бухгалтерия) выполнялся 20 мин ,в это же время на этом же диске запустил на документообороте эту операцию(7ГБ) выполнилось за 40 сек, но там хоть видно было что идет обращение к диску:

[GilevVyacheslav]

NNS, ваши показания на счет дисков не очень бьются с тестом
у диска заявлено 500 мб/с на чтение а у вас 950? рейд 1 не ускоряет, а немного замедляет диски )

далее, я же несколько раз написал про параллельные расписания, нет вы продолжаете лупить "все базы"
у вас там небось и копии баз есть, и прочий мусор и он зря статистикой обсчитывается

далее, пока по хронометражу, если у вас только одна база обсчитывается 20 минут, а остальные выполняются быстро, то чисто математически не набегает 8 ночных часов
у меня складывается ощущение что вы доносите информацию с искажениями

про проверку целостности - отдельная песня, нахрена ее так часто делать, делайте раз в месяц отдельным расписанием вообще

также в регламент на ночь есть смысл добавить скрипт maxdop=4, а с утра ставить maxdop=1

[NNS]

GilevVyacheslav,

у диска заявлено 500 мб/с

тут есть над чем задуматься, действительно у этих дисков должна быть скорость 500 на чтение, скорее всего программа тестирования не может обмануть кэш Raid контроллера.
Я продолжаю лупить все базы потому что не умею писать скрипты, я могу только галочки поставить и всё),и еще дополнительно, потому что в одном плане обслуживания делаются как резервные копии, так и сами процедуры с базами, таким образом при появлении новой базы не надо думать все ли с ней будет в порядке. Я понял, что надо все переделать полностью.
По хронометражу я сегодня поставлю ночью все базы по старинке только maxdop=4, и не буду трогать пока не закончится.
Я могу искажать информацию только из за своего незнания, намеренно это совершенно глупо было бы. Есть еще фактор, что задание то в итоге завершилось (с чего я и написал изначально), но на его выполнение потребовалось почти сутки, возможно последующие подобные операции с бд происходят быстрее, с учетом что ранее эта процедура производилась совсем давно.

Это очень странно, чем я больше знаю читая всё это, тем я в итоге меньше знаю.

[GilevVyacheslav]

NNS, вы что не знаете какой размер кэша у контроллера? ну сделайте тест на 4000 Mb . Если размер кэша меньше, то тест выдаст более достоверный результат. Вряд ли у файлы баз меньше чем кэш контроллера.

"Я продолжаю лупить все базы потому что не умею писать скрипты" При чем тут скрипты. Вы что не можете воспользоваться мастером регламентных заданий несколько раз? Пишите для каждой базы персональное задание. Не надо ставить "все базы".
включите для всех ваших баз асинхронное обновление статистики
ALTER DATABASE YourDatabaseName SET AUTO_UPDATE_STATISTICS_ASYNC ON
GO
YourDatabaseName - имя конкретной базы

Сделайте хронометраж, смотрите куда уходит время больше всего. Проверку целостности баз уберите из ежедневного регламента.

[NNS]

GilevVyacheslav, Размер кэша 2ГБ, я поставил тест с 4ГБ файлом, и вот результат:

я запустил тест несколько раз на разных версиях программ, чувствую себя каким то тролем), но это то, что показывает мне программа.
вероятно все же или программа работает по другому или контроллер, либо они вместе. Видимо нужны более объективные методы исследования.

[GilevVyacheslav]

NNS, так что там с хронометражем?

[NNS]

GilevVyacheslav, Жду когда можно будет отписаться, что все закончилось.

На текущий момент 18 часов выполнения.

[GilevVyacheslav]

NNS, ну так уже можно посмотреть куда больше всего ушло времени на текущем участке

[NNS]

GilevVyacheslav, Только я не знаю как это сделать. Единственно на что хватает ума, это понять что выполнилась проверка целостности, и выполняется реорганизация.

[GilevVyacheslav]

NNS, по поводу теста - собственно результат теперь показывает более менее достоверный- 421 на запись может быть как раз либо ухудшением из-за рейд 1, либо некоторой степенью остатка места на диске (trim скорее всего шедулером делается самой ОС)
но благодаря тому что вы подключили диск через контроллер с кэшем, то замаскировали следующую проблему: диски Samasung EVO при длительной записи (например ребилде индексов в базе) могут значительно проседать в момент пробития их кэша.
Серия PRO дороже серии EVO в некоторых ситуациях до двухкратной разницы в силу преимущества двухкратно больше перезаписываемого объема. Серия EVO использует технологию TurboWrite. Серия PRO это технологию не использует.
У серии EVO когда "кэш" TruboWrite забивается под завязку, то скорость записи резко падает и значительно медленее чем у PRO. У серии PRO такого падения не происходит.
Для домашних пользователей серия EVO предпочтительней, так как тяжело в одиночку пробить кэш. Для баз данных субд где устойчивая постоянная запись наиболее критичный фактор серия PRO даст однозначно преимущество при наличии таких вещей как перепроведении документов за месяц в базе данных.
Мы лично pro диски используем под базы с небольшим количеством пользователей, а диски evo отлично подходят для бэкапов.
В вашем случае из-за контроллера со своим кэшем ситуация будет происходить когда сначала кэш контроллра будет пробит, а потом кэш диска. Ловить такое тяжело, но эта одна из гипотез почему регламенты то быстро то медленно идут.
Ждем что покажет Ваш хронометраж.

[NNS]

GilevVyacheslav, Я использовал в своей терминологии неверные названия я называл Samsung PRO именем Samsung EVO PRO. Фактически у нас базы стоят на Raid1 из Samsung PRO (красненьких)

А серые EVO используются для виртуализации.

[GilevVyacheslav]

NNS, если вы думаете что ловко переобулись
у красненьких тоже не все идеально

так что - ХРОНОМЕТРАЖ!!!

[NNS]

GilevVyacheslav, С небольшими погрешностями хронометраж такой

• Задание запустилось 05.03 в 00:11 закончилось 06.03 в 03.42
  
• Проверка целостности: 10 мин
  
• Реорганизация индекса: 24 часа
  
• Обновление статистики: 2,5 часа
  
• DBCC FREEPROCCACHE: Менее минуты
  

Результат теста (никто не работает, планы обслуживания не выполняются)

[GilevVyacheslav]

NNS, что и требовалось доказать
в нормальный сервер вы воткнули диски от домашнего компа, при интенсивной записи скорость естественно западает
самый просто вопрос - денежный, лучше всего воткнуть intel p4610 1.6 tb
но раз вы хотите бесплатно, тогда вам нужно отказаться от слепого перестроения всех индексов подряд без разбору - это ненужная работа
перестраивать нужно только те индексы которые сильно дефрагментировались
поищите скрипты типа https://gist.github.com/KotegBegemoteg/d224be2683b...
только я советую сделать более строгий порог : всё что меньше 30% дефрагментировано вообще не трогать, также не трогать таблицы где меньше 10000 строк, а полноценный ребилд делать только для индексов за 60%
после этого думаю проблем с временем не останется

[NNS]

GilevVyacheslav, Обидно то, что руководство не особо экономит на всем этом.
Когда нам продавали сервер в него изначально поставили такие SSD далее, когда количество баз разрослось, вбирали диски по IOPS У samsung судя по характеристикам IOPS на запись существенно выше чем у стоявших ранее SSD. Про просадки никто не пишет нигде (по крайней мере на поверхности), где вообще можно узнать что они начнут проседать, или просто если написано серверный, значит норм получаете.

[NNS]

GilevVyacheslav, intel p4610 написано интерфейс подключения PCI, а на картинках он везде sata. Просто мы собираемся переезжать на VMware, а там проблемы могут еще усугубиться. Поэтому возможно придется что то менять, и первое что приходит в голову прочитав все здешние советы, это:
1. Отказаться от raid (он был для "надежности", но походу лучше бекапа нет надежности)
2. Купить серверный SSD под все базы (осталось выбрать модель sata на 1TB)

[GilevVyacheslav]

NNS, вы если будете делать по своему, то снова херня получится
pci разъемы есть в любой материнке, не делайте мозг
другое дело если у вас одноюнитовый корпус, то может так оказаться, что вставлять надо под углом 90 градусов через райзер карту
S3500 мало чем отличаются от EVO, такие же убогие диски
sata покупать не надо, надо что я говорю

либо https://www.regard.ru/catalog/tovar270254.htm (только убедитесь что под вашу ОС есть драйвера)
либо p4600 типа https://market.yandex.ru/product--tverdotelnyi-nak...
либо p3700 https://market.yandex.ru/product--tverdotelnyi-nak...
либо p4800х https://market.yandex.ru/product--tverdotelnyi-nak...

также можете взять диск u.2 через переходник pci , диск Intel DC P4610 1.6 Тб SSDPE2KE016T801 U.2 https://www.nix.ru/autocatalog/ssd_intel/SSD-16-Tb...
переходник для разных серверов разные, привожу модель для серверов супермикро https://www.regard.ru/catalog/tovar365136.htm

возьмите какую то другую модель, в особенности sata/sas и результат я не гарантирую

а пока суть до дело, уберите старый регламент по индексам, запустите отдельно скрипт, замерьте его время, если выполнится за пару часов, то заносите в расписание

[GilevVyacheslav]

да, забыл про шнурок для u.2 https://www.regard.ru/catalog/tovar328926.htm
подробнее www.gilev.ru/u2ssd

с вмваре вы гемороя огребете, сначала текущие проблемы решите, потом уже дальше поговорим
там тонкостей хватает www.gilev.ru/nvmevmware

[Setitle]

GilevVyacheslav, с большим интересом прочитал ваши ответы, спасибо и от меня!
Остался вопрос насчет дисков. Не понял как все таки понять насчет Кэша, его объема и подойдет ли для 1с+sql (если говорить про кэш)? А учитывая, что объем Кэша в параметрах как я понял не указывается зачастую, вообще не понятно...
Предстоит покупка сервера+СХД. (предварительно ThinkSystem SR630 (Intel Xeon Gold 5222 4C 105W 3.8GHz) + ThinkSystem DE4000F)
Предлагают диски:
Сервер - ThinkSystem 2.5" SS530 800GB Performance SAS 12Gb Hot Swap SSD
https://lenovopress.com/lp1031-thinksystem-ss530-p...
СХД - Lenovo ThinkSystem DE Series 800GB 3DWD 2.5" SSD 2U24
https://www.nix.ru/autocatalog/sistemy_khraneniya_...
Статьи на вашем сайте читал, в том числе и про NVMe (огромное спасибо за ваши труды!) Но в основном там речь про диски для клиентских ПК. (согласен, что корпоративным клиентам надо заказывать услугу по подбору :) )
На сервере будет до 100+- пользователей. 10бд, ЗГУ самая большая 35Гб.
Судя по данным которые удалось понять, это не самый лучший вариант дисков? (или далеко не самый лучший? или я ошибаюсь вообще?) Все таки Samsung 970 pro туда не запихать или как минимум странно.
Думаю вообще может СХД лишняя железка, лучше диски напрямую в сервер и NVMe. Пока, что решил NVMe в сервер и оставить СХД.
Буду благодарен за разъяснения про Кэш!

[GilevVyacheslav]

Setitle, для 100 пользователей покупать внешнюю полку это должна быть веская причина и ей точно не может быть база данных 1С
мне вообще не понятно зачем брать СХД ради СХД - у вас что в сервере места нет?

сервер мне кажется лучше будет Intel R1304WFTYSR
а в качестве диска под базу 1.6Tb Samsung PM1725b (MZWLL1T6HAJQ), можно посмотреть PM1735
под бэкапы можете взять mx500 2tb

970 или 980 вы скорее всего не воткнете, но даже если будет разъем, то скорее как диск под ОС юзайте

про диски вам надо знать
www.gilev.ru/dwpdssd
www.gilev.ru/nvmeraid

Answer 3

[Константин]

На прошлой работе админил, 150+ активных пользователей 1С
1) 1C утекает по памяти, настраивайте автоматический перезапуск процессов. Например каждые 40 часов.
2) количество процессов для 1С вообще не интересно, можно оставить 1 процессор и будет работать так же. Тупняки были решены путём установки интела из "голд" серии, с рабочей частотой >3ГГц. На самом деле, на i5 10й серии будет быстрее работать 1Ска под ваши потребности. Тест гилёва покажет кратное преимущество.
3) переиндексация и всё остальное для БД, как показывает мой опыт, делается долго только первый раз. И эффекта нет никакого.
В целом - проблему тупняков простым вливанием денег в железо не смог победить. Мы пробовали разные версии БД, пробовал postgresql, линукс/винда - работает одинаково безобразно, видимо где то внутри движка проблемы. На этом моя история закончена.

Comments

[NNS]

Спасибо, я в части частоты ЦП понимаю это, читал много где, тут согласен.
С фирмой 1С всё понятно), мне не ясно почему сам sql, не хочет пользоваться ресурсами сервера, так изобильно ему представленными и в мониторинге производительности тишина. Хотя все рецепты в интернете о том, как снизить это самое потребление).

[Михаил Е]

Константин если честно сомнительные утверждения, а именно :
"2.количество процессов для 1С вообще не интересно" - если пользователей до 20 тогда думаю да ... если вы на одном процессе будете считать себестоимость/взаиморасчеты, и на этом же процессе будут пользователи, вы увидите серьёзные просадки. Разнесение тяжелых операций и пользователей по разным процессам решает эту проблему (именно поэтому 1С в последних версиях платформы вывела опцию "Количество сеансов на процесс" в Enterprise версию сервера, который стоит дорого.)
"3) переиндексация ... эффекта нет никакого." - серьёзно?
- При неактуальной статистике будут некорректные и неоптимальные планы на MSSQL ... это может увеличивать время выполнения запроса в разы.
- При фрагментации индекса более 70% - будут table/index scan вместо index seek это тоже будет медленней в разы.

[VitalyChaikin]

Чтобы улучшить отклик нужно еще проанализировать саму Конфигурацию в которой работают юзеры. Потому что сервер может быть замечательный, а все лаги генерируются конфой. (ЕРП наверное ?)
Еще один из лайфхаков для SQL разделить файл базы данных на несколько штук;

[NNS]

VitalyChaikin, бухгалтерия, зарплата, документооборот. Но когда лагает, лагает всё, а когда не лагает, не лагает ничего). Даже база запускается долго (до ввода пароля и после ввода), причем на этом самом сервере.

[VitalyChaikin]

NNS, В кластере - один сервер ?! Еще могут влиять настройки кластера !

[NNS]

VitalyChaikin, В кластере 1 сервер, там всё по умолчанию

Answer 4

[VirDim]

Для начала установить max DOP (степень параллелизма) равным 1. Для 1С всегда рекомендуется устанавливать равным 1 в обычной работе. Подробности тут https://its.1c.ru/db/metod8dev/content/5945/hdoc (нужна учетная запись итс). Скорее всего после этого тормоза у пользователей пропадут. Конфигурация у вас какая-то типовая или самописная?

Comments

[NNS]

Я это читал, но там же они пишут что иногда можно/нужно... При этом я специально смотрел в планах обслуживания он вроде как не используется.
Конфигурации типовые с доработками, есть и полностью 100% на поддержке, но если лагают, то все одновременно и типовые и с дописками.

[VirDim]

Я это читал, но там же они пишут что иногда можно/нужно...

В вашем случае не нужно

При этом я специально смотрел в планах обслуживания он вроде как не используется

Не понимаю причем здесь планы обсуживания. Если у вас полностью типовые конфигурации в которых не очень много данных и индексы периодически реорганизуются, проблем с зависаними быть не должно.

Кстати, не совсем понял что у вас за рейды, 4 по 4 диска? То есть на систему рейд 1 из 4, на базы рейд 1 из 4 дисков итд? Проверяри производительность дисковой подсистемы на рейде? А то как-то был у меня случай, сисадмин собрал рейд 1 криво и скорость была меньше чем у одного диска. После пересборки всё стало быстро.

[NNS]

VirDim, там всего 8 корзин, и собрано 4x Radid 1.
2 диска Raid1 под систему
2 диска Raid1 под базы основные
2 диска Raid1 под базы дополнительный
2 диска Raid1 под виртуальные машины

В целом с дисковой системой порядок вроде

[VirDim]

NNS, Понятно. Вам помогла установка dop = 1?

[NNS]

По рекомендации Вячеслава на время выполнения плана обслуживания поставил значение 4. Время выполнения близится к суткам. После этого опять поставлю 1 и буду смотреть. Либо как сказано выше буду на ночь ставить 4, а утром 1. Только при условии если удастся добиться срока выполнения 8 ночных часов.

[Andrey Lutsenko]

NNS, как последние эксперименты с DOP?

Answer 5

[darst]

1с по факту не особо грузит процессор главное для нее это память и скорость дисков. Есть вариант, что sql не хватает памяти поэтому он периодически скидывает её в swap. Как вариант увеличь максимальный объем для sql.

Comments

[NNS]

Возможно вы правы, есть такие подозрения.