Sql поставщик общей памяти ошибка времени ожидания 258

Обновлено: 03.07.2024

Я просто ищу предложения о том, что других неполадок я могу сделать, чтобы попытаться отследить.

мы запускаем SQL Server 2008 R2 в кластере. Существует несколько различных серверов, которые подключаются к нему, начиная от Windows server 2003 до 2008 разные сорта.

вот что я сделал до сих пор:

запустите трассировку SQL длительных запросов и тупиков. это не показывает никаких тупиков во время проблем, и длительные запросы совпадают с нашими ошибками тайм-аута, но выглядят побочным эффектом, а не причиной. Запросы, которые являются очень основными, которые обычно возвращаются мгновенно, иногда занимают 30, 60 или 120 секунд. Это происходит в течение нескольких минут, а затем все берет трубку и отлично работает после этого.
используйте монитор производительности для отслеживания соединений пула соединений. это иногда показывает некоторые всплески в количестве соединений около времени таймаутов, но все еще даже не на полпути к пределу соединения по умолчанию 100. Опять же, здесь нет ничего, что указывало бы на причину.
отдельные веб-приложения в различные пулы приложений. мы попытались сузить приложения, которые, как мы думали, могут быть основными проблема (самая болтливая и т. д.) и помещает их в отдельные пулы приложений, но это, похоже, ни на что не влияет или не помогает нам сузить что-либо.
мониторинг использования диска на SQL Server. мы сделали некоторый мониторинг на SQL server и не видим никаких всплесков или каких-либо признаков проблем, когда эти таймауты происходят.
Проверено TempDB не было причиной проблемы.

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

выполнить трассировку SQL длительных запросов и тупиков. Это показывает, нет тупики во время проблем и длительные запросы все совпадают с нашими ошибками тайм-аута, но выглядят как побочный эффект, и не причина. Запросы, которые являются очень основными, которые обычно возвращают мгновенно в конечном итоге занимает 30, 60 или 120 секунд, чтобы работать время от времени. Этот происходит в течение нескольких минут, затем все поднимается и работает нормально после этого.

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

дополнительная точка для копания-это автоматический размер приращения вашего журнала транзакций и базы данных. Установите их на фиксированный размер вместо процента от текущих файлов. Если файлы становятся выше, время, необходимое для выделения достаточного пространства, будет в конечном итоге дольше, как тайм-аут транзакции. И ваш db останавливается.

проблемы с производительностью сводятся к CPU, IO или блокировке. Похоже, вы исключили ИО. Я бы предположил, что CPU не проблема, так как это база данных, а не номер cruncher. Таким образом, остается lock contention.

Если вы можете выполнить sp_who2 во время тайм-аута запросов, вы можете использовать столбец BlkBy для трассировки обратно к удержанию блокировки, которую все остальные ждут. Поскольку это происходит только несколько раз в день, у вас могут возникнуть проблемы с ловлей данные если вы используете это вручную, поэтому я предлагаю вам настроить автоматическую систему для сброса этого вывода на регулярной основе или, возможно, для запуска исключений тайм-аута приложения. Монитор активности также можно использовать для наблюдения за ухудшением отзывчивости запросов в режиме реального времени, как это было предложено peer.

Как только вы найдете длительный запрос и приложение, которое его выполняет, вы можете немедленно разрешить domino тайм-аутов, сократив тайм-аут для этого одного приложение ниже всех остальных (сейчас должно быть больше). Затем, вы должны проверить код, чтобы определить лучшее решение. Вы можете сократить время блокировки, зафиксировав транзакцию раньше в sproc, или уменьшить блокировку, требуемую запросом чтения, с помощью подсказок, таких как NOLOCK или UPDLOCK.

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

прокрутите вниз до SynAttackProtect и вы будет отображаться по умолчанию в windows server 2003 sp1 и далее, чтобы включить эту функцию по умолчанию. Это механизм защиты DDOS в действии, и отсутствие регистрации, что он запускает делает его невероятно трудно обнаружить, когда ваш сервер делает это.

потребовалось 3 дня в лаборатории MS, прежде чем это было выяснено.

вы упомянули 100 conenctions, у нас было приложение, которое постоянно подключалось, выполняло запросы, а затем отключалось, оно не удерживало соединения открытыми. Этот это означало, что у нас было несколько потоков на каждой машине connectiong, делая это, 10 машин, несколько потоков на машину, и считалось, что достаточно различных соединений последовательно делается / отбрасывается, чтобы вызвать защиту.

