Мы находимся в трудном положении, у нас есть размещенный сервер со следующими характеристиками:
OS: Windows Server 2008 R2 Enterprise SP1 64bit
Processor: Intel Xeon X7550 @ 2GHz (8 processors)
RAM: 16GB
Файловая система находится в SAN или NAS (не уверен).
Мы наблюдаем очень странные проблемы, когда пользователь открывает файл .xslb размером 25 МБ, что иногда занимает буквально 60–120 секунд. Сервер просто медленный для отличия.
Ресурсы не привязаны к ресурсам, процессор никогда не вскакивает, много оперативной памяти ... просто странно медленно.
Наш ведущий изучает проблему в течение нескольких недель, но не может ничего показать. Есть ли утилита, которую я могу запустить самостоятельно, которая поможет отследить нашу проблему?
я нашел Советник по производительности сервера V1.0 Есть ли опыт его использования?
В конечном итоге за это отвечает наш хост, но у нас уже 1 месяц, и наши пользователи теряют терпение. Любые советы были бы полезны.
(вы имеете в виду xlsb, а не xslb?)
Для быстрого просмотра «способны ли мои диски справляться с моими запросами»: откройте Performance Monitor и добавьте AverageDiskQueueLength счетчик для этого диска (логический или физический в порядке). В общем, оно не должно превышать 10: грубое обобщение, но поможет вам отличить хорошее от плохого. Длина очереди диска обычно должна быть от 0 до 1, но на действительно перегруженных серверах я видел, как она поднимается до сотен тысяч и остается там. Это просто счетчик количества запросов, ожидающих ввода-вывода на диске, чтобы принять их для обработки.
Но зачем вообще смотреть на дисковый ввод-вывод? Вы знаете, что это медленно, поэтому для меня взгляд на perfmon означает исключать диски как проблема. Счетчик задержки диска, вероятно, должен оставаться под волшебный 20 мс.
Для более полного обзора я бы использовал PAL (Анализ производительности журналов), фантастический инструмент, в котором вы его запускаете, сообщаете ему, какой тип «рабочей нагрузки» вы выполняете, и он выдает файл конфигурации для монитора производительности. Импортируйте этот файл в perfmon, запустите в течение 24 часов в обычный день, затем возьмите вывод журнала и импортируйте его в PAL, который выдаст красивый сводный отчет в формате HTML с использованием рекомендаций MS и реальной информации, чтобы помочь вам выявить потенциальные проблемы. Вот еще над чем подумать:
Почему вы уверены, что за такую медленную производительность отвечает сервер?
В последний раз, когда мне сообщали об этой "проблеме", это был файл Excel размером 40 МБ с более чем 200 сводными таблицами (и дюжиной внешних ссылок), которые необходимо было вычислить. на клиентской машине каждый раз его открывали. Перейдите на рабочую станцию, загрузите файл Excel, откройте диспетчер задач и наблюдайте за загрузкой процессора локальной машины при открытии файла.
В моем случае для открытия файла потребовалось 87 секунд при полной загрузке процессора на двухпроцессорной четырехъядерной системе i7. Как только я подтвердил это, я вернул проблему туда, где она и принадлежала, а именно к тому идиоту, который создал электронная таблица при таком большом количестве записей и вычислений он может задушить мэйнфрейм. Готов поспорить на хорошие деньги, в твоем случае проблема та же. Электронная таблица слишком объемна, чтобы клиентские ПК могли обрабатывать ее своевременно, что происходит, когда конечные пользователи пытаются удаленно выполнять какие-либо технические операции - они не делают это удаленно правильно, и в результате страдают все.