Ѕаза знаний студента. –еферат, курсова€, контрольна€, диплом на заказ

курсовые,контрольные,дипломы,рефераты

ѕроблема критического падени€ производительности »“ системы в час пик, при условии нехватки оперативных серверных ресурсов — »нформатика, программирование

ѕосмотреть видео по теме –еферата

Ќедавние событи€, св€занные с крупнейшим энергетическим кризисом в ћоскве натолкнули мен€ на мысль о написании этой статьи. Ќа первый взгл€д кажетс€, что общего между энергетической сетью и промышленной »“ системой? ќбщего очень много. ¬ первую очередь, это распределенные системы с большим количеством пользователей. ” этих систем схожа€ сетева€ топологи€ , схожие проблемы и методы их разрешени€. я не буду вдаватьс€ во все подробности, опишу основные моменты, касающиес€ неравномерной нагрузки на систему по времени, а проще говор€, о Ђчасах пикї.

¬ энергетических системах как впрочем, и в »“ системах сто€т схожие проблемы обработки неравномерной нагрузки на системы по времени. — одной стороны не эффективно тратить большие деньги на модернизацию оборудовани€, если подобна€ система посто€нно загружена в несколько раз меньше своей максимальной рабочей мощности.

— другой стороны просто усредн€ть значение загрузки и сравнивать с максимальной мощностью системы и на основании этого делать выводы об эффективности системы в данном случае категорически нельз€. ƒело в том, что даже небольшое превышение нагрузки относительно максимальной мощности системы может привести либо к отключению автоматикой, либо к выходу из стро€ оборудовани€.

Ќа помощь здесь приход€т автоматизированные системы позвол€ющие распредел€ть нагрузку между подсистемами. “аким образом, увеличиваетс€ обща€ эффективность использовани€. Ќо здесь есть и отрицательные моменты. ≈сли вышла кака€ либо из подсистем из стро€ и при этом потоки не были перенаправлены правильно (хот€ иногда это не имеет значени€, просто ресурсов не хватает в любом из направлений) в этом случае есть больша€ веро€тность цепной реакции отключени€ или выхода из стро€ подсистем. ѕроисходит ситуаци€, когда подсистема работает на пределе своих возможностей, а плюс к этому, на нее переключают дополнительную нагрузку в виде подключений пользователей вышедшей из стро€ другой подсистемы. ѕосле превышени€ порога нагрузки происходит авари€ или автоматика отключает подсистему и предыдуща€ ситуаци€ происходит со следующей подсистемой.

¬ вышеописанной ситуации необходимо воврем€ прин€ть решение об отключении определенного количества пользователей. „ем раньше будет прин€то это решение, тем меньшими потер€ми можно обойтись. ƒанное решение сложно прин€ть без отсутстви€ эффективных инструментов мониторинга. ¬едь нужно пон€ть количество пользователей, которых необходимо отключить. ≈сли отключить слишком мало то этот Ђснежный комї не удастс€ остановить. ќтключение слишком большого количества пользователей плохо само по себе. ќтключать пользователей нужно не просто по количеству, а желательно по приоритетам. Ќапример, важные объекты должны быть отключены в последнюю очередь.

¬ »“ системах оборудование хоть и не выходит из стро€, но аналогии можно привести те же самые. ѕользовател€м по большому счету не важно почему »“ система потер€ла часть функциональности, или не работает вообще. ѕроизошло ли это потому, что сервер вышел из стро€, или потому, что серверные мощности перегружены, - результат один и тот же Ц система не функциональна (по крайней мере в полном объеме).  огда подобна€ ситуаци€ может произойти в »“ системах? ¬о-первых, это происходит исключительно в час пик, когда запас прочности серверных мощностей невелик. Ќе буду рассказывать о принципах оптимизации алгоритмов работы SQL сервера с данными. ѕросто поделим часть информации и часть серверных ресурсов на оперативные и не оперативные.

— точки зрени€ производительности »“ систем важно, каким количеством свободных оперативных ресурсов располагает сервер. ≈сли на обработку запроса сервером оперативных ресурсов хватает, то он будет выполнен с нормальной скоростью. ¬ случае, когда свободных оперативных ресурсов нет, то этот же самый запрос будет обработан за гораздо больший интервал времени. ѕод свободными оперативными ресурсами можно понимать, например, объем свободной оперативной пам€ти (но не только).

ѕри использовании долгих, затрагивающих большое количество ресурсов, транзакций сервер занимает под их обслуживание, определенное количество оперативных ресурсов. Ёто обуславливаетс€ условием целостности транзакций. ѕри параллельной обработке большого количество длинных транзакций может наступить момент, когда обща€ производительность сервера упадет, и большинство серверных операций станет выполн€тьс€ медленнее. ѕри разборе таких ситуаций нельз€ не учитывать блокировочный механизм MS SQL сервера. ѕричиной длительного интервала времени обработки транзакции может стать неправильный или неэффективный блокировочный механизм. ¬ случае если в транзакции встречаетс€ блокировка, то эта транзакци€ становитс€ в очередь и будет обработана, когда заблокированный ресурс станет доступен. «аблокированный ресурс освобождаетс€, как правило, когда закрываетс€ друга€ транзакци€, котора€ его захватила.

“аким образом, у нас может выстроитьс€ определенна€ очередь транзакций, которые не могут быть закрыты и обработаны вследствие работы блокировочного механизма.  ажда€ открыта€ транзакци€, как говорилось уже ранее, отнимает определенное количество оперативных ресурсов. ¬ случае, когда эта очередь достигнет большого размера, оперативных ресурсов может не остатьс€. Ќачнетс€ обща€ деградаци€ производительности. ѕри этом эта очередь в большинстве случаев будет только увеличиватьс€, так как новые запросы от пользователей продолжают поступать, а производительность упала.

Ёту ситуацию можно разрешить, только прин€в воврем€ решение об отключении определенного количества пользователей, либо об ограничении входного информационного потока. „ем раньше будет прин€то это решение, тем меньше вырастет очередь и меньше пользователей необходимо будет отключить. ѕользователей нужно отключать на основании анализа. »х не должно быть слишком мало иначе не удастс€ разобрать очередь и таким образом освободить необходимое количество оперативных ресурсов. ¬ этом случае небольшой очередной всплеск активности может увеличить входной информационный поток и ситуаци€ повторитс€ вновь. ќтключаемые пользователи должны обладать определенным приоритетом. Ќапример, главному бухгалтеру, наверное, не понравитс€ что вы отключили его в момент обработки важной транзакции, в то врем€ как секретарь успешно проводил документ который мог бы запросто быть проведенным вечером.  ак правило, в самом наличии очереди обрабатываемых транзакций в MSSQL ничего плохого нет. ѕлохо тогда когда размер этой очередь превышает определенный порог.

—тандартного механизма разрешени€ подобной ситуации в MSSQL нет, единственный механизм - это механизм эскалации блокировок, когда сервер сам принимает решение об увеличении уровн€ блокировки в случае ее слишком маленькой гранул€рности. ѕодобный механизм не позвол€ет решать проблему в полном объеме.

ƒл€ эффективного разрешение данной проблемы необходимо наличие развитых средств мониторинга систем , когда оперативно собираетс€ информаци€ о наличии свободных серверных ресурсов. “акже необходимы средства нотификации, которые позвол€т получить ответственному сотруднику информацию о критической ситуации максимально оперативно. ќпределить приоритет транзакции можно, реализовав несложный дополнительный протокол. ‘актически необходимо в начале Ђважныхї транзакций в дополнительную таблицу записывать соответствие между степенью определ€ющей приоритет и уникальным идентификатором процесса (@@spid). ѕосле этого отключение сессий можно будет предпринимать более эффективно и с меньшими рисками.

 ак определить количество пользователей, которых необходимо отключить? ѕредположим, вс€ очередь составл€ет пор€дка 30-и пользователей. —колько пользователей нужно отключить? ƒес€ть, п€тнадцать, а может и все двадцать?   сожалению универсального алгоритма не существует. Ёто зависит как правило от специфики »“ системы. «десь необходимо найти тонкий баланс.

 ак часто возникают подобные ситуации? «десь все определ€етс€ веро€тностью возникновени€ подобной ситуации. Ќа веро€тность вли€ют такие основные факторы : объем свободных оперативных ресурсов (естественно зависит от мощности серверного оборудовани€), объем вход€щего информационного потока, блокировочный механизм (точнее специфика его использовани€ в текущей Ѕƒ), врем€ обработки транзакций и т.п. ¬озникает эта ситуаци€ довольно редко.

Ќаиболее актуальны подобные ситуации будут дл€ 1— 8.0. так как там блокировочный механизм отличаетс€ от блокировочного механизма 1— 7.7. ѕричиной может стать как неожиданный всплеск активности пользователей (все одновременно начали проводить документы), а также ситуаци€ когда был запущен какой то специфический большой отчет или открыта€ длинна€ транзакци€. ƒлительно заблокированный ресурс, через который проходит большинство транзакций тоже может справоцировать подобную ситуацию.

¬от один из подходов к идентификации и отключению подобных процессов. ѕростейший вариант - отключение сессий с открытыми блокировками (в таком варианте будет отключено слишком много пользователей):

declare @str char(4000)

declare @Spid char(20)

declare Mylog cursor local fast_forward for

select Spid from sysprocesses where (kpid>0 or blocked>0) and spid<>@@spid

open Mylog

fetch Mylog into @Spid

while (@@fetch_status<>-1)

begin

set @str='kill '+rtrim(@Spid)

select @str

exec(@str)

fetch Mylog into @Spid

end

close Mylog

deallocate Mylog

¬озникает вопрос, а можно ли вообще обойтись от отключений? ƒа это возможно. ƒл€ этого в блокировочном механизме необходимо учитывать наличие свободных ресурсов. ¬ случае, если их недостаточное количество, то необходимо в алгоритме не давать открывать транзакцию, или, по крайней мере, захватывать большое количество ресурсов до тех пор, пока очередь не уменьшитс€ до приемлемой величины. ¬ каждой транзакции, естественно, неэффективно в онлайн провер€ть наличие свободных ресурсов. »менно поэтому дл€ реализации данной схемы необходим отдельный менеджер, который будет это делать в фоновом режиме и выдавать информацию сесси€м пользователей по запросу.

 омпани€ SoftPoint предлагает как развитые средства мониторинга подобных ситуаций, так и реализацию блокировочных протоколов учитывающих веро€тность возникновени€ подобной ситуации.

—писок литературы

ƒл€ подготовки данной работы были использованы материалы с сайта http://klerk.ru/

Ќедавние событи€, св€занные с крупнейшим энергетическим кризисом в ћоскве натолкнули мен€ на мысль о написании этой статьи. Ќа первый взгл€д кажетс€, что общего между энергетической сетью и промышленной »“ системой? ќбщего очень много. ¬ первую о

 

 

 

¬нимание! ѕредставленный –еферат находитс€ в открытом доступе в сети »нтернет, и уже неоднократно сдавалс€, возможно, даже в твоем учебном заведении.
—оветуем не рисковать. ”знай, сколько стоит абсолютно уникальный –еферат по твоей теме:

Ќовости образовани€ и науки

«аказать уникальную работу

ѕохожие работы:

јлгоритм сжати€ исторической информации
Ёкономическа€ дискриминаци€ и рынок рабочей силы в период индустриализации в нефт€ной промышленности Ѕаку
јнализ машиночитаемых документов компьютерными средствами
ќтраслевые стандарты исторической науки в информационных технологи€х: к постановке проблемы
»нтерактивное исследование неколичественных данных: методика и инструментарий
—труктурные методы распознавани€ сложноорганизованных исторических табличных форм
“ехнологи€ выбора эффективных тактик преподавател€ при моделировании процесса обучени€
√ибридные интеллектуальные человеко-машинные вычислительные системы и когнитивные процессы
Ќекоторые проблемы подготовки специалистов на основе перспективных инфор-мационных технологий
ќ синергетической концепции высшего образовани€

—вои сданные студенческие работы

присылайте нам на e-mail

Client@Stud-Baza.ru