Доброго времени суток, уважаемые.
Данная заметка является подсказкой мне, и остальным.
Данная информация пригодиться новичкам для создания и оптимизации базы 1С на сервере SQL
Когда у тебя нет опыта работы с серверной частью 1С, то при появлении такого желания и/или необходимости появляется не мало нюансов и не очевидностей.
Печально, что даже такой простой квест, как выбор сервера под 1С не гарантирует успеха, и вы можете столкнутся с его крайне медленной производительностью.
Вот на этапе выяснения, что не так, и может понадобиться понимание того в какой последовательности и что делать.
Начинаем. Не забудьте сделать бекап данных.
Мой сервер это лезвие в блейд сервере «437507-B21 — HP BLc3000 Configure-to-order Enclosure», которое базируется на Windows Server 2012 R2 standard, и 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) в зеркале.
У вас могут быть другие входящие, это не важно (сейчас).
Мы взяли Комплексную поставку УТП (в нее входит 10 клиентских лицензий, сервер (только 32 бит), и конфигурации ЗУП, УТ, Бухгалтерии, и сама УТП. Примечательно что франзайзи во всю хотели включить отдельные поставки, и лучше сразу КОРП. Анализ показал что это лишнее, и дешевле брать комплексную конфигурацию.
При подборе железа вам важно помнить, что в клиент-серверном варианте работе 1С нужно, чтобы частота работы процессора была максимальна, как и частота работы памяти (помните об этом, выбирая железо). (то есть Hyper трейдинг и всякие С1-2-3 state лучше отключить в BIOS).
Так же надо «физически» разносить файл базы (MDF) и лога (LDF) на отдельные жесткие, а не логические диски.
И если для файловой версии оптимально будет рекомендовать SSD, то тут, не все так очевидно.
Зайдите на форум Гилева, чтобы ознакомиться с «загадками», возникающими в попытке улучшить производительность 1С. Много интересного.
В моем случае коллеги админы выдели мне лезвие на блейд сервере, с 2мя физ.процессорами AMD Quad-Core Opteron(tm) Processor 2354, с 16 Гб (667 МГц). Система на 2 дисках в зеркале. Диски под базу выделялись по Fiber chanel, на HP EVA.
Сейчас ищу другую конфигурацию, но пока надо и на этом пожить.
И вот на этапе внедрения, пока ведется анализ как переносить данные из другой ERP системы, 1С программист обратил мое внимание на медленную работу, и долгое проведение документов. То есть систему еще не эксплуатируют, а она уже тормозит и помирает, а перепроведение раза в 3 медленнее, чем у человека на ноутбуке, а с этим еще и люди работать должны будут (3-4 основных, и 25-40 табельщиков).
Не порядок.
Он порекомендовал использовать тест Гилева (легко гуглится его сайт), у которого полного сервисов поддержки, и информации. Чем и воспользовался.
Тест показал что все плохо, и рекомендованное число пользователей отсутствует.
Посмотрев повнимательнее я понял что база и лог хоть на разных дисках — но логических.
И вот для исправления этого и сделал скриншоты и эту памятку на будущее себе и другим:
Итог теста. Еще все плохо, но рекомендованное число пользователей больше требуемого, что хорошо.
Так же тестировал, используя логический раздел на зеркале основного диска в лезвие и раздела на СХД EVA.
Промежуточный итог:
Разнесение Базы данных SQL по разным дискам очень важно!
В самом минимальном варианте Базу можно базировать на логическом диске основного физического диска с системой, а лог выносить на отдельный диск (в комментариях дали информацию, что лучше на SSD)
Лучшем вариантом разнесения базы и лога на отдельные физические диски.
Так же, как подметили в комментариях, имеет смысл вынести и TEMP базу самого SQL, так как 1С ее активно использует во время работы.
P.S. В процессе поиска правды система полностью клонировалась на один отдельный SSD (то есть диски с базой и логом были логические).
Не смотря на i7-4790 с 32 GB DDR3, производительность от обычного диска и работы на сервере лучше не становится.
Создание дисков на RAM диске так же показывало низкие результаты, не отличимые от работы на простых дисках.
Так же информация в помощь — Effector Saver позволяет сохранять 1с базы
Бекапить все остальное смысла мало, так как в моем случае лицензии программные и при переносе на другое железо лицензии слетают.
Из дополнительного.
Если Вам захочется дать пользователям домена безнаказанно создавать любые БД средствами 1С, то учетной записи службы сервера 1С сделать доменную учетку, имеющую право создавать базы без всяких сисадминов вполне достаточно,
при этом логин и пароль в свойствах информационной базы писать не надо…
Всех благ!
Данная заметка является подсказкой мне, и остальным.
Данная информация пригодиться новичкам для создания и оптимизации базы 1С на сервере SQL
Когда у тебя нет опыта работы с серверной частью 1С, то при появлении такого желания и/или необходимости появляется не мало нюансов и не очевидностей.
Печально, что даже такой простой квест, как выбор сервера под 1С не гарантирует успеха, и вы можете столкнутся с его крайне медленной производительностью.
Вот на этапе выяснения, что не так, и может понадобиться понимание того в какой последовательности и что делать.
Начинаем. Не забудьте сделать бекап данных.
Мой сервер это лезвие в блейд сервере «437507-B21 — HP BLc3000 Configure-to-order Enclosure», которое базируется на Windows Server 2012 R2 standard, и 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) в зеркале.
Фотографии оборудования в серверной стойке
У вас могут быть другие входящие, это не важно (сейчас).
Мы взяли Комплексную поставку УТП (в нее входит 10 клиентских лицензий, сервер (только 32 бит), и конфигурации ЗУП, УТ, Бухгалтерии, и сама УТП. Примечательно что франзайзи во всю хотели включить отдельные поставки, и лучше сразу КОРП. Анализ показал что это лишнее, и дешевле брать комплексную конфигурацию.
При подборе железа вам важно помнить, что в клиент-серверном варианте работе 1С нужно, чтобы частота работы процессора была максимальна, как и частота работы памяти (помните об этом, выбирая железо). (то есть Hyper трейдинг и всякие С1-2-3 state лучше отключить в BIOS).
Так же надо «физически» разносить файл базы (MDF) и лога (LDF) на отдельные жесткие, а не логические диски.
И если для файловой версии оптимально будет рекомендовать SSD, то тут, не все так очевидно.
Зайдите на форум Гилева, чтобы ознакомиться с «загадками», возникающими в попытке улучшить производительность 1С. Много интересного.
В моем случае коллеги админы выдели мне лезвие на блейд сервере, с 2мя физ.процессорами AMD Quad-Core Opteron(tm) Processor 2354, с 16 Гб (667 МГц). Система на 2 дисках в зеркале. Диски под базу выделялись по Fiber chanel, на HP EVA.
Сейчас ищу другую конфигурацию, но пока надо и на этом пожить.
И вот на этапе внедрения, пока ведется анализ как переносить данные из другой ERP системы, 1С программист обратил мое внимание на медленную работу, и долгое проведение документов. То есть систему еще не эксплуатируют, а она уже тормозит и помирает, а перепроведение раза в 3 медленнее, чем у человека на ноутбуке, а с этим еще и люди работать должны будут (3-4 основных, и 25-40 табельщиков).
Не порядок.
Он порекомендовал использовать тест Гилева (легко гуглится его сайт), у которого полного сервисов поддержки, и информации. Чем и воспользовался.
Тест показал что все плохо, и рекомендованное число пользователей отсутствует.
Посмотрев повнимательнее я понял что база и лог хоть на разных дисках — но логических.
И вот для исправления этого и сделал скриншоты и эту памятку на будущее себе и другим:
Памятка
Создание базы данных в SQL server management studio. Базу и лог разносим на разные физические диски.
Методе восстановления выбираем Simple
Создаем новую базу через клиента 1С на компьютере
Выбираем добавление информационной базы. В нашем случае без конфигурации.
Задаем называние. Здесь любое. Лучше как на сервере.
Заполняем данные. Когда указывал на сервере, имя сервера указывал 127.0.0.1 — иное не работало.
здесь ничего не меняем
Делаем загрузку нашей информационной базы (предварительно имеющейся или новой, например теста)
Собственно выбор базы. Я загружаю тест Гилева для платформы 8.3
Подтверждаем
Подтверждаем
Имейте ввиду:
Запуская тест Гилева в тестовой базе, которая расположена в тех же местах хранения что и любая боевая — имейте ввиду, что как минимум Лог файл стремиться занять все свободное место, что чревато остановкой боевой базы и не прохождением теста!!!
Создание базы данных в SQL server management studio. Базу и лог разносим на разные физические диски.
Методе восстановления выбираем Simple
Создаем новую базу через клиента 1С на компьютере
Выбираем добавление информационной базы. В нашем случае без конфигурации.
Задаем называние. Здесь любое. Лучше как на сервере.
Заполняем данные. Когда указывал на сервере, имя сервера указывал 127.0.0.1 — иное не работало.
здесь ничего не меняем
Делаем загрузку нашей информационной базы (предварительно имеющейся или новой, например теста)
Собственно выбор базы. Я загружаю тест Гилева для платформы 8.3
Подтверждаем
Подтверждаем
Имейте ввиду:
Запуская тест Гилева в тестовой базе, которая расположена в тех же местах хранения что и любая боевая — имейте ввиду, что как минимум Лог файл стремиться занять все свободное место, что чревато остановкой боевой базы и не прохождением теста!!!
Итог теста. Еще все плохо, но рекомендованное число пользователей больше требуемого, что хорошо.
Так же тестировал, используя логический раздел на зеркале основного диска в лезвие и раздела на СХД EVA.
Итоги теста
Здесь Лог на логическом диске в зеркале на SAS 10K, а база на СХД EVA с SAS дисками 15K
А здесь База на логическом диске в зеркале на SAS 10K, а лог на СХД EVA с SAS дисками 15K
Здесь Лог на логическом диске в зеркале на SAS 10K, а база на СХД EVA с SAS дисками 15K
А здесь База на логическом диске в зеркале на SAS 10K, а лог на СХД EVA с SAS дисками 15K
Промежуточный итог:
Разнесение Базы данных SQL по разным дискам очень важно!
В самом минимальном варианте Базу можно базировать на логическом диске основного физического диска с системой, а лог выносить на отдельный диск (в комментариях дали информацию, что лучше на SSD)
Лучшем вариантом разнесения базы и лога на отдельные физические диски.
Так же, как подметили в комментариях, имеет смысл вынести и TEMP базу самого SQL, так как 1С ее активно использует во время работы.
P.S. В процессе поиска правды система полностью клонировалась на один отдельный SSD (то есть диски с базой и логом были логические).
Не смотря на i7-4790 с 32 GB DDR3, производительность от обычного диска и работы на сервере лучше не становится.
Создание дисков на RAM диске так же показывало низкие результаты, не отличимые от работы на простых дисках.
Так же информация в помощь — Effector Saver позволяет сохранять 1с базы
Бекапить все остальное смысла мало, так как в моем случае лицензии программные и при переносе на другое железо лицензии слетают.
Из дополнительного.
Если Вам захочется дать пользователям домена безнаказанно создавать любые БД средствами 1С, то учетной записи службы сервера 1С сделать доменную учетку, имеющую право создавать базы без всяких сисадминов вполне достаточно,
при этом логин и пароль в свойствах информационной базы писать не надо…
Всех благ!
webzlo
вот еще пару советов: Обязательно в настройках электропитания в панели управления выставьте максимальную производительность. Отключите Dep
evr1ka
хм. Спасибо, странно, но это тоже упустил.
DikSoft
До кучи: скрипты для установки планов электропитания на максимум. Смысл, думаю, понятен:
evr1ka
Благодарю!
Sergey-S-Kovalev
Не сочтите, что я придераюсь или что то еще. Просто скажите, насколько начинает быстрее работать после установки плана питания на «Высокая производительность»?
И какие конкретно пункты в настройках плана питания это обеспечивают, если вы конечно заглядывали в настройки плана питания на серверных системах, особенно виртуализованных?
DikSoft
Прирост производительности получился около 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С.
Sergey-S-Kovalev
Я попытаюсь сэмулировать ситуацию и выдать свой вариант.
Я не совсем понял на какой конфигурации вы тестировали и получили 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, а потом была миграция в корпоративный ЦОД.
После этого ни одной заявки в сервисдеске о просадке производительности не было.
В общем сейчас звезды сложились так, что у меня есть возможность проверить на этом сервере этот гилевотест. Времени бы.
Fall_Angel
Позвольте вставлю свой коммент чуть выше и опишу итоги своих изысканий. Надеюсь будет полезно.
Как правильно настроить 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)
evr1ka
Благодарю!
DikSoft
Это на 2643 или на файловой штуковине с i7?
Fall_Angel
Это на 2643, Server 2008R2+SQL 2008R2
webzlo
и еще на практике встречал что если база лежит на зеркальном рейде то работает 1с на порядок медленнее
evr1ka
Собственно ради таких как ваш комментарий, я сделал данный пост. С миру по нитке.
mihmig
Как мне кажется, зеркало из двух дисков будет работать медленнее самого медленного диска.
И может не ставить зеркало на базу от которой требуется производительность?
Ночного и обеденного бекапа может оказаться достаточно?
evr1ka
Зеркало на системного диска С сделано потому что для блейд лезвия доступно только 2 диска.
Собственно изначально этот раздел поделили еще на 2 дополнительных логических, куда и положил базу. И это было не правильно )
Работать так нельзя, хотя не менеджер ресурсов ни что-либо еще (кроме теста Гилева) не показал проблемы.
Думаю зеркало не плохое решение, если нет другого ))
Бекап в жизни админа жизненно необходим, средствами Effector Saver настроил выгрузку базы в формате 1С ночью, и SQL днем, так как для выгрузки 1С нужно чтобы не было пользователей (как я понял). Но надо проверять, плюс версия фришная (еще не купили).
mihmig
Попробовать Postgres не хотите?
evr1ka
Хочу, но не для основного места работы. Тут с лицензиями проблемы нет.
Плюс почитал, что на Linux реазилациях для грамотной работы тоже требуются лицензии (и не бесплатные), и итог может быть не таким очевидным.
Проблема как я понял в том, что база 1С как бы «объемная», и она размазывает свои данные по SQLу в плоскости, что и вызывает такие дикие проблемы по производительности.
Люди рекомендуют 1С-никам (разработчикам) написать свой сервер баз данных, для решения такой проблемы.
mihmig
В случае линукса мы платим только за лицензии 1С (тоже немало конечно), но экономим на лицензиях на MS (SQL+Windows)
На сэкономленные деньги можно увеличить мощность железа (или добавить сервер для Postgres)
evr1ka
Спасибо за информацию. И поверьте, — лицензии 1С, в сравнении с SAP — копейки )
У нас корпоративно он по дефолту, но для ЗУП, там только итоговые суммы зарплат.
Изначально данный модуль брать даже не планировали, поэтому корпорейт в данном вопросе мешать не стал, так как локально местные задачи HR решать в экселях кажись все устали, а поддерживать для расчета Navision — тоже затратно.
MiXaiL27
А еще есть смысл в специализированных решениях с обменом. Делать меняную конфигурацию-комбайн ущербное решение. Лучше уж специализированные конфигурации с обменом. Да и нормальную CRM с ERP в одном флаконе мешать все равно замучаешься. Ну и само собой разнести их физически.
evr1ka
Согласен. Особенно про разнесения физически. Я например для себя так еще и не нашел конфигурации сервера, который бы показывал «превосходные» результаты по тестам, чтобы тупо заказать, и купить.
gentoonofb
Простите, но пост в стиле «я сделяль»
evr1ka
Доброго вам. Какой информации Вам не хватило, в данном тексте, или о чем бы вам было интересно узнать?
saboteur_kiev
Вообще не указано, какое железо было до, какое стало после.
Процессор и название сервера вообще никак не отображает дисковую систему, которая собственно была главной целью, для увеличения скорости работы. Просто вкратце упомянут fibre channel, и все.
В результатах теста, не понятны результаты. На картинке я вижу что-то типа 8 — это и есть рекомендуемое количество пользователей?
Весь сыр-бор с блейд серверами и fiber channel ради 8 пользователей?
Если нет, то как тогда читать результаты?
evr1ka
Спасибо Вам, добрый человек, за пояснение. Поправил статью, чтобы было больше понимания (добавил описание железа, характеристик и фото, а так же пару тестов с итогами.
По самой конфигурации:
saboteur_kiev
Все, что я увидел в тестах, это что текущий тест изменился с 9.17 до 9.47
Снова, для тех, кто не запускает тест сам, это в каких попугаях?
Раньше у вас комфотно работало 9.17 человек, а после всех изменений уже девять с половиной («текущий тест»)?
evr1ka
Число в 9.17 это «в Попугаях Гилева».
Рекомендованное число чуть дальше указывается, и значится как в 98 человек, что устраивает.
saboteur_kiev
Так хоть чуть лучше.
Как я понял в ваших итоговых двух картинок, итог такой:
Если логи вынести на более быстрое устройство, чем базу, производительность увеличивается. Например в вашем случае — почти в два раза. Если к этому тесту еще приложить какой-нить бенчмарк самого диска (скорость чтения/записи в мб\сек), можно уже и без 1С тестов прикидывать будет.
evr1ka
Да, все верно. Тест показывает именно это.
Было дело, что в студенчестве на курсах компьютерной грамотности преподавал. Так вот еще от туда понял, что если хочешь чего-то понять — постарайся объяснить другому. Спасибо за ваши вопросы и пояснения.
DikSoft
Ещё из очевидного, но не упомянутого.
Вынос TempDB на отдельный диск существенно помогает ускориться в «попугаях по Гилёву»
Вынос MDF на SSD практически не даёт прироста производительности. А вот LDF — наоборот.
evr1ka
Подтверждаю. Мои тесты тоже показали что вынос LDF в сторону уже улучшает картину. А что еще и на SSD — вообще интересная информация.
Я поэтому сейчас смотрю на самосбор на x99 чипсете с SSD на M.2 драйве от Samsung (у них 2,4 GB/s скорость чтения-записи).
Вообще сказка должна выйти.
Найти бы еще серверный вариант такого решения…
GuessWho
1С крайне не рекомендует делать бекапы баз через выгрузку в dt. Если что-то с базой не так, dt может обратно и не развернуться. Бекапы нужно делать с помощью штатных средств выбранной БД. Зачем этот «Effector Saver»?
evr1ka
Спасибо за Ваш комментарий, не знал о такой рекомендации. Данную программу посоветовали внедренцы. Выгрузка в dt дополнительная, не основная. Учту эту информацию — добавлю дополнительную выгрузку средствами самой БД.
gotch
Пребываю в недоумении от вашей статьи. ИТ — наука, или шаманство?
Почему? В каких случаях? В каких случаях разницы нет? Что такое физический диск? Является ли Lun в дисковой группе физическим диском? Почему в некоторых случаях разнесение на несколько Lun даже в одной дисковой группе улучшает производительность?
Действительно?
Неужели все, что удалось узнать про Tempdb?
Сакральное знание заключается в том, что «надо все разложить на разные диски, потому что тогда утилита Гилева дает лучшие результаты»?
И все? И никакого perfmon, латентности, дисковых очередей, анализа ожидания внутри SQL базы?
evr1ka
Доброго дня Вам! Буду отвечать:
ИТ — это информационные технологии. Конечно, для того чтобы для меня стало все логично в работе 1С с SQL необходим опыт (читай время) и знания (читай источники). Мой эпизодический опыт соприкосновения с 1С за 16 лет привел к тому что видите. К Шаманству.
Вопрос хорошо это или плохо?
Для более расширенного ответа рекомендую пройти на gilev.ru — все таки это их стезя, там они лучше на это отвечают. И да, под физическим диском я имею в виду Lun в дисковой группе. И лучший результат давало, когда только LDF файл на Lun. Мне удобнее чтобы и база была на СХД, так как есть разделение труда, и за блейд и СХД отвечают другие человек. Я говорю — мне надо столько-то разделов такого объема, он мне из выделяет и подключает.
Мой личный вывод. Можете привести свои доводы. В случае ограниченности ресурсов — не самое плохое решение.
Наверно стоит сообщить что опыт работы с SQL у меня минимален, не было необходимости. Ставь под различные системы, прописывать пользователей — это одно (например по Primavera, или OpenWells или еще что). Заниматься оптимизацией — другое. Навык не прокачан, собираюсь ликвидировать это в текущем году. Можете рекомендовать где и как (можно и чем).
За данное сакральное знание, не знающие люди (а вернее компании) платят большие деньги, и не всегда получают. Порядок цен от 10'000 до 100'000 $ и более. Та же услуга по оптимизации у Гилева начинается от 140'000 рублей.
И да, все остальное тоже делалось, но там настолько все объемно, и не очевидно, что пока не вносил в статью.
Думаю провести контрольные замеры, так как начиналось все перед новым годом, а активная эксплуатация системы на конец января — март этого года. Может зря я панику навожу, и текущей производительности для работы с головой хватит.
gotch
Покачайте ваш навык на 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.
evr1ka
Огромное, человеческое спасибо!
Sergey-S-Kovalev
| 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/
Rumlin
Вам бы спасибо сказали и карму поправили, если бы Вы написали это отдельной статьей.
evr1ka
Великолепно!
Хотя я читал и отличные мнения (что не надо разносить 1С и базы данных), но ваше разъяснение и подход мне больше по душе (и по аппаратному ключу, и по виртуализации. Я думаю это решаемо, когда знаешь что надо решать.
Ссылки зачитываю, спасибо
DikSoft
А которых? Авторов движка, авторов типового конфига, или местных внедренцев за допиливания? ;-) Ни в одном из этих случаев битьё результата не даст. В чем тогда смысл совета?
Штоа???
evr1ka
Ну собственно после похожего совета коллеги, мучать 1С-программиста внедренца, который указал на проблему, решил разбираться в ней сам.
MiXaiL27
В нашем офисе вбивать данные в меняную конфигурацию УТ+CRM способ наказания провинившихся! У неё потрясающая производительность, примерно, как у Rust на убунту!
Sergey-S-Kovalev
|«Не читал, но осуждаю»
Прочитал, продолжаю осуждать. Смотреть графики производительности в таскменеджере это пять баллов.
Аморфные цифры на картинках. Вместо подробностей о тестировании — вода.
По ссылке о Результатах работ:
=================
Неприятная новость
Запрошенную информацию найти не удалось. Возможно, будет полезен поиск по сайту или приведённые ниже ссылки.
=================
Но я уверен парни свой хлеб таки зарабатывают, просто потому что с дефолтной тормозной конфигурацией делают что то, из того что я перечислил выше.
| А которых?
Тех кто хаит дефолтные конфигурации иначинает их изменять. Этих бы я бил с особой жестокостью и цинизмом. Обычно это внедренцы. Свои же быстро перестают создавать себе же головняки на будущее, даже до битья не доходит.
Смысл — не быть виноватым в не компетенции 1Сников.
| Штоа???
Верю нашей сертифицированной и обученной команде разработки. А еще мне в 8.3 не нужно увеличивать количество рабочих процессов, что бы агент не падал когда, работает полторы сотни пользователей, и ВНЕЗАПНО один из руководителей решает запустить отчет не выбрав вообще никаких фильтров.
Но впрочем куда мне до всеопытных людей. Все же 1Сники знают, что за нововведение было в платформе 8.1.11, и по-любому виноваты всегда в этом админы и их обновления на венду, ведь после них всегда все падать начинает, правда я не уверен, что админы должны отключать полнотекстовую индексацию в базе. Это у них всегда сервера тормозят, даже если графики хоста и самой виртуалки не перескакивают 10% нагрузки.
Вообщем опыт опыту рознь :)
могу померяться индивидуальными размерами, если ваши порядки хотя бы превышают десяток кластеров 1С, полсотни серверов баз данных, террабайта баз, ну и конфигураций розницы, биллинга и упп разных. про бух и зуп я даже не говорю. о количестве пользователей я думаю вы догадаетесь сами, и какая обвязка вокруг всего этого.
Я всегда за конструктивную критику. У меня опыта много, я много чего могу рассказать.