находитесь ли вы на этом уровне (поскольку это не четко определенный порог MS), трудно сказать.

Как и другие плакаты предложили, похоже у вас есть проблема блокировок. Мы столкнулись с подобной проблемой несколько недель назад; однако наш был гораздо более прерывистым и часто очищался, прежде чем мы могли получить DBA на сервер для запуска sp_who2, чтобы проследить проблему.

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

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

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

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

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

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

Я предлагаю вам глубоко взглянуть на супер крутой SQL Server в Динамические Административные Представления характеристика:

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

эта статья является хорошим началом с DMVs, хотя она была написана для SQL 2005 (DMVs feature first appearance):Устранение Неполадок Производительности Проблемы в SQL Server 2005, особенно главы "блокировка".

мой опыт работы с этими проблемами (не на SQL Server, хотя) заключается в том, что перегруженная многозадачность часто является причиной проблемы. Если аналогичные / подключенные данные / таблицы запрашиваются (почти) одновременно многими соединениями, СУБД может возникнуть проблема с сохранением всей изоляции при проверке. Это не такая большая проблема использования диска, как заставить некоторые соединения ждать, пока что-то будет сделано другими. Синхронизация очень дорогая с точки зрения использования ЦП.

в 100 на мой взгляд, связей слишком много. (По моему опыту снова) даже 20 соединений, запрошенных одной машиной, могут быть чрезмерно оптимистичными.

звучит так, как будто у вас уже есть ответ, но в случае, если вам нужно еще одно место, чтобы посмотреть, вы можете проверить размер и активность вашего temp DB. У нас была такая проблема однажды на клиентском сайте, где несколько раз в день их производительность ужасно ухудшалась и иногда тайм-аут. Проблема оказалась отдельным приложением, которое так сильно колотило БД temp, что это влияло на общую производительность сервера.

удачи с продолжением устранение неполадок!

Я видел подобные проблемы, если антивирус был установлен на SQL server. Функции автоматического обновления AV синхронизировали сервер и не позволяли достаточно процессора для SQL Server.

кроме того, вы разместили небольшое приложение на самом SQL server, которое проверяет, что соединения могут быть сделаны или запускает очень простой SQL, например "SELECT GETDATE();"? Это исключило бы сетевые возможности.

поскольку я каждый день устраняю неполадки в рамках своей работы, вот что я хотел бы сделать:

поскольку это SQL Server 2008 R2, вы можете запустить SQLDiag, который поставляется как часть продукта. Вы можете обратиться к книгам Онлайн для получения более подробной информации. Вкратце, захватите сценарий трассировки и блокатора на стороне сервера.

после захвата трассировки найдите событие "внимание". Это будет spid, который получил ошибку. Если вы фильтруете по SPID, вы увидите RPC: завершенное событие перед "вниманием". Проверь время вон там. Это время 30 секунд? Если да, то клиент ждал 30 секунд, чтобы получить ответ от SQL и получил "тайм-аут" [это настройка клиента, поскольку SQL никогда не остановится и соединение]

теперь проверьте, действительно ли запрос, который выполнялся, должен занять 30 секунд?

Если да, то настройте запрос или увеличить тайм-аут от клиента.

Если нет, то этот запрос должен ждать каких-то ресурсов (заблокирован)

в этот момент вернитесь к блокирующему скрипту и проверьте временные рамки, когда" внимание " пришло

выше предполагается, что проблема с SQL Server не связана с сетью!

проблема в том, что из-за плохого запроса время выполнения запроса занимает более 60 секунд или блокировка таблицы

проблема выглядит как взаимоблокировка; у нас есть запросы, которые блокируют запросы для завершения во времени. Тайм-аут по умолчанию для запроса составляет 60 секунд, и после этого у нас будет SQLException для тайм-аута.

проверьте журналы SQL Server на наличие блокировок. Другой способ решить проблему, чтобы увеличьте время ожидания для объекта Command (Temp Solution).

эти серверы виртуализированы? В другом посте я читал о SQL server, работающем иногда очень медленно из-за отсутствия достаточной памяти. Это, в свою очередь, было вызвано так называемым шаром памяти, который виртуализатор использовал для ограничения объема памяти, используемой этим виртуальным сервером. Это было трудно найти, потому что давление на физическую память не имело ничего общего с самим SQL server.

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

