Если система работает постоянно и ее постоянно используют, то перезапускать невозможно. Плюс ко всему система отвечает за безопасность движения судов-ее нельзя перезапускать. А если попробовать чистить процедурный кэш и кэш ОС? Попробуйте-может поможет. В любом случае поделитесь результатами-будет думаю всем интересно.
На счет 1С. Мой друг, когда я с ним поделился этой инфой, использовал чистить процедурный кэш и кэш ОС. И тоже запросы перестали тупить. Сам он занимается администрированием и внедрением 1С с MS SQL Server
Кстати, вот на счет кэша могу сказать-что поставьте себе эту утилиту каждый час и посмотрите на разницу-система меньше тупить будет. Так что возможно-это и была причина, но не единственная.
Зачастую действительно приходится лечить симптомы, т к когда система интегрирована с разными другими системами, порой сложно каждый раз искать причину (параметризация запросов и прочее), поэтому выработал следующий алгоритм решения проблемы:
1) попытаться найти причину за разумное время, параллельно собирая симптомы и то, что может в будущем помочь: факты и их связь с тормозами
2) если не удается найти причину-пишется костыль, но п.1 продолжается
3) ищем параллельные (альтернативные) пути решения
Конечно, п.3 является своего рода тоже костылем, но когда у вас время ограничено и причин каждый раз может быть много, то иногда лучше решить костылем, а потом искать причину.
Если проблема в запросе-рано или поздно найдете причину и исправите запрос.
Однако, если причина вообще непонятна и этим занимались 3 специалиста достаточно долгое время, включая меня, то пришлось пойти именно такими шагами. Главное-пользователи довольны. Но да-причину установить не удалось. Зато удалось решить ее последствия. И опять же-все проверили, и память, и задачи агента и т д и т п. Просто заметил связь с тормозами и ОЗУ. Их было две:
1) когда кэш все съедал-это уже решено
2) когда скуль все съедал, иногда тормоза были, но необязательно. Т е если скуль съедает все-это еще не повод, что запросы будут медленными. Правда конечно непонятно, почему он нередко съедает всю выделенную ему память. В ИС нет сложных запросов, которые требуют столько памяти. И пользователей не более 20-ти одновременно работающих с системой.
Пробовал, но оптимальный вариант не искал-поверил на слово Майкрософту:
https://blogs.technet.microsoft.com/sqlruteam/2014/02/09/173/
Но думаю руки дорастут. Пока на всех серверах стоит от 3 до 4 ГБ ОЗУ под MS SQL Server, а на самих серверах ОЗУ от 6 до 16 ГБ.
Ему хоть все 8 дай-все съест)
Да это понятно. Просто экспериментами на нескольких объектах удалось повысить скорость именно запуская чистку кэша. Ведь утилита, которая описана в статье, не отнимает весь кэш, а только тот, что не используется. Т е после применения кэш уменьшается максимум на 70-80%, а иногда и вовсе на 50%. Проблема в том, что часто кэшируемые данные используются редко, а не как предполагается часто. Но конечно с кэшем вопрос открытый, т к 9 серверов у Заказчика и 3 рабочих компьютера-это еще не показатель, хотя и заставляет задуматься. У меня даже когда запускаешь 3 студии 2015 и кучу страниц в браузере без этой утилиты кэш растет как на дрожжах и съедает всю ОЗУ, но благодаря вызовам каждый час этой утилиты тормозов не происходит и ОЗУ всегда хватает ОС, т е нет коротких тормозов в системе и не нужно ее перезапускать.
Я оцениваю следующим образом (ну и не только я): [чистая работа в часах]*2 или на 3 (смотря на возможность увеличить время или нет по возможности). Если нельзя на 3 умножать, т к на такой срок не пойдет Заказчик, то к формуле прибавить еще небольшой статический коэффициент в рабочих днях. И это работает. Умножение на 2 служит на всякий-кто-то заболеет, что-то недоучли и прочее-прочее. В основном конечно буфер-это человеческий фактор, если опыт в данной или похожей работе уже был. А если не было опыта, то еще нужно заложить риск с переносом выполненых работ с демостенда на живую систему (новые технологии были неправильно поняты кем-то из разработчиков или внедренцев). Изучение новых технологий (как и настройка демостенда) обычно у нас протекает еще до подписания договора, т к это полезно коллективу для саморазвития. И даже если Заказчик откажется-можно продать потом-использовать как рекламу+есть знания. Но таких случаев было всего 2 у нас.
1) попытаться найти причину за разумное время, параллельно собирая симптомы и то, что может в будущем помочь: факты и их связь с тормозами
2) если не удается найти причину-пишется костыль, но п.1 продолжается
3) ищем параллельные (альтернативные) пути решения
Конечно, п.3 является своего рода тоже костылем, но когда у вас время ограничено и причин каждый раз может быть много, то иногда лучше решить костылем, а потом искать причину.
Если проблема в запросе-рано или поздно найдете причину и исправите запрос.
Однако, если причина вообще непонятна и этим занимались 3 специалиста достаточно долгое время, включая меня, то пришлось пойти именно такими шагами. Главное-пользователи довольны. Но да-причину установить не удалось. Зато удалось решить ее последствия. И опять же-все проверили, и память, и задачи агента и т д и т п. Просто заметил связь с тормозами и ОЗУ. Их было две:
1) когда кэш все съедал-это уже решено
2) когда скуль все съедал, иногда тормоза были, но необязательно. Т е если скуль съедает все-это еще не повод, что запросы будут медленными. Правда конечно непонятно, почему он нередко съедает всю выделенную ему память. В ИС нет сложных запросов, которые требуют столько памяти. И пользователей не более 20-ти одновременно работающих с системой.
https://blogs.technet.microsoft.com/sqlruteam/2014/02/09/173/
Но думаю руки дорастут. Пока на всех серверах стоит от 3 до 4 ГБ ОЗУ под MS SQL Server, а на самих серверах ОЗУ от 6 до 16 ГБ.
Ему хоть все 8 дай-все съест)