Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
 Re: Утечка памяти?  [new]
komrad
Member

Откуда:
Сообщений: 5252
o-o
komrad
пропущено...


с нашего

Тогда так: наши жалкие Тб шлют завистливый привет из пула в 35Гб,
где они проходом (нет, пробегом) получают пинки в зад
от спешащих побывать в этом самом пуле
вашим Тб, таким же жалким, но преспокойно сидящим в 600Гб


да, у вас похоже не кэш, а заводская проходная, перманентно в состоянии "с утра и вечером" :))

но с другой стороны, ваш кэш всегда натёрт, сияет и блестит ;)
26 окт 16, 14:23    [19823892]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
o-o
Guest
komrad
но с другой стороны, ваш кэш всегда натёрт, сияет и блестит ;)

иллюзии..иллюзии
их код, это аксессники, которые грузят таблицы целиком
и такой же SA (сейчас с него код переписываю)
а в 15:00 угадайте, что у нас?
РЕБИЛД ВСЕХ ИНДЕКСОВ.
почему не ночью?
ну, сперва был ночью, ровно тогда, когда перезаливаются те две базы за терабайт.
(т.е. они ребилдили то, что все равно будет дропнуто)
после 3х лет борьбы с этим ребилдом случилась революция:
DBA проканались и пришли к выводу, что ребилдить лучше после загрузки, а не во время.
и теперь делают это в 15:00,
вместе с пересчетом статистик.
ну а то: мы же только что залили базу через DROP TABLE + SELECT INTO + CREATE INDEX.
зачем нам статистика с фуллсканом, автоматом получаемая с CREATE INDEX?
мы лучше с RESAMPLE сделаем еще раз, ведь чем больше, тем лучше
26 окт 16, 15:13    [19824112]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
komrad
Member

Откуда:
Сообщений: 5252
o-o
komrad
но с другой стороны, ваш кэш всегда натёрт, сияет и блестит ;)

иллюзии..иллюзии
их код, это аксессники, которые грузят таблицы целиком

видел такое, в одной а-MaryKay-ской лавке - много было всяких акцессовских баз с линками в сиквел & оракл и обработкой данных на клиенте

o-o
а в 15:00 угадайте, что у нас?
РЕБИЛД ВСЕХ ИНДЕКСОВ.

;) бизнес-ризон, нет?

o-o
и теперь делают это в 15:00,
вместе с пересчетом статистик.
ну а то: мы же только что залили базу через DROP TABLE + SELECT INTO + CREATE INDEX.
зачем нам статистика с фуллсканом, автоматом получаемая с CREATE INDEX?
мы лучше с RESAMPLE сделаем еще раз, ведь чем больше, тем лучше

тут, наверняка, супер-точный расчет типа "точная статистика для запросов хуже, чем приблизительная"
вот и "блюрят" её ;)
26 окт 16, 15:25    [19824188]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
o-o
Guest
да здесь просто Зазеркалье.
в крокет играют фламингами и мартовские зайцы скачут со странными воплями
---
при всем при этом никакой утечки памяти, круто :)
26 окт 16, 15:36    [19824259]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
o-o,
а хинты? Хинты у вас там любят, нет?
26 окт 16, 15:47    [19824344]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
o-o
Guest
Mike_za
o-o,
а хинты? Хинты у вас там любят, нет?

хинты только мои.
в смысле, пришлось hash join прописать в некоторых местах.
у нас произошло странное:
они нам восстанавливают свою OLTP-базу, делают ее ридонли, мы ее переливаем
как нам надо, со своими индексами и т.д.
так вот, по жизни был в планах HASH JOIN, таблицы же здоровые.
и вот вдруг в один прекрасный день часть их полетела в NESTWED LOOPS.
оказалось, накануне они на OLTP-базе закомпрессили часть таблиц.
какой-то бред: объем ок, стал меньше, но число строк ну никак не уменьшилось.
тем не менее, планы полетели.
---
отдельный разговор WITH(NOLOCK).
ИМ ВСЕМ его сказали использовать.
поэтому уйма кода с этим хинтом.
но на ридонли базе это мало что меняет.
26 окт 16, 16:04    [19824470]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
o-o
Guest
ну что, признавайтесь,
кто еще может похвастаться тем, что ребилдит в 15 часов?
я думаю, приз уйдет нашим ДБА.
какое-такое PLE?
позор тем, у кого содержимое не меняется в течение 14 дней!
ведь это означает, вы не ребилдите терабайт индексов каждый божий день,
а разве сервер может считаться ухоженным, если не делается хотя бы попытка подобного ребилда?