при запуске точно такой же сохраненный proc с тем же аргумент из среды SQL Server Management Studio запрос выполняется за 15 секунд. Но при запуске его из нашего приложения с использованием вышеуказанной установки истекло время ожидания SqlCommand. Один и тот же SqlCommand (с разными, но сопоставимыми данными) успешно работал в течение нескольких недель, но теперь он не удался с любым аргументом таблицы, содержащим более 20 или около того целых чисел. Мы сделали трассировку и обнаружили, что при запуске из объекта SqlCommand база данных потратила все 90 секунд на получение блокировок и будет вызывать процедура в момент ожидания. Мы изменили время CommandTimeout, и независимо от того, какое время мы выбрали, сохраненный proc будет вызываться только в самом конце этого периода. Таким образом, мы предполагаем, что SQL Server бесконечно получал одни и те же блокировки снова и снова, и что только тайм-аут объекта команды заставил SQL Server остановить свой бесконечный цикл и начать выполнение запроса, к этому времени было слишком поздно для успеха. Моделирование этого же процесса на аналогичном сервер, использующий подобные данные, не обнаружил такой проблемы. Нашим решением была перезагрузка всего сервера баз данных, после чего проблема исчезла.

таким образом, кажется, что есть некоторая проблема в SQL Server, где некоторый ресурс получает кумулятивно потребляется и никогда не освобождается. В конце концов, при подключении через SqlConnection и запуске SqlCommand с использованием параметра таблицы SQL Server переходит в бесконечный цикл получения блокировок. Цикл завершается тайм-аутом Объект SqlCommand. Решение заключается в перезагрузке, по-видимому, восстановлении (временное?) здравомыслие для SQL Server.

значение по умолчанию-30 секунд, как указано в приведенном выше url-адресе Microsoft, попробуйте установить это на большее количество секунд или, возможно, -1 перед открытием соединения, чтобы увидеть, решает ли это проблему.

Это может быть настройка в веб.config или app.файлы конфигурации или на вас файлы конфигурации applicaiton / web server.

(3) Увеличьте шаг роста базы до 515мб, на файл журнала транзакций тоже самое, ограничений на максимальный размер лога быть не должно.
Далее в локальных политиках безопасности найдите строку локальные политики\назначение прав пользователей\выполнение задач по обслуживанию томов и добавьте в свойствах пользователя от которого запускается служба MS SQL Server. По дефолту это "NT Service\MSSQLSERVER"
Эта настройка позволит MS SQL Server мгновенно инициализировать место под создание новой базы и мгновенно расширять размер существующих.

Дополнительно можно системную базу temp разбить на несколько файлов (4 рекомендуется для крупных внедрений) и установите для каждого файла начальный размер 1024 и шаг роста 512.

Далее в локальных политиках безопасности найдите строку локальные политики\назначение прав пользователей\выполнение задач по обслуживанию томов и добавьте в свойствах пользователя от которого запускается служба MS SQL Server. По дефолту эт (4) Ошибка появляется реже, но все равно падает. Судя по диспетчеру, sql съедает около 10Гб(ограничение), rphost 2-3,5Гб.

(6) А что за ограничение? или это предположение?

"Сервер 1С Предприятия" х64 или х32?

(7) Память у SQL Сервера обязательно ограничивать. Иначе процедурный кэш забьёт всю память в сервере, которая есть.
Вопрос про разрядность сервера 1С очень хороший, кстати.

(6) меня напрягла цифра 10) потом уже перечитал первые посты и увидел что ограничение на оперативу.

(4) а можно немного подробнее, про рекомендацию разбиения. Встречал пару раз такое, но толком никто не смог объяснить что это дает и почему 4, а не 2 или 5.
или может есть занимательно чтиво на эту тему?

(19)Это делается для ускорения ввода/вывода. Когда с tempdb работают несколько сессий возникает внутренняя конкуренция за ресурсы - соединения с файлом.
Лучше ставить от 2 до 8 в зависимости от количества ядер процессора (логичестких). Больше 8 ставить не нужно.
Минимальный размер выставляется 1024 для базы и 512мб лог для небольших баз - в большинстве случаев этих цифр более чем достаточно, если конечно у вас база измеряется не сотнями ГБ

толком никто не смог объяснить что это дает и почему 4, а не 2 или 5.

Выше параллельность и скорость работы, в общем случае.

Смысл рекомендации такой же как и у MaxDoP = 1 для MS SQL - потому что, в большинстве случаев, 4 (по количеству физических ядер процессора) лучше чем 1 и имеет больший смысл чем 9-10.
На самом деле оптимальное значение необходимо подбирать экспериментальным путём, проводя тестирование после каждого изменения настроек. Но, это дорого, долго и не все это умеют.

В общих чертах описано и на итс, и в библиотеке типовых вопросов крупных внедрений. А на подробное описание в разделе MS SQL ссылку уже дали.

Я бы вернулся на 8.3.8 и ограничил максимум оперативы для SQL.

У Вас уже стоит ограничение по памяти.

Ваш случай это 2я половина текста. Основная суть процесс х32 не может работать с адресным пространством достаточным для обработки массива информации. Соответственно - это переполнение. Совет перейти на х64 севрер 1с или ниже, есть вариант как пофиксить таблицы конфигурации.
Вот сам текст.

1С:Предприятие 8.2. Лицензия на сервер (x86-64)

По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.

Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):
1. Выключить все фоновый задачи у всех баз

В 8.1.11 появился переключатель «запрет на фоновые задания» в
момент создания базы.

Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском — вещь в себе — и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять — возможно проблема «уйдет».
2. Перезапустить сервер

Делать резервное копирование рекомендую при любых действиях, когда может потребоваться «возврат» к предыдущему состоянию данных

4) снимаем базу с поддержки, выгружаем cf

убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение) убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение)

вот пример работоспособности этого приема

1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FR OM dbo.Config WH ERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.

можно попробывать и более радикальный шаг здесь:
удаляем (в менежмент консоли) в базе данных таблицу «config»

DR OP TABLE [dbo].[Config]
5) делаем «загрузить конфигурацию» (не объединение) из cf

Следует отметить, что ошибки, содержащие именно код 80004005, встречаются постоянно. У них есть особая классификация, которую при желании можно найти в соответствующей литературе.

Сопутствующая проблема и методы её решения

С ситуацией, описанной ранее, тесно связана ещё одна, происходящая параллельно. Выглядит она так: 10007066.

Выглядит она таким образом:

Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005.

Когда происходит ошибка 1с hresult clr 80004005, программа завершает свою работу в аварийном режиме.

Если вы ознакомитесь во время загрузки программы со специальным журналом (речь идёт о технологическом журнале), там есть табличка, содержащая информацию об этих хранилищах.

С помощью средств MS SQL Server Query Analizer нужно найти в табличке несколько колонок image и сделать для каждой следующий запрос

select top 10 DATALENGTH(_Fld4044 from _InfoReg4038 order by DATALENGTH(_Fld4044) desc

При этом, со стороны стандартных проверок, проводимых платформой (chdbfl), поступит информация о том, что база полностью в порядке.

Ошибка выделения памяти hresult 80004005 (на английском это out of memory for query result 1с) может происходить вследствие различных причин, имеющей общую черту. Для системы 1С это, прежде всего, недостаток оперативной памяти. Если говорить точнее, речь идёт о некорректном применении возможностей памяти, поэтому для решения задачи лучше использовать несколько косвенных алгоритмов.

Необходимо сделать рестарт (перезапуск) сервера. Таким образом памяти, которая доступна для работы, временно станет больше. Также есть возможность воспользоваться сервером в 64 разряда, содержащем приложения.

Исходя из опыта, ошибка СУБД hresult 80004005 чаще определяется двумя факторами:

данные хранятся в хранилище значений (реквизите);
в таблице конфигураций содержатся двоичные данные объёмом более 120 мегабайт.

Когда советы от сотрудников 1С не приносят результата (ошибка 1с hresult 80004005 остаётся), попробуйте воспользоваться другой пошаговой инструкцией:

используйте все базы, включив у них все фоновые задачи;
в 8.1.11. должен появиться переключатель о запрете на фоновые задачи (во время создания базы);
сделайте перезапуск сервера.

воспользоваться инструментами sql и сделать бэкап;
снять базу с поддержки;
выгрузить cf.

Есть ещё один способ, с помощью которого неопознанная ошибка субд hresult 80004005 может быть исправлена. Нужно открыть конфигуратор и снять конфигурацию, не сохраняя её. Далее, сохранив, нужно поместить её в отдельный файл без сохранения её изменённого вида.

Выполните в SQL операцию, предназначенную для конкретной базы:

DELETE FROM dbo.Config WHERE DataSize > 125829120

После выполнения этой команды проведите загрузку сохранённой конфигурации.

Что касается радикальных шагов, используемых в особо трудных ситуациях, иногда помогает такая схема:

"Устранение неполадок SQL Server" чтение заметок - управление памятью

Самонастраивающееся ядро СУБД (самонастраивающееся ядро СУБД)

В течение долгого времени Microsoft была привержена самонастраивающейся (самонастраивающейся) базе данных SQL Server для снижения общей стоимости владения продуктом. Начиная с SQL Server 2005, SQL Server управляет использованием памяти динамически, и при настройке использования памяти нет необходимости перезапускать ядро базы данных.

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

Использование этих элементов конфигурации для замены значений по умолчанию зависит от версии операционной системы, версии SQL Server, доступной физической памяти и архитектуры процессора.

Как SQL Server выделяет память

Сам SQL Server предназначен для использования максимально возможного объема памяти. В нормальных условиях он не освобождает выделенную память, если ОС не запускает и не устанавливает флаг уведомления о нехватке памяти (флаг уведомления о ресурсах).

SQL Server 2005 SQLOS добавила специальный поток для мониторинга уведомлений о памяти (Memory Notification), выдаваемых ОС (это также одна из функций самонастройки).

В ОС есть два типа уведомлений о памяти:

Объем памяти: SQL Server может увеличить использование рабочего набора и использовать больше памяти

Мало памяти: ОС испытывает нехватку памяти, SQL Server высвобождает часть памяти ОС

Если оба типа ОС уведомлений о памяти не установлены, это означает, что использование памяти стабильно и SQL Server продолжит работу в существующем пространстве процесса. Но эта функция не была доступна до Windows 2003 и SQL Server 2005.

Классификация давления памяти в соответствии с Memory Pressure - Classified ：

Сколько памяти может использовать SQL Server, зависит от:

Количество установленной на сервере памяти
Ограничение памяти системы Windows
Архитектура SQL Server (32 бит / 64 бит)
Элементы конфигурации управления использованием памяти SQL Server
Версия SQL Server

Ограничения 32-битного VAS

Windows запускает все процессы в VAS. 32-разрядный процесс может адресовать только до 4 ГБ памяти, и эти 4 ГБ памяти разделены на пространство режима ядра (режим ядра) и пространство пользовательского режима (режим пользователя). По умолчанию для каждого окна выделяется 2 ГБ.

Режим ядра в основном используется для ОС, а пользовательский режим используется для текущего выполняемого процесса приложения (например, SQL Server).

1. Выделение VAS в пользовательском режиме и VirtualAlloc

VAS пользовательского режима объемом 2 ГБ, зарезервированный SQL Server, будет отправлен только при выделении физической памяти. Это через Windows API VirtualAlloc.

Для 32-разрядного SQL Server или Windows вызов VirtualAlloc возвращает 32-разрядный указатель, поэтому SQL Server может использовать только 2 ГБ VAS пользовательского режима.

Память, выделенная через VirtualAlloc, не обязательно является реальной физической памятью. Когда выделенная память фиксируется, это будет память RAM. При отправке памяти окна должны подтвердить, что общий объем памяти, предоставленный SQL Server и другими прикладными процессами, <= (RAM + файл подкачки).

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

2. Распределение небуферного пула (MemToLeave)

Большая часть памяти, занимаемой SQL Server, выделяется пулу буферов для кэширования данных и планов запросов. Когда требуются непрерывные страницы размером более 8 КБ, небуферные пулы выделяются через многостраничные распределители, такие как LinkedServer, стек потоков, CLR, резервный кеш и т. Д.

Чтобы обеспечить достаточный объем памяти, не являющейся буферным пулом, 32-разрядный SQL Server при запуске резервирует часть VAS. Зарезервированная часть также называется MemToLeave, size = MaxWorkerThread * 0,5 МБ + 256, где MaxWorkerThread = (ProcessorCount-4) +256.

По умолчанию MemToLeave = 256 * 0,5 + 256 = 384 МБ, поэтому размер области кеша составляет примерно (2–384 МБ) = 1664 МБ.

3. Настройка VAS (Настройка VAS)

На сервере с 4 ГБ памяти можно использовать настройку VAS, чтобы VAS пользовательского режима занимал 3 ГБ, а VAS режима ядра можно уменьшить до 1 ГБ.

Следует отметить, что уменьшение объема памяти в режиме ядра уменьшает системные PTE (Page Table Entires), вызывая нестабильность системы, и в то же время уменьшается объем памяти, к которой может обращаться SQL Server.

Чтобы реализовать настройку VAS в Windows 2008, используйте BCDEdit / set IncreaseUserVa [значение] (значение между 2048 и 3072).

4. AWE(Address windowing extension)

На серверах с оперативной памятью более 4 ГБ вы можете использовать AWE, чтобы позволить SQL Server использовать память. Чтобы использовать AWE, вам необходимо сначала включить PAE и использовать BCDEdit / set PAE ForceEnable, чтобы включить его в Windows 2008.

Затем SQL Server включает «AWE Enabled», и учетная запись службы должна иметь разрешение на блокировку страниц памяти («Блокировать страницы в памяти», назначьте этому пользователю разрешение в групповой политике).

AWE расширяет указатель управления памятью с 32 до 36 бит, поэтому он может адресовать 64 ГБ памяти. А при выделении памяти используйте функцию AllocateUserPhysicalPages вместо VirtualAlloc. Этот API напрямую выделяет физическую память через PTE.

Память AWE может использоваться только пулом буферов, и она заблокирована и не выгружается на страницы, поэтому лучше всего установить «max server memory», чтобы ограничить объем.

5. -g параметры запуска

На 32-битных платформах вы можете использовать параметр запуска SQL Server -g, чтобы указать объем памяти MemToLeave, тем самым увеличивая объем памяти, выделяемой MemToLeave. Но в то же время это также уменьшит выделение буферного пула.

Используйте 64-битный SQL Server

Теоретический верхний предел VAS на 64-битной платформе может достигать 16EB = 16000000 ТБ. Фактически, X64 ограничен 8 ТБ, а IA64 - 7 ТБ. При использовании более 4 ГБ ОЗУ SQL Server не требует дополнительной настройки.

Память, используемая SQL Server, может быть отправлена только через VAS, поэтому вся память не блокируется и выгружается на страницы. Таким образом, когда ОС испытывает нехватку памяти, память может быть выгружена на диск (жесткая страница).

При таком достаточном количестве VAS теория распределения MemToLeave больше не применима, и параметр запуска -g также не имеет смысла.

Кэш процедур (кэш процедур) также будет хранить больше, что может вызвать проблему чрезмерного кеширования процедур.

Параметры конфигурации 64-разрядной памяти SQL Server

1. Минимальная / большая память сервера

SQL Server предоставляет два фактических уровня элементов конфигурации, которые ограничивают размер пула буферов: минимальная память сервера / максимальная память сервера. Следует отметить, что с SQL Server 2000 до 2008 R2 эти две конфигурации предназначены только для пула буферов. .

Когда включена функция «блокировать страницы памяти», разница между ними означает: диапазон, который SQL Server может регулировать при нехватке внешней памяти.

При установке максимального значения универсального значения нет. Основной принцип начальной конфигурации: когда память сервера <= 16 ГБ, ОС резервирует 1 ГБ, а каждые 4 ГБ ОЗУ резервируют 1 ГБ; когда> = 16 ГБ, ОС резервирует 1 ГБ, а каждые 8 ГБ ОЗУ резервируют 1 ГБ.

Например: сервер 32 ГБ, максимальное значение = 32-1-4 = 27 ГБ. Затем убедитесь, что значение счетчика производительности Memory \ Available Mbytes находится в диапазоне от 150 до 300, и постепенно настройте максимальный объем памяти сервера.

2. Заблокируйте страницы в памяти.

64-разрядная SQLOS использует VirtualAlloc для выделения всей памяти по умолчанию.Память, выделяемая этим API, не блокируется и может быть выгружена на страницы. Отметьте MemoryLow, когда ОС испытывает нехватку памяти, SQL Server освобождает память до «минимального объема памяти сервера».

Если его скорость выпуска недостаточно высока или выпущенный объем не удовлетворяет ОС, память будет выгружена в файл подкачки. Для SQL Server, который использует большую память, разбиение по страницам WorkingSet очень серьезно влияет на производительность.

Включите блокировку страниц памяти, чтобы SQL Server использовал AWE API AllocateUserPhysicalPages при выделении памяти буферного пула. Память, выделяемая этой функцией, заблокирована и не выгружается на страницы.

Пул буферов занимает большую часть памяти SQL Server, поэтому включение заблокированных страниц памяти в значительной степени позволит избежать разбиения по страницам WorkingSet. Элемент конфигурации AWE Enabled является недопустимой нулевой операцией в 64-разрядном SQL Server.

После включения страницы блокировки памяти SQLServr.exe диспетчера задач отображает использование памяти небуферного пула. Вам необходимо использовать SQL Server: Memory Manager \ Total Server Memory, чтобы просмотреть общее использование памяти.

Включение заблокированных страниц памяти - это функция SQL Server 2005/2008/2008 R2 Enterprise Edition и 2008 R2 Standard Edition. После обновления 2008 SP1_CU2 и 2005 SP3_CU4 другие версии также могут включать заблокированные страницы памяти, установив флаг трассировки 845.

3. LPA(Large Page Alloction)

В системе X64 выделение больших страниц означает выделение страниц памяти размером 2 МБ, а страница памяти по умолчанию составляет 4 КБ. Включение LPA должно соответствовать условиям: a). SQL Server Enterprise Edition b). ОЗУ сервера> = 8 ГБ c). Включить заблокированные страницы памяти.

В системе X64 с включенным LPS (поддержка больших страниц) и флагом трассировки 834 SQL Server будет использовать большие страницы для выделения памяти буферного пула, и время запуска SQL Server значительно увеличилось.

Строго проверьте преимущества производительности и попробуйте включить ее на выделенном сервере SQL Server.

Диагностировать давление памяти

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

SQL Server: счетчики производительности в диспетчере буферов：

1. Buffer Cache Hit Ratio

Рекомендуемое значение: OLTP> = 95%, OLAP> = 90. Этот счетчик сам по себе не указывает на то, что SQL Server испытывает нехватку памяти, а> = 95% указывает только на то, что SQL Server выполнил предварительное чтение и предварительную выборку страниц данных, как было задумано. .

2. Page Life Expectancy

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

Количество свободных страниц в буферном пуле SQL Server. Когда счетчик ожидаемой продолжительности жизни страницы продолжает уменьшаться, количество свободных страниц близко к 0, а количество свободных страниц в списке остается равным 0, это указывает на значительную нехватку памяти.

4. Free List Stalls/Sec

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

5. Lazy Writes/sec

Число страниц данных пула буферов, обновляемых процессом LazyWriter за секунду. Когда происходит отложенная запись в секунду, уровень PLE и свободных страниц остается низким, и снова возникает задержка свободного списка, что указывает на нехватку ОЗУ.

SQL Server: счетчики производительности в диспетчере памяти：

1. Общая память сервера (КБ) и память целевого сервера (КБ)

Первый указывает объем памяти, который SQL Server уже занимает, а второй указывает объем памяти, который SQL Server хочет занять. Когда последнее больше, чем первое, это доказывает, что SQL Server требуется больше доступной памяти, что также является одним из признаков нехватки памяти.

2. Memory Grants Outstanding

Общее количество процессов, которые успешно получили память рабочей области. Слишком низкое значение указывает на большую активность пользователя или большую нагрузку.Если значение параметра Memory Grants Pending одновременно слишком велико, это также является одним из признаков нехватки памяти.

3. Memory Grants Pending

Общее количество процессов, ожидающих предоставления памяти рабочей области.

DMV, связанные с памятью

Общие проблемы, связанные с памятью

1. Непонимание утечки памяти SQL Server

Похоже, что SQL Server съест столько памяти, сколько возможно. Это не утечка памяти. Утечка памяти расширенной хранимой процедуры или драйвера сервера ссылок может привести к тому, что SQL Server получит память без ограничений.

2. Проблема с пейджингом

После SQL Server 2005 SP2, когда WiringSet процесса SQL Server сокращается и выгружается на диск, в журнале ошибок будет записано, что «значительная часть памяти процесса SQL Server выгружена».

1. Неправильно установлен максимальный объем памяти сервера, заблокированные страницы памяти не включены.

2. Операция ввода-вывода без буферизации, выполняемая Windows, занимает много кэша настройки системы, например копирование файлов.

3. Чрезмерное использование памяти или утечка памяти из-за проблем с драйверами оборудования.

СсылкаKB918483И найдите первопричину процесса усадки рабочего набора и устраните ее. Для SQL Server включение заблокированных страниц памяти - единственный способ решить эту проблему после выборки.

