Мониторинг загрузки процессора терминального сервера #117380

Всем привет.Вот столкнулся с проблемой - на терминальном сервере постоянно почти 100% загрузка, в основном при формировании отчетов.... чтобы выяснить за что браться в первую очередь необходимо выявить клиентов, которые больше всего грузят терминальный сервер...Никто не сталкивался с такой задачей?

а что за сервер-то? что за база? SQL/не SQL - поподробнее. Т.к. у меня сервер с 2 камнями, одновременно пользователей 20-25 работает в 3 базах, загрузка около 20 процентов МАКСИМУМ!!!

А собственно какая разница в том, кто загружает проц? Хоть Иванов, хоть Петров - машине монопенисуально. Особенно когда есть серъезные подозрения, что Иванов с Петровым запускают отчеты не для того, чтобы процы грузить, а для того, чтобы работать (есть такие ненормальные юзвери - вместо того, чтобы анектоды пересказывать, они работают). Вряд ли инструкция, запрещающая Петрову работать потому, что он проц грузит, спасет ситуацию.Поэтому гораздо эффективнее не заниматься фигней, а искать узкие места. Начать с того, что 100% загрузка проца в таскменеджере ни о чем не говорит. Например если дисковая система IDE, то ресурсы проца запросто могут использоваться на ее обслуживание. Особенно когда мало памяти и система постоянно свопится.А что показывает счетчик Processor Queue Lenght объекта System?

Спасибо откликнувшимся. Щас все полностью опишу...пока описываю - не подскажите как эти счетчики смотреть?

Сервер:2*2,4 Ксеоны4 Гб Памяти2 винта скайзевых по 37,2 Гб - не в массиве, на одном стоит система, на другом лежит база.Размер базы: 1,35 Гб в ДБФ-е бухия 3.1 оччень переписанная фирма торговая документооборот большой.814 Гб только ДБФ-файлы в базе.

Для себя из 2-х возможностей (отимизировать запросы 1с и повышение производительности оборудования) выбрал второе.Теперь даже неудобно как-то.Некоторые отчеты (ОСВ по 10 счету-примерно 8млн ед.хранения-30к номенклатур) засаживали всю бухгалтерию на отдых. Купили серверок 7к у.е. (2*3Ггц с 2Мб кешем, памяти немного -ОЗУ 2Ггб, быстрые диски). Админ говорил не надо больше ОЗУ, лучше быстрые диски-оказался прав. Теперь 25 юзеров делая отчеты, если все дружно нажмут один и тот же, максимум 10-15минут делают. Проц загружен максимум на 1%. Если гигабитный свич поставить, наверное будут думать - зачем такой сервер купили.

Кеш для процессоров известен?

я не знаю, а где можно посмотреть?

То 3. Ну смотреть ессно в Perfomance Monitor. В таскменеджере показатели для домохозяек. Описания основных счетчиков можно посмотреть на http://www.sql.ru/articles/mssql/03121001PERF_COUNTERs.shtml. Или на http://www.sql.ru/articles/mssql/02111903PerformanceCounters.shtml.Конечно разобраться с ними не так просто - многие показатели взамосвязаны, многие цифры нужно уметь читать или сравнивать с некими "эталонными" значениями. Но это с опытом придет.Юзверей много? Вроде ресурсы сервера приличные - рыл на 20 хватать должно.

Если увеличение производительности процессоров путем увеличения частоты, кеша невозможно, то увеличения производительности дисковой системы приведет только к ухудшению ситуации. Т.е. ОЗУ, быстрая дисковая система завалит процессор и он не справится. Здесь, на форуме советуют снять гипертридинг. Может это разгрузит процессора.

То 2.Информация о том что Иванов постоянно отнимает более 20 процентов общих ресурсов может дать информацию к тому что посмотреть какие конкретно отчеты он запускает что бы их оптимизировать. Бывают такие Ивановы которые вообще не ценят общие серверные ресурсы и несмотря на то что им нужен отчет за 1 месяц они запускают за 5-ть лет и уходят пить кофе. А бывает что специфические настройки на локальной машине клиента приводят к тому что Иванов держит транзакцию дольше других в несколько раз и тем самым блокирует работу осталдьных(например включен одбс трейсинг). Да много чего бывает. Так что я не был бы так категоричен.