К сообщению приложен файл. Размер - 13Kb
26 окт 16, 16:23    [19824623]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
o-o
Guest
* содержимое = содержимое buffer pool
26 окт 16, 16:24    [19824634]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
komrad
Mind
пропущено...
Не хотите - не пользуйтесь :)


Запрос и аутпут красив/нагляден; вообще, в сети с трудом можно найти скрипты, которые дают подобную раскладку.
Поскольку в Ваш скрипт я не углублялся, то и перенаправил Mike_za к автору.

Так что не воспринимайте это как критику, а лишь как признание авторства, вклада в общее дело и первоочередности ответа.
Да это шутка была. Просто мне очень интересно куда потерялись 15Гб и каким счетчиком их можно найти.
26 окт 16, 19:49    [19825530]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
komrad
RecommendedMinimum - это, строго говоря, от скорости винтов зависит
Нет никакой связи с винтами.
o-o
aleksrov
Вам 8000 и не надо, рекомендуется не меньше 300, но конечно больше будет лучше.

так, товарищи, я живу настоящим, а не 10 лет назад, да и машинка не i386
автор
...
Today the value 300 is ridiculously small as a threshold for when to start worrying about buffer pool pressure
...
Summary: don’t use the value 300 as any kind of Page Life Expectancy threshold.
Anyone that continues to recommend doing so is doing you a disservice.
Use an adaptive formula like (DataCacheSizeInGB/4GB*300).
Even better – monitor the steady-state value of PLE and react when it dips *and stays* below your steady-state value

Да, именно эта формула и используется для расчета RecommendedMinimum.
26 окт 16, 19:54    [19825558]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
aleksrov
Mind,

К тому что max memory большое значение.
И? Сервер уже зарезервировал 25Гб. При чем тут max memory? Вопрос в том куда сервер дел эти гигабайты которые уже получил от ОС.
26 окт 16, 19:58    [19825576]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
komrad
Member

Откуда:
Сообщений: 5252
Mind
komrad
RecommendedMinimum - это, строго говоря, от скорости винтов зависит
Нет никакой связи с винтами.

данные откуда сиквел берет, чтобы поместить в кэш (и заместить там страницы) и отдать сессии?
26 окт 16, 22:09    [19825911]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
komrad
Mind
пропущено...
Нет никакой связи с винтами.

данные откуда сиквел берет, чтобы поместить в кэш (и заместить там страницы) и отдать сессии?
Чем быстрее диски, тем быстрее замещает, тем меньше PLE, так что ли?
26 окт 16, 23:12    [19826073]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
o-o
Guest
Mind
komrad
пропущено...

данные откуда сиквел берет, чтобы поместить в кэш (и заместить там страницы) и отдать сессии?
Чем быстрее диски, тем быстрее замещает, тем меньше PLE, так что ли?

Блиииин, так у нас глядишь, самые быстрые диски в мире
То-то в еррорлог валятся четырёхзначные числа,
SQL Server has encountered 1795 occurrence(s) of I/O requests taking longer than 15 seconds to complete.
Картинка с другого сайта.
27 окт 16, 00:12    [19826161]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
aleksrov
Member

Откуда:
Сообщений: 948
o-o
ну что, признавайтесь,
кто еще может похвастаться тем, что ребилдит в 15 часов?
я думаю, приз уйдет нашим ДБА.


Ха, щас! У нас в некоторых филиалах делается в обед (еще в некоторых делается шринк в это же время автоматом), на мои возрожения ответ был типа: это Best Practice, так делали наши отцы (т.е. админы до них), отцы наших отцов и их отцы и мы умрем но будем делать так, да и вообще вы там теоретики сидите, реальной жизни не видите, а мы тут на передовой (герои блин.) пашем.
27 окт 16, 05:05    [19826291]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
aleksrov
Member

Откуда:
Сообщений: 948
Да, плюс перестраивается все независимо от размера и фрагментации, и еще у некотрых перед этим стоит пересчет статистики.
27 окт 16, 08:02    [19826375]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
komrad
Member

Откуда:
Сообщений: 5252
Mind
komrad
пропущено...

данные откуда сиквел берет, чтобы поместить в кэш (и заместить там страницы) и отдать сессии?
Чем быстрее диски, тем быстрее замещает, тем меньше PLE, так что ли?

производительность системы определяется производительностью самого медленного компонента
и в данном случае отрицать связь с винтами не совсем верно

автор
Нет никакой связи с винтами.


я бы сказал так: с быстрой дисковой подсистемой PLE отрастает быстрее из-за более быстрой обработки запросов в части ввода/вывода
27 окт 16, 11:17    [19827183]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
aleksrov
o-o
ну что, признавайтесь,
кто еще может похвастаться тем, что ребилдит в 15 часов?
я думаю, приз уйдет нашим ДБА.


Ха, щас! У нас в некоторых филиалах делается в обед (еще в некоторых делается шринк в это же время автоматом), на мои возрожения ответ был типа: это Best Practice, так делали наши отцы (т.е. админы до них), отцы наших отцов и их отцы и мы умрем но будем делать так, да и вообще вы там теоретики сидите, реальной жизни не видите, а мы тут на передовой (герои блин.) пашем.


В мировой практике это называется "культ карго".
27 окт 16, 11:27    [19827264]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
aleksrov
Member

Откуда:
Сообщений: 948
Владислав Колосов
aleksrov
пропущено...


Ха, щас! У нас в некоторых филиалах делается в обед (еще в некоторых делается шринк в это же время автоматом), на мои возрожения ответ был типа: это Best Practice, так делали наши отцы (т.е. админы до них), отцы наших отцов и их отцы и мы умрем но будем делать так, да и вообще вы там теоретики сидите, реальной жизни не видите, а мы тут на передовой (герои блин.) пашем.


В мировой практике это называется "культ карго".


Загуглил. Народ жжет:
И тогда они (обиригены) стали думать: что же они делают не так? Почему бледнолицым падало с неба такое добро, а они денно и нощно копали огороды и крутили жернова — и им ничего с неба ни разу не упало? Наверное, для получения всех этих дивных вещей надо делать то же, что и бледнолицые? А именно — кричать слова в железную коробку, надев на уши приспособления, а затем проложить полосы, разжечь костры и ждать? И с неба снова упадет всякое изобилие, которое не надо выпиливать, вытачивать и выскабливать из костей больших рыб? Наверное, все это — особо мощные магические ритуалы, сильнейшее волшебство, которым овладели бледнолицые и тем самым обманом заставляют потусторонние силы приносить им все эти блага?
Ведь совершенно очевидно, что все прекрасные вещи появились именно в результате магических действий! Ведь никто никогда не видел, чтобы американцы их ДЕЛАЛИ!
27 окт 16, 11:44    [19827428]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
o-o
Guest
komrad
я бы сказал так: с быстрой дисковой подсистемой PLE отрастает быстрее из-за более быстрой обработки запросов в части ввода/вывода

да нет же, тут все дело в адекватном либо нет размере buffer pool против размера обрабатываемых данных.
ну вот у нас есть любимая всеми таблица в 400Гб со всеми нужными данными,
а еще ее секционировали, навесили сверху вьюху, откуда ВЫКИНУТ ключ секционирования (аллилуйя),
ее дали пользователям.
сделано это СПЕЦИАЛьНО, в комментарии ко вью так и написано: скрываем поле секционирования от пользователя.
отлично, теперь все кому не лень джойнят с этой таблицей, индексы не секционированы,
если попадаешь на индекс, уже счастье, хотя объем еще тот, ну и если не попадаешь, кранты.

итого: постоянно закачивается то один, то другой индекс, ну пусть в среднем индекс 50Гиг,
есть потребность постоянно грузить те 50Гиг или эти 5оГиг, короче, унитаз.
если диски таковы, что 35Гиг (наш buffer pool) прокачиваются за 2 минуты, будет 120 (наше обычное значение)
если быстрее, ну будет 60 (как написал Mind, PLE уходит вниз, значит, диски быстрые )
PLE не будет расти, пока buffer pool не начнет вмещать хотя бы полностью индекс или что там еще у нас за раз запрашивается.
хоть какая скорость у дисков, PLE стремится к 0,
пока все нужное для одного запроса не вмещается полностью в память.