3. Блокировка страниц памяти включена, но максимальный объем памяти сервера не ограничен, что вызывает нестабильность ОС.

Если блокировка страниц памяти включена, но максимальный объем памяти сервера не ограничен или максимальный объем памяти сервера установлен слишком большим, SQL Server израсходует доступную память, в результате чего ОС будет не хватать памяти и работать нестабильно или даже аварийно.

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

4. Домен приложения отмечен как выгруженный, что вызывает нехватку памяти.(App Domain is marked for unload due to memory pressure)

Это ошибка, связанная с SQLCLR, которая обычно возникает на 32-битном SQL Server или может возникать на 64-битном SQL Server, где установлен максимальный объем памяти сервера, который ограничивает доступный VAS SQLCLR.

Как правило, это вызвано неэффективным использованием памяти сборкой SQLCLR и ограниченным VAS, доступным для SQLCLR.

Эта ошибка возникает в 32-битной версии, рекомендуется обновить ее до 64-битной версии, чтобы использовать больше VAS в пользовательском режиме. Однако, если сборка SQLCLR использует большие объекты памяти (например, DataSet), обновление может не решить проблему.

Превратите код SQLCLR в независимую консоль или программу WinForm и правильно настройте использование памяти.

Если SQLCLR сохраняет состояние всего выполнения, но безопасность доступа кода определяется как UNSAFE, при удалении информация о состоянии будет потеряна и возникнут более серьезные проблемы.

Лучшее решение этой проблемы - перейти на 64-разрядную версию.Временное решение - использовать параметр запуска -g для увеличения памяти MemToLeave для SQLCLR.

5. Ошибка 701 и FAILED_VIRTUAL_RESERVE

Когда SQL Server не может выделить непрерывную область VAS, он сообщит об этой ошибке и выведет запрошенный размер выделения.

Обычно эта ошибка возникает только в 32-битных системах с ограниченным MemToLeave, потому что различные типы операций, которым необходимо выделить более 8 КБ, такие как установка избыточного кэша резервных копий, XML, SQLCLR, типов пространственных данных и связанных серверов и т. Д.

Лучшее решение этой проблемы - перейти на 64-разрядную версию. Временное решение - использовать параметр запуска -g для увеличения объема памяти MemToLeave.

6. Виртуальная машина с превышением доступности

В настоящее время виртуализация SQL Server очень распространена. Расширенная функция «Memory Overcommit», предоставляемая виртуальным менеджером, позволяет общему объему памяти виртуальной машины превышать фактический общий объем ОЗУ хост-сервера.

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

Освобождение памяти - это процесс, выполняемый на гостевой виртуальной машине. Это один из инструментов виртуальной машины, который устанавливается в каждую гостевую виртуальную машину путем выпуска драйвера (Ballooning Driver). Он может получить память от Гостя и вернуть ее хосту.

Когда хост испытывает нехватку памяти (когда память перегружена), память будет уведомлена об освобождении и возврате памяти. Если объем возвращенной памяти или скорость возврата недостаточны для хоста для решения проблемы нехватки памяти, хост будет напрямую выгружать память гостевой виртуальной машины на диск.

Производительность выгружаемого гостя снизится, и SQL Server, работающий на нем, также будет затронут, и даже память буферного пула упадет до 0.

Менеджеры виртуализации, поддерживаемые Microsoft, теперь предоставляют методы для установки минимального объема зарезервированной памяти гостевой виртуальной машины, чтобы обеспечить нормальную работу SQL Server, описанного выше, поэтому его следует устанавливать разумно во время виртуализации.

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

7. Настройки многоэкземплярной памяти

Для нескольких экземпляров на машине каждый должен быть настроен с соответствующими минимальным и максимальным объемом памяти сервера, а сумма максимальной памяти сервера должна быть меньше, чем физическая оперативная память, чтобы зарезервировать достаточно памяти для ОС.

Если минимальный объем памяти сервера не установлен, когда ОС или другие экземпляры испытывают нехватку памяти, этот экземпляр будет активно сжимать память и вызывать проблемы с производительностью.

подводить итоги

Самое главное: по какой причине вы сегодня не пользуетесь 64-битной системой! ?

Читайте также:

Sql поставщик общей памяти ошибка времени ожидания 258

Рекомендации по решению проблемы от разработчиков 1С

Сопутствующая проблема и методы её решения

"Устранение неполадок SQL Server" чтение заметок - управление памятью