Comments 12
Логический диск (Disk)
Средняя длина очереди чтения диска (Avg. Disk Queue Length)
Средняя длина очереди запросов к диску. Отображает количество запросов к диску, ожидающих обработки в течении определенного интервала времени. Нормальным считается очередь не больше 2 для одиночного диска. Если в очереди больше двух запросов, то возможно диск перегружен и не успевает обрабатывать поступающие запросы. Уточнить, с какими именно операциями не справляется диск, можно с помощью счетчиков «Среднее количество запросов на чтение» и «Средняя длина очереди записи на диск».
А что делать если это не одиночный диск? Или к примеру это вообще виртуальный диск? Какая тогда длинна очереди может считаться нормой?
А что делать если это не одиночный диск?
Грубая оценка — 2*количество дисков. Но вообще лучше просто смотрите на другие показатели, latency в первую очередь, объективно вас ведь не очередь как таковая интересует, а скорость работы (единственное что — тут надо иметь заранее померенную точку отсчета при слабой нагрузке).
Обращу особое внимание на то, что показания данного счетчика нельзя рассматривать в отрыве от других. Наиболее важным дополнительным показателем являются данные о задержках Более подробную информацию можно получить, например, здесь и здесь.
Файл подкачки
Эти рекомендации по файлу подкачки кочуют из гайда в гайд десятки лет, вы можете объяснить, ЗАЧЕМ? Ну ладно, 25 лет назад ОЗУ была роскошью, но сейчас-то? Файл подкачки размером с ОЗУ, серьезно? Даже если у меня ОЗУ сотни гиг? Да если он хотя бы частично будет использоваться, пользователи просто сожрут IT-отдел из-за адских тормозов. Вы можете привести хоть какой-то реальный кейс, когда это нужно?
Я не зря спросил про реальные кейсы. Вы можете показать счетчики производительности с нагруженного сервера с хотя бы десятками гиг ОЗУ, где файл подкачки рекомендуемого размера активно используется хотя бы наполовину, и при этом сервер не испытывает проблем с производительностью? Мне действительно интересно.
в контексте платформы SharePoint, работающей по особым правилам.
В чем конкретно заключается эта "особость" в контексте работы именно с виртуальной памятью и файлом подкачки? Подсистема памяти Windows как-то по особенному отрабатывает запросы именно от Sharepoint?
Вот давайте на примере — есть у меня сервер с сотней гиг ОЗУ. Я последовал рекомендациям и выставил файл подкачки в ту же сотню гиг. По мониторингу объем свободной физической памяти не менее 50%, своп практически не используется. Я беру и выставляю ему размер в 2 гига с возможностью роста до десяти. Что будет с моим сервером, станет ли он работать хуже, если да — то почему, если с использованием файла подкачки ничего не поменялось?
Дальше у меня растет нагрузка, и в один прекрасный момент я вижу, что свободной физической памяти становится менее 20%. Я не собираюсь ждать, пока всё встанет колом, и удваиваю объем ОЗУ. Должен ли я также удвоить своп? Что, после того, как ПО получило в свое распоряжение удвоенный объем ОЗУ, оно и в своп в два раза больше писать начнет? По какой причине? Можете показать, что это действительно так на практике?
А если (ну вдруг) у меня all-flash СХД и блейды, в каждом из которых полтерабайта ОЗУ, грузятся с неё же, я точно должен выбрасывать в помойку под блейд, где будет крутиться Sharepoint, эти самые полтерабайта? Зачем? Как это место будет использоваться?
Поймите меня правильно, гайд "сделай так, и всё будет зашибись" я и сам найду легко (как и любой вменяемый системный администратор). Вопрос в том, насколько эти гайды соответствуют реалиям современного мира. Если уж пишет системный архитектор, а не очередной технический писатель, под копирку переписавший предыдущий гайд (а тот, в свою очередь, слизан с предыдущего, и так много лет), то хотелось бы услышать аргументированные советы, а не просто "вот в гайдах так написано".
Использование файла подкачки всегда будет наносить ущерб производительности ввиду того, что скорость работы с ОЗУ существенно превышает работу с дисковой подсистемой.
Многочисленные службы и компоненты SharePoint (веб-приложение корпоративного портала, процессы, обеспечивающие работу службы поиска, службы Excel, системные задания и др.) активно работают с данными и используют память. Платформа SharePoint, действительно, имеет свои особенности, связанные с тем, что это ASP.Net x64 веб-приложение (в основе .Net Framework 4.x), что означает вполне конкретную архитектуру, важным компонентом которой является среда исполнения кода (CLR). CLR использует специализированные механизмы управления выделением и перераспределением сегментов виртуальной памяти. Работа служб, компонентов, обработка пользовательских запросов на портале, — все эти действия связаны с обработкой серверного кода, содержащего обращение к всевозможным объектам внутри этого кода. Даже в случае отсутствия утечек памяти ввиду ошибок в коде, допущенных разработчиками, удаление объектов из оперативной памяти специальным компонентом CLR, — сборщиком мусора, — не гарантирует моментальное освобождение сегментов памяти. Существует временной разрыв между двумя этими операциями из-за особенностей работы сборщика мусора. С учетом особенностей работы служб и компонентов SharePoint, CLR Майкрософт рекомендует размер файла подкачки и его размер – не мене 100% от размера ОЗУ, что связано с тем, что при таком соотношении сборщик мусора меньше использует управляемую память и меньше нагружает ЦП.
Средства ОС Windows Server позволяют настроить параметры виртуальной памяти так, чтобы вообще не использовался файл подкачки. Да, вы можете увеличить объем ОЗУ, оставив без изменений ранее установленный размер файла подкачки. Поддерживать всегда соотношение 1:1 или 1:1,5 не является строго обязательным для всех без исключений размеров ОЗУ на серверах SharePoint и носит рекомендательный характер. В случае, если файл подкачки не используется или его размер минимален, у ОС теряется всякая возможность выгружать данные неактивных процессов из ОЗУ на диск и возврат обратно при продолжении работы с нею или она серьезно ограничена. Наличие файла подкачки позволяет более управлять размещением данных, востребованных в тот или иной момент времени, обеспечивая более эффективное использование быстродействующей ОЗУ в случае возникновения потребностей приложений, превышающих объем этой ОЗУ.
Пример 1. Ресурсоемкие операции загрузки файлов больших размеров, воспроизведение видео на портале, обход контента службой поиска, кастомные решения, связанные с обработкой списков и библиотек с большим кол-вом элементов/файлов и многие другие нередко приводят к резким всплескам объемов используемой памяти. В одно прекрасное утро HR разместили новость, содержащую видео длительностью около 10 мин на главной странице портала, с утра практически одновременно ее решили просмотреть порядка 600 человек, при этом ввиду ошибки в действиях системного администратора в тот же период времени был запущен полный обход контента службой поиска, обычно занимавший 2-2,5 часа. При этом сервис новостей являлся бизнес-критичным, т.к. публиковались выступления топ-менеджеров, знакомство с которыми должно было проходить в течение 1-2 дней после публикации. Ранее работа портала была стабильна и особых проблем не возникало, на серверах по 16 Гб ОЗУ. За счет наличия файла подкачки внезапный всплеск нагрузки прошел почти безболезненно, сервис продолжил работу. Были отдельные обращения о снижении скорости работы на портале. У системного администратора была возможность проанализировать причины и остановить обход.
Пример 2. Более 15 000 пользователей портала, активно осуществляющих поиск по порталу. Этот сервис бизнес-критичный. В системе развернули несколько новых решений под SharePoint, работа которых была связана с обработкой больших списков (содержащих большое кол-во элементов). Ввиду особенностей выделения сегментов памяти CLR и сборки мусора приложениями ASP.Net возможны ситуации постепенного нарастания зарезервированных объемов памяти, требуемые для работы одного и того же приложения, проявляющиеся постепенно, и нарастающие со временем. С точки зрения конечных пользователей это проявляется, как правило, в постепенном снижении производительности при работе на корпоративном портале. В корпоративной сети применили новую групповую политику, в результате чего были урезаны в правах некоторые учетные записи. Каких-либо ошибок не наблюдалось при работе на портале, но решения предусматривали дополнительные действия и ведение журналов и запись сообщений об ошибках при возникновении исключений. Оперативно увеличить объем ОЗУ не представлялось возможным, клиенту обратился с просьбой оперативно выяснить у устранить причины заметного снижения производительности работы на портале. Время на коммуникации плюс время на работу специалиста на анализ причин, плюс внесение изменений в настройки AD. Весь этот временной промежуток работа пользователей на корпоративном портале продолжалась.
150%, указанное мною и рекомендуемое Майкрософт, на практике хорошо себя зарекомендовали. Обычно этих пределов достаточно для того, чтобы выиграть время и принять решение относительно какой-то внештатной ситуации. Подчеркну, что эта рекомендация дана в привязке к типовым размерам ОЗУ на серверах SharePoint (16-24-32).
PLE, наоборот, наглядно показывает, когда место в кэше закончилось — он просто резко обрывается вниз. При этом он может не падать до пресловутых 300 мс, но все равно показывать «пилу» — это означает, что данные постоянно вымываются из кэша. Поэтому рекомендуется смотреть не на абсолютное значение этого показателя, а на его динамику — если он постоянно обрывается, у вас явно не хватает памяти для кэша (buffer pool) и надо либо увеличивать место (т.е. добавлять памяти), либо заниматься тем, что в этот кэш помещается — т.е. оптимизировать запросы так, чтобы они делали меньше избыточных чтений
Подробнее, например, тут
Мониторинг SharePoint 2013/2016: ключевые счетчики производительности