На сервере HP ProLiant DL580 G5 (64Gb ОЗУ) вертится сервер приложений 1С + SQL 2005. ОС windows server 2008 x64.
Винты 8 штук 15к raid 10.
Конфигурация УПП размером 35Гб, одновременно работают порядка 100 или чуть больше пользователей на 2 терминальных серверах. На данный момент не устраивает производительность 1с. Например расчет себестоимости идет около 1 часа и блокирует работу других пользователей. SQL забирает под себя всю оперативную память. Как я понял - скуля не освобождает память, если ее никто не требует. Вообще стоит ли освобождать память(периодический рестарт серверов, служб и т.д)? Каковы рекомендации по настройке сервера приложений 1С? На форумах читал что и для больших баз с большим количеством пользователей используются сервера с меньшим количеством ОЗУ. Один из предложений для повышения производительности - перенос tempdb на ssd винт или ОЗУ. Про гибкие блокировки в курсе(неужели нет других вариантов)?
Винты 8 штук 15к raid 10.
Конфигурация УПП размером 35Гб, одновременно работают порядка 100 или чуть больше пользователей на 2 терминальных серверах. На данный момент не устраивает производительность 1с. Например расчет себестоимости идет около 1 часа и блокирует работу других пользователей. SQL забирает под себя всю оперативную память. Как я понял - скуля не освобождает память, если ее никто не требует. Вообще стоит ли освобождать память(периодический рестарт серверов, служб и т.д)? Каковы рекомендации по настройке сервера приложений 1С? На форумах читал что и для больших баз с большим количеством пользователей используются сервера с меньшим количеством ОЗУ. Один из предложений для повышения производительности - перенос tempdb на ssd винт или ОЗУ. Про гибкие блокировки в курсе(неужели нет других вариантов)?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) to surgeon,
кстати вы не пробовали перекинуть файл подкачки в память (типа на виртуальный диск)? иногда очень даже помогает.
Но есть высокий риск незагрузки сервера, когда он не может найти диск подкачки (хотя по логике вещей такого быть не должно!!) :))
Если не хотите рисковать- отключите файл подкачки совсем, физической памяти вроде хватает (64 Гб)
На счет самой УПП- это поделие будет тормозить в любом случае, почему- вопрос к разработчкиам из 1с :)))
кстати вы не пробовали перекинуть файл подкачки в память (типа на виртуальный диск)? иногда очень даже помогает.
Но есть высокий риск незагрузки сервера, когда он не может найти диск подкачки (хотя по логике вещей такого быть не должно!!) :))
Если не хотите рисковать- отключите файл подкачки совсем, физической памяти вроде хватает (64 Гб)
На счет самой УПП- это поделие будет тормозить в любом случае, почему- вопрос к разработчкиам из 1с :)))
В общем произвел переход на новый сервер - база SQL 2008 вертится на таком сервере:
HP ProLiant DL580G7
процессор (4) Intel® Xeon® E7-4870 (2.40GHz/10-core/30MB/130W) Processors
кэш процессора 30MB (1 x 30MB) Level 3 cache
память 256GB PC3-10600R DIMMs (DDR3) installed in (8) memory boards
сетевой адаптер HP NC375i Integrated Quad Port Multifunction Gigabit Server Adapter (4 x 1Gb Port)
контроллер RAID Embedded HP Smart Array P410i/1GB FBWC Controller
дисковая подсистема 8 Hot-plug SFF 2.5" SAS HDD
Рейд в 10 настроен. База весит 35Гб. Рассчет себестоимости проводиться за несколько минут.
На данный момент в УПП еще внедряется еще и ТОиР. Посмотрим как все это будет вертеться.
HP ProLiant DL580G7
процессор (4) Intel® Xeon® E7-4870 (2.40GHz/10-core/30MB/130W) Processors
кэш процессора 30MB (1 x 30MB) Level 3 cache
память 256GB PC3-10600R DIMMs (DDR3) installed in (8) memory boards
сетевой адаптер HP NC375i Integrated Quad Port Multifunction Gigabit Server Adapter (4 x 1Gb Port)
контроллер RAID Embedded HP Smart Array P410i/1GB FBWC Controller
дисковая подсистема 8 Hot-plug SFF 2.5" SAS HDD
Рейд в 10 настроен. База весит 35Гб. Рассчет себестоимости проводиться за несколько минут.
На данный момент в УПП еще внедряется еще и ТОиР. Посмотрим как все это будет вертеться.
Для повышения быстродействия выключите проверку сертификатов
EXEC sp_fulltext_service 'verify_signature', 0
GO
потом
Перенесите tempdb на быстрый независимый массив/диски (что вы и собирались)
Выключите антивирус на сервере СУБД
После всех настроек посмотрите на рекомендации SQL Server 2005 Best Practices Analyzer они укажут на "тонкое место" вашей структуры.
EXEC sp_fulltext_service 'verify_signature', 0
GO
потом
Перенесите tempdb на быстрый независимый массив/диски (что вы и собирались)
Выключите антивирус на сервере СУБД
После всех настроек посмотрите на рекомендации SQL Server 2005 Best Practices Analyzer они укажут на "тонкое место" вашей структуры.
На данный момент пробую на новом сервере HP DL580G7 256Gb ОЗУ RAID10 10к. win2008R2+SQL2008R2.
Настроил SQL по полезным советам (6).
SQL Server 2008 R2 Best Practices Analyzer ничего критического не показывает.
В базу УПП 1 пользователь - проведение документа Рассчет себестоимости выпуска заняло более 3 часов. Далее прервал.
Настроил SQL по полезным советам (6).
SQL Server 2008 R2 Best Practices Analyzer ничего критического не показывает.
В базу УПП 1 пользователь - проведение документа Рассчет себестоимости выпуска заняло более 3 часов. Далее прервал.
Если начались блокировки (я не в курсе про УПП, нормально ли то, что этот отчет строится так долго и что блокирует юзеров), то тут уже всякими "настройками серверов", боюсь, не обойдёшься, нужно смотреть комплексно - и железо, и настройки, и, главное, код.
В чем заключаются тормоза? В отчетах только или в целом в работе базы? Вообще, час на отчет, имхо, это нереально долго. Нужно смотреть по отчету в чем проблема - в коде, в запросе. По запросам смотреть производительность, например, с помощью ЦУП из корпоративного инструментального пакета.
Всякого рода настройки серверов повышают общую производительность, но если какой-либо отчет откровенно тупит, его код придётся пересматривать с большой долей вероятности.
С другой стороны, если это "самый ацкий отчет" УПП и с ним технически всё хорошо, то надо копать именно в сторону спецов по УПП. Спрашивать у них, что да как.
В чем заключаются тормоза? В отчетах только или в целом в работе базы? Вообще, час на отчет, имхо, это нереально долго. Нужно смотреть по отчету в чем проблема - в коде, в запросе. По запросам смотреть производительность, например, с помощью ЦУП из корпоративного инструментального пакета.
Всякого рода настройки серверов повышают общую производительность, но если какой-либо отчет откровенно тупит, его код придётся пересматривать с большой долей вероятности.
С другой стороны, если это "самый ацкий отчет" УПП и с ним технически всё хорошо, то надо копать именно в сторону спецов по УПП. Спрашивать у них, что да как.
Рекомендую отделить сервер баз данных от сервера SQL и разместить их на разных физических серверах. Это во-первых. Во вторых установить 64х битный SQL и выдать на эту железку 16Гб оперативки.
А вообще иногда полезно проводить свертку базы и переиндексацию.
А вообще иногда полезно проводить свертку базы и переиндексацию.
(10) klimovss, Сервер 1С и Сервер БД на данный момент разнесены.
На железке из (1) стоит сервер 1С x64, Win2008x64
На железке из (9) стоит SQL 2008 x64,Win2008x64.
Сверка и переиндексация - это средствами 1С тестирование и исправление?
(11) romansun, сегодня попробую.
PS. На DBF версии рассчет себестоимости провел за 20 минут.
На железке из (1) стоит сервер 1С x64, Win2008x64
На железке из (9) стоит SQL 2008 x64,Win2008x64.
Сверка и переиндексация - это средствами 1С тестирование и исправление?
(11) romansun, сегодня попробую.
PS. На DBF версии рассчет себестоимости провел за 20 минут.
(13)Если на ДБФ проводит все быстро, то нужно копать в сторону SQL, как мне кажется, размер базы и журнала транзакций, были ли пересчитаны статистики перед расчетом, попробовать установить базу в simple. У меня вот в ДБФ по 100мегабитной сетке самым тяжелым отчетом был анализ субконто, потому что данных нужно было по сети тягать много.
(13) surgeon, свертка делается силами спеца по 1с, тестирование исправления вашими. Из собственного опыта могу предложить попробывать сделать выгрузку, а затем создать пустую БД на SQLе и загрузить туда базу. Такое примитивное действо иногда способно творить чудеса на уровне обращения воды в пиво. И еще вопросец, а как у вас собрана связь между серверами на уровне железа?
Я для предприятий где нужна работа по принципу 7х24 делал так. 2 сервера, 2 базы центральная и переферийная.
В центральной выполняем регламентные операции типа расчета себестоимости, создание, перепроведение большого количества документов. В переферийной оперативный документооборот.
В часы наименьшей активности происходит обмен.
В центральной выполняем регламентные операции типа расчета себестоимости, создание, перепроведение большого количества документов. В переферийной оперативный документооборот.
В часы наименьшей активности происходит обмен.
(12) Cartman,
+1
можно даже вторую базу разместить на этом же сервере.
Главное суть, что пока идет расчет себестоимости в одной базе, во второй все пользователи нормально работают.
А то что расчет идет 1 час, так это еще побожески.
В зависимости от глубины аналитики расчет может идти и сутки. Правда никогда не понимал зачем нужна такая точность в распределении затрат, но это уже вопрос к "экономистам".
+1
можно даже вторую базу разместить на этом же сервере.
Главное суть, что пока идет расчет себестоимости в одной базе, во второй все пользователи нормально работают.
А то что расчет идет 1 час, так это еще побожески.
В зависимости от глубины аналитики расчет может идти и сутки. Правда никогда не понимал зачем нужна такая точность в распределении затрат, но это уже вопрос к "экономистам".
(45) hvlad77
Да не разместить базёнку, а на отдельной машинке(можно даже не сервер, а хорошую рабочую станцию), где убрано всё лишнее. Если мамка позволяет, то напихать в нее кучу мозгов (если хватит под базу), создать в оперативке электронный диск и в ней покрутить отчеты на базе. Накрайняк пару SSDшек в нулевой райд запендорить и в ней поднять весь этот хлам.
Понятно, что придется утопить совесть в стакане-другом алкоголя, ибо в этом случае сидеть на ломаной первоэске, и нелицензионной винде/скуле.
Да не разместить базёнку, а на отдельной машинке(можно даже не сервер, а хорошую рабочую станцию), где убрано всё лишнее. Если мамка позволяет, то напихать в нее кучу мозгов (если хватит под базу), создать в оперативке электронный диск и в ней покрутить отчеты на базе. Накрайняк пару SSDшек в нулевой райд запендорить и в ней поднять весь этот хлам.
Понятно, что придется утопить совесть в стакане-другом алкоголя, ибо в этом случае сидеть на ломаной первоэске, и нелицензионной винде/скуле.
1. На SQL каждую ночь реиндексация и обновление статистики
2. Проверить, какой процент данных SQL берет из кеша, а какой читает с винта - 95% из кеша это хорошо. Если мало - хорошо бы увеличить объем RAM.
3. Проверить настройки SQL - там есть параметр Minimum server memory и Maximum server memory. Минимум - 0, максимум - объем RAM на серваке минус затраты на ОС и другие задачи.
4. Проверить код 1С - возможно слишком много запросов лишних. Например если к элементу справочника обращаться как ТекущийЭлемент(), то на SQL каждый раз летит запрос select * from scXX where id = 'YYYYYY'. А если сделать ТекЭл = ТекущийЭлемент(); и обращаться уже к ТекЭл, то запрос всего один. Ну и вообще посмотреть через profiler, что там происходит.
2. Проверить, какой процент данных SQL берет из кеша, а какой читает с винта - 95% из кеша это хорошо. Если мало - хорошо бы увеличить объем RAM.
3. Проверить настройки SQL - там есть параметр Minimum server memory и Maximum server memory. Минимум - 0, максимум - объем RAM на серваке минус затраты на ОС и другие задачи.
4. Проверить код 1С - возможно слишком много запросов лишних. Например если к элементу справочника обращаться как ТекущийЭлемент(), то на SQL каждый раз летит запрос select * from scXX where id = 'YYYYYY'. А если сделать ТекЭл = ТекущийЭлемент(); и обращаться уже к ТекЭл, то запрос всего один. Ну и вообще посмотреть через profiler, что там происходит.
1) реиндексацию и обновление настроено пару дней назад.
2) объем ОЗУ достаточен
3) параметры мин и макс были подкручены
4) не знаю конечно какой код в 1С написали, но конфа стандартная без исправлений.
Также возникло подозрение что проблема в данных. Документ Рассчет себестоимости выпуска за сентябрь проводиться быстро, а за октябрь долго. И еще пробовал за октябрь с разницей в 2 дня - тоже на ранней медленно, а на новой быстро проводиться.
2) объем ОЗУ достаточен
3) параметры мин и макс были подкручены
4) не знаю конечно какой код в 1С написали, но конфа стандартная без исправлений.
Также возникло подозрение что проблема в данных. Документ Рассчет себестоимости выпуска за сентябрь проводиться быстро, а за октябрь долго. И еще пробовал за октябрь с разницей в 2 дня - тоже на ранней медленно, а на новой быстро проводиться.
у меня зарплата 8.2 в связке windows server2008 64bit+SQL2008 так не пошла,тянет всякую гадость с временных таблиц при расчёте, так же производительность низкая, а вот бухгалтерия 2.0 летает. На windows server 2003 32Bit +SQL2005 ЗИК работает прекрасно.Все обнавления и патчи по sql2008 накатывал, никто не знает в чём проблемма?
попробовал перевести базы dbf на sql - заметно тормознее стало. Формирование отчета по основным средствам заняло 3 мин в sql и почти 50 сек в dbf версиях. Версия 1с 7.7 сборка 25, SQL 2005. Т.е. смысла не имеет переходить?
З.Ы. База в dbf немногим менее 1 гига.
З.Ы. База в dbf немногим менее 1 гига.
вопрос, возможно, неуместен, но: рассчитаны ли итоги по регистрам?
Далее из своей практики:
1. проверить фрагментацию файла базы (средствами винды). если фрагментов больше 20 - дефраг диска.
2. упорядочить фрагментацию страниц в базе (сжатие базы с реструктуризацией и оставлением свободного места ок. 15%).
3. проверить размер ЛОГ-файла. если не обрезается обычним сжатием - поиграть с моделями лога - переключить на простую, сжать, переключить на полную, сжать.
Пробовал когда-то разнести tempdb на отдельный физический диск - немного, но помогло.
А вообще УПП очень много ресурсов убивает на расчет партий и с этим ничего не поделаеш. Пришлось полностью отключать партийку. база дожила до 280Г.
Далее из своей практики:
1. проверить фрагментацию файла базы (средствами винды). если фрагментов больше 20 - дефраг диска.
2. упорядочить фрагментацию страниц в базе (сжатие базы с реструктуризацией и оставлением свободного места ок. 15%).
3. проверить размер ЛОГ-файла. если не обрезается обычним сжатием - поиграть с моделями лога - переключить на простую, сжать, переключить на полную, сжать.
Пробовал когда-то разнести tempdb на отдельный физический диск - немного, но помогло.
А вообще УПП очень много ресурсов убивает на расчет партий и с этим ничего не поделаеш. Пришлось полностью отключать партийку. база дожила до 280Г.
Да мне тоже кажется надо искать узкое место,
железо хорошее ,на оборудование денег не жалеют
мы работаем с оборудованием поскромнее , база хоть и не такая большая но один терминальный сервер до 60-80 пользователей держит , хотя идет там только выписка документов и их печать, отчёты формируются в другой базе на другом сервере.
железо хорошее ,на оборудование денег не жалеют
мы работаем с оборудованием поскромнее , база хоть и не такая большая но один терминальный сервер до 60-80 пользователей держит , хотя идет там только выписка документов и их печать, отчёты формируются в другой базе на другом сервере.
Лучше отделить сервер баз данных от сервера SQL и разместить их на разных физических серверах. Это во-первых. Во вторых установить 64х битный SQL и выдать на эту железку 16Гб оперативки.
А вообще иногда полезно проводить свертку базы и переиндексацию.
А вообще иногда полезно проводить свертку базы и переиндексацию.
(54) - 1. Абсолютно верно 2. На любителя 3. Реиндексация бывает бесполезна когда нет нужных индексов а научным методом доказано что 1с не строит всех необходимых индексов (строятся только минимальный набор) - и бывают ситуации когда ручное создание дополнительных индексов решает проблему производительности.
Рекомендуемые меры:
1. Разобраться прежде всего с сетью - по крайней мере, поперфмонить. А вообще - лучше поискать узкие места на каждом из серверов.
Не исключено, что можно решить задачу имеющимися средствами - поправить настройки, перегруппировать задачи на серверах по принципу схожести характера нагрузки на подсистемы - например, вынести всех аналитиков с их базами на отдельный достаточно мощный сервер и т.п.
3. В идеале - приобрести достаточно шустрый современный массив с 1-2 полками 15К винтов, плавно ставить во все серверы FC HBA и переезжать на него; все серверы посадить на гигабит, причем транковать сетевушки, где возможно (до свича, т.е. возможно потребуется приобрести приличествующий свич); добить мозгов, где не хватает.
1. Разобраться прежде всего с сетью - по крайней мере, поперфмонить. А вообще - лучше поискать узкие места на каждом из серверов.
Не исключено, что можно решить задачу имеющимися средствами - поправить настройки, перегруппировать задачи на серверах по принципу схожести характера нагрузки на подсистемы - например, вынести всех аналитиков с их базами на отдельный достаточно мощный сервер и т.п.
3. В идеале - приобрести достаточно шустрый современный массив с 1-2 полками 15К винтов, плавно ставить во все серверы FC HBA и переезжать на него; все серверы посадить на гигабит, причем транковать сетевушки, где возможно (до свича, т.е. возможно потребуется приобрести приличествующий свич); добить мозгов, где не хватает.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот