Мы разработали систему с экраном поиска, который выглядит примерно так:
http://demo1.nsourceservices.com/images/logos/stackoverflow1.png
Как видите, есть довольно серьезные функции поиска. Вы можете использовать любую комбинацию статусов, каналов, языков, типов кампаний, а затем сузить их по имени и т. Д.
Затем, как только вы выполнили поиск, а в нижней части появятся отведения, вы можете отсортировать заголовки.
Запрос использует ROWNUM для создания схемы разбиения на страницы, поэтому мы одновременно возвращаем только около 70 строк.
Проблема
Несмотря на то, что мы возвращаем только 70 строк, происходит очень много операций ввода-вывода и сортировки. Это имеет смысл, конечно.
Это всегда вызывало небольшие всплески в очереди на диск. Он начал замедляться еще больше, когда мы достигли 3 миллионов отведений, и теперь, когда мы приближаемся к 5, очередь диска иногда привязывается к одной или двум секундам подряд.
Это на самом деле все еще работоспособно, но в этой системе есть еще одна область с чувствительным ко времени процессом, скажем для простоты, что это веб-служба, которая должна очень быстро обслуживать ответы, иначе это приведет к превышению времени ожидания на другом конец. Пики дисковой очереди вызывают замедление этой части, что приводит к превышению времени ожидания вниз по течению. Конечный результат - это фактически отбрасывание телефонных звонков в нашем автоматическом IVR на основе VoiceXML, и это очень плохо для нас.
Что мы попробовали
Мы пробовали:
- Задачи обслуживания, которые сводят количество проводов в системе к минимуму.
- Добавлены очевидные индексы, чтобы помочь.
- Запустил мастер настройки индекса в профилировщике и применил большинство его предложений. Один из них собирался более или менее воспроизвести всю таблицу внутри индекса, поэтому я настроил ее вручную, чтобы сделать немного меньше.
- Добавлено больше оперативной памяти на сервер. Это было немного низко, но теперь у него всегда есть что-то вроде 8 гигабайт бездействия, и сервер SQL настроен на использование не более 8 гигабайт, однако он никогда не использует больше 2 или 3. Я нашел это странным. Почему бы просто не поместить всю таблицу в оперативную память? Всего 5 миллионов лидов, и места достаточно.
- Рассмотрены планы выполнения запросов. Я вижу, что на данный момент индексы, по-видимому, в основном выполняют свою работу - около 90% работы выполняется на этапе сортировки.
- Рассматривал разбиение таблицы Leads на другой физический диск, но у нас нет ресурсов для этого, и, похоже, в этом нет необходимости.
В заключении ...
Часть меня чувствует, что сервер должен справиться с этим. Пять миллионов записей - это не так много, учитывая мощность этого сервера, который представляет собой неплохое четырехъядерное ядро с 16 гигабайтами оперативной памяти. Тем не менее, я могу видеть, как часть сортировки вызывает прикосновение к миллионам строк, чтобы вернуть горстку.
Так что вы сделали в подобных ситуациях? Мой инстинкт заключается в том, что нам, возможно, следует сократить некоторые функциональные возможности, но если есть способ сохранить это в неприкосновенности, это спасет меня от войны с бизнес-подразделением.
Заранее спасибо!