Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
вот еще пару советов: Обязательно в настройках электропитания в панели управления выставьте максимальную производительность. Отключите Dep
хм. Спасибо, странно, но это тоже упустил.
До кучи: скрипты для установки планов электропитания на максимум. Смысл, думаю, понятен:
.
Для 2012-х (включая R2) серверов:
Import-Module ActiveDirectory
$cred = Get-Credential your_domain\admin_login
$cn = Get-ADComputer -Filter "OperatingSystem -like ""* 2012 *"""
$cim = New-CimSession -ComputerName $cn.name -Credential $cred
$p = Get-CimInstance -Name root\cimv2\power -Class win32_PowerPlan `
-Filter "ElementName = ""Высокая производительность""" -CimSession $cim
Invoke-CimMethod -InputObject $p[0] -MethodName Activate -CimSession $cim
.
Для 2008 R2:
Import-Module ActiveDirectory
$cred = Get-Credential your_domain\admin_login
$cn = Get-ADComputer -Filter "OperatingSystem -like ""* 2008 *"""
$cim = New-CimSession -ComputerName $cn.name -Credential $cred
$p = Get-CimInstance -Name root\cimv2\power -Class win32_PowerPlan `
-Filter "ElementName = ""Высокая производительность""" -CimSession $cim
Invoke-CimMethod -InputObject $p[0] -MethodName Activate -CimSession $cim
Благодарю!
Не сочтите, что я придераюсь или что то еще. Просто скажите, насколько начинает быстрее работать после установки плана питания на «Высокая производительность»?
И какие конкретно пункты в настройках плана питания это обеспечивают, если вы конечно заглядывали в настройки плана питания на серверных системах, особенно виртуализованных?
И какие конкретно пункты в настройках плана питания это обеспечивают, если вы конечно заглядывали в настройки плана питания на серверных системах, особенно виртуализованных?
Прирост производительности получился около 10%. С 22-x «гилёвских попугаев» до 24,5
Изменения, вносимые переключением плана электропитания отслеживались с помощью реестра и программки PowerSchemeEd.
В подробности особо не влезал. Понятно, что для виртуальных серверов влияние символическое, но проверку сделал.
Первоначально была изменена схема питания только у гипервизоров (2012 R2), получен прирост до 24-х «попугаев».
Потом для всех участников процесса: Win 2012R2 для MS SQL 2012, двух Win 2008R2 — кластер серверов 1С, двух Win 2008R2 — члены фермы серверов терминалов. + 0,5 попугаев. Т.е. в пределах погрешности.
Для дальнейшего тестирования были взяты копии двух рабочих баз. Одна с «тонкими» клиентами — типовая бухгалтерия, вторая — УСО с толстыми клиентами. Тестировалось массовое перепроведение (обработкой) и один тяжёлый отчёт. Замерялось время выполнения. К сожалению записи замеров сейчас не найду. Остались только выводы и процентные сравнения.
Т.к. была возможность поэкспериментировать с изменениями всей связки, дополнительно получил следующие результаты и наблюдения:
MDF при работе с реальной базой небольшого размера (около 50 Гиг) практически фиолетовы наращивания IOPS. Что на перепроведении, что на отчётах. Разве что на iSCSI не стоит выносить.
Расположение TempDb и логов, наоборот очень критично. Пропускная способность сети: 1Гб/с, 10 Гб/с, физика или виртуальная сеть внутри одного гипервизора, практически НИКАК не сказывается на скорости. Потому как сервер 1С совершенно по идиотски работает с СУБД. Латентность канала наоборот весьма критична. Клиент, сервер 1с и сервер БД в случае толстого клиента или сервер 1с и сервер БД значительно быстрее работают в переделах портов одного свитча.
В опытах участвовало два сервера на двух Xeon e5 2630 v2. Гипертрединг был выключен в BIOS, т.к. выяснилось, что его включение напрочь убивает скорость работы толстого клиента 1С в терминале и сервера 1С. В разы. В отличии от MS SQL Server, который наоборот проседает при выключении гипертрединга на гипервизоре на 10-20 %.
4 SSD были подключены в RAID 10 через адаптековский контроллер, на нем же был создан ещё один массив, уже из обычных 7200-х SATA дисков, под оси, терминал и остальные потребности.
В опытах получено практически никакое влияние типа VHDX диска под базы SQL. Фиксированного он размера или динамически расширяемый. Перед тестами диски создавались с нуля.
В ходе замеров был взят на время «динозавр» на двух старых XEON E5630 и с памятью DDR2. Сервер 1С на нём выдал в «гилёвских попугаях» и в нашей схеме более 30 единиц! Видимо, сказывается древний инструмент для сборки 1С и полное отсутствие оптимизации под более новые процессоры и ОС. По причине старости и ненадёжности в рабочей схеме его не оставили. Да, на него также был поставлен Hyper-V, так что списать на виртуализацию потери скорости не получилось.
Вот вкратце о результатах и рекомендациях и именно для 1С.
Для «нормальных» систем действия будут другими.
Кстати, заодно были сделаны замеры скорости массового проведения для сравнения 8.2 и 8.3. Понятно, что в 8.3 при этом была включена опция совместимости.
8.3. оказалась на 20% медленнее, чем 8.2. Конфиг был типовой. УСО.
Так что рекомендации по оптимизации связки серверов для 1С имеют свои особенности, вызванные дикими архитектурными компромиссами этой системы вкупе с ленью разработчиков реализовывать то, что нужно пользователям, а не то, что модно и прикольно. И то, что совершенно логично работает для DocsVision, например, может дать обратный эффект для 1С.
Изменения, вносимые переключением плана электропитания отслеживались с помощью реестра и программки PowerSchemeEd.
В подробности особо не влезал. Понятно, что для виртуальных серверов влияние символическое, но проверку сделал.
Первоначально была изменена схема питания только у гипервизоров (2012 R2), получен прирост до 24-х «попугаев».
Потом для всех участников процесса: Win 2012R2 для MS SQL 2012, двух Win 2008R2 — кластер серверов 1С, двух Win 2008R2 — члены фермы серверов терминалов. + 0,5 попугаев. Т.е. в пределах погрешности.
Для дальнейшего тестирования были взяты копии двух рабочих баз. Одна с «тонкими» клиентами — типовая бухгалтерия, вторая — УСО с толстыми клиентами. Тестировалось массовое перепроведение (обработкой) и один тяжёлый отчёт. Замерялось время выполнения. К сожалению записи замеров сейчас не найду. Остались только выводы и процентные сравнения.
Т.к. была возможность поэкспериментировать с изменениями всей связки, дополнительно получил следующие результаты и наблюдения:
MDF при работе с реальной базой небольшого размера (около 50 Гиг) практически фиолетовы наращивания IOPS. Что на перепроведении, что на отчётах. Разве что на iSCSI не стоит выносить.
Расположение TempDb и логов, наоборот очень критично. Пропускная способность сети: 1Гб/с, 10 Гб/с, физика или виртуальная сеть внутри одного гипервизора, практически НИКАК не сказывается на скорости. Потому как сервер 1С совершенно по идиотски работает с СУБД. Латентность канала наоборот весьма критична. Клиент, сервер 1с и сервер БД в случае толстого клиента или сервер 1с и сервер БД значительно быстрее работают в переделах портов одного свитча.
В опытах участвовало два сервера на двух Xeon e5 2630 v2. Гипертрединг был выключен в BIOS, т.к. выяснилось, что его включение напрочь убивает скорость работы толстого клиента 1С в терминале и сервера 1С. В разы. В отличии от MS SQL Server, который наоборот проседает при выключении гипертрединга на гипервизоре на 10-20 %.
4 SSD были подключены в RAID 10 через адаптековский контроллер, на нем же был создан ещё один массив, уже из обычных 7200-х SATA дисков, под оси, терминал и остальные потребности.
В опытах получено практически никакое влияние типа VHDX диска под базы SQL. Фиксированного он размера или динамически расширяемый. Перед тестами диски создавались с нуля.
В ходе замеров был взят на время «динозавр» на двух старых XEON E5630 и с памятью DDR2. Сервер 1С на нём выдал в «гилёвских попугаях» и в нашей схеме более 30 единиц! Видимо, сказывается древний инструмент для сборки 1С и полное отсутствие оптимизации под более новые процессоры и ОС. По причине старости и ненадёжности в рабочей схеме его не оставили. Да, на него также был поставлен Hyper-V, так что списать на виртуализацию потери скорости не получилось.
Вот вкратце о результатах и рекомендациях и именно для 1С.
Для «нормальных» систем действия будут другими.
Кстати, заодно были сделаны замеры скорости массового проведения для сравнения 8.2 и 8.3. Понятно, что в 8.3 при этом была включена опция совместимости.
8.3. оказалась на 20% медленнее, чем 8.2. Конфиг был типовой. УСО.
Так что рекомендации по оптимизации связки серверов для 1С имеют свои особенности, вызванные дикими архитектурными компромиссами этой системы вкупе с ленью разработчиков реализовывать то, что нужно пользователям, а не то, что модно и прикольно. И то, что совершенно логично работает для DocsVision, например, может дать обратный эффект для 1С.
Я попытаюсь сэмулировать ситуацию и выдать свой вариант.
Я не совсем понял на какой конфигурации вы тестировали и получили 10% прирост после изменения схемы питания, но вторая попытка могла быть быстрее из-за тиринга на схд или кэширования в самой SQL, вплоть до кэширования в рэйдконтроллере. Такие виды тестирования обычно подразумевают многократный тест до изменений и многократный тест после изменения, с обязательным восстановлением в эталонное состояние до запуска каждого теста.
Мне бывший коллега и друг предложил пройти официальный курс администрирования связки 1С и SQL, и полагаю после этого я смогу написать сюда статью основываясь не только на жизненном опыте и историях траблшутинга всего и всея, но и уже имея представление о официальном взгляде разработчиков на все это.
А 30 гилевских едениц это сколько? 10-20-30-100-200-300 пользователей делающих чего и в чем?
Из моей практики в конфигурации сервера 2x Xeon E5520@2.27 (16 логических ядер всего) / 24GB DDR3
дисковой подсистемой подключенной через рэйдконтроллер HP P410 на 10к SAS винтах
2x 147 под RAID1 (ОС)
4x 300 под RAID10 (DB+TempDB)
2x 1000 под RAID1 (Log)
с установленной Windows Server 2008R2 и SQL 2008 и сервер 1С 8.2 х64 на одном серевере, обслуживала до ~110 пользователей в 16 базах размером от 200 МБ до 180 ГБ, где было несколько розниц, упп, специфичной конфигурации в виде 1С Молокозавод, ну и бух+зуп всех организаций группы компаний. Ключ сервера 1С: был подключен напрямую к серверу, пользователи все работали по сети. Рабочих процессов было увеличено до 8. Сеть через гигабитный сетевой интерфес — гигабитный свитч в серверной — гигабитный свитч в кроссовой — один из клиентских свитчей с гигабитным линком в сторону серверов и 100 мегабитными линками к клиентам.
Если шла штатная работа, то сервер справлялся, а вот включение перепроведений или массового изменения документов в любой из четырех самых больших баз тут же создавала дисковую очередь на разделе с DB и как следствие весьма ухудшала скорость работы для всех.
Поскольку все известные мне твики и оптимизации к тому моменту уже были исчерпаны, то сначала счастье наступило уже после перехода на vmware 5.0 + vnx 5500 + 2x IBM System x3850, а потом была миграция в корпоративный ЦОД.
После этого ни одной заявки в сервисдеске о просадке производительности не было.
В общем сейчас звезды сложились так, что у меня есть возможность проверить на этом сервере этот гилевотест. Времени бы.
Я не совсем понял на какой конфигурации вы тестировали и получили 10% прирост после изменения схемы питания, но вторая попытка могла быть быстрее из-за тиринга на схд или кэширования в самой SQL, вплоть до кэширования в рэйдконтроллере. Такие виды тестирования обычно подразумевают многократный тест до изменений и многократный тест после изменения, с обязательным восстановлением в эталонное состояние до запуска каждого теста.
Мне бывший коллега и друг предложил пройти официальный курс администрирования связки 1С и SQL, и полагаю после этого я смогу написать сюда статью основываясь не только на жизненном опыте и историях траблшутинга всего и всея, но и уже имея представление о официальном взгляде разработчиков на все это.
А 30 гилевских едениц это сколько? 10-20-30-100-200-300 пользователей делающих чего и в чем?
Из моей практики в конфигурации сервера 2x Xeon E5520@2.27 (16 логических ядер всего) / 24GB DDR3
дисковой подсистемой подключенной через рэйдконтроллер HP P410 на 10к SAS винтах
2x 147 под RAID1 (ОС)
4x 300 под RAID10 (DB+TempDB)
2x 1000 под RAID1 (Log)
с установленной Windows Server 2008R2 и SQL 2008 и сервер 1С 8.2 х64 на одном серевере, обслуживала до ~110 пользователей в 16 базах размером от 200 МБ до 180 ГБ, где было несколько розниц, упп, специфичной конфигурации в виде 1С Молокозавод, ну и бух+зуп всех организаций группы компаний. Ключ сервера 1С: был подключен напрямую к серверу, пользователи все работали по сети. Рабочих процессов было увеличено до 8. Сеть через гигабитный сетевой интерфес — гигабитный свитч в серверной — гигабитный свитч в кроссовой — один из клиентских свитчей с гигабитным линком в сторону серверов и 100 мегабитными линками к клиентам.
Если шла штатная работа, то сервер справлялся, а вот включение перепроведений или массового изменения документов в любой из четырех самых больших баз тут же создавала дисковую очередь на разделе с DB и как следствие весьма ухудшала скорость работы для всех.
Поскольку все известные мне твики и оптимизации к тому моменту уже были исчерпаны, то сначала счастье наступило уже после перехода на vmware 5.0 + vnx 5500 + 2x IBM System x3850, а потом была миграция в корпоративный ЦОД.
После этого ни одной заявки в сервисдеске о просадке производительности не было.
В общем сейчас звезды сложились так, что у меня есть возможность проверить на этом сервере этот гилевотест. Времени бы.
прошло 2 года… :)
добрый вечер :) можно совет?
имеется 2 физических «сервера», как лучше расположить продукты жизни-деятельности майкрософт и 1с для терминального подключения пользователей к 1с?
"1 сервер": RDP сервер + толстый клиент 1с + 1с сервер
"2 сервер": SQL сервер
или
"1 сервер": RDP сервер + толстый клиент 1с
"2 сервер": SQL сервер + 1с сервер
p.s. если нужны уточнения — уточню :)
1й — 16 гб оперативки
2й — 32 гб оперативки
добрый вечер :) можно совет?
имеется 2 физических «сервера», как лучше расположить продукты жизни-деятельности майкрософт и 1с для терминального подключения пользователей к 1с?
"1 сервер": RDP сервер + толстый клиент 1с + 1с сервер
"2 сервер": SQL сервер
или
"1 сервер": RDP сервер + толстый клиент 1с
"2 сервер": SQL сервер + 1с сервер
p.s. если нужны уточнения — уточню :)
1й — 16 гб оперативки
2й — 32 гб оперативки
2й
мне тоже нравится, но меня просто смутил гипертрейдинг:
Гипертрединг был выключен в BIOS, т.к. выяснилось, что его включение напрочь убивает скорость работы толстого клиента 1С в терминале и сервера 1С. В разы. В отличии от MS SQL Server, который наоборот проседает при выключении гипертрединга на гипервизоре на 10-20 %.
Позвольте вставлю свой коммент чуть выше и опишу итоги своих изысканий. Надеюсь будет полезно.
Как правильно настроить SQL можно прочитать здесь
По поводу остального:
1) Отключаем энергосбережение серверов везде где только возможно. В панели управления Windows, в BIOS-е сервера…
2) На данный момент самая быстрая связка из актуальных еще продуктов это Server 2008R2+SQL 2008R2 на одном сервере работающие через общую память. (Shared memory) (Продукты Server 2012(R2) и SQL 2012 работают медленнее)
3) Скорость RAM не менее 1333 Mhz, объем должен превосходить в 1.5 раза размер базы. Нужно учесть потребность в памяти для процессов 1с (по 1.5 ГБ на процесс, 2Гб для системы + все остальное для SQL)
4) CPU… К нему отношение особое, быстрее всего почему-то работает на десктопных процессорах, а именно на разогнанном до 4Ghz Core i7, на сервере лучше использовать 3.2-3.5Ghz процессоры.
5) HDD в 10-й рейд + в качестве кеша к рейду 1-2 SSD диска. (технология MaxCache от Adaptec)
Как правильно настроить SQL можно прочитать здесь
По поводу остального:
1) Отключаем энергосбережение серверов везде где только возможно. В панели управления Windows, в BIOS-е сервера…
2) На данный момент самая быстрая связка из актуальных еще продуктов это Server 2008R2+SQL 2008R2 на одном сервере работающие через общую память. (Shared memory) (Продукты Server 2012(R2) и SQL 2012 работают медленнее)
3) Скорость RAM не менее 1333 Mhz, объем должен превосходить в 1.5 раза размер базы. Нужно учесть потребность в памяти для процессов 1с (по 1.5 ГБ на процесс, 2Гб для системы + все остальное для SQL)
4) CPU… К нему отношение особое, быстрее всего почему-то работает на десктопных процессорах, а именно на разогнанном до 4Ghz Core i7, на сервере лучше использовать 3.2-3.5Ghz процессоры.
5) HDD в 10-й рейд + в качестве кеша к рейду 1-2 SSD диска. (технология MaxCache от Adaptec)
Сервер и результаты
и еще на практике встречал что если база лежит на зеркальном рейде то работает 1с на порядок медленнее
Собственно ради таких как ваш комментарий, я сделал данный пост. С миру по нитке.
Как мне кажется, зеркало из двух дисков будет работать медленнее самого медленного диска.
И может не ставить зеркало на базу от которой требуется производительность?
Ночного и обеденного бекапа может оказаться достаточно?
И может не ставить зеркало на базу от которой требуется производительность?
Ночного и обеденного бекапа может оказаться достаточно?
Зеркало на системного диска С сделано потому что для блейд лезвия доступно только 2 диска.
Собственно изначально этот раздел поделили еще на 2 дополнительных логических, куда и положил базу. И это было не правильно )
Работать так нельзя, хотя не менеджер ресурсов ни что-либо еще (кроме теста Гилева) не показал проблемы.
Думаю зеркало не плохое решение, если нет другого ))
Бекап в жизни админа жизненно необходим, средствами Effector Saver настроил выгрузку базы в формате 1С ночью, и SQL днем, так как для выгрузки 1С нужно чтобы не было пользователей (как я понял). Но надо проверять, плюс версия фришная (еще не купили).
Собственно изначально этот раздел поделили еще на 2 дополнительных логических, куда и положил базу. И это было не правильно )
Работать так нельзя, хотя не менеджер ресурсов ни что-либо еще (кроме теста Гилева) не показал проблемы.
Думаю зеркало не плохое решение, если нет другого ))
Бекап в жизни админа жизненно необходим, средствами Effector Saver настроил выгрузку базы в формате 1С ночью, и SQL днем, так как для выгрузки 1С нужно чтобы не было пользователей (как я понял). Но надо проверять, плюс версия фришная (еще не купили).
Попробовать Postgres не хотите?
Хочу, но не для основного места работы. Тут с лицензиями проблемы нет.
Плюс почитал, что на Linux реазилациях для грамотной работы тоже требуются лицензии (и не бесплатные), и итог может быть не таким очевидным.
Проблема как я понял в том, что база 1С как бы «объемная», и она размазывает свои данные по SQLу в плоскости, что и вызывает такие дикие проблемы по производительности.
Люди рекомендуют 1С-никам (разработчикам) написать свой сервер баз данных, для решения такой проблемы.
Плюс почитал, что на Linux реазилациях для грамотной работы тоже требуются лицензии (и не бесплатные), и итог может быть не таким очевидным.
Проблема как я понял в том, что база 1С как бы «объемная», и она размазывает свои данные по SQLу в плоскости, что и вызывает такие дикие проблемы по производительности.
Люди рекомендуют 1С-никам (разработчикам) написать свой сервер баз данных, для решения такой проблемы.
В случае линукса мы платим только за лицензии 1С (тоже немало конечно), но экономим на лицензиях на MS (SQL+Windows)
На сэкономленные деньги можно увеличить мощность железа (или добавить сервер для Postgres)
На сэкономленные деньги можно увеличить мощность железа (или добавить сервер для Postgres)
Спасибо за информацию. И поверьте, — лицензии 1С, в сравнении с SAP — копейки )
У нас корпоративно он по дефолту, но для ЗУП, там только итоговые суммы зарплат.
Изначально данный модуль брать даже не планировали, поэтому корпорейт в данном вопросе мешать не стал, так как локально местные задачи HR решать в экселях кажись все устали, а поддерживать для расчета Navision — тоже затратно.
У нас корпоративно он по дефолту, но для ЗУП, там только итоговые суммы зарплат.
Изначально данный модуль брать даже не планировали, поэтому корпорейт в данном вопросе мешать не стал, так как локально местные задачи HR решать в экселях кажись все устали, а поддерживать для расчета Navision — тоже затратно.
А еще есть смысл в специализированных решениях с обменом. Делать меняную конфигурацию-комбайн ущербное решение. Лучше уж специализированные конфигурации с обменом. Да и нормальную CRM с ERP в одном флаконе мешать все равно замучаешься. Ну и само собой разнести их физически.
Простите, но пост в стиле «я сделяль»
Доброго вам. Какой информации Вам не хватило, в данном тексте, или о чем бы вам было интересно узнать?
Вообще не указано, какое железо было до, какое стало после.
Процессор и название сервера вообще никак не отображает дисковую систему, которая собственно была главной целью, для увеличения скорости работы. Просто вкратце упомянут fibre channel, и все.
В результатах теста, не понятны результаты. На картинке я вижу что-то типа 8 — это и есть рекомендуемое количество пользователей?
Весь сыр-бор с блейд серверами и fiber channel ради 8 пользователей?
Если нет, то как тогда читать результаты?
Процессор и название сервера вообще никак не отображает дисковую систему, которая собственно была главной целью, для увеличения скорости работы. Просто вкратце упомянут fibre channel, и все.
В результатах теста, не понятны результаты. На картинке я вижу что-то типа 8 — это и есть рекомендуемое количество пользователей?
Весь сыр-бор с блейд серверами и fiber channel ради 8 пользователей?
Если нет, то как тогда читать результаты?
Спасибо Вам, добрый человек, за пояснение. Поправил статью, чтобы было больше понимания (добавил описание железа, характеристик и фото, а так же пару тестов с итогами.
По самой конфигурации:
По самой конфигурации:
Мой сервер это лезвие в блейд сервере «437507-B21 — HP BLc3000 Configure-to-order Enclosure», которое базируется на Windows Server 2012 R2 standart, и SQL 2012.
Сам блейд соединен с файловым хранилищем (СХД) и сетью посредством девайса HP WS-CBS3020-HPQ на котором читается 4 GB SAN Switch.
СХД же основано на HP StorageWorks HSV300. Называем ее EVA. В ней 8 сегментов по 6 дисков на 600 GB (всего 48 шт. Dual Port 15K Fibre Channel spare: 495808-001), соединенных по Fibre Channel.
Само лезвие имеет конфигурацию в 2а физических процессора по 4 ядра на AMD Quad-Core Opteron(tm) Processor 2354, с установленной оперативной памятью в 16 Гб (667 МГц) и 2мя жесткими дисками SAS 6G DP 10K на 300 GB (spare 507284-001) в зеркале.
Все, что я увидел в тестах, это что текущий тест изменился с 9.17 до 9.47
Снова, для тех, кто не запускает тест сам, это в каких попугаях?
Раньше у вас комфотно работало 9.17 человек, а после всех изменений уже девять с половиной («текущий тест»)?
Снова, для тех, кто не запускает тест сам, это в каких попугаях?
Раньше у вас комфотно работало 9.17 человек, а после всех изменений уже девять с половиной («текущий тест»)?
Число в 9.17 это «в Попугаях Гилева».
Рекомендованное число чуть дальше указывается, и значится как в 98 человек, что устраивает.
Рекомендованное число чуть дальше указывается, и значится как в 98 человек, что устраивает.
Так хоть чуть лучше.
Как я понял в ваших итоговых двух картинок, итог такой:
Если логи вынести на более быстрое устройство, чем базу, производительность увеличивается. Например в вашем случае — почти в два раза. Если к этому тесту еще приложить какой-нить бенчмарк самого диска (скорость чтения/записи в мб\сек), можно уже и без 1С тестов прикидывать будет.
Как я понял в ваших итоговых двух картинок, итог такой:
Если логи вынести на более быстрое устройство, чем базу, производительность увеличивается. Например в вашем случае — почти в два раза. Если к этому тесту еще приложить какой-нить бенчмарк самого диска (скорость чтения/записи в мб\сек), можно уже и без 1С тестов прикидывать будет.
Ещё из очевидного, но не упомянутого.
Вынос TempDB на отдельный диск существенно помогает ускориться в «попугаях по Гилёву»
Вынос MDF на SSD практически не даёт прироста производительности. А вот LDF — наоборот.
Вынос TempDB на отдельный диск существенно помогает ускориться в «попугаях по Гилёву»
Вынос MDF на SSD практически не даёт прироста производительности. А вот LDF — наоборот.
Подтверждаю. Мои тесты тоже показали что вынос LDF в сторону уже улучшает картину. А что еще и на SSD — вообще интересная информация.
Я поэтому сейчас смотрю на самосбор на x99 чипсете с SSD на M.2 драйве от Samsung (у них 2,4 GB/s скорость чтения-записи).
Вообще сказка должна выйти.
Найти бы еще серверный вариант такого решения…
Я поэтому сейчас смотрю на самосбор на x99 чипсете с SSD на M.2 драйве от Samsung (у них 2,4 GB/s скорость чтения-записи).
Вообще сказка должна выйти.
Найти бы еще серверный вариант такого решения…
1С крайне не рекомендует делать бекапы баз через выгрузку в dt. Если что-то с базой не так, dt может обратно и не развернуться. Бекапы нужно делать с помощью штатных средств выбранной БД. Зачем этот «Effector Saver»?
Пребываю в недоумении от вашей статьи. ИТ — наука, или шаманство?
Почему? В каких случаях? В каких случаях разницы нет? Что такое физический диск? Является ли Lun в дисковой группе физическим диском? Почему в некоторых случаях разнесение на несколько Lun даже в одной дисковой группе улучшает производительность?
Действительно?
Неужели все, что удалось узнать про Tempdb?
Сакральное знание заключается в том, что «надо все разложить на разные диски, потому что тогда утилита Гилева дает лучшие результаты»?
И все? И никакого perfmon, латентности, дисковых очередей, анализа ожидания внутри SQL базы?
Базы данных SQL по разным дискам очень важно!
Лучшем вариантом разнесения базы и лога на отдельные физические диски.
Почему? В каких случаях? В каких случаях разницы нет? Что такое физический диск? Является ли Lun в дисковой группе физическим диском? Почему в некоторых случаях разнесение на несколько Lun даже в одной дисковой группе улучшает производительность?
В самом минимальном варианте Базу можно базировать на логическом диске основного физического диска с системой, а лог выносить на отдельный диск (в комментариях дали информацию, что лучше на SSD)
Действительно?
Так же, как подметили в комментариях, имеет смысл вынести и TEMP базу самого SQL, так как 1С ее активно использует во время работы.
Неужели все, что удалось узнать про Tempdb?
Сакральное знание заключается в том, что «надо все разложить на разные диски, потому что тогда утилита Гилева дает лучшие результаты»?
И все? И никакого perfmon, латентности, дисковых очередей, анализа ожидания внутри SQL базы?
Доброго дня Вам! Буду отвечать:
ИТ — это информационные технологии. Конечно, для того чтобы для меня стало все логично в работе 1С с SQL необходим опыт (читай время) и знания (читай источники). Мой эпизодический опыт соприкосновения с 1С за 16 лет привел к тому что видите. К Шаманству.
Вопрос хорошо это или плохо?
Для более расширенного ответа рекомендую пройти на gilev.ru — все таки это их стезя, там они лучше на это отвечают. И да, под физическим диском я имею в виду Lun в дисковой группе. И лучший результат давало, когда только LDF файл на Lun. Мне удобнее чтобы и база была на СХД, так как есть разделение труда, и за блейд и СХД отвечают другие человек. Я говорю — мне надо столько-то разделов такого объема, он мне из выделяет и подключает.
Мой личный вывод. Можете привести свои доводы. В случае ограниченности ресурсов — не самое плохое решение.
Наверно стоит сообщить что опыт работы с SQL у меня минимален, не было необходимости. Ставь под различные системы, прописывать пользователей — это одно (например по Primavera, или OpenWells или еще что). Заниматься оптимизацией — другое. Навык не прокачан, собираюсь ликвидировать это в текущем году. Можете рекомендовать где и как (можно и чем).
За данное сакральное знание, не знающие люди (а вернее компании) платят большие деньги, и не всегда получают. Порядок цен от 10'000 до 100'000 $ и более. Та же услуга по оптимизации у Гилева начинается от 140'000 рублей.
И да, все остальное тоже делалось, но там настолько все объемно, и не очевидно, что пока не вносил в статью.
Думаю провести контрольные замеры, так как начиналось все перед новым годом, а активная эксплуатация системы на конец января — март этого года. Может зря я панику навожу, и текущей производительности для работы с головой хватит.
Пребываю в недоумении от вашей статьи. ИТ — наука, или шаманство?
ИТ — это информационные технологии. Конечно, для того чтобы для меня стало все логично в работе 1С с SQL необходим опыт (читай время) и знания (читай источники). Мой эпизодический опыт соприкосновения с 1С за 16 лет привел к тому что видите. К Шаманству.
Вопрос хорошо это или плохо?
Базы данных SQL по разным дискам очень важно!
Лучшем вариантом разнесения базы и лога на отдельные физические диски.
Почему? В каких случаях? В каких случаях разницы нет? Что такое физический диск? Является ли Lun в дисковой группе физическим диском? Почему в некоторых случаях разнесение на несколько Lun даже в одной дисковой группе улучшает производительность?
Для более расширенного ответа рекомендую пройти на gilev.ru — все таки это их стезя, там они лучше на это отвечают. И да, под физическим диском я имею в виду Lun в дисковой группе. И лучший результат давало, когда только LDF файл на Lun. Мне удобнее чтобы и база была на СХД, так как есть разделение труда, и за блейд и СХД отвечают другие человек. Я говорю — мне надо столько-то разделов такого объема, он мне из выделяет и подключает.
В самом минимальном варианте Базу можно базировать на логическом диске основного физического диска с системой, а лог выносить на отдельный диск (в комментариях дали информацию, что лучше на SSD)
Действительно?
Мой личный вывод. Можете привести свои доводы. В случае ограниченности ресурсов — не самое плохое решение.
Так же, как подметили в комментариях, имеет смысл вынести и TEMP базу самого SQL, так как 1С ее активно использует во время работы.
Неужели все, что удалось узнать про Tempdb?
Наверно стоит сообщить что опыт работы с SQL у меня минимален, не было необходимости. Ставь под различные системы, прописывать пользователей — это одно (например по Primavera, или OpenWells или еще что). Заниматься оптимизацией — другое. Навык не прокачан, собираюсь ликвидировать это в текущем году. Можете рекомендовать где и как (можно и чем).
Сакральное знание заключается в том, что «надо все разложить на разные диски, потому что тогда утилита Гилева дает лучшие результаты»?
И все? И никакого perfmon, латентности, дисковых очередей, анализа ожидания внутри SQL базы?
За данное сакральное знание, не знающие люди (а вернее компании) платят большие деньги, и не всегда получают. Порядок цен от 10'000 до 100'000 $ и более. Та же услуга по оптимизации у Гилева начинается от 140'000 рублей.
И да, все остальное тоже делалось, но там настолько все объемно, и не очевидно, что пока не вносил в статью.
Думаю провести контрольные замеры, так как начиналось все перед новым годом, а активная эксплуатация системы на конец января — март этого года. Может зря я панику навожу, и текущей производительности для работы с головой хватит.
Покачайте ваш навык на http://www.sqlskills.com
Можно сходу помедитировать на
http://www.sqlskills.com/blogs/paul/are-io-latencies-killing-your-performance/
http://www.sqlskills.com/blogs/kimberly/8-steps-to-better-transaction-log-throughput/
http://www.sqlskills.com/blogs/paul/how-to-examine-io-subsystem-latencies-from-within-sql-server/
http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-always-have-one-data-file-per-processor-core/
http://www.sqlskills.com/blogs/paul/correctly-adding-data-files-tempdb/
Запустите Perfmon, оцените число обращений к диску. Сопоставьте его с теоритической максимальной производительностью дисковой группы.
Подумайте о http://support.qlogic.com/SupportCenter/articles/Question_Answers/2718
Уверен, после этого вы более точно сможете оценить как вам расположить файлы, в каких дисковых группах и с каким типом RAID.
Можно сходу помедитировать на
http://www.sqlskills.com/blogs/paul/are-io-latencies-killing-your-performance/
http://www.sqlskills.com/blogs/kimberly/8-steps-to-better-transaction-log-throughput/
http://www.sqlskills.com/blogs/paul/how-to-examine-io-subsystem-latencies-from-within-sql-server/
http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-always-have-one-data-file-per-processor-core/
http://www.sqlskills.com/blogs/paul/correctly-adding-data-files-tempdb/
Запустите Perfmon, оцените число обращений к диску. Сопоставьте его с теоритической максимальной производительностью дисковой группы.
Подумайте о http://support.qlogic.com/SupportCenter/articles/Question_Answers/2718
Уверен, после этого вы более точно сможете оценить как вам расположить файлы, в каких дисковых группах и с каким типом RAID.
| Windows Server 2012 R2 standart
Windows Server 2012 R2 standard, на английском D на конце.
С тестом Гилёва не знаком, но уверен что он меряет сферических коней в квадратном вакууме. Расчитать нагрузку когда бухгалтерия запускает квартальное перепроведение документов, выгрузку алкогольной декларации и в это же время операторы с магазинов фигачат приход с магазинов, а руководство генерит отчеты с весьма широкими фильтрами этот тест не сможет.
Столь подробное перечисление характеристик бесполезно для понимания производительности.
Отсутствие системы виртуализации — плохо.
Отсутствие ssd на схд, и как следствие отсутствие фасткэша и тиринга для производительности баз — плохо.
База 1С в файловом варианте, даже на ssd при 10+ пользователей это плохо. Если еще и по сети — ужасно.
База 1С на простом компе это плохо.
Раскидывание ос/tempdb/mdb/ldf на разные физические диски это очевидность ровно до момента пока вы не становитесь взрослыми и обзаводитесь нормальной СХД и перестаете обращать внимание на эту мелочь.
Выгрузка в .dt нужна раз в пару недель, ровно для того что бы понять, что структура базы не повреждена. Не выгрузился .dt — ищи в базе битые таблицы. Бэкап делается средствами СУБД.
Больше всего иопсов нужно отдавать разделу, где лежит mdb
Если у вас часто растет tempdb и грузит систему — бейте 1Сников за экскрементокод, они пищут слишком сложные запросы, которые скуль вынужден разбивать на порции более простых.
ldf можно положить просто на обычный диск, поскольку запись в него последовательна в 90% случаев. В моменты перепроведения документов всегда захлебывается именно том с данными, а не логами.
Обслуживайте базу — делайте транк и шринк баз, делайте перестройку индексации. Курите статьи нормальных DBA / DB Developer — вроде этой
на скульном серваке в свойствах скуля выставите объем проглатываемой им памяти на 3-4 гигабайта меньше чем полный объем памяти на сервере, в идеале 700-900 мегов должно быть свободно даже когда в базе адская нагрузка.
если переводить режим логов в simple — убедитесь что база бэкапится чаще раза в день.
На сервере баз данных кроме баз данных ничего не должно быть. Сервер кластера 1С лучше держать на отдельном сервере при большом количестве пользователей, 40+.
8.3 работает быстрее 8.2 by design.
настройте сервер кластера 1С
продакшн сервер где работают пользователи и тестовый сервер для 1Сников и сотрудников бухгалтерии устраивающих тестовые перепроведения больших периодов — это разные сервера и датасторы.
сеть в треугольнике терминльник-сервер1с-серверБД должна быть гигабитной, в идеале виртуальной и 10и гигабитной.
100 пользователей в 1С с своих ПК хуже чем 100 пользователей с терминальника. потому что thin режим клиента нагружает сервер 1С гораздо больше чем thick.
не доверяйте автовыбору скорости подключения у клиента 1С, ставьте принудительно.
управляйте базами 1С сразу, потом можете не успеть
помните что программная лицензия на сервер кластера позволяет увеличивать ресурсы сервера 1С, но не позволяет их уменьшать
не теряйте листочек с пинкодами от программных лицензий.
ключ кластера 1С должен быть аппаратным, серьезно! да он дороже, да ощутимо, но простаивающая 1Ска потом выйдет вашей организации куда затратнее. а еще он не зависит от падения ОС и железа.
зыю
статью можно считать законченной :)
карма в жопе, ссылки по быстрому:
https://helpf.pro/faq/view/1502.html
http://habrahabr.ru/post/250287/
http://habrahabr.ru/post/273633/
Windows Server 2012 R2 standard, на английском D на конце.
С тестом Гилёва не знаком, но уверен что он меряет сферических коней в квадратном вакууме. Расчитать нагрузку когда бухгалтерия запускает квартальное перепроведение документов, выгрузку алкогольной декларации и в это же время операторы с магазинов фигачат приход с магазинов, а руководство генерит отчеты с весьма широкими фильтрами этот тест не сможет.
Столь подробное перечисление характеристик бесполезно для понимания производительности.
Отсутствие системы виртуализации — плохо.
Отсутствие ssd на схд, и как следствие отсутствие фасткэша и тиринга для производительности баз — плохо.
База 1С в файловом варианте, даже на ssd при 10+ пользователей это плохо. Если еще и по сети — ужасно.
База 1С на простом компе это плохо.
Раскидывание ос/tempdb/mdb/ldf на разные физические диски это очевидность ровно до момента пока вы не становитесь взрослыми и обзаводитесь нормальной СХД и перестаете обращать внимание на эту мелочь.
Выгрузка в .dt нужна раз в пару недель, ровно для того что бы понять, что структура базы не повреждена. Не выгрузился .dt — ищи в базе битые таблицы. Бэкап делается средствами СУБД.
Больше всего иопсов нужно отдавать разделу, где лежит mdb
Если у вас часто растет tempdb и грузит систему — бейте 1Сников за экскрементокод, они пищут слишком сложные запросы, которые скуль вынужден разбивать на порции более простых.
ldf можно положить просто на обычный диск, поскольку запись в него последовательна в 90% случаев. В моменты перепроведения документов всегда захлебывается именно том с данными, а не логами.
Обслуживайте базу — делайте транк и шринк баз, делайте перестройку индексации. Курите статьи нормальных DBA / DB Developer — вроде этой
на скульном серваке в свойствах скуля выставите объем проглатываемой им памяти на 3-4 гигабайта меньше чем полный объем памяти на сервере, в идеале 700-900 мегов должно быть свободно даже когда в базе адская нагрузка.
если переводить режим логов в simple — убедитесь что база бэкапится чаще раза в день.
На сервере баз данных кроме баз данных ничего не должно быть. Сервер кластера 1С лучше держать на отдельном сервере при большом количестве пользователей, 40+.
8.3 работает быстрее 8.2 by design.
настройте сервер кластера 1С
продакшн сервер где работают пользователи и тестовый сервер для 1Сников и сотрудников бухгалтерии устраивающих тестовые перепроведения больших периодов — это разные сервера и датасторы.
сеть в треугольнике терминльник-сервер1с-серверБД должна быть гигабитной, в идеале виртуальной и 10и гигабитной.
100 пользователей в 1С с своих ПК хуже чем 100 пользователей с терминальника. потому что thin режим клиента нагружает сервер 1С гораздо больше чем thick.
не доверяйте автовыбору скорости подключения у клиента 1С, ставьте принудительно.
управляйте базами 1С сразу, потом можете не успеть
помните что программная лицензия на сервер кластера позволяет увеличивать ресурсы сервера 1С, но не позволяет их уменьшать
не теряйте листочек с пинкодами от программных лицензий.
ключ кластера 1С должен быть аппаратным, серьезно! да он дороже, да ощутимо, но простаивающая 1Ска потом выйдет вашей организации куда затратнее. а еще он не зависит от падения ОС и железа.
зыю
статью можно считать законченной :)
карма в жопе, ссылки по быстрому:
https://helpf.pro/faq/view/1502.html
http://habrahabr.ru/post/250287/
http://habrahabr.ru/post/273633/
Вам бы спасибо сказали и карму поправили, если бы Вы написали это отдельной статьей.
Великолепно!
Хотя я читал и отличные мнения (что не надо разносить 1С и базы данных), но ваше разъяснение и подход мне больше по душе (и по аппаратному ключу, и по виртуализации. Я думаю это решаемо, когда знаешь что надо решать.
Ссылки зачитываю, спасибо
Хотя я читал и отличные мнения (что не надо разносить 1С и базы данных), но ваше разъяснение и подход мне больше по душе (и по аппаратному ключу, и по виртуализации. Я думаю это решаемо, когда знаешь что надо решать.
Ссылки зачитываю, спасибо
С тестом Гилёва не знаком, но уверен что он меряет сферических коней в квадратном вакууме«Не читал, но осуждаю». Ну-ну. Зачем тогда писать очевидно некорректные вещи? «Нормальная» нагрузка на SQL сервер и его работа в связке 1С Сервер- Сервер БД, это существенно отличающиеся сценарии использования.
«Бить 1С-ников за кривой код»А которых? Авторов движка, авторов типового конфига, или местных внедренцев за допиливания? ;-) Ни в одном из этих случаев битьё результата не даст. В чем тогда смысл совета?
8.3 работает быстрее 8.2 by design.Штоа???
Ну собственно после похожего совета коллеги, мучать 1С-программиста внедренца, который указал на проблему, решил разбираться в ней сам.
В нашем офисе вбивать данные в меняную конфигурацию УТ+CRM способ наказания провинившихся! У неё потрясающая производительность, примерно, как у Rust на убунту!
|«Не читал, но осуждаю»
Прочитал, продолжаю осуждать. Смотреть графики производительности в таскменеджере это пять баллов.
Аморфные цифры на картинках. Вместо подробностей о тестировании — вода.
По ссылке о Результатах работ:
=================
Неприятная новость
Запрошенную информацию найти не удалось. Возможно, будет полезен поиск по сайту или приведённые ниже ссылки.
=================
Но я уверен парни свой хлеб таки зарабатывают, просто потому что с дефолтной тормозной конфигурацией делают что то, из того что я перечислил выше.
| А которых?
Тех кто хаит дефолтные конфигурации иначинает их изменять. Этих бы я бил с особой жестокостью и цинизмом. Обычно это внедренцы. Свои же быстро перестают создавать себе же головняки на будущее, даже до битья не доходит.
Смысл — не быть виноватым в не компетенции 1Сников.
| Штоа???
Верю нашей сертифицированной и обученной команде разработки. А еще мне в 8.3 не нужно увеличивать количество рабочих процессов, что бы агент не падал когда, работает полторы сотни пользователей, и ВНЕЗАПНО один из руководителей решает запустить отчет не выбрав вообще никаких фильтров.
Но впрочем куда мне до всеопытных людей. Все же 1Сники знают, что за нововведение было в платформе 8.1.11, и по-любому виноваты всегда в этом админы и их обновления на венду, ведь после них всегда все падать начинает, правда я не уверен, что админы должны отключать полнотекстовую индексацию в базе. Это у них всегда сервера тормозят, даже если графики хоста и самой виртуалки не перескакивают 10% нагрузки.
Вообщем опыт опыту рознь :)
могу померяться индивидуальными размерами, если ваши порядки хотя бы превышают десяток кластеров 1С, полсотни серверов баз данных, террабайта баз, ну и конфигураций розницы, биллинга и упп разных. про бух и зуп я даже не говорю. о количестве пользователей я думаю вы догадаетесь сами, и какая обвязка вокруг всего этого.
Я всегда за конструктивную критику. У меня опыта много, я много чего могу рассказать.
Прочитал, продолжаю осуждать. Смотреть графики производительности в таскменеджере это пять баллов.
Аморфные цифры на картинках. Вместо подробностей о тестировании — вода.
По ссылке о Результатах работ:
=================
Неприятная новость
Запрошенную информацию найти не удалось. Возможно, будет полезен поиск по сайту или приведённые ниже ссылки.
=================
Но я уверен парни свой хлеб таки зарабатывают, просто потому что с дефолтной тормозной конфигурацией делают что то, из того что я перечислил выше.
| А которых?
Тех кто хаит дефолтные конфигурации иначинает их изменять. Этих бы я бил с особой жестокостью и цинизмом. Обычно это внедренцы. Свои же быстро перестают создавать себе же головняки на будущее, даже до битья не доходит.
Смысл — не быть виноватым в не компетенции 1Сников.
| Штоа???
Верю нашей сертифицированной и обученной команде разработки. А еще мне в 8.3 не нужно увеличивать количество рабочих процессов, что бы агент не падал когда, работает полторы сотни пользователей, и ВНЕЗАПНО один из руководителей решает запустить отчет не выбрав вообще никаких фильтров.
Но впрочем куда мне до всеопытных людей. Все же 1Сники знают, что за нововведение было в платформе 8.1.11, и по-любому виноваты всегда в этом админы и их обновления на венду, ведь после них всегда все падать начинает, правда я не уверен, что админы должны отключать полнотекстовую индексацию в базе. Это у них всегда сервера тормозят, даже если графики хоста и самой виртуалки не перескакивают 10% нагрузки.
Вообщем опыт опыту рознь :)
могу померяться индивидуальными размерами, если ваши порядки хотя бы превышают десяток кластеров 1С, полсотни серверов баз данных, террабайта баз, ну и конфигураций розницы, биллинга и упп разных. про бух и зуп я даже не говорю. о количестве пользователей я думаю вы догадаетесь сами, и какая обвязка вокруг всего этого.
Я всегда за конструктивную критику. У меня опыта много, я много чего могу рассказать.
добрый вечер :) можно совет?
имеется 2 физических «сервера», как лучше расположить продукты жизни-деятельности майкрософт и 1с для терминального подключения пользователей к 1с?
«1 сервер»: RDP сервер + толстый клиент 1с + 1с сервер
«2 сервер»: SQL сервер
или
«1 сервер»: RDP сервер + толстый клиент 1с
«2 сервер»: SQL сервер + 1с сервер
p.s. если нужны уточнения — уточню :)
1й — 16 гб оперативки
2й — 32 гб оперативки
имеется 2 физических «сервера», как лучше расположить продукты жизни-деятельности майкрософт и 1с для терминального подключения пользователей к 1с?
«1 сервер»: RDP сервер + толстый клиент 1с + 1с сервер
«2 сервер»: SQL сервер
или
«1 сервер»: RDP сервер + толстый клиент 1с
«2 сервер»: SQL сервер + 1с сервер
p.s. если нужны уточнения — уточню :)
1й — 16 гб оперативки
2й — 32 гб оперативки
Сорри если поздно:
«1 сервер»: RDP сервер + толстый клиент 1с
«2 сервер»: SQL сервер + 1с сервер
То есть SQL и 1C сервере — почти обязательное условие.
А вообще надо смотреть какой проц на сервере. Может оказаться что оперативы там меньше и харды менее шустрые, а работает он шустрее. ))
Делайте тесты, примерно как указано тут мной или другими
Удачи
«1 сервер»: RDP сервер + толстый клиент 1с
«2 сервер»: SQL сервер + 1с сервер
То есть SQL и 1C сервере — почти обязательное условие.
А вообще надо смотреть какой проц на сервере. Может оказаться что оперативы там меньше и харды менее шустрые, а работает он шустрее. ))
Делайте тесты, примерно как указано тут мной или другими
Удачи
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Добавление и настройка базы 1С на сервер