Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
e_mikhailov Member Откуда: Россия Сообщений: 53 |
Коллеги, добрый день! Нужна ваша помощь. SQL Server использует не более 14Гб ОЗУ, хотя ему выделено до 20Гб и счётчики производительности показывают, что он нуждается в дополнительной памяти. ОС: Microsoft(R) Windows(R) Server 2003 Enterprise x64 Edition R2 (Version 5.2.3790 Service Pack 2 Build 3790) СУБД: Microsoft SQL Server 2005 - 9.00.5000.00 (X64) Corporation Enterprise Edition (64-bit) SP4 AWE я не включал, т.к. SQL 64-х битный. Также стоит опция Boost SQL Server priority и блокировка страниц в памяти для учётки, под которой стартует служба sqlserver. Ночью, в момент наименьшей активности пользователей, я установил min server memory = max server memory = 20000Мб., чтобы принудительно заставить SQL использовать 20Гб и перезагрузил сервер. Установка подействовала: SQL-сервер сразу запользовал 18Гб вместо 14Гб, как было раньше, прекратился свопинг и значения счётчика Memory\Pages/sec упали с 3000-1000 в пиках до практически нуля (как и должно быть). По началу всё работало хорошо, но начиная с 6:30 утра, когда активно начали подключаться пользователи удалённых филиалов, на сервере начались проблемы... Пользователи начали отваливаться с ошибкой: Server TCP provider has stopped listening on port [ 1433 ] due to a failure. Error: 0x2747, state: 2. The server will automatically attempt to reestablish listening. (ошибка явно указывает на то, что сервер перестал слушать порт 1433 из-за ошибки 0х2747. Из описания ошибки 0х2747 на microsft.com операция на сокете не может быть выполнена потому что система испытывает недостаточное буферное пространство или из-за того, что очередь переполнена. Другими словами данная проблема была вызвана нехваткой оперативной памяти или высокой загрузкой компьютера для обработки пакетов из-за переполнения очереди. http://msdn.microsoft.com/ru-ru/library/ms681391(v=VS.85).aspx WSAENOBUFS 10055 (0x2747) An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.) В результате я вернул старое значение min server memory = 128Мб., оставил под систему 4Гб, перезагрузил сервер и после этого всё заработало, указанная ошибка больше не проявлялась. Но вместе с тем SQL Server снова начал потреблять только 14Гб. памяти и снова в течении дня происходит своп и Pages/sec в пиках зашкаливает до 3000 и, как результат, общие тормоза системы... У меня вопрос, как можно заставить SQL-сервер использовать больше 14гб, что ему необходимо, но при этом чтобы он это делал корректно и не возникали ошибки? |
14 авг 12, 11:34 [13007945] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Не раскрыт вопрос - а сколько всего памяти на машине то ? |
14 авг 12, 11:40 [13007992] Ответить | Цитировать Сообщить модератору |
e_mikhailov Member Откуда: Россия Сообщений: 53 |
Glory, добрый день! Сорри, забыл написать, всего 24Гб из них всегда было выделено под винду 4Гб, а под sql динамически от 128мб до 20гб |
14 авг 12, 11:42 [13008010] Ответить | Цитировать Сообщить модератору |
nicescar Member Откуда: Сообщений: 94 |
А какие счетчики производительности вы опрашивали, чтобы понять, что сервер нуждается в памяти? |
14 авг 12, 11:52 [13008086] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Это все случайно у вас не на виртуалке ? |
14 авг 12, 11:57 [13008116] Ответить | Цитировать Сообщить модератору |
e_mikhailov Member Откуда: Россия Сообщений: 53 |
nicescar, Счётчики Target Server Memory и Total Server Memory упорно показывают что SQL использует только 14Гб. При этом значения: SQLServer:Buffer Manager\Buffer cache hit ratio = 90-95% (в идеале должно быть 100%); SQLServer:Plan Cache\Cache hit ratio = 65-75 (в идеале должно быть больше 85); Memory\Pages/sec в среднем = 15-20, в пиках нагрузки доходит до 3000 (в идеале должно стремиться к нулю). Т.е. всё указывает на то, что серваку не хватает памяти, но брать он её почему то не хочет. Причём после принудительного min server memory = max server memory = 20000Мб он её всё таки взял и счётчики по памяти пришли к нормальным значениям, но при этом проявился "побочный эффект" в виде ошибки 0х2747 Glory, Да, на виртуалке. |
14 авг 12, 12:04 [13008159] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
http://blogs.msdn.com/b/repltalk/archive/2010/12/28/troubleshooting-sql-server-error-the-operating-system-returned-error-1453.aspx ??? |
||
14 авг 12, 12:06 [13008180] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
Server TCP provider has stopped listening on port [ 1433 ] due to a failure. Error: 0x2747, state: 2. The server will automatically attempt to reestablish listening. (ошибка явно указывает на то, что сервер перестал слушать порт 1433 из-за ошибки 0х2747. Из описания ошибки 0х2747 на microsft.com операция на сокете не может быть выполнена потому что система испытывает недостаточное буферное пространство или из-за того, что очередь переполнена. Это другая память и другая очередь. С оперативной памятью используемой сервером совсем не связана. Но я бы на твоём месте убрал этот форс 20Gb, An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.) Это очередь пакетов TCP/IP в стеке. Вряд ли ты её поломал своими 20Gb, но ставить их всё равно глупо. В результате я вернул старое значение min server memory = 128Мб., оставил под систему 4Гб, перезагрузил сервер и после этого Разумно. всё заработало, указанная ошибка больше не проявлялась. Но вместе с тем SQL Server снова начал потреблять только 14Гб. памяти и снова в течении дня происходит своп и Pages/sec в пиках зашкаливает до 3000 и, как результат, общие тормоза системы... А с чего ты взял, что ему нужн БОЛЬШЕ ? У меня вопрос, как можно заставить SQL-сервер использовать больше 14гб, что ему необходимо, но при этом чтобы он это делал корректно и не возникали ошибки? Ну во-первых, больше всего сервак использует память под кэш данных, это основной потребитель памяти, и если просто серверу не нужно обрабатывать большее кол-во данных, он не будет ни в каком случае использовать лишние буфера. Т.е. грубо говоря вполне возможно, что ему больше и не надо. Ты выложи конкретно какие параметры ты смортел, значения, конфиг машины (объём памяти, процы) и тебе наверняка скажут, что не так и что делать. |
14 авг 12, 14:00 [13008910] Ответить | Цитировать Сообщить модератору |
e_mikhailov Member Откуда: Россия Сообщений: 53 |
Glory, спасибо за дельный совет! Лимита не было. Но галка Unlimited не стояла. Сейчас наши сисадмины галку поставили, проверить, поменялось что либо или нет, смогу только вечером после ребута сервера. Настройки min/max оставить теми же (128мб и 20000мб) и не делать min server memory = max server memory = 20000Мб? Ведь по идее после ребута он должен нормально забирать память. Можно ли оставить включенным Boost SQL Server priority, если у нас на этом сервере ещё установлен Касперский и у нас установлен всего один инстанс у SQL Server-а? |
14 авг 12, 14:05 [13008957] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
Счётчики Target Server Memory и Total Server Memory упорно показывают что SQL использует только 14Гб. При этом значения: SQLServer:Buffer Manager\Buffer cache hit ratio = 90-95% (в идеале должно быть 100%); Идеала ты никогда не достигнеш. Это же СУБД, а не эксель, её хлеб -- хранить данные на диске. 90-95% -- это очень хорошо, и ничего больше делать не нужно. Хиты эти не означают напрямую, что памяти мало серверу под буфера. Они означают, что какие-то данные (5% в твоём случае) не находились в кэше за наблюдаемый период и их прочитали с диска. Это может быть как в случае переполненности кэша, так и просто тупо потому, что эти данные ещё никто никогда не запрашивал, и их пришлось прочитать впервые после старта сервера. SQLServer:Plan Cache\Cache hit ratio = 65-75 (в идеале должно быть больше 85); Это тоже недостижимый идеал, ты можеш на лету создавать каждую секунду новые запросы и никогда их повторно не выполнять, им придётся всегда компилироваться заново. У тебя тут ТОЖЕ достаточно хорошо. Memory\Pages/sec в среднем = 15-20, в пиках нагрузки доходит до 3000 (в идеале должно стремиться к нулю). Это я не знаю что такое. Свапинг ? Т.е. всё указывает на то, что серваку не хватает памяти, но брать он её почему то не хочет. Ну я пока наоборот вижу, что всё хорошо и памяти особенно не нужно. Если бы у тебя был Buffer cache hit ratio порядка 10-20% , было бы о чём беспокоится. Glory, Да, на виртуалке. Чё сервер в виртуальной машине ? Ужас... |
14 авг 12, 14:10 [13009001] Ответить | Цитировать Сообщить модератору |
tpg Member Откуда: Novosibirsk Сообщений: 23902 |
А вот
для
|
||||||
14 авг 12, 14:28 [13009190] Ответить | Цитировать Сообщить модератору |
nicescar Member Откуда: Сообщений: 94 |
Если уж нужно искать узкие места, то для начала можно и в sys.dm_os_wait_stats глянуть. Тут вопрос с багой при указании определенного количества памяти.. Однако ж, виртуалка с памятью в 24 ГБ - это сильно. Почему бы на физику не переехать при таких-то объемах? Может быть, виртуальный хост просто не может выдать машинке полный объем памяти? Boost SQL Server priority с памятью никак не связан, касательно этой проблемы он вам ничем не поможет. |
14 авг 12, 14:31 [13009210] Ответить | Цитировать Сообщить модератору |
e_mikhailov Member Откуда: Россия Сообщений: 53 |
tpg, насчёт "не лучший выбор, при существовании 2008 сервера..." согласен! В скором времени планируем перейти на 2008, но пока так... |
14 авг 12, 15:19 [13009704] Ответить | Цитировать Сообщить модератору |
e_mikhailov Member Откуда: Россия Сообщений: 53 |
nicescar, Почему бы на физику не переехать при таких-то объемах? Политика нашего руководства, здесь ничего не исправишь... Может быть, виртуальный хост просто не может выдать машинке полный объем памяти? Как оказалось может! Glory был прав, после установки галочки "unlimited" в настройках памяти виртуалки, проблема решилась и пока вышенаписанная ошибка не проявлялась! На момент создания виртуального сервера было выделено всего 16Гб ОЗУ, по видимому это значение где то там закешировалось, т.к. после того, как виртуалке расширили ОЗУ до 24ГБ, она по прежнему позволяла SQL-лю потреблять только 14ГБ, как было раньше. После установки галочки "unlimited" значения счётчиков памяти тоже значительно улучшились и стали близки к идеальным значениям: SQLServer:Buffer Manager\Buffer cache hit ratio = 99,7% - 99,9% , до добавления галочки было 90-95% (в идеале должно быть 100%); SQLServer:Plan Cache\Cache hit ratio = 85,5 - 90,9 , до добавления галочки было 65-75 (в идеале должно быть больше 85); Memory\Pages/sec в среднем = 0,1 - 0,5 в пиках 300 , до добавления галочки было 15-20, в пиках нагрузки доходит до 3000 (в идеале должно стремиться к нулю). Это значит, что избыточный страничный обмен теперь отсутствует. Вечером перезагрузим сервер, чтобы уж полностью выполнить всё, как написано в статье Glory. |
14 авг 12, 15:28 [13009809] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
cтатья не моя ) моя только ссылка |
||
14 авг 12, 15:43 [13009919] Ответить | Цитировать Сообщить модератору |
e_mikhailov Member Откуда: Россия Сообщений: 53 |
Glory, всё равно, большое спасибо! |
14 авг 12, 15:51 [13009983] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5496 |
посмотри еще счетчик Page Life Expectancy в пиковые нагрузки и в среднем |
||
14 авг 12, 17:33 [13010692] Ответить | Цитировать Сообщить модератору |
проходил мимо1
Guest |
возможно про это говорили, но я что-то нигде не увидел упоминания про lock pages in memory иначе ваша настройка max server memory бессмысленна |
14 авг 12, 17:51 [13010792] Ответить | Цитировать Сообщить модератору |
Mind Member Откуда: Лучший город на Земле Сообщений: 2322 |
SQLServer:Buffer Manager\Buffer cache hit ratio - этот счетчик про то, как дисковая подсистема справляется с упреждающим чтением. SQLServer:Plan Cache\Cache hit ratio - может свидетельствовать о кривом приложении и большом количестве ad-hoc запросов Memory\Pages/sec - а этот имхо вообще ни о чем А еще меня как то смущает достоверность таких тестов:
|
||||||
14 авг 12, 20:21 [13011439] Ответить | Цитировать Сообщить модератору |
step_ks Member Откуда: Сообщений: 936 |
|
||||
14 авг 12, 22:15 [13011895] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5496 |
boost priority я бы убрал тынц |
||
15 авг 12, 00:37 [13012305] Ответить | Цитировать Сообщить модератору |
tpg Member Откуда: Novosibirsk Сообщений: 23902 |
|
||
15 авг 12, 06:34 [13012595] Ответить | Цитировать Сообщить модератору |
e_mikhailov Member Откуда: Россия Сообщений: 53 |
komrad, посмотри еще счетчик Page Life Expectancy в пиковые нагрузки и в среднем Вчера в течении дня помониторил счётчик Page Life Expectancy. В статье прочитал, что его значения должны быть больше 300: http://www.sqlmag.com/article/sql-server/page-life-expectancy-a-reliable-indicator-of-sql-server-memory-pressure Вот что получилось у меня: в среднем в течении дня его значение от 280 до 420, минимальные 114-120, максимальные 650-700. Хорошие это показатели или SQL-лю опять что то не хватает? tpg, Я про ОС постил, если что, а не про сиквел Да, я так и понял, что разговор про 2008-ю винду) komrad, boost priority я бы убрал Насчёт boost priority, всё как то противоречиво... В статье написано, что нежелательно его включать, если на сервере кроме SQL-ля крутится что либо ещё, типа веб сервера и т.п. При этом они же пишут: "To be fair, Microsoft mentions in this Microsoft Connect article that you might see some performance improvements in “high-end servers primarily with OLTP workloads”." А это как раз наш случай! У нас сервер целиком и полностью заточен под СУБД и никаких других пользовательских сервисов на нём не крутится. По требованию нашей службы безопасности только установлен Касперский. Собственно, чтобы он не отъел ресурсы от SQL и был включен этот параметр. Так всё таки, как быть с этим boost priority? Так ли плохо в нашем случае он влияет на производительность? |
16 авг 12, 09:58 [13018761] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5496 |
2 минуты - это конечно мало да и 10 - не фонтан покажи результат вот этого запроса :
запусти этот запрос с утра, в нагруженные часы и вечером
http://support.microsoft.com/kb/319942/en-us
Не знаю, может у кого из коллег есть сугубо положительный опыт использования такой опции, но по своему опыту скажу - для достижения высокой производительности SQL данная опция ни разу не рассматривалась в кач-ве решения.
Тем более, если сервер выделенный - перед кем бустить приоритет то? Про память : http://blogs.technet.com/b/askperf/archive/2008/03/25/lock-pages-in-memory-do-you-really-need-it.aspx |
||||||||||
16 авг 12, 10:59 [13019028] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5496 |
про антивирус - вы добавили исключения согласно статье ? набор ссылок про антивирусы для SQL |
||||
16 авг 12, 12:00 [13019469] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |