SQL 2008 не освобождает оперативную память Сервер 1С(8.2.15.294), в 4 базах 25 юзеров(не терминал 20 вводят данные, 5 формируют отчеты), при полной загрузке sql 2008(версия 10.50.1600.1) съедает 4 гига оперативной памяти. Нормально ли такое потребеление оперативной памяти? Когда работа пользователей заканчивается, sql не освобождает занятую оперативную память, это нормально? Если нет, как настроить, чтобы память выделялась и освобождалась динамически? |
Это нормально. Так и должно быть. |
Нормально |
не трогай его, он сам знает что ему делать с памятью |
спасибо! |
включил ограничение оперативной памяти для sql, оставил 2,5 гига на 25 пользователей, плюс гиг отъедает сервер 1С. 4 дня полет нормальный. А в принципе принудительное ограничение чем-то чревато для 1С? |
(6) Нахрена SQL покупали - не понятно. |
я вот тоже так думаю! просто в этой конторе за скуль отчечают админы и мне им нужно аргументированно объяснить, почему ограничение памяти есть зло. если мы увеличим оперативную память с 6 гигов до 12, не продолжить ли скуль так же отъедать всю оперативную память? в какой момент ограничение памяти начнет косячить? |
(7) Далеко не у всех Пользователи в базах вводят по одному документу в день. |
(9) Они его искусственно опустили до уровня бесплатных СУБД. Нафига бабло платили я не понял. |
Зачем ограничивать? Циферек жалко? |
11 дык другим приложениям памяти не хватает. |
Уж сколько раз твердили миру - скуль должен жить на отдельном сервере... |
У них там поди еще и контроллер домена... |
(14) Главное, что бы там же в кваку не рубились :) |
13, 14 начиная с какго количества пользователей имеет смысл выделять скуль на отдельный сервер? |
(16) Как только ставишь скуль - сразу на отдельный сервер. |
(14) Чем не нравится совмещение AD с SQL сервером? Железо хорошее - аппаратный RAID, куча ядер, памяти десятки гигабайт. Только без религиозной лабудени. (16) По барабану на отдельность сервера. Не слушай древних фанатиков. Главное - доступность ресурсов. Я при расчете объем ОЗУ для SQL сервера 1С считаю как годовой прирост всех обслуживаемых БД + 20% от общего объема. Не забываем еще про 1Гиг для всяких системных нужд. Если остальные процессы оставляют для SQL указанный объем - вполне можно крутиться на том же железе хоть с 500 пользователями. ПЫСЫ: Не путать с парой SQL+терминал. В таком режиме невозможно оценить объем ресурсов, которые съест терминал. В такой связке на SQL может не хватить памяти, что ведет к плачевной производительности и багам. |
(18) Ну-ну. Рассчитай-ка объем ОЗУ для базы гигов в 200-300? |
18 Спасибо. А какая кореляция между размером оперативной памяти и суммарным размером всех бд, крутящихся на sql? Не один же к одному! |
(20) Чем больше базы входит в память - тем лучше. |
(18) Я понимаю, что у тебя под нужды AD есть возможность выделить отдельный дисковый массив. Но у автора то поди массив один, на котором крутятся все базы. Если там еще и AD пастись будет очереди к диску обеспечены. |
(19) Я не телепат. Для таких баз ОЗУ не напасешься и главным критерием может стать производительность дисковой. (21) Чем больше АКТИВНО ИСПОЛЬЗУЕМОЙ части базы. Выделять память для кеша скана сертификатов - неразумно. Хранить же таблицу и индексы итогов регистра товаров на складах не в кеше - смертоубийственно. (22) Ничего не выделяя, на RAID 10 на 4х SAS HDD или 2х SSD с батарейкой и гигом кеша. Ты смотрел нагрузку на HDD, создаваемую глобальным каталогом на 1500к пользователей? Она СМЕШНАЯ. ЕМНИП, на каталог до 20 000 пользователей мелкософт рекомендовал выделять порядка 512 мегов дополнительной памяти. |
(23) Т.е. отключение кэширования записи на диски никак не сказывается на производительности? |
Текущее время: 10:15. Часовой пояс GMT +3. |