Я проверил сервер SQLS2008 с помощью Profiler в течение одного дня ... накладные расходы, похоже, не беспокоили этого нового клиента, который есть у моей компании. Они используют устаревшее приложение VB6 в качестве интерфейса. Они испытывают тайм-ауты при высоком использовании ОЗУ SQLS. В настоящее время сервер работает под управлением x64 sqls2008 на виртуальной машине с почти 9 ГБ ОЗУ. Параметр максимальной памяти сервера SQL Server в настоящее время установлен на 6 ГБ.
Я поместил результаты трассировки в таблицу и запросил их с помощью этого запроса.
ВЫБЕРИТЕ TextData, ApplicationName, читает
FROM [TraceWednesday] WHERE textdata не null и EventClass = 12 GROUP BY TextData, ApplicationName, читает ORDER BY читает DESC
Как я и ожидал, некоторые значения очень высокие.
Top Reads, in pages.
2504188
1965910
1445636
1252433
1239108
1210153
1088580
1072725
Правильно ли я полагаю, что верхний (2504188 страниц) составляет 20033504 КБ, что примерно составляет ~ 20 000 МБ, 20 ГБ? Эти запросы часто выполняются, и их выполнение может занять некоторое время. В конце концов оперативная память израсходована из-за увеличения размера кеша, и тайм-ауты возникают, когда SQL не может так сильно «разбрасывать» страницы в буферном пуле. Расходы растут. Правильно ли я понимаю?
Я читал, что мне нужно настроить связанный T-SQL и создать соответствующие индексы. Очевидно, что сокращение операций ввода-вывода заставит SQL Server использовать меньше оперативной памяти. ИЛИ, может быть, это может просто замедлить процесс пережевывания всей оперативной памяти. Если будет прочитано намного меньше страниц, может быть, все будет работать намного лучше, даже при высокой загрузке? (меньше времени на замену и т. д.)
В настоящее время наш единственный вариант - перезапускать SQL один раз в неделю, когда использование оперативной памяти велико, и таймауты внезапно исчезают. SQL снова дышит.
Я уверен, что многие администраторы баз данных были в такой ситуации ... Я спрашиваю, прежде чем я начну выкапывать весь плохой T-SQL и помещать индексы туда и сюда, что еще я могу сделать? Любой совет, кроме того, что я знаю (пока немного ..)
Очень признателен.
Лео.
Вообще говоря, SQL Server будет выделять столько памяти, сколько ему разрешено, без использования файла подкачки. Эта память используется как кэш для страниц данных. (Существует также кеш планов и некоторые другие вещи, но я думаю, что это выходит за рамки этого вопроса.) Это распределение имеет эффект «использования» всей свободной памяти на сервере и часто беспокоит людей, которые не знаком с SQL Server.
Не беспокойтесь о количестве памяти, беспокойтесь о физическом чтении страниц (которое происходит с диска) и логическом чтении страницы (которое происходит из памяти. Логическое чтение страницы не так проблематично, как чтение физической страницы, потому что оно происходит намного быстрее, но они по-прежнему занимают ограниченное количество времени. Даже если у вас был терабайт ОЗУ и вся ваша база данных была кэширована в памяти, процессорам все равно потребуется определенное количество времени, чтобы просмотреть все ваши данные. Это всегда лучше, если в SQL Server будет меньше данных для просмотра, даже если они полностью кэшированы в ОЗУ.
Доступ к данным замедляется, когда ваши данные не помещаются в ОЗУ и серверу приходится читать их с диска.
В вашей ситуации похоже, что SQL читает 20 ГБ данных. Это не поместится в 6 ГБ кэша данных, поэтому SQL Server будет повторно использовать память, загружая данные с диска поверх «старых» данных, которые, по его мнению, больше не нужны. Если другой запрос от другого пользователя поступает через 1 секунду, SQL, возможно, придется вернуться на диск, чтобы заново прочитать эти «старые» данные.
Настройка запросов и улучшение индексации должны привести к тому, что SQL Server будет иметь меньше данных для просмотра, а это означает, что более вероятно, что данные, которые необходимо просмотреть, могут остаться в кэше данных, в ОЗУ, и меньше данных придется читать из disk в случае, если требуемые данные отсутствуют в кэше данных.
Увеличение ОЗУ («бросание проблемы с оборудованием») также означает, что есть больше шансов сохранить эти данные в ОЗУ, НО обычно вы можете получить большее улучшение (может быть, в 10 раз или больше, если вам повезет и индексирование действительно плохо для начала - я видел улучшения в 60 раз и выше), чем вы можете, увеличив объем оперативной памяти, доступной для кэширования данных (обычно невозможно увеличить объем оперативной памяти более чем в 2 или 3 раза без нового сервера или создания большого напряжения, которое не было запланировано для вашей среды виртуальной машины.) Конечно, обычно проще / быстрее подключить новые микросхемы RAM, чем настраивать запросы, но иногда у вас нет выбора .
Другой вещь, которую стоит сделать заключается в том, чтобы регулярно обновлять статистику вашего индекса. В средах без администратора баз данных это обслуживание часто оказывается на второй план. Устаревшая статистика может привести к тому, что механизм запросов будет использовать неэффективные планы, и это особенно заметно / болезненно для больших таблиц.
Последнее замечание: перезапуск SQL Server очистит все данные кэша, и эти данные придется перезагружать с диска по мере поступления запросов после перезапуска SQL Server. Обычно это означает, что после перезапуска SQL Server работает медленнее, а не быстрее. SQL-серверы, которые работают быстрее после перезапуска, обычно испытывают чрезмерную блокировку (перезапуск сервера отбрасывает все блокирующие и заблокированные соединения) или они наблюдают бурю запросов, которые заставляют его читать много-много данных с диска (часто эти запросы вызываются обеспокоенными пользователями, которые повторно отправляют один и тот же запрос несколько раз с интервалом в несколько секунд или минут, потому что это «занимает слишком много времени»).