Всем привет.
Вот столкнулся с проблемой - на терминальном сервере постоянно почти 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-ть лет и уходят пить кофе. А бывает что специфические настройки на локальной машине клиента приводят к тому что Иванов держит транзакцию дольше других в несколько раз и тем самым блокирует работу осталдьных(например включен одбс трейсинг). Да много чего бывает. Так что я не был бы так категоричен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(23) к 35 - 40 ?

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

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

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

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

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

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

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

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