закачивают за раз больше данных, чем вмещает buffer pool, и вечно кто-то активен => PLE --> 0
27 окт 16, 11:47    [19827457]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
aleksrov,

ну вот ваши админы кричат в железную коробку и строят деревянные самолеты. Даже диспетчера в будку сажают :) Потому, что у одного предка это сработало и вывело из трудной ситуации.
27 окт 16, 11:49    [19827465]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
komrad
Member

Откуда:
Сообщений: 5252
o-o
komrad
я бы сказал так: с быстрой дисковой подсистемой PLE отрастает быстрее из-за более быстрой обработки запросов в части ввода/вывода

да нет же, тут все дело в адекватном либо нет размере buffer pool против размера обрабатываемых данных.

ну безусловно :)
альтернативный вариант - уменьшить кол-во активных сессий ;)
27 окт 16, 12:10    [19827586]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
komrad
o-o
пропущено...

да нет же, тут все дело в адекватном либо нет размере buffer pool против размера обрабатываемых данных.

ну безусловно :)
альтернативный вариант - уменьшить кол-во активных сессий ;)

Можно еще блокировки монопольные на таблицы вешать или апплоки
27 окт 16, 12:24    [19827682]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
aleksrov
Member

Откуда:
Сообщений: 948
o-o
komrad
я бы сказал так: с быстрой дисковой подсистемой PLE отрастает быстрее из-за более быстрой обработки запросов в части ввода/вывода

да нет же, тут все дело в адекватном либо нет размере buffer pool против размера обрабатываемых данных.
ну вот у нас есть любимая всеми таблица в 400Гб со всеми нужными данными,
а еще ее секционировали, навесили сверху вьюху, откуда ВЫКИНУТ ключ секционирования (аллилуйя),
ее дали пользователям.
сделано это СПЕЦИАЛьНО, в комментарии ко вью так и написано: скрываем поле секционирования от пользователя.
отлично, теперь все кому не лень джойнят с этой таблицей, индексы не секционированы,
если попадаешь на индекс, уже счастье, хотя объем еще тот, ну и если не попадаешь, кранты.

итого: постоянно закачивается то один, то другой индекс, ну пусть в среднем индекс 50Гиг,
есть потребность постоянно грузить те 50Гиг или эти 5оГиг, короче, унитаз.
если диски таковы, что 35Гиг (наш buffer pool) прокачиваются за 2 минуты, будет 120 (наше обычное значение)
если быстрее, ну будет 60 (как написал Mind, PLE уходит вниз, значит, диски быстрые )
PLE не будет расти, пока buffer pool не начнет вмещать хотя бы полностью индекс или что там еще у нас за раз запрашивается.
хоть какая скорость у дисков, PLE стремится к 0,
пока все нужное для одного запроса не вмещается полностью в память.

закачивают за раз больше данных, чем вмещает buffer pool, и вечно кто-то активен => PLE --> 0


Вопрос немного не по теме: как тогда правильно работать с ООООЧЕНЬ большими индексами (в 100 гигов к примеру), как их правильно ребилдить, чтобы не навредить системе в целом (+ если у нас еще AlwaysOn или репликация транзпкций), как быть? Пускай 2 варианта: в первом индекс секционирован, во втором нет.
Правдв интересно, никогда не работал с таким обьемом.
27 окт 16, 12:56    [19827893]     Ответить | Цитировать Сообщить модератору
 Re: Утечка памяти?  [new]
o-o
Guest
вообще-то они и есть хозяева.
а мы все внешние: те, кто им делает загрузку и ДБА тоже внешние.
поэтому наезжать можно только на ДБА или на IT.

а отчетники это священные коровы.
и этим животным давно сказано, где у них узкое место.

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

индексы же надо ребилдить, базы все время бэкапить
(простая модель + после заливки содержимое не меняется.
так у нас же 6 бэкапов в день, полный как раз во время заливки, дифф за ним стоит в очереди,
т.к. запускается раньше, чем полный успевает отработать)
короче, полная видимость работы ДБА и такая же у IT:
ну разве в IT виноваты, что супер-процедуры с табличными параметрами часами нестед лупят?
это же и есть непосильный труд

короче.
люди заняты, диски и сервер тоже. ваще идиллия
27 окт 16, 13:02    [19827933]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить