1С 8.2 и безмерное отъединение памяти на windows x64
Исходные:
Терминальный виртуальный сервер Windows 2008 х64.
16 Гб памяти
Файловая 1С 8.2
Конфа Бухгалтерия 2:0
Одна из баз размером 10 Гб, остальные 1-3 Гб.
Одновременно запущено примерно 5-7 1С процессов.
Когда стоял 32 битный сервак, стояло 8 Гб памяти и их хватало на все (5-10) пользователей.
Перешли на х64 и уже 16 Гб, как правило забиты полностью.
И главное в ТаскМенеджере не видно, какой процесс так съедает память:
Здесь видим, что память под завязку.
А максимально не так много занято 1С ками. Процессы отсортированы по уменьшению потребления памяти.
Почему так происходит?
Во первых не понятно, что занимает память, а во вторых куда же она девается?
Кто знает тащит ли 1С в память всю базу в файловом варианте?
Терминальный виртуальный сервер Windows 2008 х64.
16 Гб памяти
Файловая 1С 8.2
Конфа Бухгалтерия 2:0
Одна из баз размером 10 Гб, остальные 1-3 Гб.
Одновременно запущено примерно 5-7 1С процессов.
Когда стоял 32 битный сервак, стояло 8 Гб памяти и их хватало на все (5-10) пользователей.
Перешли на х64 и уже 16 Гб, как правило забиты полностью.
И главное в ТаскМенеджере не видно, какой процесс так съедает память:
Здесь видим, что память под завязку.
А максимально не так много занято 1С ками. Процессы отсортированы по уменьшению потребления памяти.
Почему так происходит?
Во первых не понятно, что занимает память, а во вторых куда же она девается?
Кто знает тащит ли 1С в память всю базу в файловом варианте?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
По картинке что то не похож на 2008, вроде 2003. Как вариант попробовать разрешить выделение более 1 Гб на 32 битный процесс, это делается в настройках запуска ОС. Базу всю в память 1с не загружает, при нормальной работе в памяти обычно 150-250Мб. При большом объеме базы обычно 1с тормозит а не жрет память. Перезагрузка сервера решает проблему на какой нибудь срок или в первый же день работы снова жрет память?
(2) Ну про сервак могу ошибаться, что-то в свойствах не написана версия..
Память набирается по мере запуска 1С-ок, моментально.
Т.е. можно запустить даже одну 1С и построить большой отчет карточку и она отъест половину (гигов 8) по графику, а так будет показывать, что процесс занял не более 1 Гб.
Вобще у нас процессы и так могу брать более 1Гб, до 3 Гб точно 1С забирала как то при закрытии месяца.
Я конечно далеко уже не шарю в винде, но по моему толи не верно отображает ТаскМенеджер, толи чего то не отображает.
Память набирается по мере запуска 1С-ок, моментально.
Т.е. можно запустить даже одну 1С и построить большой отчет карточку и она отъест половину (гигов 8) по графику, а так будет показывать, что процесс занял не более 1 Гб.
Вобще у нас процессы и так могу брать более 1Гб, до 3 Гб точно 1С забирала как то при закрытии месяца.
Я конечно далеко уже не шарю в винде, но по моему толи не верно отображает ТаскМенеджер, толи чего то не отображает.
(3) FreeArcher, таск менеджер может и не отображать, память как бы зависает где то у меня тоже так было (можно убедиться завершив сеансы текущих пользователей, памяти освободиться намного больше чем должно бы). Попробуйте именно перезагрузить сервак (чтоб вся зависшая память очистилась)и после этого смотреть как будет потребляться память и через какое приблизительно время начнет проявлять себя проблема (у меня месяц работало нормально, потом загрузка начинала расти). Еще проверьте журнал ошибок винды, особенно закладку система (а лучше все) на предмет ошибок.
(4) Когда завершаем процессы 1С память высвобождается полностью, т.е. занято не более 1,5 Гиг.
Перезагрузить конечно попробую, но помнится память занимается по мере запуска больших задач. на 1С. Т.е. вот сформировал карточку за квартал и все памяти на 4-5 гига стало меньше свободной. Ну а когда все работают почти всегда потолок уже. И пока 1С не закроешь память не высвобождается.
Перезагрузить конечно попробую, но помнится память занимается по мере запуска больших задач. на 1С. Т.е. вот сформировал карточку за квартал и все памяти на 4-5 гига стало меньше свободной. Ну а когда все работают почти всегда потолок уже. И пока 1С не закроешь память не высвобождается.
(7) FreeArcher, проблема сидит либо в базе 10гб, либо в virtualbox, либо в самой винде. Надо пробовать разные варианты, если перезагрузка виртуалки проблему не решает, значит надо думать в сторону virtualbox. Платформа 1c и virtualbox то кстати свежие? Вполне возможно что virtualbox с таким объемом памяти не справляется, на железный сервак нельзя перенести или на нем еще другие задачи решаются?
(8) А кто говорил про virtualbox. Там вобще Солярис стоит.
Но не в этом суть
Сейчас разговаривал с одним специалистом по серверам и 1С, он говорит, что файловая 1С под каждую сессию создает для себе виртуальную среду, чем и потребляет много памяти. Т.е. вот запустил пользователь 2 сессии одной и той же базы, создались 2 отдельные среды и так для каждого пользователя.
При сервере приложений создается только одна виртуальная среда на базу для все пользователей, тем самым и экономится память.
Но не в этом суть
Сейчас разговаривал с одним специалистом по серверам и 1С, он говорит, что файловая 1С под каждую сессию создает для себе виртуальную среду, чем и потребляет много памяти. Т.е. вот запустил пользователь 2 сессии одной и той же базы, создались 2 отдельные среды и так для каждого пользователя.
При сервере приложений создается только одна виртуальная среда на базу для все пользователей, тем самым и экономится память.
(9) Существует такая же проблема на виртуальном сервере (исходные такие же, кроме памяти - 8 Гб)- медленная работа пользователей и т.д.
Но - даже когда ресурсоемкие регламентные операции выполняются монопольно в базе (и со всеми отключеннными сессиями на сервере, кроме теущей, конечно) - все равно вываливается ошибка "Недостаточно памяти".
Клиент пока всячески открещивается от SQL...
Но - даже когда ресурсоемкие регламентные операции выполняются монопольно в базе (и со всеми отключеннными сессиями на сервере, кроме теущей, конечно) - все равно вываливается ошибка "Недостаточно памяти".
Клиент пока всячески открещивается от SQL...
(23) SQL поможет только с блокировками, медленная работа не убыстрится.
В х86 архитектуре процесс в памяти может занимать не боле 2 Гб, в Х64 не более 4 Гб. Если у вас журнал регистрации настолько большой то проблема именно в этом. Поможет тут SQL даже не знаю, ведь журнал все равно на клиенте будет выводится. Хотя возможно все отборы будут проходить на стороне сервера и тогда нормально.
В х86 архитектуре процесс в памяти может занимать не боле 2 Гб, в Х64 не более 4 Гб. Если у вас журнал регистрации настолько большой то проблема именно в этом. Поможет тут SQL даже не знаю, ведь журнал все равно на клиенте будет выводится. Хотя возможно все отборы будут проходить на стороне сервера и тогда нормально.
(12) Сервер SQL и сервер приложения 1С находятся на разных машинах, память отжирается на машине с сервером приложения 1С. Прежде и далее я говорю только о сервере приложения 1С
(13) Спасибо, очень похоже на решение моей проблемы, но есть одно "но" : там написано
>>"..и небольшим или нулевым количеством активных пользователей"
а у меня пользователей более 100 и меньше 15 никогда не бывает.
У меня крутится регламентное задание, которое считывает журнал регистрации и помещает его в регистр сведений (называется "Очень быстрый журнал регистрации", как то так, внедрял не я. Когда оно не работает - потребляется где то около 6 гигов памяти, когда стартует оно - моментально отъедаются все 24 гига, да так, что на сервер даже по rdp не зайти.
Моя проблема больше напоминает
И еще - просто по теме настройки и отказоустойчивости.
Попробую обновиться на 319
(13) Спасибо, очень похоже на решение моей проблемы, но есть одно "но" : там написано
>>"..и небольшим или нулевым количеством активных пользователей"
а у меня пользователей более 100 и меньше 15 никогда не бывает.
У меня крутится регламентное задание, которое считывает журнал регистрации и помещает его в регистр сведений (называется "Очень быстрый журнал регистрации", как то так, внедрял не я. Когда оно не работает - потребляется где то около 6 гигов памяти, когда стартует оно - моментально отъедаются все 24 гига, да так, что на сервер даже по rdp не зайти.
Моя проблема больше напоминает
И еще - просто по теме настройки и отказоустойчивости.
Попробую обновиться на 319
(14) Ну тут надо по коду посмотреть. Например в этой обработки скорее всего журнал регисрации читается в Таблицу значений. Далее прикинуть какой размер этого журнала. Если столько пользователей и он не обрезается, то он будет просто громадным. А таблица значений в памяти весит. Т.е. все логично.
Может менять код и грузить порциями, или обрезать журнал после каждой загрузки.
Может менять код и грузить порциями, или обрезать журнал после каждой загрузки.
(15) По коду там журнал выгружается в XML и читается уже из файла. При этом выгружается и читается не весь журнал, а только еще не прочитанные с момента прошлого запуска записи.
Даже если просто открыть журнал регистрации и сделать любой отбор - объем занимаемой памяти тут же подскакивает с 5-6 до 20 гигов.
Даже если просто открыть журнал регистрации и сделать любой отбор - объем занимаемой памяти тут же подскакивает с 5-6 до 20 гигов.
(16) А куда журнал читается из XML? Есть промежуточный носитель. Или сразу по мере прочтения пишется. Скорее всего файл читается, путь и не весь, отсюда и память. Да и вы это подтвердили что журнал очень большой.
Я думаю только менять код.
Или читать журнал порциями, по сколько-то строк или по времени, час например.
Или писать в регистр по мере прочтения файла журнала, т.е. не грузить его в память.
Так а если ночью переносить журнал ночью делать, тоже напрягает?
Я думаю только менять код.
Или читать журнал порциями, по сколько-то строк или по времени, час например.
Или писать в регистр по мере прочтения файла журнала, т.е. не грузить его в память.
Так а если ночью переносить журнал ночью делать, тоже напрягает?
(17) Я согласен с вами в том, что память будет расходоваться. Но не 20 же гигов! Это каких размеров должен быть файл XML, чтобы при чтении с помощью ЧтениеXML отъелось 20 гигов?
Файл читается с помощью ЧтениеXML, и процессе чтения сразу же пишется в регистр сведений, после чего удаляется с жесткого диска.
И как тогда объяснить, что при простом открытии журнала регистрации и установке отбора вся ситуация повторяется? Там внутри код изменить не получится.
За день пользователи сгенерируют очень много событий, процесс загрузки будет долгим. а ночью сервера иногда перезагружаются. В данный момент задание стартует каждые 30 минут, и выполняется в среднем за 15-20 минут. При этом занято в среднем 20 гигов, и работа пользователей возможна. Но иногда бывает так, что забиваются все имеющиеся 24, и вот тогда всех выбрасывает.
Я все же планирую обновиться на 319. хуже то явно уже не будет.
Файл читается с помощью ЧтениеXML, и процессе чтения сразу же пишется в регистр сведений, после чего удаляется с жесткого диска.
И как тогда объяснить, что при простом открытии журнала регистрации и установке отбора вся ситуация повторяется? Там внутри код изменить не получится.
За день пользователи сгенерируют очень много событий, процесс загрузки будет долгим. а ночью сервера иногда перезагружаются. В данный момент задание стартует каждые 30 минут, и выполняется в среднем за 15-20 минут. При этом занято в среднем 20 гигов, и работа пользователей возможна. Но иногда бывает так, что забиваются все имеющиеся 24, и вот тогда всех выбрасывает.
Я все же планирую обновиться на 319. хуже то явно уже не будет.
ЗаписьЖурналаРегистрации("Журнал регистрации.Начало выгрузки данных журнала", УровеньЖурналаРегистрации.Информация, Метаданные.Подсистемы.жр_АнализЖурналаРегистрации, ИмяФайлаДанных, СокрЛП(ПредставлениеФильтра));
Ошибка = "";
Попытка
ВыгрузитьЖурналРегистрации(ИмяФайлаДанных, Фильтр);
Исключение
// может не хватить места, но это не повод не загружать данные.
// начнем, и мелкими пачками загрузим
// а переременную установим для отладки
Ошибка = ОписаниеОшибки();
КонецПопытки;
ЗаписьЖурналаРегистрации("Журнал регистрации.Завершение выгрузки данных журнала", УровеньЖурналаРегистрации.Информация, Метаданные.Подсистемы.жр_АнализЖурналаРегистрации, , Ошибка);
ПоказатьОбратите внимание на первую и последнюю строчки. В ЖР регистрируется когда журнал начал выгружаться, и когда он закончил выгружаться. Я щас посмотрел по этим записям (странно, почему раньше не догадался этого сделать) - между ними по времени разница в среднем 18 минут.
То есть код тут не при чем.
UPD.
Если запускать предприятие в управляемом режиме, и оттуда смотреть журнал регистрации - журнал формируется быстро.
(19) demon_infernal, Раз уж у вас журнал регистрации дублируется в регистр сведений "Очень быстрый журнал регистрации", то при выполнении метода ВыгрузитьЖурналРегистрации(ИмяФайлаДанных, Фильтр) память будет расходоваться динамически, т. к. сам журнал регистрации большой. Представте себе как будет происходить выборка согласно фильтру, если у вас выгрузка происходит примерно 18 минут, то могу сказать, что у вас очень большой журнал регистрации и походу не урезается. Советую вам урезать журнал регистрации через конфигуратор, т.к. все равно у вас события пишутся в регистр.
У меня проблема вроде решилась обрезкой журнала регистрации через конфигуратор. Во всяком случае, задание загрузки его в регистр сведений стало выполняться около минуты и подвисания с вылетом всех пользователей прекратились. Но на 319 скорее всего обновлюсь.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот