Проблема производительности ASP.NET/SQL 2008

Мы разработали систему с экраном поиска, который выглядит примерно так:

_{(источник: nsourceservices.com )}

Как вы можете видеть , есть довольно серьезный поисковый функционал. Вы можете использовать любую комбинацию статусов, каналов, языков, типов кампании, а затем сузить ее по названию и т. Д.

Затем, когда вы выполните поиск и потенциальные клиенты появятся внизу, вы сможете отсортировать заголовки.

Запрос использует ROWNUM для выполнения схемы разбиения по страницам, поэтому мы возвращаем только около 70 строк за раз.

Проблема

Несмотря на то, что мы возвращаем только 70 строк, происходит очень много операций ввода-вывода и сортировки. Это, конечно, имеет смысл.

Это всегда вызывало небольшие всплески в Disk Queue. Он начал замедляться еще больше, когда мы набрали 3 миллиона лидов, а теперь, когда мы приближаемся к 5, Disk Queue иногда задерживается на секунду или две подряд.

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

Что мы пробовали

Мы пробовали:

• Задачи обслуживания, которые сокращают количество потенциальных клиентов в системе до минимума.
• Добавлены очевидные индексы, чтобы помочь.
• Запустил мастер настройки индекса в профилировщике и применил большинство его предложений. Один из них собирался более или менее воспроизвести всю таблицу внутри индекса, поэтому я вручную настроил его, чтобы сделать немного меньше.
• Добавил больше оперативной памяти на сервер. Это было немного мало, но теперь у него всегда что-то вроде 8 гигабайт в режиме ожидания, а SQL-сервер настроен на использование не более 8 гигов, однако он никогда не использует больше 2 или 3. Я нашел это странным. Почему нельзя просто поместить всю таблицу в ОЗУ? Всего 5 миллионов лидов, и места предостаточно.
• Облили планы выполнения запросов. Я вижу, что на данный момент индексы, похоже, в основном выполняют свою работу - около 90% работы происходит на этапе сортировки.
• Рассматривается возможность разделения таблицы Leads на другой физический диск, но мы этого не делаем. У меня есть для этого ресурсы, и, похоже, в этом нет необходимости.

В заключение ...

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

Так что ты делал в подобных ситуациях? Я считаю, что нам, возможно, следует сократить некоторые функции, но если они есть ' Это способ сохранить это в неприкосновенности, что спасет меня от войны с бизнес-подразделением.

Заранее спасибо!