Использование Монитора ресурсов: дисковая подсистема
Для удобства рассмотрения мы будем использовать скриншот Монитора ресурсов (рис. A), запущенного на производственном сервере под управлением Windows Server 2008 R2. На этом сервере установлен Exchange Server 2010 со всеми ролями, поэтому он нуждается в большой дисковой подсистеме с приемлемой производительностью. (Примечание: как и все другие наши серверы, этот работает в виртуальной машине на базе VMware vSphere 4.1.)
Начнем с общего обзора консоли. Большую часть окна занимают статистические показатели, о которых я подробно расскажу ниже. Справа расположены графики, каждый из которых представляет один из важных показателей производительности дисковой подсистемы.
Ниже я подробно рассмотрю каждый показатель. Я не буду повторяться: если показатель присутствует в нескольких местах, я упомяну его только в первый раз.
Процессы с дисковой активностью
В разделе «Процессы с дисковой активностью» (Processes With Disk Activity) перечислены все запущенные процессы, использующие ресурсы хранения. В списке показано имя исполняемого файла и ряд связанных с ним статистических показателей.
• «Образ» (Image) – имя исполняемого файла. Это имя процесса, активно использующего диск.
• «ИД процесса» (PID) – идентификатор процесса. Может пригодиться для управления процессами с использованием других утилит или для поиска процессов в Диспетчере задач (Task Manager).
• «Чтение (байт/с)» (Read (B/sec)) – среднее количество прочитанных процессом байтов в секунду за последнюю минуту.
• «Запись (байт/с)» (Write (B/sec)) – среднее количество записанных процессом байтов в секунду за последнюю минуту.
• «Всего (байт/с)» (Total (B/sec)) – среднее количество использованных байтов в секунду за последнюю минуту.
Информация, которая приводится в этом разделе, не особенно актуальна для диагностики – она лишь позволяет выяснить, какие процессы потребляют больше всего ресурсов диска. На рис. A, например, можно заметить, что больше всего операций чтения с диска выполняет процесс с именем «DPMRA.exe».
В разделе «Работа диска» (Disk Activity) собраны более полезные для диагностики сведения. Самый ценный показатель – пожалуй, время ответа, поскольку его можно оценить, даже не зная исходной конфигурации дисковой подсистемы.
Справа от названия раздела расположены два небольших индикатора. Зеленый показывает текущий дисковый ввод/вывод (Disk I/O), то есть, количество передаваемых в данный момент данных), а синий – максимум активного времени дисковой подсистемы (Highest Active Time).
• «Файл» (File) – имя файла, используемого процессом. Здесь указывается полный путь к файлу, чтобы его легче было найти.
• «Приоритет ввода/вывода» (I/O Priority) – приоритет операций ввода/вывода.
• «Время ответа (мс)» (Response Time (ms)) – время отклика диска в миллисекундах. Как правило, чем ниже этот показатель, тем лучше. В целом, время ответа менее 10 мс свидетельствует о хорошей производительности. Не страшно, если этот показатель время от времени превышает отметку в 10 мс, но если системе постоянно приходится дожидаться ответа дисковой подсистемы более 20 мс, это может свидетельствовать о наличии проблем, а конечные пользователи в таком случае заметят ощутимое снижение быстродействия. Если время ответа достигает 50 мс и выше, значит, проблема действительно серьезная. На рис. A, как видите, время ответа составляет 5-6 мс, так что дисковая подсистема функционирует исправно, если судить по этому показателю.
В разделе «Запоминающие устройства» (Storage) содержатся следующие сведения:
• «Логический диск» (Logical Disk) – буква диска.
• «Физический диск» (Physical disk) – выбранный для мониторинга физический диск.
• «Активное время (%)» (Active Time (%)) – сколько времени диск проводит, активно обслуживая запросы, в противовес времени простоя. Если активность диска постоянно очень высока (скажем, более 80%), это может указывать на наличие потенциальных проблем, связанных с ресурсами хранения. Если пользователи жалуются на низкое быстродействие, а активное время постоянно составляет 100%, возможно, необходимо увеличить объем дисковой подсистемы или установить более производительные накопители.
• «Свободно (МБ)» (Available Space (MB)) – количество свободного пространства в текущем томе диска.
• «Всего (МБ)» (Total Space (MB)) – общий объем тома.
• «Длина очереди диска» (Disk Queue Length) – средняя длина очереди диска. Длина очереди показывает количество ожидающих выполнения запросов (на чтение и запись) в любой момент времени. Если этот показатель довольно высок, это может свидетельствовать о том, что скорость вращения диска недостаточна для удовлетворения запросов приложений или что дисковая подсистема имеет слишком низкую производительность и не справляется с запросами. Однако чтобы оценить, насколько высок показатель, необходимо хорошо понимать, как создается базовый том в SAN. Каждый диск, из которых складывается базовый том, предоставляет дополнительные ресурсы, которые учитываются при расчете длины очереди (проще говоря, чем больше дисков, тем выше будет длина очереди).
Уровень RAID и размер страйпа тоже влияют на длину очереди, что дополнительно усложняет задачу. Однако если компьютер оснащен всего одним диском, а длина очереди постоянно превышает 2, система нуждается в дополнительных ресурсах хранения. Длина очереди более 5 свидетельствует о наличии серьезных проблем. Если вам известно, из скольких дисков состоит базовый том, умножьте количество дисков на 2, чтобы очень грубо, приблизительно, прикинуть максимально допустимую длину очереди. К примеру, если в системе десять дисков, а длина очереди равна 18, значит, все в порядке.
Графики – очень полезный инструмент. В верхнем графике показана скорость обмена данными между диском и операционной системой за последнюю минуту. Зеленая кривая показывает текущий суммарный ввод/вывод, а синяя – активное время диска за этот период. На остальных графиках показана длина очереди для каждого диска в системе.
На сервере Exchange, который показан в моем примере, используется четыре диска (тома SAN). С учетом структуры базовых томов SAN в этом массиве, никаких проблем, связанных с длиной очереди, не возникает.
До встречи во второй части
Автор: Scott Lowe
Перевод SVET
Оцените статью: Голосов
Источник
Большое среднее время ответа диска
Столкнулся с тем, что жесткий диск нагружен на 100% и показывает очень большое среднее время ответа. При этом компьютер долго запускается и зависает. В смарте ничего плохого не вижу.
Переустановка ОС не помогает.
Система: Windows 10 Pro 1909
Материнская плата: MSI x470 Gaming Plus Max
Жесткий диск: Seagate Barracuda 2TB ST2000DM008
Высокое время ответа жесткого диска
Время ответа жёсткого диска в среднем составляет 5000 мс. Активное время 100%. Помогите.
Скорость записи HDD падает, а среднее время ответа возрастает
Здравствуйте, купил новый ST4000DM004 и теперь с ним мучаюсь. Картина следующая: Файловая система.
Среднее время ответа консультанта
Помогите, пожалуйста, найти среднее время ответа на сообщение по определенной тематике. Возможно.
Большое время кадра
Здравствуйте , снова прошу помощи у знатоков ) Ближе к сути ! Конкретно вижу цифры в CS GO , но.
xiadosw, не знаю, обратили ли вы внимание что у вас еще и интеренет загружен. Что-то качается со скоростью 36 мегабит))) Что бы это могло быть? Не обновления ли случайно? ))) или какой-то другой виндовский мусор?
И от того, что вы ставите лицензию — это дерьмище к сожалению не страдает. Поэтому лично я себе делал вот так
кроме этого
Большое время работы
Добрый вечер, форумчане! Возникла проблема : у программы чтения файла очень большой runtime(пишу.
Большое время перерисовки OpenGL
Здравствуйте, я студент 2 курса, учусь на программиста, решил начать писать какую ни будь.
Ttfb время слишком большое
Здравствуйте. Кто-нибудь знает, почему ttfb время слишком большое? От чего это бывает и как.
Задержка на очень большое время
Интересно, кто сталкивался с данным вопросом. Каким образом можно реализовать задержку на 5 часов.
Большое время выполнения запроса
Здравствуйте, уважаемые форумчане! Имеется функция: function.
Время ответа
Всем привет Как можно сократить время ответа сервера? Кэш используется, оптимизированы скрипты.
Источник
Из-за чего периодически увеличивается среднее время ответа HDD?
Ситуация: понадобилось залезть во внутренности ноутбука. После сбора Windows запустилась, я её выключил, не дождался завершения процесса выключения и потушил всё зажатием кнопки питания. Собрал окончательно корпус, и после запуска Windows начинала процесс восстановления но безуспешно. Я пытался откатиться до точки востановления, но это не удалось из-за ошибки 0x800700XXX точный код вспомнить не могу, но там было что-то про повреждённые разделы.
В итоге переустановил Windows, всё запустилось. Но ноутбук очень сильно тормозит, причём периодически. При перезапуске тормоза происходят разной степени тяжести. Как я понимаю они из-за высокого времени ответа HDD. Так, как в диспетчере задач он загружен на 100%. И время ответа колеблется от 10мс до 15000мс. Чаще всего держится в районе 1000 — 3000.
Я запустил chckdsk /r /f
После проверки лог ничего не показал.
Потом другой утилитой произвёл проверку. Скриншот прикрепляю. То что она показала, мне не совсем понятно, и я не могу локализовать проблему. Модель диска — ST1000LM048
Я бы рад его поменять, если проблема именно в нём. Но я не уверен, возможно криво встала Windows или ещё какой косяк. Драйвер устройства я ставил с официального ресурса производителя ноутбука (MSI GP72 7REX).
Вот такой лог системных событий
Ищу ответ на вопросы:
-Почему такая низкая скорость ответа HDD?
-Связанны ли тормоза с ней?
Источник
Пожалуйста, перестаньте отслеживать среднее время на сайте!
Привет! Меня зовут Сергей Захарченко, я руковожу агентством web-аналитики «Dopamine Analytics» и сегодня я расскажу вам почему стоит забыть про среднее время на сайте.
Во времена unit-экономики, продуктовых метрик и data-driven подхода многие из нас продолжают слепо доверять бесполезным показателям, которые далеко не всегда информативны, а зачастую попросту бессмысленны.
К таким метрикам относятся среднее время на сайте, глубина просмотров и показатель отказов. Эти три фундаментальные качественные характеристики трафика преследуют нас в большинстве систем аналитики, и многие digital-специалисты продолжают буквально молиться на них, не понимая, как на самом деле они работают.
В данной статье я постараюсь подробно рассказать о среднем времени на сайте, чтобы дать возможность маркетологам сконцентрироваться на действительно важных показателях.
Этот показатель призван рассказать нам о том, как долго пользователь взаимодействует с тем или иным сайтом. И большинство из нас уверено, что чем дольше пользователи сидят на сайте — тем лучше этот самый сайт и тем более целевая аудитория на него приходит. Самое страшное начинается тогда, когда время на сайте начинает сокращаться: горе-маркетологи начинают искать причину этого явления, тратя драгоценные рабочие часы на войну с ветряными мельницами. И даже если причина будет найдена, профит от нее сгодится только для одного: объяснить своему начальнику (чтобы он объяснил своему), что по факту ничего страшного с глобальной точки зрения не произошло и можно жить дальше.
Чаще всего изменение среднего времени сеанса происходит из-за появления новых источников трафика, которые увеличивают/сокращают этот показатель по всем каналам суммарно. Плюс, это может произойти если поменялся «стандартный» для этого сайта user-journey (раньше пользователи заходили на главную страницу, а теперь рекламные кампании ведут на страницу продукта и т.д.).
Также могут измениться доли desktop/mobile пользователей или даже поло-возрастная структура трафика. Причин может быть бесконечное множество, и в большинстве случаев это означает лишь одно: на сайте что-то изменилось. Это хорошо или плохо? Скорее всего – никак.
Единицы из нас понимают, как на самом деле считается время, проведенное пользователями на сайте. Почти все уверены, что время сеанса — это разница между моментом открытия и закрытия сайта (что было бы вполне логично), но системы аналитики НЕ ЗНАЮТ когда мы закрываем вкладку в браузере! По умолчанию они знают только время открытия очередной страницы (или клика по кнопке, если это было предварительно настроено), и высчитывают время на сайте как «Время открытия последней страницы» минус «Время открытия первой страницы». Таким образом, если пользователь на вашем сайте посмотрел только 1 страницу, то время его сеанса в Google Analytics будет 0 секунд.
Внимание, вопрос: какое среднее время будет отображаться в Google Analytics, установленном на одностраничном лендинге?
Правильный ответ: ноль секунд. Это происходит потому, что за сеанс пользователи просматривают одну единственную страницу, соответственно с систему аналитики попадает только одна временная точка (момент открытия сайта) и вычислить разницу не представляется возможным.
Но ведь на большинстве одностраничных лендингов Google Analytics показывает среднее время больше 0 секунд?! Да, это происходит из-за того, что пользователь мог перезагрузить страницу или выполнить какое-то целевое действие. Следите за руками: если было 100 сеансов по 0 секунд (пользователи просматривали только одну страницу) и 1 сеанс во время которого пользователь случайно обновил страницу спустя 25 минут (1500 секунд), то расчет будет происходить следующим образом:
(общее кол-во секунд)/(общее кол-во сеансов)
Т.е. (0+1500)/(100+1) = 15 секунд в среднем проводили пользователи на сайте. Какой вывод можно сделать из получившейся цифры? Никакого. И это нормально!
Другой пример: вы перешли из соц.сетей на статью vc.ru, которая представляет из себя длинный лонгрид (на 10 минут вдумчивого чтения). После открытия страницы вы действительно изучали ее на протяжении нескольких минут, после чего закрыли сайт. В этом случае время вашего сеанса в Google Analytics будет составлять те же самые 0 секунд, т.к. вы не открыли больше никаких страниц на сайте vc.ru и не совершили никаких целевых действий. Означает ли это то, что статья написана плохо? Нет, просто так устроен подсчет времени в системах аналитики.
Существуют ли способы исправить такой странный подход в подсчете времени? Да, вы можете настроить отправку событий «пустышек», которые будут срабатывать каждые 15 секунд пока пользователь находится на сайте, тем самым вы дадите возможность Google Analytics’у посчитать разницу между открытием первой страницы и возникновением последнего события «пустышки». Многие владельцы сайтов именно так и поступают, что позволяет им знать более точное время взаимодействия пользователей с контентом. Но опять же, в большинстве случаев это попытка решить несуществующую проблему, т.к. даже при этом условии упускается из вида такая фундаментальная вещь, как паттерны поведения пользователей.
Представим себе пользователя, который зашел на сайт news.yandex.ru, увидел там заголовок новости про повышение прожиточного минимума, после чего он перешел на сайт tass.ru (с полным текстом новости), за 9 секунд увидел заветную цифру (11 012 рублей), ради которой переходили по ссылке и закрыл сайт. В итоге время сеанса = 9 секунд (допустим, что на tass.ru настроено улучшенное отслеживание времени). При этом новость состояла из 2 000 символов, на чтение которых нужно потратить ориентировочно 1,5 минуты. Разве плохо, что пользователь смог получить информацию, ради которой он пришел на сайт за 9 секунд, а не за полторы минуты? Нет, это нормально.
В большинстве случаев ответ будет «нет». Особенно нет смысла отслеживать динамику изменения этого показателя от месяца к месяцу (как поступает большинство маркетологов). Мой многолетний опыт показывает, что среднее время «по больнице» на обычных сайтах составляет от 1 до 3 минут (в зависимости от тематики), и увеличение/уменьшение этого показателя на 20-30 секунд ни на что не повлияет, а трудозатрат на поиск причин этих изменений уходит довольно много.
Что же делать в этой ситуации? Перестать обращать внимание на изменение времени на сайте и начать ориентироваться на конверсионные метрики: те, которые показывают увеличилась прибыль вашего сайта или уменьшилась.
Источник
