Оптимизация работы 1С Сервер + MSSQL на виртуалке (VMware ESXi)
Добрый день,
Помогите пожалуйста разобратся. Отчеты медлено формируются, да и всякие операции тоже не очень быстро все работает, программист 1С все сваливает на Виртуализацию а сам никакие действия по оптимизации БД не делал и не делает (регламентные задания, дефрагментацию индексов, дефрагментация и обновление статистики...) тд. Тест Гилева показывает может быть не идеальные но неплохие результаты. Хочу понять проблема в оборудовании или в бездействие 1С программиста который должен заниматься оптимизации и всем что связано с 1С. Сервер 1С 8.3.10.2375 и MSSQL 2014 находится на Госте Windows Server 2012 R2 выделен 64ГБ ОЗУ и 8 процесеров, БД весит около 50ГБ , Shared Memory - включен. В настройки Виртуальной Машины все на High (CPU, RAM, HDD). На хосте только 2 виртуальные машине, они друг другу не мешают, все остальные ВМ на другом хосте. Я с 1С никогда не имел дело, я сети администрирую и пару серверов, но хочу как-то помочь Бухгалтерии, чтобы работать было боле менее нормально, "специалист" 1С работает только удалёна, он только базу поставил и все, все оптимизации как например "Shared Memory" и другое, все я делал прочитав пару статьей. Пользователей около 15, все работает на толстом клиенте. Отчет по договорам - формируется около 20 минут, очень долго, этот отчет в excel экспортировал показывает около 10.000 строк. Помогите пожалуся разобратся в данный ситуации, спасибо.
Конфиг:
Сервер: Lenovo x3650 M5
Проц: 2x - Intel Xeon E5-2630 v4 10Cores 2.2 GHz 25MB
ОЗУ: 128ГБ
Storage: Lenovo Storwize V3700 V2 (SAS диски 10k - RAID10)
ESXI хост:
Технология вирутализации Intel VT - ВКЛЮЧЕНА
TURBO BOOST - ВКЛЮЧЕН
enable NUMA - ВКЛЮЧЕН
NUMA Node Interleaving - ОТКЛЮЧЕН
________________________________________
Power Management - High Performance (Host & Guest)
Mem.ShareScanGHz = 0
________________________________________
Print screen
Гилев тест:
CrystalDisk HDD test:
CrystalDisk HDD test v2:
Помогите пожалуйста разобратся. Отчеты медлено формируются, да и всякие операции тоже не очень быстро все работает, программист 1С все сваливает на Виртуализацию а сам никакие действия по оптимизации БД не делал и не делает (регламентные задания, дефрагментацию индексов, дефрагментация и обновление статистики...) тд. Тест Гилева показывает может быть не идеальные но неплохие результаты. Хочу понять проблема в оборудовании или в бездействие 1С программиста который должен заниматься оптимизации и всем что связано с 1С. Сервер 1С 8.3.10.2375 и MSSQL 2014 находится на Госте Windows Server 2012 R2 выделен 64ГБ ОЗУ и 8 процесеров, БД весит около 50ГБ , Shared Memory - включен. В настройки Виртуальной Машины все на High (CPU, RAM, HDD). На хосте только 2 виртуальные машине, они друг другу не мешают, все остальные ВМ на другом хосте. Я с 1С никогда не имел дело, я сети администрирую и пару серверов, но хочу как-то помочь Бухгалтерии, чтобы работать было боле менее нормально, "специалист" 1С работает только удалёна, он только базу поставил и все, все оптимизации как например "Shared Memory" и другое, все я делал прочитав пару статьей. Пользователей около 15, все работает на толстом клиенте. Отчет по договорам - формируется около 20 минут, очень долго, этот отчет в excel экспортировал показывает около 10.000 строк. Помогите пожалуся разобратся в данный ситуации, спасибо.
Конфиг:
Сервер: Lenovo x3650 M5
Проц: 2x - Intel Xeon E5-2630 v4 10Cores 2.2 GHz 25MB
ОЗУ: 128ГБ
Storage: Lenovo Storwize V3700 V2 (SAS диски 10k - RAID10)
ESXI хост:
Технология вирутализации Intel VT - ВКЛЮЧЕНА
TURBO BOOST - ВКЛЮЧЕН
enable NUMA - ВКЛЮЧЕН
NUMA Node Interleaving - ОТКЛЮЧЕН
________________________________________
Power Management - High Performance (Host & Guest)
Mem.ShareScanGHz = 0
________________________________________
Print screen
Гилев тест:
CrystalDisk HDD test:
CrystalDisk HDD test v2:
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Это нужно отчет смотреть, как он формируется и выгружается, о то может оказаться, что 20 минут - норма.
Проц: 2x - Intel Xeon E5-2630 v4 10Cores 2.2 GHz - слабоват по частоте.
формируется около 20 минут, очень долго, этот отчет в excel экспортировал показывает около 10.000 строк. Помогите пожалуся разобратся в данный ситуации, спасибо.
Это нужно отчет смотреть, как он формируется и выгружается, о то может оказаться, что 20 минут - норма.
Проц: 2x - Intel Xeon E5-2630 v4 10Cores 2.2 GHz - слабоват по частоте.
(8)Визуально просматривать код, брать запрос(-ы) и выполнять в консоли запросов.
Если "криминала" в первом приближении не будет обнаружено, то выполнить отчет с замером производительности, чтобы понять, на что тратится больше всего времени. По результатам делать выводы.
Если "криминала" в первом приближении не будет обнаружено, то выполнить отчет с замером производительности, чтобы понять, на что тратится больше всего времени. По результатам делать выводы.
(1) как говорят, оптимизировать можно тремя способами, настройкой сервера, наращиванием оборудования и оптимизацией кода.. если по первым двум всё вроде хорошо (визуально)), то надо смотреть код отчёта.
Насчёт регл. действий в sql тоже интересно, как давно и какие планы обслуживания выполнялись, возможно нужен пересчет итогов, тестирование/исправление базы и т.д.
Еще интересно посмотреть в свойства базы на sql - какой прирост в мегабайтах стоит у базы.
Насчёт регл. действий в sql тоже интересно, как давно и какие планы обслуживания выполнялись, возможно нужен пересчет итогов, тестирование/исправление базы и т.д.
Еще интересно посмотреть в свойства базы на sql - какой прирост в мегабайтах стоит у базы.
(9)
Строго говоря, обслуживание SQL-сервера и SQL-баз к обязательным компетенциям 1с-программиста также не относится.
Обычно это разруливается между одинэсниками и админами "полюбовно", с учетом конкретных раскладов на месте. Ибо и у админа и у одинэсника вполне достаточно аргументов, чтобы "стать в позу". Причем у одинэсника аргументов даже больше. Никакого "специфического для 1С" обслуживания sql-базы не требуют.
Никакие плановые обслуживания не проводется! В этом и проблема. 1С это не моя область знаний, и что-то самому делать не очень хочется, дабы не напортачить что-то.
Строго говоря, обслуживание SQL-сервера и SQL-баз к обязательным компетенциям 1с-программиста также не относится.
Обычно это разруливается между одинэсниками и админами "полюбовно", с учетом конкретных раскладов на месте. Ибо и у админа и у одинэсника вполне достаточно аргументов, чтобы "стать в позу". Причем у одинэсника аргументов даже больше. Никакого "специфического для 1С" обслуживания sql-базы не требуют.
(35) А какое отношение "дефраг" имеет отношение к ПРОГРАММИСТУ? Программист может совмещать разные компетенции и часто так и происходит. Но непосредственно к компетенции программиста никакие "дефраги" и "стандартные операции" по обслуживанию sql-баз отношения не имеют. Админ - гораздо более размытая и широкая компетенция. И включает системное обслуживание не только железа, но и ПО. Другое дело, что СУБД - довольно специфическое системное ПО. И в больших конторах этим вообще отдельные люди могут заниматься. Да, часто бывает, что если СУБД используется только для 1С, то у одинэсников может оказаться больше компетенций и бэкграунда в обслуживании СУБД, чем у админов. Тогда могут "естественным путем" договориться, что этим занимаются одинэсники. Это случается, если одинэсники сами неплохие админы, а админы загружены. Или админам проще "спихнуть" этот кусок работы и одинэсники не против. Или одинэсники консультируют админов в этом вопросе. Потому что нормальные админы всегда стремятся иметь прямой контроль и управление как всеми бэкапами в организации, так и всеми показателями производительности, так и всеми сервисными процедурами. Потому что ИТ-инфраструктура предприятия это одно целое и за ней необходим централизованный контроль и уход.
Теперь про "сваливать все на виртуализацию". Если общая производительность системы устраивает и проблема в конкретном отчете - тут уже отчет надо смотреть. Есть там потенциал по его оптимизации или нет. Это компетенции программиста 1С. Но если как вы намекали есть проблема с производительностью в целом - то что вам может ответить программист? Только то, что проблема лежит за пределами исходного кода 1С (вне его непосредственных компетенций).
Дальше уже вопрос анализа производительности и поиска узких мест в системе в целом. А это уже гораздо ближе к компетенциям админа. Естественно, одинесник неправ "сваливая все на виртуализацию". Вряд ли проблема в ней. Он просто не знает в чем проблема. И пытается отфутболить ее вам как умеет. И правильно делает. Что ему еще остается?
Теперь про "сваливать все на виртуализацию". Если общая производительность системы устраивает и проблема в конкретном отчете - тут уже отчет надо смотреть. Есть там потенциал по его оптимизации или нет. Это компетенции программиста 1С. Но если как вы намекали есть проблема с производительностью в целом - то что вам может ответить программист? Только то, что проблема лежит за пределами исходного кода 1С (вне его непосредственных компетенций).
Дальше уже вопрос анализа производительности и поиска узких мест в системе в целом. А это уже гораздо ближе к компетенциям админа. Естественно, одинесник неправ "сваливая все на виртуализацию". Вряд ли проблема в ней. Он просто не знает в чем проблема. И пытается отфутболить ее вам как умеет. И правильно делает. Что ему еще остается?
Запусти отчет локально на виртуалке, чтобы исключить сетку и пользовательские компы и собрать всю нагрузку в одно место. Если "гребется" точно также медленно - смотри на характер нагрузки. Первым делом на показатели нагрузки на дисковую подсистему.
(36)По прогресс-бару понятно, что отчет формируется с помощью цикла.
Что происходит внутри цикла - известно только разработчику этого отчета. Почему программист 1С не переделает отчет - не известно, возможно, не хочет, а возможно, что и смысла нет.
Не видя конфигурацию и внутренности отчета смысла говорить о чем-то мало.
В тесте Гилева "попугаи" адекватные железу.
Что происходит внутри цикла - известно только разработчику этого отчета. Почему программист 1С не переделает отчет - не известно, возможно, не хочет, а возможно, что и смысла нет.
Не видя конфигурацию и внутренности отчета смысла говорить о чем-то мало.
В тесте Гилева "попугаи" адекватные железу.
Судя по всему вопрос не только в одном отчете. (но если только в нем то хорошо)
А так 1сник прав быстрее оно работать и не должно. Толстый клиент, хоть и в клиент сервере но все равно не так быстр, большая база, наверняка там лет 5 минимум данных, плюс слабая частота процессора.
Ну и надо как бы пользователей посмотреть, а то их медленно может быть и не медленно а вполне себе нормально, а этот отчет формируется 1 раз в месяц и может делаться хоть 5 часов по факту.
А так 1сник прав быстрее оно работать и не должно. Толстый клиент, хоть и в клиент сервере но все равно не так быстр, большая база, наверняка там лет 5 минимум данных, плюс слабая частота процессора.
Ну и надо как бы пользователей посмотреть, а то их медленно может быть и не медленно а вполне себе нормально, а этот отчет формируется 1 раз в месяц и может делаться хоть 5 часов по факту.
Спасибо всем за отзывчивость. Сначала начну с малого (настройка плана обслуживания БД), потом посмотрим что и как. Скажите пожалуйста, реорганизация индекса когда нужно делать? Раз в неделю ?
План обслуживания ниже который я создал подойдет?
*Или лучше использовать инструкцию Transact-SQL которая сама выбирает что делать реорганизацию и перестроение:
План обслуживания ниже который я создал подойдет?
*Или лучше использовать инструкцию Transact-SQL которая сама выбирает что делать реорганизацию и перестроение:
DECLARE *SQL NVARCHAR(MAX)
DECLARE *MIN_IND_SIZE integer = 128
DECLARE *MIN_FRAGMENTATION_LEVEL integer = 10
DECLARE *CRITICAL_FRAGMENTATION_LEVEL integer = 30
DECLARE currentIndex CURSOR LOCAL READ_ONLY FORWARD_ONLY FOR
SEL ECT 'ALT ER INDEX [' + ind.name + N'] ON [' +
SCHEMA_NAME(obj.[schema_id]) + '].[' + obj.name + '] ' +
CASE WHEN stat.avg_fragmentation_in_percent > *CRITICAL_FRAGMENTATION_LEVEL
THEN 'REBUILD WITH (SORT_IN_TEMPDB = ON, ON LINE = ON)'
ELSE 'REORGANIZE'
END + ';'
FR OM (
SEL ECT stat.[object_id], stat.index_id,
avg_fragmentation_in_percent = MAX(stat.avg_fragmentation_in_percent)
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') stat
WH ERE stat.page_count > *MIN_IND_SIZE AND stat.index_id > 0
AND stat.avg_fragmentation_in_percent > *MIN_FRAGMENTATION_LEVEL
GROUP BY stat.[object_id], stat.index_id
) stat
JOIN sys.indexes ind WITH(NOLOCK) ON stat.[object_id] = ind.[object_id]
AND stat.index_id = ind.index_id
JOIN sys.objects obj WITH(NOLOCK) ON obj.[object_id] = stat.[object_id]
OPEN currentIndex
FETCH NEXT FR OM currentIndex INTO *SQL
WHILE **FETCH_STATUS = 0 BEGIN
print *sql
EXEC sys.sp_executesql *SQL
FETCH NEXT FR OM cur INTO *SQL
END
CLOSE currentIndex
DEALLOCATE currentIndex Показать
Автор!
Вам не повезло. У вас не типовая 1С:Бухгалтерия, в которой багов тоже хватает - а лютая, бешенная, самописка на "обычных" формах. "Толстый" клиент. В 2020 это что-то в районе 1С 7.7, т.е. устаревшая технология. сравните свой снимок экрана (12) с "правильным" описанием конфигурации (хоть и отраслевой конфы)
Проблема скорее всего в неоптимальном коде отчета (да и всей конфы возможно тоже).
"Ваш" программист 1с как я понял на контакт не идет. Вам надо привлечь другого, стороннего, для анализа кода отчета. Это разовая работа, недорогая, думаю уговорить бухгалтера можно (но это только если это надо им, а не вам; а то бывает плачутся-плачутся а как денег потратить 10тыс руб - так "ладно, переживем").
Как выше уже писали, для ваших потребностей железо нормальное, показатели Гилева для железа приемлемые.
Всякие там обслуживания на уровне sql - это для поддержания производительности, актуально для больших баз. Для вас это явно не причина медленной работы.
Вам не повезло. У вас не типовая 1С:Бухгалтерия, в которой багов тоже хватает - а лютая, бешенная, самописка на "обычных" формах. "Толстый" клиент. В 2020 это что-то в районе 1С 7.7, т.е. устаревшая технология. сравните свой снимок экрана (12) с "правильным" описанием конфигурации (хоть и отраслевой конфы)
Проблема скорее всего в неоптимальном коде отчета (да и всей конфы возможно тоже).
"Ваш" программист 1с как я понял на контакт не идет. Вам надо привлечь другого, стороннего, для анализа кода отчета. Это разовая работа, недорогая, думаю уговорить бухгалтера можно (но это только если это надо им, а не вам; а то бывает плачутся-плачутся а как денег потратить 10тыс руб - так "ладно, переживем").
Как выше уже писали, для ваших потребностей железо нормальное, показатели Гилева для железа приемлемые.
Всякие там обслуживания на уровне sql - это для поддержания производительности, актуально для больших баз. Для вас это явно не причина медленной работы.
(46) перечитал вводные
вообще 10.000 строк выдавать в отчет - нонсенс. И 20 минут для 10.000 строк может и не норма, но думаю допустимо.
Ни один человек не в состоянии прочитать 10.000 строк, работать с таким отчетом невозможно.
Если надо 10.000 строк - то это уже выгрузка для обмена с другим приложением, и отчет здесь не нужен, а нужна именно выгрузка в файл.
Другое дело если это все-таки отчет, тогда надо проверить его с установкой максимума отборов (продукт, филиал, агент), чтоб выдавал 10-20 строк. И вот если при выдаче в 20 строк он будет думать более пары минут - тогда уже 100% кривой код отчета.
вообще 10.000 строк выдавать в отчет - нонсенс. И 20 минут для 10.000 строк может и не норма, но думаю допустимо.
Ни один человек не в состоянии прочитать 10.000 строк, работать с таким отчетом невозможно.
Если надо 10.000 строк - то это уже выгрузка для обмена с другим приложением, и отчет здесь не нужен, а нужна именно выгрузка в файл.
Другое дело если это все-таки отчет, тогда надо проверить его с установкой максимума отборов (продукт, филиал, агент), чтоб выдавал 10-20 строк. И вот если при выдаче в 20 строк он будет думать более пары минут - тогда уже 100% кривой код отчета.
(46)
Спасибо что уделили внимание. По поводу скрина, я удалил все описание о конфиге, там программист добавил свои 3 копейки. Вот в этом и проблема, нет никого толкового привлечь, всех у кого спросил никто не знает, у нас в Кишиневе 100% есть хорошие спецы 1С, но нужно их найти, а найти не просто. Да, можно обзвонить конторы которые предоставляют такие услуги, но там Директор хочет контракт, Отдел продаж тоже хочет кушать, а сам программист 1С получает гроши. Хотелось бы найти напрямую толкового человека, чтобы сделать нормальный аудит. Вот именно что бухглатеры плачутся, иногда очень трудно достучаться до него, нужно сейчас он сделает завтра, давно бы отфудболали но нужно найти другого который тоже знал нюансы нашей сферы деятельности, круговорот...В прочем, после того как я показал тест Гилева и в целом нормальное состояние сервера, что проблема вовсе не вирутализации, наш финансовый директор еще один раз поговорил с программистом и тот уже не был таким уверенным в своём убеждение, сказал что посмотрит что может сделать.
Спасибо что уделили внимание. По поводу скрина, я удалил все описание о конфиге, там программист добавил свои 3 копейки. Вот в этом и проблема, нет никого толкового привлечь, всех у кого спросил никто не знает, у нас в Кишиневе 100% есть хорошие спецы 1С, но нужно их найти, а найти не просто. Да, можно обзвонить конторы которые предоставляют такие услуги, но там Директор хочет контракт, Отдел продаж тоже хочет кушать, а сам программист 1С получает гроши. Хотелось бы найти напрямую толкового человека, чтобы сделать нормальный аудит. Вот именно что бухглатеры плачутся, иногда очень трудно достучаться до него, нужно сейчас он сделает завтра, давно бы отфудболали но нужно найти другого который тоже знал нюансы нашей сферы деятельности, круговорот...В прочем, после того как я показал тест Гилева и в целом нормальное состояние сервера, что проблема вовсе не вирутализации, наш финансовый директор еще один раз поговорил с программистом и тот уже не был таким уверенным в своём убеждение, сказал что посмотрит что может сделать.
(48)
Отчет я для себя выгрузил в Excel, чтобы посмотреть сколько строк, в 1С я не нашел как посмотреть ) Я не дуамю что мои бухглатеры работают с таким отчетам, он наверника делается один раз в месяц, честно не знаю, только дагадки. И вовсе проблема не состоит именно в этом отчете, проста в тот день ГлавБух пришел ко мне и попросил на серваке этот отчет сформировать, вот как это было.
Отчет я для себя выгрузил в Excel, чтобы посмотреть сколько строк, в 1С я не нашел как посмотреть ) Я не дуамю что мои бухглатеры работают с таким отчетам, он наверника делается один раз в месяц, честно не знаю, только дагадки. И вовсе проблема не состоит именно в этом отчете, проста в тот день ГлавБух пришел ко мне и попросил на серваке этот отчет сформировать, вот как это было.
Автор, вы большой молодец, что пытаетесь разобраться.
Прочитал всю тему, согласен с коллегами, что без выкладки самого отчета из 1С смысла вникать нет. Если там цикл - быстрее ваш отчет не заработает, и планы обслуживания не помогут.
Прочитал всю тему, согласен с коллегами, что без выкладки самого отчета из 1С смысла вникать нет. Если там цикл - быстрее ваш отчет не заработает, и планы обслуживания не помогут.
Ребят, можете пожалуйста поделится твиками. В какие дефолтные настройки нужно покывырятся чтобы 1С сервис + SQL работал лучше.
- Например, читал что хорошо раз не знаю в сколько время перезапускать сервис 1С
- (SQL) Max degree of Parallelism должно быть 1, некоторые говорят 2 или 3 (у меня сейчас 3 а было 1)
- (SQL) Cost Thereshold for Parallelism - у меня сейчас стоит значение 500
...какие другие настройки/значения нужно измиинть?
- Например, читал что хорошо раз не знаю в сколько время перезапускать сервис 1С
- (SQL) Max degree of Parallelism должно быть 1, некоторые говорят 2 или 3 (у меня сейчас 3 а было 1)
- (SQL) Cost Thereshold for Parallelism - у меня сейчас стоит значение 500
...какие другие настройки/значения нужно измиинть?
(56) 1. Перезапускать сам сервис 1С необходимости нет, если он не глючит, а вот перезапуск процессов(rphost) как правило устанавливают с периодичностью 86400.Может и чаще - если нет каких-то длительных регламентных заданий в БД, обслуживаемых сервисом 1С.
2 и 3 - это холиварные параметры. Много копий сломано. Лично моё мнение: MDOP - не трогать вообще(0), COST-ом можно поиграться в сторону увеличения и то, если вы точно определите тот факт, что распараллеливание выполнения запроса ведет к увеличению времени, по сравнению со временем выполнения этого же запроса в один поток.
2 и 3 - это холиварные параметры. Много копий сломано. Лично моё мнение: MDOP - не трогать вообще(0), COST-ом можно поиграться в сторону увеличения и то, если вы точно определите тот факт, что распараллеливание выполнения запроса ведет к увеличению времени, по сравнению со временем выполнения этого же запроса в один поток.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот