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
  • Коллеги про службы рассказали очень подробно и добавить нечего, но не забывайте про Distributed Cash, который очень ресурсоемкий.

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

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

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

    6 августа 2019 г. 6:27
  • Использование 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