Ребята, доброго времени суток!
Встречал где-то в литературе, что надо выносить тяжелые отчеты за пределы базы(на другой сервер), чтобы повысить производительность и записи и отчетов. В microsoft BOL есть инфа про выделение под логи транзакций отдельного LUN'a, под tempdb и под саму базу. Также на курсах 1С тоже говорилось про разнесение tempdb, логов транзакций и базы по разным дисковым массивам. И, кажется, даже на тех же курсах упоминалось про вынесение отчетов на другой сервер. Если кто тоже встречал информацию по сабжу, то дайте линк, плиз. У меня вот из головы просто вышибло, где я это встречал. А необходимо почитать как это правильно реализуется.
Прочие БД - Вынос тяжелых отчетов на другой сервер
-
kim-aa
Re: Прочие БД - Вынос тяжелых отчетов на другой сервер
Grub,
Вы путаетесь. Вы смешиваете оптимизацию системы ввода-вывода и оптимизацию серверов по операциям.
Сервера, да и сами базы СУБД, при высокой нагрузке действительно лучше оптимизировать под конкретные операции.
Условно их групируют в три клана:
- Оптимизированные на запись многочисленных транзакций- OLTP
- Оптимизированные на массовое чтение - OLAP
- Оптимизированные на гиперкубы - DataWarehaus (обычно это уже агрегированная база)
Если вы действительно хотите разгрузить сервер OLTP, то вам придется подымать его асинхронную копию, на которой и должны выполняться операции OLAP.
Типа этого
Просто вынести отчеты на другой сервер приложений, имеет смысл если у вас трехуровневая система с отдельным сервером СУБД и отдельными серверами приложений и при этом вы точно знаете, что основной затык происходит при расчете в коде 1С, а не массовой выборке в MS SQL
Вы путаетесь. Вы смешиваете оптимизацию системы ввода-вывода и оптимизацию серверов по операциям.
Сервера, да и сами базы СУБД, при высокой нагрузке действительно лучше оптимизировать под конкретные операции.
Условно их групируют в три клана:
- Оптимизированные на запись многочисленных транзакций- OLTP
- Оптимизированные на массовое чтение - OLAP
- Оптимизированные на гиперкубы - DataWarehaus (обычно это уже агрегированная база)
Если вы действительно хотите разгрузить сервер OLTP, то вам придется подымать его асинхронную копию, на которой и должны выполняться операции OLAP.
Типа этого
http://www.sql.ru/forum/actualthread.aspx?tid=685538
Просто вынести отчеты на другой сервер приложений, имеет смысл если у вас трехуровневая система с отдельным сервером СУБД и отдельными серверами приложений и при этом вы точно знаете, что основной затык происходит при расчете в коде 1С, а не массовой выборке в MS SQL
-
Grub
Re: Прочие БД - Вынос тяжелых отчетов на другой сервер
kim-aa, нет не путаюсь. Суть в том, что база является и OLTP и OLAP одновременно. При формировании отчетов, база зависает и в консоли администрирования 1С видно, что затык идет из-за блокировок(видно кто "держит" базу и расспросив "виновника", выясняем что он формирует отчет).
Система у нас действительно трехуровневая, поэтому как одно из решений и рассматривается вынос отчетов на другой сервер.
За ссылку Спасибо. Сейчас посмотрю.
По ссылке. Так и не увидел решения. Шел разговор, но ничем не закончился. Я промахнулся когда в первом посте не указал СУБД. Перевод базы, работающую всю свою жизнь на одной СУБД, на другую СУБД чреват большими проблемами. Поэтому сузим круг информации. Интересует MS SQL.
Система у нас действительно трехуровневая, поэтому как одно из решений и рассматривается вынос отчетов на другой сервер.
За ссылку Спасибо. Сейчас посмотрю.
По ссылке. Так и не увидел решения. Шел разговор, но ничем не закончился. Я промахнулся когда в первом посте не указал СУБД. Перевод базы, работающую всю свою жизнь на одной СУБД, на другую СУБД чреват большими проблемами. Поэтому сузим круг информации. Интересует MS SQL.
-
kim-aa
Re: Прочие БД - Вынос тяжелых отчетов на другой сервер
Цитата Grub:
При формировании отчетов, база зависает и в консоли администрирования 1С видно, что затык идет из-за блокировок(видно кто "держит" базу и расспросив "виновника", выясняем что он формирует отчет).
Если у вас трехуровневая система, то при блокировке необходимо проанализировать где основной затык.
Вариант А: Не хватает мощности сервера приложений (высока загрузка CPU & Mem).
Основным признаком является, то что MS SQL при этом простаивает и количество дисковых операций не велико (винчестер не визжит - грубо говоря). В данном случае имеет смысл создания отдельного сервера приложений ориентированного только на отчеты.
Данный вариат попробовать можно достаточно быстро, т.к. для пробы хватит любой мало-мальски мощной рабочей станции.
Вариант Б: Не хвататает мощности сервера MS SQL.
Основным признаком является интенсивные операции ввода вывода, при относительно низкой процессорной загрузке.
Тут два варианта:
- Покупка и настройка отдельного дискового хранилища.
- Покупка и настройка отдельного сервера СУБД + приложений ориентированного только на отчеты. Настройка асинхронной репликации между серверами.
Во-всех случаях нужно обратить внимание на индексирование таблиц где происходят блокировки.
При очень больших таблицах, имеет смысл подумать о создании кластерной таблицы (состоящей из группы сегментов)
По собственному опыту работы админом с 1С, могу сказать, что при проблемах с самописными отчетами, основной источник проблем, это кривые руки программиста. Если вместо операций со множествами и SELECT используются циклы многократной вложенности, то можно хоть укакаться, но проблема останется.
Цитата Grub:
Перевод базы, работающую всю свою жизнь на одной СУБД, на другую СУБД чреват большими проблемами
А это никто и не рекомендовал.
Цитата Grub:
нет не путаюсь.
Путаетесь, путаетесь, тк. в одном контексте приводите два различных способа повышения нагрузочной способности системы.
Цитата Grub:
Встречал где-то в литературе, что надо выносить тяжелые отчеты за пределы базы(на другой сервер), чтобы повысить производительность и записи и отчетов. В microsoft BOL есть инфа про выделение под логи транзакций отдельного LUN'a, под tempdb и под саму базу
Это пример оптимизации ввода-вывода внутри одного сервера. Возможно и рекомендовано всегда.
Цитата Grub:
И, кажется, даже на тех же курсах упоминалось про вынесение отчетов на другой сервер.
Это пример разнесения нагрузки между серверами для повышения нагрузочной способности системы в целом.
Возможно и рекомендовано только если архитектура системы это позволяет.
Например, такое разнесение неплохо помогает при перегрузке на чтение по сети, но совсем не помогает при записи (если у вас, конечно, не кластер Active-Active)
При формировании отчетов, база зависает и в консоли администрирования 1С видно, что затык идет из-за блокировок(видно кто "держит" базу и расспросив "виновника", выясняем что он формирует отчет).
Прочие БД - Вынос тяжелых отчетов на другой сервер
Если у вас трехуровневая система, то при блокировке необходимо проанализировать где основной затык.
Вариант А: Не хватает мощности сервера приложений (высока загрузка CPU & Mem).
Основным признаком является, то что MS SQL при этом простаивает и количество дисковых операций не велико (винчестер не визжит - грубо говоря). В данном случае имеет смысл создания отдельного сервера приложений ориентированного только на отчеты.
Данный вариат попробовать можно достаточно быстро, т.к. для пробы хватит любой мало-мальски мощной рабочей станции.
Вариант Б: Не хвататает мощности сервера MS SQL.
Основным признаком является интенсивные операции ввода вывода, при относительно низкой процессорной загрузке.
Тут два варианта:
- Покупка и настройка отдельного дискового хранилища.
- Покупка и настройка отдельного сервера СУБД + приложений ориентированного только на отчеты. Настройка асинхронной репликации между серверами.
Во-всех случаях нужно обратить внимание на индексирование таблиц где происходят блокировки.
При очень больших таблицах, имеет смысл подумать о создании кластерной таблицы (состоящей из группы сегментов)
По собственному опыту работы админом с 1С, могу сказать, что при проблемах с самописными отчетами, основной источник проблем, это кривые руки программиста. Если вместо операций со множествами и SELECT используются циклы многократной вложенности, то можно хоть укакаться, но проблема останется.
Цитата Grub:
Перевод базы, работающую всю свою жизнь на одной СУБД, на другую СУБД чреват большими проблемами
Прочие БД - Вынос тяжелых отчетов на другой сервер
А это никто и не рекомендовал.
Цитата Grub:
нет не путаюсь.
Прочие БД - Вынос тяжелых отчетов на другой сервер
Путаетесь, путаетесь, тк. в одном контексте приводите два различных способа повышения нагрузочной способности системы.
Цитата Grub:
Встречал где-то в литературе, что надо выносить тяжелые отчеты за пределы базы(на другой сервер), чтобы повысить производительность и записи и отчетов. В microsoft BOL есть инфа про выделение под логи транзакций отдельного LUN'a, под tempdb и под саму базу
Прочие БД - Вынос тяжелых отчетов на другой сервер
Это пример оптимизации ввода-вывода внутри одного сервера. Возможно и рекомендовано всегда.
Цитата Grub:
И, кажется, даже на тех же курсах упоминалось про вынесение отчетов на другой сервер.
Прочие БД - Вынос тяжелых отчетов на другой сервер
Это пример разнесения нагрузки между серверами для повышения нагрузочной способности системы в целом.
Возможно и рекомендовано только если архитектура системы это позволяет.
Например, такое разнесение неплохо помогает при перегрузке на чтение по сети, но совсем не помогает при записи (если у вас, конечно, не кластер Active-Active)