Одна из причин подвисания системы DIRECTUM (случай из практики)

Одна из причин подвисания системы DIRECTUM (случай из практики)

В некоторых случаях клиенты жалуются на проблемы с подвисанием всей системы DIRECTUM. Пользователи в этот момент не могут работать с клиентской частью.

Как правило, в такой ситуации необходимо искать причину либо в блокировках на SQL-сервере, либо проблема с ресурсами самого железа (сервер, сеть и т.д.).

В качестве примера, хотелось бы привести ситуацию, когда наблюдалось отсутствие значительных блокировок влияющих на работу всех пользователей, и в то же время пользователи испытывали сложности при работе с проводником.

 Что было предпринято: стандартный набор – записаны и проанализированы счетчики ОС и SQL сервера. Так вот, выяснилось, что в некоторые моменты времени происходило полное исчерпание всей доступной оперативной памяти на сервере. Здесь стоит отметить, что на SQL расположен один экземпляр SQL и более не стоит никакого дополнительного ПО.

С другой стороны SQL обычно использует всю доступную ему память под кэширование пользовательских запросов, если эти аппетиты не ограничить явно настройкой Minimum Server Memory и Maximum Server Memory.

Так вот в нашем случае, для нужд системы был оставлен запас не менее 10-12 ГБ (без учета потребления самим процессом sqlservr.exe), что теоретически должно было исключить резкое исчерпание доступной памяти. Но в нашем случае, 10 ГБ свободного пространства не спасали от этой проблемы.

Кроме того, ситуация усугублялась тем, что после нескольких таких «исчерпаний», кластер считал, что ноду недоступной (собственно логично) и переводил активность на резервную.

Далее одним из предпринятых шагов, для устранения проблемы, было уменьшение памяти, выделяемой SQL-серверу под кэширование пользовательских запросов, в нашем случае под нужды операционной системы и других компонент SQL-сервера было оставлено порядка 40 ГБ оперативной памяти.

Тем не менее ситуация с исчерпанием памяти повторилась через несколько недель:

Т.е. по сути уменьшив объем буферного пула SQL мы лишь отсрочили появление проблемы.

Не буду описывать в деталях, но было выяснено, что в некоторый момент времени, процесс sqlservr.exe потреблял памяти значительно больше, чем было доступно системе, что в итоге и приводило к подвисанию системы DIRECTUM и всего SQL-сервера

Далее был проведен детальный анализ для выяснения того, что именно приводит к увеличению потребления памяти процессом sqlservr.exe, в том числе с привлечением специалистов MicroSoft.

По результатам анализа было выяснено, что наиболее вероятной причиной является рост и заполнение занимаемой памяти в хранилище TokenAndPermUserStore, находящейся вне буферного пула, и как следствие, потребление всей доступной памяти на сервере.

Узнать размер хранилища TokenAndPermUserStore можно с помощью запроса:

И действительно, в моменты «исчерпания» всей доступной памяти значения TokenAndPermUserStore значительно отличались от обычного.

Одной из наиболее вероятных причин была названа утечка памяти, описанная в статьях http://support.microsoft.com/kb/2277078 и http://support.microsoft.com/kb/927396/en-us. И хотя в статьях идет речь о исправлении проблемы в  CU3 для 2008 и проблеме в 2005 версии SQL соответственно, по факту проблема имеет место быть и в 2008 R2 версии, хотя ее вероятность значительно снижена.

В качестве временных рекомендаций для устранения этой проблемы предложено периодически выполнять  очистку кэша этого хранилища:

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

Для чего написана эта статья?

Во-первых, поделится опытом с сообществом, возможно, кому-то этот опыт будет полезен.

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

Ну, а в-третьих, хотелось бы поинтересоваться, сталкивался ли кто-то с подобными проблемами, если да, то возможно был найден более изящный способ исправления ситуации?