А если используется модель восстановления простая, нужно ли тогда делать эту инструкцию? У нас БД относительно небольшие-до 10 ГБ. Полные резервные копии делаются каждые 3-4 часа.
Нет, именно кэш ОС.
Т е вместо перезагрузок плановых достаточно чистить кэш.
можно пруф который подтвердит это утверждение?
Ссылки я давал-можно посмотреть и почитать. И сами можете попробовать на своем компьютере.
Если Вы не чистите периодически кэш, ОС без перезагрузки начнет тормозить рано или поздно.
И вместо перезапуска попробуйте почистить кэш ОС.
Про несколько месяцев не очень понял, сколько хп у вас? Поставьте мониторинг и разбирайте проблемы. Улучшить надо только то что тормозит, остальное не надо трогать. Это 5-7 дней работы DBA. Вроде прописные вещи.
Несколько месяцев мы мониторили и разбирали проблемы, которые каждый раз были-новые запросы. Потом пришло понимание, что ВСЕ запросы тормозят в случайное время. Т е проблема не в запросах, хотя и их улучшили тоже. В результате поиска причины не в том месте, ушло несколько месяцев.
Еще раз для ясности, если перегружаете продакт чтобы избавится от проблем или чистите кэш всей бд постоянно, признайтесь себе честно — вы не понимаете что происходит.
Перезагружать теперь не нужно, когда чистится периодически кэш всей ОС.
И я понимаю что происходит-чистить кэш ОС нужно периодически, до этого не было чистки. Процедурный кэш тоже чистить надо, но и там и там нужно подобрать частоту чистки.
Ниже написали, что еще сжатие файлов приводит к увеличению времени ожидания выполнения запросов-на заметку взял. Сегодня уже поправим на 2-х серверах. О результатах отпишу.
кроме этого часто к не очень хорошим последствиям приводит периодические операции shrink file/db
Верно, а ведь у нас такое делается-как раз на тех, где редко, но скуль съедает всю ОЗУ ему отведенную.
Вы сейчас очень сильно помогли в поиске еще одной причины.
Поэкспериментирую-расскажу результаты.
Запрос надо переписать, если нужно использовать хинты unknown. Статистику обновить. В общем лучше использовать один раз построенный план. Выше вам про магию очень точно подметили.
Мне так все время отвечали (мои коллеги) и не сдвинулись тогда мы с места еще несколько месяцев-пытаясь улучшать запросы и т д. В итоге-недовольны пользователи, и время съедается у администратора. Данное решение позволяет ловить действительно плохие запросы и серьезные проблемы, а с остальным данный подход сам разберется. И уж точно ничего не должно падать при очистке кэша.
Статистику обновлять пробовали. Проблема была в том, что долгие ожидания появляются даже у простых запросов. Я конечно полностью процедурный кэш не отнял у серверов, но чистка 1 раз в час существенно улучшило время отклика. Ни один сервер не упал при чистке процедурного кэша, равно как и очистке кэша ОС вообще.
IMHO сбрасывать процедурный кэш — плохая практика. Поскольку это приводит к повторной компиляции процедур и построению нового плана, что является причиной временного снижения производительности запросов.
Вы проверяли так ли это? Это вызывает большую нагрузку на ЦП, но в общем лучше построить эффективный план для каждого запроса с новыми параметрами, чем быстро использовать неэффективный план.
Думаю наверняка есть СУБД, где планы не кэшируются, но здесь утверждать не буду. Слышал, что вроде Vertica не использует кэширование планов для повторного использования, а только для асинхронного доступа. Но здесь утверждать не буду-сам не читал.
Пробовали ставить на определенных хранимках такие параметры-стало только хуже, т е всегда тяжелые стали. Вообще говоря, есть гипотеза-зачем вообще планы строить на запрос, если почти никогда не знаешь какие параметры придут. Или план строится для одних параметров, но никто не гарантирует, что план будет эффективен для того же запроса с другими параметрами. Так что возможно, если вообще каждый раз новый план строить-это нагрузка на ЦП (но обычно он мощный), но зато эффективный план для каждого случая. Серебряной пули нет, но в моей практики это решило минимум 90% проблем (я сюда не беру проблемы, связанные с плохими запросами и т д, а оставшиеся-непонятно почему вдруг простой запрос или несложная хранимка начинает в 10-ки раз дольше ожидать). Вопрос-как частно нужно вообще кэш сбрасывать-тут нужно по обстоятельствам. Если для входных параметров каждый раз нужен свой план и запросы такие выполняются часто, то нужно смотреть на частоту таких запросов. А если выполняются редко такие запросы или их мало, то процедурный кэш можно чистить раз в сутки или вообще раз в неделю.
Например вызов хранимых процедур занимал от 0 до 0,5 сек. И примерно Elapsed=Worker.
Когда шли тормоза, то Elapsed доходил до 10-30 сек., а Worker до 1 сек. Т е выполнение вырастало макс в 2 раза, а ожидания многократно. Профайлер показал лишь следствия-ничего отличающегося из запросов нет-что когда сервер нормально работает, что когда тормозил.
Ваши слова как бальзам на душу, но увы обычно там что-то еще-аля Касперский или доктор Веб и безопасников не переубедить.
Кстати, а почему 90%? Откуда такой подсчет?
Я ориентируюсь всегда вот поэтому рассчету
Да, индексы перелапатили-я еще об этом напишу. И это в разы улучшело положение, но опять же все запросы в случайное время просто в разы медленнее выполнялись, причем именно по ожиданию Elapsed.
Запросы тяжелые ловим-правим по мере их появления.
Асинхронное стоит у двоих серверов-там 2014 версия, а у остальных (2005-2012)-синхронная. Ожидания были в разы больше выполнения до того, как стал процедурный кэш чистить. Стоят последние обновления, кроме 2014-там SP1.
Правда сразу такое изменение не удастся у нас ввести, но постепенно сделаем)
Нет, именно кэш ОС.
Т е вместо перезагрузок плановых достаточно чистить кэш.
Ссылки я давал-можно посмотреть и почитать. И сами можете попробовать на своем компьютере.
Если Вы не чистите периодически кэш, ОС без перезагрузки начнет тормозить рано или поздно.
И вместо перезапуска попробуйте почистить кэш ОС.
Несколько месяцев мы мониторили и разбирали проблемы, которые каждый раз были-новые запросы. Потом пришло понимание, что ВСЕ запросы тормозят в случайное время. Т е проблема не в запросах, хотя и их улучшили тоже. В результате поиска причины не в том месте, ушло несколько месяцев.
Перезагружать теперь не нужно, когда чистится периодически кэш всей ОС.
И я понимаю что происходит-чистить кэш ОС нужно периодически, до этого не было чистки. Процедурный кэш тоже чистить надо, но и там и там нужно подобрать частоту чистки.
Ниже написали, что еще сжатие файлов приводит к увеличению времени ожидания выполнения запросов-на заметку взял. Сегодня уже поправим на 2-х серверах. О результатах отпишу.
У Вас как в производстве или на работе?
Верно, а ведь у нас такое делается-как раз на тех, где редко, но скуль съедает всю ОЗУ ему отведенную.
Вы сейчас очень сильно помогли в поиске еще одной причины.
Поэкспериментирую-расскажу результаты.
Мне так все время отвечали (мои коллеги) и не сдвинулись тогда мы с места еще несколько месяцев-пытаясь улучшать запросы и т д. В итоге-недовольны пользователи, и время съедается у администратора. Данное решение позволяет ловить действительно плохие запросы и серьезные проблемы, а с остальным данный подход сам разберется. И уж точно ничего не должно падать при очистке кэша.
Вы проверяли так ли это? Это вызывает большую нагрузку на ЦП, но в общем лучше построить эффективный план для каждого запроса с новыми параметрами, чем быстро использовать неэффективный план.
Думаю наверняка есть СУБД, где планы не кэшируются, но здесь утверждать не буду. Слышал, что вроде Vertica не использует кэширование планов для повторного использования, а только для асинхронного доступа. Но здесь утверждать не буду-сам не читал.
Учту на будущее
Дайте ссылку пожалуйста
Когда шли тормоза, то Elapsed доходил до 10-30 сек., а Worker до 1 сек. Т е выполнение вырастало макс в 2 раза, а ожидания многократно. Профайлер показал лишь следствия-ничего отличающегося из запросов нет-что когда сервер нормально работает, что когда тормозил.
Кстати, а почему 90%? Откуда такой подсчет?
Я ориентируюсь всегда вот поэтому рассчету
Но ведь учиться никогда не поздно)
Запросы тяжелые ловим-правим по мере их появления.