Производительность в 1С, как же понять что тормозит в 1с её работу и что улучшить?
Здравствуйте! Проблема заключается вот в чём:
Имеется сервер с Windows Server 2008R2.
Intel® Xeon® CPU E5620 @ 2.40GHz 2 процессора по 8 ядер
ASUSTeK Computer INC. : Z8NA-D6©
Оперативная память: 49ГБ частота памяти 1*333
ЖД: INTEL SSDSC2BX800G4
SQL 2008, шарид мемори включён, в плане электропитания выбран режим наивысшей производительности.
Однако Тест Гилёва показывает не более 17 попугаев(При запуске на сервере). В чём же проблема? Куда копать?
Только что провёл тест на файловой базе данных, и он показал 44,64.
Заранее спасибо!
Имеется сервер с Windows Server 2008R2.
Intel® Xeon® CPU E5620 @ 2.40GHz 2 процессора по 8 ядер
ASUSTeK Computer INC. : Z8NA-D6©
Оперативная память: 49ГБ частота памяти 1*333
ЖД: INTEL SSDSC2BX800G4
SQL 2008, шарид мемори включён, в плане электропитания выбран режим наивысшей производительности.
Однако Тест Гилёва показывает не более 17 попугаев(При запуске на сервере). В чём же проблема? Куда копать?
Только что провёл тест на файловой базе данных, и он показал 44,64.
Заранее спасибо!
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
файловый тест и клиент-серверный не корректно сравнивать
приходите на наш тренинг по подбору оборудованию, больше нигде подобного полного освещения темы вы не найдете
E5620
процессор для неудачников, низкая частота, прежде всего проблема в процессоре, процессор это 50% всей производительности, к тому же максимум из него по дефолту не выжат, это надо настраивать в биос и ос ,
файловый тест и клиент-серверный не корректно сравнивать
приходите на наш тренинг по подбору оборудованию, больше нигде подобного полного освещения темы вы не найдете
(1)
Как много "букаф"...
Скажу одно. В свое время тоже голову с попугаями ломал. А вопрос решился просто заменой массива хардов.
И первые и вторые - абсолютно новые. Но на сигейтах тормозил, а на рапторах взлетел с 17 до 60.
Так что не торопитесь говорить, что дело не в железе.
Тут тоже вопросв много - какая память, какой хард, может тупо камень печкой прикинулся)))
Как много "букаф"...
Скажу одно. В свое время тоже голову с попугаями ломал. А вопрос решился просто заменой массива хардов.
И первые и вторые - абсолютно новые. Но на сигейтах тормозил, а на рапторах взлетел с 17 до 60.
Так что не торопитесь говорить, что дело не в железе.
Тут тоже вопросв много - какая память, какой хард, может тупо камень печкой прикинулся)))
сори. сразу не обратил внимание. но "копать" нужно в данном направлении, замедляет 1С только обмен с диском.
ищете в сети и качаете книгу "эксперт 1с по технологическим вопросам".
там во втором разделе как раз описано что Вам нужно сделать - настройки счетчиков производительности в винде и настройка технологического журнала.
там во втором разделе как раз описано что Вам нужно сделать - настройки счетчиков производительности в винде и настройка технологического журнала.
специально запустил у себя: Однопоточный синтетический тест платформы 1С:Предприятие + Многопоточный тест записи на диск (2.1.0.7)
Гилёв Вячеслав Валерьевич
(gilev.ru/1c/tpc)
тест показал 63,29, махнусь неглядя на сервак.
Гилёв Вячеслав Валерьевич
(gilev.ru/1c/tpc)
тест показал 63,29, махнусь неглядя на сервак.
Прикрепленные файлы:
так, что ищите проблемы. может ненаглядный Каспер стоит или обновление в этот момент шло. в общем диск был занят другими приложениями.
(10)
SSD - используется в качестве диска С , так что скорее всего да, но где это можно посмотреть ? Я бы проверил.
(11)
Серверу выделено 30ГБ оперативной памяти, ядер на SQL выделено 16 (каждый процессор по 8)
SSD - используется в качестве диска С , так что скорее всего да, но где это можно посмотреть ? Я бы проверил.
(11)
l создает базу в режиме full и приходится затем каждую базу созданную автоматически, перенастраивать
Серверу выделено 30ГБ оперативной памяти, ядер на SQL выделено 16 (каждый процессор по 8)
Возможно причина в настройках SQL:
имхо база в режиме simple быстрее работает чем база в режиме full
Но по умолчанию sql создает базу в режиме full и приходится затем каждую базу созданную автоматически, перенастраивать вручную.
затем сколько памяти отведено на sql сервер, сколько ядер и т.п.
имхо база в режиме simple быстрее работает чем база в режиме full
Но по умолчанию sql создает базу в режиме full и приходится затем каждую базу созданную автоматически, перенастраивать вручную.
затем сколько памяти отведено на sql сервер, сколько ядер и т.п.
tempdb лучше на отдельном шустром диске
поковыряйтесь в параметрах базы автообновление статистики , автосжатие лучше убрать, авторасширение в зависимости от скорости изменений > 1 мб (по умолчанию)
поковыряйтесь в параметрах базы автообновление статистики , автосжатие лучше убрать, авторасширение в зависимости от скорости изменений > 1 мб (по умолчанию)
1.44 попугая в файловой базе на 2,4GHz - это нормально (на 3,2 - 65 => 3,2/2,4 * 65 = 48). Зависимость файловой базы от частоты процессора практически линейная (на одной архитектуре вообще линейная).
2. 17 попугаев на серверной базе - это почти хорошо, т.к. в самом лучшем случае клиент-серверная база с одним пользователем работает в 2 раза медленнее. У Вас в 2,6 почти раз медленнее, что говорит о наличии некоторых проблем.
3. Основные проблемы для одного потока, в котором нет никакой конкуренции за ресурсы, - это передача данных от сервера 1С серверу SQL и обратно, время записи данных на диск (как со стороны 1С - лог, так и со стороны SQL - файл базы данных, лог базы данных, файлы временных таблиц). Чтение с диска в однопоточном тесте Гилева, полагаю, вообще не производится, т.к. памяти хватает и вся база закеширована.
Отсюда простые рекомендации:
1. Включите boost. Он позволит одному потоку достигать большей частоты и увеличит цифры теста как для файловой, так и для серверной части. Но для Вашего процессора тут все печально - 2,66GHz всего. Проц еще 32nm, 10-го года начала выпуска. Проц, собственно, - это тут самое узкое место, полагаю.
2. Разнесите логи и данные SQL на разные физические диски. Но если у Вас SSD, то это особо не поможет.
3. Разделите tenpdb на несколько частей (добавьте файлы в системную таблицу tempdb). Поместите их на отдельный диск (или вообще в RAM).
4. Но, полагаю, что-то выжать из этой железяги будет непросто.
2. 17 попугаев на серверной базе - это почти хорошо, т.к. в самом лучшем случае клиент-серверная база с одним пользователем работает в 2 раза медленнее. У Вас в 2,6 почти раз медленнее, что говорит о наличии некоторых проблем.
3. Основные проблемы для одного потока, в котором нет никакой конкуренции за ресурсы, - это передача данных от сервера 1С серверу SQL и обратно, время записи данных на диск (как со стороны 1С - лог, так и со стороны SQL - файл базы данных, лог базы данных, файлы временных таблиц). Чтение с диска в однопоточном тесте Гилева, полагаю, вообще не производится, т.к. памяти хватает и вся база закеширована.
Отсюда простые рекомендации:
1. Включите boost. Он позволит одному потоку достигать большей частоты и увеличит цифры теста как для файловой, так и для серверной части. Но для Вашего процессора тут все печально - 2,66GHz всего. Проц еще 32nm, 10-го года начала выпуска. Проц, собственно, - это тут самое узкое место, полагаю.
2. Разнесите логи и данные SQL на разные физические диски. Но если у Вас SSD, то это особо не поможет.
3. Разделите tenpdb на несколько частей (добавьте файлы в системную таблицу tempdb). Поместите их на отдельный диск (или вообще в RAM).
4. Но, полагаю, что-то выжать из этой железяги будет непросто.
(16)
Спасибо! Похоже, что вы правы!
(17)
Тормоза при проведении заказа клиента на УТ11 ( На проведение уходит почти 10 сек иногда, а иногда и за 3-4 проводится.)
Спасибо! Похоже, что вы правы!
(17)
ла надо посмотреть планы выполнения запросов, настройки SQL сервера, адекватность индексов и кеша.
Системные метрики по памяти, дисковым очередям и прочее..
Системные метрики по памяти, дисковым очередям и прочее..
Тормоза при проведении заказа клиента на УТ11 ( На проведение уходит почти 10 сек иногда, а иногда и за 3-4 проводится.)
(16)
Чтение с диска в однопоточном тесте Гилева, полагаю, вообще не производится, т.к. памяти хватает и вся база закеширована.
второй тест, идущий следом тестирует диск в многопоточном режиме на максимуме загрузки, тест написан с учетом пробивания кэша контроллера дисков
(24)
второй тест, идущий следом тестирует диск в многопоточном режиме на максимуме загрузки, тест написан с учетом пробивания кэша контроллера дисков
С этим я не спорю. Просто те самые "попугаи" - это, в общем-то, первый тест, который однопоточный.
(25) искажаете,
есть операции типа открытия элементов интерфейса, которые коррелируют с тестом и есть операции, которые работают фоном, пользователь их не видит, но они например делают закачку данных многопоточно из другой системы - разные тесты для разных операций
есть операции типа открытия элементов интерфейса, которые коррелируют с тестом и есть операции, которые работают фоном, пользователь их не видит, но они например делают закачку данных многопоточно из другой системы - разные тесты для разных операций
А в чем собственно проблемы? - оценка в гилевских попугаях не имеет никакого отношения к реальной работе.
Почему собственно задумались об повышении производительности железа ?
На каких то операция пользователям некомфортно... или вылазят блокировки?
Может для начала надо посмотреть планы выполнения запросов, настройки SQL сервера, адекватность индексов и кеша.
Системные метрики по памяти, дисковым очередям и прочее..
Посмотреть на учет - может не закрываются в 0 остатки регистров накопления/бух итогов - то, что накопилось с течением времени и вызывает деградацию производительности системы.
Сравнение однопоточного файлового и многопоточного серверного вариантов не имеет практического смысла.
Сервер 1с на виртуалке с е5-2699 2.2Г и 32Гб памяти, база на данный момент 800 гиг с приростом 20-30 гиг в месяц
Сервер SQL на таком же проце с 64Гб
- нет никаких проблем с производительностью за последние пол года точно.
Почему собственно задумались об повышении производительности железа ?
На каких то операция пользователям некомфортно... или вылазят блокировки?
Может для начала надо посмотреть планы выполнения запросов, настройки SQL сервера, адекватность индексов и кеша.
Системные метрики по памяти, дисковым очередям и прочее..
Посмотреть на учет - может не закрываются в 0 остатки регистров накопления/бух итогов - то, что накопилось с течением времени и вызывает деградацию производительности системы.
Сравнение однопоточного файлового и многопоточного серверного вариантов не имеет практического смысла.
Сервер 1с на виртуалке с е5-2699 2.2Г и 32Гб памяти, база на данный момент 800 гиг с приростом 20-30 гиг в месяц
Сервер SQL на таком же проце с 64Гб
- нет никаких проблем с производительностью за последние пол года точно.
(27)
Да, дело не железе, а в одном проблемном документе - заказе.
Нормально спроектированная и отлаженная система на том же самом оборудовании при увеличении объема данных не будет деградировать.
И смысл сразу валить на железо на основании попугаемеров нет.
у вас другой и явно более быстрый процессор, но при этом вы человеку говорите что дело не в железе
Да, дело не железе, а в одном проблемном документе - заказе.
Тормоза при проведении заказа клиента на УТ11 ( На проведение уходит почти 10 сек иногда, а иногда и за 3-4 проводится.)
так что нужно смотреть на реальных данных что в эти моменты происходит.
Нормально спроектированная и отлаженная система на том же самом оборудовании при увеличении объема данных не будет деградировать.
И смысл сразу валить на железо на основании попугаемеров нет.
(33) если проблема массовая, носит общий характер, то проблема с высокой вероятностью связана и с железом в том числе
если есть отдельная операция, которая написана программистом с ущербной днк ))), то дело в таком случае и в железе и в коде
то что плохой код это ни как не характеризует железо,
и основание валить в том числе на железо на основе теста есть и еще какое
ускорять можно и кодом и железом
если есть отдельная операция, которая написана программистом с ущербной днк ))), то дело в таком случае и в железе и в коде
то что плохой код это ни как не характеризует железо,
и основание валить в том числе на железо на основе теста есть и еще какое
ускорять можно и кодом и железом
(35)
Вполне возможно, что проблема в железе, но:
Тест разве проводит низкоуровневые проверки? - он оперирует общей производительностью системы, которая складывается и из программных факторов, таких как настройка ОС, СУБД, конфигурации.
Т.е. три четверти теста зависит от программных настроек, причем больший вклад дают конфигурация и СУБД.
И на что тогда надо обратить первым внимание? на железо?
PS: Железо уже в наличии. оно есть и мгновенно не меняется. Самое простое что можно "быстро" с ним сделать - это добавить оперативки. А проще всего проверить в первую очередь конфигурацию и настройки СУБД - это займет меньше времени и средств.
PSS: По собственному опыту:
Удаление лишнего условия при соединении в запросе позволило увеличить производительность этого запроса на порядки.
Установка правильно порядка измерений в регистрах - еще прирост производительности (селективные индексы).
Перенос одного из условий отбора вирт таблицы регистра в секцию "ГДЕ" - тоже прирост выполнения в 3-4 раза.
Организация учета, что бы закрывались в 0 таблицы остатков (устранение "пересортов" по вроде бы неважным измерения) - еще плюс..
В большинстве случаев надо не сверх-быстро - а стабильно, т.е. одинаковое время на операции с увеличеним данных вне зависимости от их объемов как в месяц так и проводок в секунду. И тут железо стоит на последнем месте.
Если добился стабильности - тогда можно переходить на новое железо - эффект будет заметен.
то проблема с высокой вероятностью связана и с железом в том числе
Вполне возможно, что проблема в железе, но:
Тест разве проводит низкоуровневые проверки? - он оперирует общей производительностью системы, которая складывается и из программных факторов, таких как настройка ОС, СУБД, конфигурации.
Т.е. три четверти теста зависит от программных настроек, причем больший вклад дают конфигурация и СУБД.
И на что тогда надо обратить первым внимание? на железо?
PS: Железо уже в наличии. оно есть и мгновенно не меняется. Самое простое что можно "быстро" с ним сделать - это добавить оперативки. А проще всего проверить в первую очередь конфигурацию и настройки СУБД - это займет меньше времени и средств.
PSS: По собственному опыту:
Удаление лишнего условия при соединении в запросе позволило увеличить производительность этого запроса на порядки.
Установка правильно порядка измерений в регистрах - еще прирост производительности (селективные индексы).
Перенос одного из условий отбора вирт таблицы регистра в секцию "ГДЕ" - тоже прирост выполнения в 3-4 раза.
Организация учета, что бы закрывались в 0 таблицы остатков (устранение "пересортов" по вроде бы неважным измерения) - еще плюс..
В большинстве случаев надо не сверх-быстро - а стабильно, т.е. одинаковое время на операции с увеличеним данных вне зависимости от их объемов как в месяц так и проводок в секунду. И тут железо стоит на последнем месте.
Если добился стабильности - тогда можно переходить на новое железо - эффект будет заметен.
(36) E5620 не сочетается с
ну да, купили унылую хрень и думаете "оно есть и мгновенно не меняется"
не в теории, а на практике когда есть желание у Заказчика решать вопросы мы помогли и за день организовали новое железо, вот отзыв
и главное, это замена заметно помогла решить вопрос
как показывает практика, руководство охотней выделяет суммы как раз на апгрейд, а не колупания программиста, хотя важно со всех сторон решать задачу
причем кодом решение проблемы может происходить значительно дольше чем железом
думаю вам будете интересен
Железо уже в наличии
ну да, купили унылую хрень и думаете "оно есть и мгновенно не меняется"
не в теории, а на практике когда есть желание у Заказчика решать вопросы мы помогли и за день организовали новое железо, вот отзыв
и главное, это замена заметно помогла решить вопрос
PSS: По собственному опыту:
Удаление лишнего условия при соединении в запросе позволило увеличить производительность этого запроса на порядки.
пока запрос не оптимален, его надо оптимизировать, но если дальше оптимизация не возможна, вот тут то замена E5620 на нормальный проц скажется очень
Удаление лишнего условия при соединении в запросе позволило увеличить производительность этого запроса на порядки.
как показывает практика, руководство охотней выделяет суммы как раз на апгрейд, а не колупания программиста, хотя важно со всех сторон решать задачу
причем кодом решение проблемы может происходить значительно дольше чем железом
думаю вам будете интересен
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот