none
Как настроить IIS и SQL, чтобы снизить потребление ОЗУ? RRS feed

  • Вопрос

  • Здравствуйте. Есть Ферма Sharepoint 2016 состоящая из 4х серверов:
    1) DB1 - WM, 8 ядер по 2,3 GHz, 14 Гб RAM, Wndows Server 2016. Установлен SQL 2017;
    2) SHPT1 - WM, 8 ядер по 2,3 GHz, 16 Гб RAM, Wndows Server 2016. Установлен Sharepoint 2016 с ролями - передний план и распределенный кэш;
    3) SHPT2 - WM, 8 ядер по 2,3 GHz, 16 Гб RAM, Wndows Server 2016. Установлен Sharepoint 2016 с ролями - Сервер приложений и поиск;
    4) OWA1 - WM, 8 ядер по 2,3 GHz, 12 Гб RAM, Wndows Server 2016. Установлен Office Online Service.

    На DB1 процесс sqlservr.exe съедает до 92% ОЗУ.
    На SHPT1 процессы w3wp.exe съедают до 80% ОЗУ.
    На SHPT2 процессы noderunner.exe съедают до 80% ОЗУ.
    На OWA1 процессы w3wp.exe съедают до 80% ОЗУ.

    В тот момент, когда потребление ОЗУ становится больше 70% - ферма начинает сильно подтормаживать, спасает только перезагрузка всех серверов. 
    Я уверен, что потребление ОЗУ можно как-то умереть, но не смог найти нормального мануала, по тонкой настройке. Может кто-то может что-то подсказать?
    5 августа 2019 г. 14:17

Ответы

  • Добрый день,

     Думаю сначала надо выяснить что вызывает "тормоза". Проверьте обращения к диску на каждом из серверов, в частности Queue Length, и каким файлам. Если уходит в своп, то в зависимости от роли сервера (WFE или APP), то либо добавлять памяти, либо дополнительный сервер на роль. И да, поиск стоит выделить в отдельную роль.

    Планирование нагрузки можно посмотреть здесь:

    https://docs.microsoft.com/ru-ru/sharepoint/administration/capacity-planning

    6 августа 2019 г. 8:06
  • Потребление памяти SQL можно стандартно лимитировать - https://mstechtalk.com/set-memory-limits-sql-server/

    Но не вижу у вас какого-либо overperfomance в разрезе ОЗУ. Возможно также вам имеет смысл подумать о внедрении дополнительного WFE и APP.

    6 августа 2019 г. 6:27
  • Коллеги про службы рассказали очень подробно и добавить нечего, но не забывайте про Distributed Cash, который очень ресурсоемкий.

    Windows Server AppFabric 1.1 может стать причиной чрезмерного потребления памяти на уровне операционной системы. Это затрагивает систему распределенного кэша, поэтому при выделении 16 ГБ памяти на сервере распределенного кэша должно быть не менее 34 ГБ памяти, включая 2 ГБ резервной памяти для операционной системы. 

    6 августа 2019 г. 8:11
  • Использование swap ещё не говорит о недостатке памяти, ранее коллега писал:

    "Это распространенное заблуждение что файл подкачки используется при недостатке физической памяти.

    На деле файл подкачки используется для освобождения физической памяти с целью ее использования для ускорения работы компьютера, например кэшированием.

    Так что выгрузка неиспользуемых страниц из памяти в файл подкачки является нормальным и желаемым явлением."

    Просто следуйте рекомендациям - https://docs.microsoft.com/en-us/sharepoint/technical-reference/the-paging-file-size-should-exceed-the-amount-of-physical-ram-in-the-system

    6 августа 2019 г. 8:13
  • Добрый день

    ресурсы есть поиск.

    нужно проанализировать какой контент больше всего меняется.

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

    1. Проверяем что происходило и сколько времени заняло.

    2. можно посмотреть какой именно контент индексировался.

    относительно недавно столкнулся с проблемой, когда в двух коллекциях происходила синхронизация групп/пользователей с внешней системой. синхронизация была кривовата и происходило большое обновление групп и пользователей, что приводило к пересчету прав и постоянно грузило (у меня 4 сервера SP):

    1. проц и сеть на сервере WFE

    2. сеть и диск на SQL

    3. немного проц и сеть Search сервер.


    мой блог не много о SharePoint


    7 августа 2019 г. 6:26
    Модератор

Все ответы

  • SQL съест столько памяти, сколько ему выделено - и это нормально.

    Сколько клиентов работает с фермой? SharePoint голый или с расширениями (Project, Reporting, OLAP etc)? Размер баз какой примерно?

    5 августа 2019 г. 14:52
  • В компании 700 сотрудников, но одновременно не больше 200 используют портал. 

    Голый sharepoint. 

    Если я правильно понял, как смотреть размер, то 3 БД контента:

    BD1 - 35894,09 МБ

    BD2 - 1567,77 МБ

    BD3 - 31133,00 МБ

    + БД служебные. 

    Для баз контента настроен RBS.

    6 августа 2019 г. 5:29
  • Потребление памяти SQL можно стандартно лимитировать - https://mstechtalk.com/set-memory-limits-sql-server/

    Но не вижу у вас какого-либо overperfomance в разрезе ОЗУ. Возможно также вам имеет смысл подумать о внедрении дополнительного WFE и APP.

    6 августа 2019 г. 6:27
  • Алексей, за инструкцию по настройке памяти огромное спасибо!

    WFE  - это Web Front End server. А APP это кто?

    6 августа 2019 г. 7:14
  • Сервер приложений. Вам кстати поиск тоже можно вынести на отдельную машину.
    6 августа 2019 г. 7:30
  • Может быть есть какая-то зависимость или инструкция количество пользователей/количество серверов в ферме? Просто изначально по гайдам майкрософт мы укладывались в понятие "небольшая организация" и топология из 4х вроде как нормально должна вытаскивать наши запросы. 
    6 августа 2019 г. 7:39
  • Добрый день,

     Думаю сначала надо выяснить что вызывает "тормоза". Проверьте обращения к диску на каждом из серверов, в частности Queue Length, и каким файлам. Если уходит в своп, то в зависимости от роли сервера (WFE или APP), то либо добавлять памяти, либо дополнительный сервер на роль. И да, поиск стоит выделить в отдельную роль.

    Планирование нагрузки можно посмотреть здесь:

    https://docs.microsoft.com/ru-ru/sharepoint/administration/capacity-planning

    6 августа 2019 г. 8:06
  • Коллеги про службы рассказали очень подробно и добавить нечего, но не забывайте про Distributed Cash, который очень ресурсоемкий.

    Windows Server AppFabric 1.1 может стать причиной чрезмерного потребления памяти на уровне операционной системы. Это затрагивает систему распределенного кэша, поэтому при выделении 16 ГБ памяти на сервере распределенного кэша должно быть не менее 34 ГБ памяти, включая 2 ГБ резервной памяти для операционной системы. 

    6 августа 2019 г. 8:11
  • Использование swap ещё не говорит о недостатке памяти, ранее коллега писал:

    "Это распространенное заблуждение что файл подкачки используется при недостатке физической памяти.

    На деле файл подкачки используется для освобождения физической памяти с целью ее использования для ускорения работы компьютера, например кэшированием.

    Так что выгрузка неиспользуемых страниц из памяти в файл подкачки является нормальным и желаемым явлением."

    Просто следуйте рекомендациям - https://docs.microsoft.com/en-us/sharepoint/technical-reference/the-paging-file-size-should-exceed-the-amount-of-physical-ram-in-the-system

    6 августа 2019 г. 8:13
  • Добрый день

    ресурсы есть поиск.

    нужно проанализировать какой контент больше всего меняется.

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

    1. Проверяем что происходило и сколько времени заняло.

    2. можно посмотреть какой именно контент индексировался.

    относительно недавно столкнулся с проблемой, когда в двух коллекциях происходила синхронизация групп/пользователей с внешней системой. синхронизация была кривовата и происходило большое обновление групп и пользователей, что приводило к пересчету прав и постоянно грузило (у меня 4 сервера SP):

    1. проц и сеть на сервере WFE

    2. сеть и диск на SQL

    3. немного проц и сеть Search сервер.


    мой блог не много о SharePoint


    7 августа 2019 г. 6:26
    Модератор
  • Большое спасибо всем за ответы!

    Alexey Klimenko, память в SQL лимитировал. Возможно в будущем действительно вынесу поиск в отдельную машину.

    Mikhail Efimov, где и как можно посмотреть «обращения к диску на каждом из серверов, в частности Queue Length, и каким файлам. »

    Mikhail Zhuikov, Выполнил настройку распределённого кэша согласно https://docs.microsoft.com/ru-ru/SharePoint/administration/manage-the-distributed-cache-service у меня как раз как в примере 16 ГБ.

    Alexey Klimenko, на всех серверах размер файла подкачки выбирается автоматически по выбору ОС.



    • Изменено Дмитрий Ф 29 августа 2019 г. 19:17 убрал лишнее
    29 августа 2019 г. 19:16
  • Kaplin Vladimir, есть контент, у которого меняется много прав и есть контент, индексация которого выполнять довольно долго. 

    Скриншот

    Когда стал смотреть, какой именно контент индексируется, убрал с помощью фильтра успешные результаты и осталось:

    - элементы, где «Объект удален»

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

    - элементы, где «Этот элемент усечен, так как количество символов в выводимых данных превысило максимально допустимое.»

    - элементы, где «Этот элемент состоит из нескольких частей и (или) может иметь вложения. Были проиндексированы не все части элемента. Непроиндексированные части недопустимы либо пропущены намеренно (например, изображения). Также возможно, что удаленный сервер не отвечал на запросы во время индексирования этих частей.»

    - элементы, где «Достигнуто предельное число скачиваний файла. Убедитесь, что может быть выполнен обход контента всего текста документа.»

    Это норма или с этим нужно что-то делать?

    29 августа 2019 г. 19:34