Всего 30-35 активных 20-25

То 5.Вот показательный пример того как выбирают оборудование вслепую. Надо было мониторить систему и четко знать что и с какими характеристиками покупать.

Еще можно в лог писать начало и окнчание формирования отчета. По этой инфе можно определить какие отчеты оптимизировать, а какие запускать только ночью.

ночью - это не выход :-) простите, а как данный счетчик по русски называется?

То 10. Фигня все это. Какой юзверь что запускает совершенно ясно из его должностных обязанностей и описания бизнес-процессов. Насколько часто тоже несложно определить. Опять же исходя из вышеописанного плюс частоты повторения процессов.Кроме того сложно учудить что-то с настройками терминального клиента так, чтобы он душил напрочь всю систему транзакциями. Именно о терминальном сервере мы и ведем речь.Далее - только сам Иванов знает, какой отчет и за какой период ему следует выполнять. Никакой человек в здравом уме и трезвой памяти не станет запускать отчет за ненужный ему период только для того, чтобы попить кофе. А если и запускает, то не админу опеределять нужность юзверю этого отчета и определять с помощью счетчиков

+ 15. perfmona степень его квалификации. Путь отдел по борьбе с персоналом этим занимается.А энергию админа предлагаю направить в мирное русло - не с юзверями бороться, а узкие места вычислять в системе.

2 нет, как раз наоборот. Может сложиться мнение, что задач для такого оборудования не хватат. А здесь следующее:Процессорная группа с таким кешем, как в , сожрет любую задачу(в рамках разумного), а дальше надо кешу удачно данные спрогнозировать, здесь гипертридинг как нельзя кстати, и шина должна быть с частотой соответствующей применяемым процессорам, а если с этим все в порядке, тогда дисковую систему можно применить шуструю. Вот тогда и загрузка процов может быть минимальна. Это просто плюс к квалифицированному выбору оборудования.

предрассудки...(не завалит)От производительности оборудования конечно зависит, но от производительности ОС-1Сэ значительно больше... отчеты этт ерунда, оне токо тормозят, а вот транзакции(ну можно и поумнее завернуть, тока я не силен в терминах, как та лошадь - все понимаю, а сказать неумею), особенно когда в модуле проведения обращения к куче регистров и куче доков/справочников и циклов в цикле штук 20...

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

+ 2 эти речи мне напоминают пояснения по выбору холодильника в устах продовца, которому сказали что и как говорить клиенту...

Проблема с транзакциями у меня практически устранилась после применения компоненты управления приоритетами... я не спорю - отчеты криво написаны..но мне оперативно нужно выяснить какие из них более крив написаны :-)

дак можно на куюнибудь машину(стороннюю от терма) монитор загрузки проца кажным усером навешать, там и позыришь в файле, могу подкинуть, тока сначало перепишу(но этт не быстро - лень) чтоб лог давал, а то он тока выводит в HTA(что-то вроде HTML) загрузку(процц, память и пр...) по типу таскманагера... хотя для терма в этом разе можно и перфоманс монитор, но он и сам неплохо подгружает процц...

диски в SCSI RAID зеркало +включить НТ обязательно+ копать код отчетов.На таком железе без проблем работают 35-40 пользователей.Найти и локализовать проблему на терминальном сервере проще простого,подключаешься удаленно к клиентам которые загружают процессор и смотришь что они делают.

То 15. Значит ты не работал с большими базами для которых простой 5-ть минут это чп. Если у тебя нет средств оперативного контроля то у тебя существенно больше рисков.Вообщем информация по загрузке пользователем является одной из самых важной информации в мониторинге производительности. По ней ты можешь устанавливать дальнейшие фильтры и получать более подробную,детальную информацию.Вообщем сейчас нет времени и желания спорить . Могу сказать что мои утверждения основаны на основании большого опыта решения подобных проблем. Если завтра будет эта ветка на плаву то я смогу рассказать очень много ситуаций из жизни.

завтра обязательно подниму.план у меня пока след.1) Вопреки желанию сисадмина перевести на Stripe массив - сейчас просто отдельно два винта стоят.2) Сделать дефрагментацию диска (26% фрагментировано);3) Переработать код отчетов.

Какой страйп? на сервере?! да еще при 100% загрузке при чтении?Я бы на месте админа тебя повесил на шлейфах. Nothing personal.

Как выявить кто сколько из юзеров в терминале грузит процTask manager показывает юзеров и все его процессыTask manager->processes->CPU time Но чтобы что-то улучшить в железе надо смотреть Perfomance Monitor,осознанно выбирая показатели для мониторинга.to >Т.е. ОЗУ, быстрая дисковая система завалит процессор и он не справитсябыстрые диски завалят?Бред.Полный.сравни скорость отдачи данных с винта и проц -ОЗУ.и учти что винту необходимо иногда еще перепозиционировать головку,и нажо ждать поворота диска чтобы прочитать нужный сектор.Хуже будет если проц будет ждать данные,намного.>но мне оперативно нужно выяснить какие из них более крив написаны.Смотреть текст отчетов ,там все видно лучше всего.

То 24. Я не знаю что значит "большая база" и потому не могу утверждать, что с ними работал :) И даже не могу судить о счетчиках, позволяющих сравнивать опыт. Кроме того я не знаю какое отношение имеет размер базы к ее производительности при условии ее грамотного проектирования :)Тем не менее 5 мин простоя - это действительно ЧП. И даже 2 мин. простоя крайне фигово. Особенно если перед бедним менеджером сидит недовольный клиент.Тем не менее у меня есть стойкое ощущение, что ты пытаешься тянуть веревку не с того конца. А именно вычисляя кто из 65 юзверей грузит систему. Я это могу сказать достаточно точно без всяких извращений по крайней мере для своей конторы - два заместителя руководителей продающих подразделений, занимающиеся анализом эффективности и планированием продаж. И даже знаю самые "тяжелые" отчеты, которыми они оперируют. А также самые "тяжелые" документы, их количество и кто из юзверей их проводит. Исключительно из статистики по документообороту и месту человека в цепочке бизнес-процессов. Причем "вес" отчета или документа уже можно прогнозировать на этапе проектирования.

извините если не правильно выразился, но чтобы 2 диска видились как один.

То 28. Убегаю нет времени.Ты подходишь к проблеме как 1С-ик и админ и нач отдела одновременно. т.е. ты хорошо знаешь систему ты хорошо знаешь какие у кого права. Во многих компаниях эти должностные обязанности разделены. Права и должностные обязанности и следовательно исп. функиционал часто меняются. Впрочем ладно , завтра обосную. убежал.

к 35 - 40 ?

да, приемлимо, больше 40 активных пользователей желателен RAID 10.

То 30. Ты будешь смеяться, но начальник отдела, админ и "одноэсники" у нас разделены. И к ним добавлены еще и администраторы баз данных. И у всех свои функции.Тем не менее если я проектирую систему, то знаю бизнес-процессы этой конторы, знаю систему, особенности ее поведения, системные ресурсы и пр. перечисленные выше прибамбасы.

"Сейчас не об этом." (с)Я о позырить чем занимаются 35 - 40 усеров...

а в чем проблема? подключаешься к сессии и смотришь что какая-то несознательная личность вместо остатков на текущий день по своему складу, строит оборотку по всем складам фирмы за 3 года..Я из-за этого в основных отчетах добавлял проверку на наличие фильтров и запрет полной детализации большинству пользователей.

проблеммы то нет, тока их(этих лишностей) как ты сказал 35 - 40

Завтра наступило.

У меня была такая хрень - копнул - оказалось, что эти свилоги засунули в каталог обмена досовский вариант шариков(Lines) и радостно стартили их в терминале.Написал докладную, всем дали по кепке. Проблема исчезла.ЗЫ. Дос приложения в терминале дают 100%-ную загрузку обоих процессоров.Похожего эффекта можно достигнуть, поставив на серваке прогу для пакетной записи CD. Эта скотина в каждом сеансе терминала пытается сканировать прожигалку на предмет наличия отформатированной компашке.Короче, ищи в запущенных процессах.

Спасибо всем за предложения. извини за недалекость - спутал Task Manager с Perfomance Manager :-)где-то к вечеру буду у клиента, тогда подниму ветку...