Есть ли смысл разносить сервер 1С и сервер баз данных на 8.1
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Если у Вас есть проблемы с производительностью, то нужно принимать меры, разносить ради простого разнесения конечно нет смысла.
Если проблема с производительностью то надо делать комплекс мер и начинать с наиболее простых и очевидных, по повышению производительности:
1. Сколько у вас процессов сервера 1с и какой разрядности, может кластер сделать?
2. Сложно ли перейти на 8.2 (это необходимо рано ил поздно)? Вы лишаете себя управляемых блокировок как минимум и производительности за счет самой платформы.
3. Какой SQL? Производилось ли секционирование?
4. проводилось ли нагрузочное тестирование и проверка узких мест оборудования? Вы пробовали ставить ЦУП?
Вообще 1С сейчас разрабатывает версию платформы с автоматической балансировкой нагрузки между серверами 1С.
Если проблема с производительностью то надо делать комплекс мер и начинать с наиболее простых и очевидных, по повышению производительности:
1. Сколько у вас процессов сервера 1с и какой разрядности, может кластер сделать?
2. Сложно ли перейти на 8.2 (это необходимо рано ил поздно)? Вы лишаете себя управляемых блокировок как минимум и производительности за счет самой платформы.
3. Какой SQL? Производилось ли секционирование?
4. проводилось ли нагрузочное тестирование и проверка узких мест оборудования? Вы пробовали ставить ЦУП?
Вообще 1С сейчас разрабатывает версию платформы с автоматической балансировкой нагрузки между серверами 1С.
У меня на 8.1 работало отлично, 50 пользователей. А вот когда перешли на 8.2 то тормоза жуткие стали. Если честно не могу пока сказать это из за платформы или из за того что всё на одном серваке стоит. Думаем это дело разделять, но я что то сомневаюсь что платформа 8.2 на столько тяжелей..разделение должно помочь
Смысл имеет разносить при большой нагрузке на 1С сервер (когда количество одновременно работающих пользователей велико), у меня на прошлой работе только это помогло расшевелить базу при нагрузке в 30 работающих человек... по сути 1С сервер начинает жрать процессорное время, подвигая скуль в ресурсах, а скуль кушает память....
На самом деле нужно смотреть по нагрузке и по планируемой пиковой загруженности всей системы. Если следовать всем рекомендациям, то под каждую задачу необходим свой сервер, но это невсегда целесообразно и экономически обосновано
Конечно есть. SQL-сервер всегда ставил отдельно и никаких проблем не испытывал. Только сервер 1С должен быть обязательно соединен с SQL-сервером гигабитным ethernet. Кроме этого, файлы SQL-базы данных (*mdf и *ldf для MS SQL) должны быть на SAS-дисках или SSD-накопителях, установленных желательно в RAID0 для надежности.
(22) vprus, цитирую: "...должны быть на SAS-дисках или SSD-накопителях, установленных желательно в RAID0 для надежности."
Имелось в виду RAID 10? Дело в том, что RAID 0 и надежность - диаметрально противоположные понятия ;-) А то щас пионэры наставят, начитавшись :-)
А по сути - сильно улучшается производительность (скажем, хотя бы в тесте Гилева) при отдельном сервере БД?
Я, собсно, вот к чему. Надо ли огород городить, может, до некоторых масштабов, лучше поставить сервак помощнее?
Нонешние процы все же весьма производительные, а уж серверные - так вообще. Система с двумя ксеонами Е5 или Е7 по вычислительной мощности потянет и 1С, и СУБД просто играючи. Оперативки можно набить побольше, и вуаля. А скорость обмена информацией между процом, аппаратным рэйдом и оперативкой всяко же больше, чем через гигабитную локалку.
В общем, все опять сводится к извечному вопросу - где возникают наибольшие тормоза?
Имелось в виду RAID 10? Дело в том, что RAID 0 и надежность - диаметрально противоположные понятия ;-) А то щас пионэры наставят, начитавшись :-)
А по сути - сильно улучшается производительность (скажем, хотя бы в тесте Гилева) при отдельном сервере БД?
Я, собсно, вот к чему. Надо ли огород городить, может, до некоторых масштабов, лучше поставить сервак помощнее?
Нонешние процы все же весьма производительные, а уж серверные - так вообще. Система с двумя ксеонами Е5 или Е7 по вычислительной мощности потянет и 1С, и СУБД просто играючи. Оперативки можно набить побольше, и вуаля. А скорость обмена информацией между процом, аппаратным рэйдом и оперативкой всяко же больше, чем через гигабитную локалку.
В общем, все опять сводится к извечному вопросу - где возникают наибольшие тормоза?
сопутствующий вопрос: если кластер и клиент находятся на одной машине (виндоус), что можно сделать с настройками кластера для ускорения обмена данными клиента и базы ? тормозит жутко порой при сохранении больших объемов данных в базу. хотя бы клиент-серверный вариант оставили про запас что-ли...(
Как раз произвел разделение сервера 1С и базы SQL. Не увидел большого прироста в производительности.
Сервер 1с вертится на HP Proliant DL580 G5 64Gb Raid 10. А сервер SQL вертится на HP Proliant DL580 G7 256Gb raid 10. На обоих серверах дури хватает. Процы загружены мало, дисковая подсистема тоже не сильно. Параллельно работает порядка 100-150 пользователей. по счет процов так вообще вопрос - нафига эта куча процессов с кучей ядер и HT. Все равно большинство приложений не умеет использовать их. И висит все это мертвым грузом.
Сервер 1с вертится на HP Proliant DL580 G5 64Gb Raid 10. А сервер SQL вертится на HP Proliant DL580 G7 256Gb raid 10. На обоих серверах дури хватает. Процы загружены мало, дисковая подсистема тоже не сильно. Параллельно работает порядка 100-150 пользователей. по счет процов так вообще вопрос - нафига эта куча процессов с кучей ядер и HT. Все равно большинство приложений не умеет использовать их. И висит все это мертвым грузом.
При количестве пользователей от 30-40 - ДА. Согласно рекомендациям самого Microsoft (в случае использования MS SQL Server) сиквэл сервер не рекомендуется совмещать на одном физическом сервере с еще чем либо (домена контроллера или терминального сервера и т.п.). Но одного разделения конечно не достаточно. Нужно еще "разнести" лог и данные, оптимизировать сеть, выровнять разделы. В общем правильно настроить сам SQL
имеет смысл
согласно рекомендациям самого Microsoft (в случае использования MS SQL Server) сервер не рекомендуется совмещать на одном физическом сервере с еще чем либо (домена контроллера или терминального сервера и т.п.). Но одного разделения конечно не достаточно. Нужно еще "разнести" лог и данные, оптимизировать сеть, выровнять разделы. В общем правильно настроить сам SQL
согласно рекомендациям самого Microsoft (в случае использования MS SQL Server) сервер не рекомендуется совмещать на одном физическом сервере с еще чем либо (домена контроллера или терминального сервера и т.п.). Но одного разделения конечно не достаточно. Нужно еще "разнести" лог и данные, оптимизировать сеть, выровнять разделы. В общем правильно настроить сам SQL
Наблюдал картину когда в конфигурации Управление Торговым Предприятием для Украины.
примерно 10 пользоователей.
24 - 30 тысяч документов в месяц.
Сервер "домашний компьютер", помоему i5 проц с 8 гиг памяти.
Долго заходили в базу, проводили документы и т.д. Причём SQL при загрузке\выгрузки информационной базы загонял в потолок одно из ядер и больше не использовал.
Перенесли сервер 1С и SQL на новый сервер (серверной сборки) полегчало, но не сильно... Заметно полегчало только после разноса на разные, отдельные сервера. Причём на сервере SQL сделали упор на дисковый массив. В итоге жизнь наладилась.. Но всёравно, перепроведение документов за месяц занимает довольно большое время.
Вопрос к разработчикам "из-за чего и что делать?" был получен ответ "ну, запросы там это... не оптимальны... Если хотите - можете оптимизировать". Ну бЭлин! это же получится нифига не типовая конфа! как её потом поддерживать?
А по поводу ускорения работы: можно настроить индексирование регистров базы, и есть обработка "КонсольЗаданий" с помощью которой можно настроить регламентированные задачи 1С-сервера...
примерно 10 пользоователей.
24 - 30 тысяч документов в месяц.
Сервер "домашний компьютер", помоему i5 проц с 8 гиг памяти.
Долго заходили в базу, проводили документы и т.д. Причём SQL при загрузке\выгрузки информационной базы загонял в потолок одно из ядер и больше не использовал.
Перенесли сервер 1С и SQL на новый сервер (серверной сборки) полегчало, но не сильно... Заметно полегчало только после разноса на разные, отдельные сервера. Причём на сервере SQL сделали упор на дисковый массив. В итоге жизнь наладилась.. Но всёравно, перепроведение документов за месяц занимает довольно большое время.
Вопрос к разработчикам "из-за чего и что делать?" был получен ответ "ну, запросы там это... не оптимальны... Если хотите - можете оптимизировать". Ну бЭлин! это же получится нифига не типовая конфа! как её потом поддерживать?
А по поводу ускорения работы: можно настроить индексирование регистров базы, и есть обработка "КонсольЗаданий" с помощью которой можно настроить регламентированные задачи 1С-сервера...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот