Appautocheckmode 1с грузит процессор
(2) Там стоит 0, процессы не перзапускаются, вообще на этой форме все по нулям и приоритет на производительности
(4) Не успел увидеть вопрос снят. Но мне когда-то админы утверждали, что частый ребут сервера - вреден. Даже раз в неделю не хотели делать.
(3) тогда другой вариант: кто-то запускает дикий жесткий внешний отчет (или встроенный отчет, но без отборов - за все года по всем аналитикам), который сжирает всю память в ноль.
(7) памяти 32 гига , 18 на SQL отдано, остальное рпхостам, в момент пиковой нагрузки было доступно еще 4 гига, проблем в нехватке памяти нет.
А по поводу перегрузки сервера каждый день, это было сделано для разгона юзеров, но не работало, после перегрузки сеансы снова восстанавливались, может еще здесь как то собака порылась. И остановка службы 1с батниками и запуск через час тоже не помогали. Я так и не понял почему такое происходит.
(10) Вот сейчас смотрю, бух записьвсего 1236794654 , спрашиваю что делала, говорит только платежки набивала.. и по памяти она рекордсмен 1989947775.
Врать не станет
ну это я уже смотрю сейчас всего (сеанс начать 3 часа назад), попробую в момент загрузки смотреть текущие значения, но уже смотрел не смог отловить кто и что причина.
"после перегрузки сеансы снова восстанавливались" - еслиуж перегружать, то перезагружать оба сервера (1С и SQL) Сервер SQL "восстанавливает" прерванные соединения. Имхо. У Вас действительно проблемы. не только с железом :)
(16) 8.3
(14) 1с и скл живут на одном сервере
И еще момент восстанавливали сеансы базы с толстыми клиентами, и сами базы в режиме совместимости с 8.2 8.1. Но это так отступление от темы, потому что это происходит и на другом сервере где проблем с пиковыми нагрузками нет.
Сейчас написана иб которая только и занимается тем что удаляет сеансы пользователей на кластерах, сейчас проблем с бэкапами нет. (И причина тоже не в ней, написана она была уже во время проблем с производительностью)
13. Стандартные платежки БП3
(18) Да, спс, я знаю - у Вас платформа 8.3.10.2639. У меня 8.3.11.3034 и сейчас сидят два десятка пользователей на одном(!) rphost-е сервера 1С - ЧЯДНТ?
Ну возможно просто проц. слабый, сервер такой себе в плане процессора. В среднем порядка 70 сеансов, проц XEON E3-1230 3.3 ГГЦ
Но блин иногда неделями же работает без проблем, и пиковая нагрузка проходит в течении 10-30 минут
(офф) Имхо, в 1С сложно угадать что не так пошло. Помню, было дело, поймал ошибку платформы, когда всю память сервер активно забивал в то время, когда в базе работали только рег.задания без активных пользователей.
(22) Там вообще по нулям, эта колонка мне знакома когда переводил с бп2 - бп3 там висели большие значения и сам перевод висел но сервер работал как надо.
Если у автора действительно rphostЫ, то по Диспетчеру задач на закладка "Подробности" можно подсмотреть идентификатор процесса, который грузит сервер, а в оснастке администрирования серверов 1С, в сеансах, можно посмотреть кто сидит на этом процессе, чем занят - журнал регистрации. Круг ссужается. Как вариант, имхо, интерес также вызывают те пользователи, которые грузят сервер, но в журнале регистрации действий не имеют записей в этот период - не исключено что они грузят сервер отчетами.
(27) Спасибо, буду пробовать.
Но вешает базу не один рпхост, нагрузка немного размазана по 2-3 процессам.
(32) тоже самое что и в (27) но уже доступно с учетки ИТС, спасибо
Сейчас посмотрел по "Время вызова общее" с утра максимальное значение 104.186 затем 84, 68, 24 (это с утра, примерно 4-5 часов).
В принципе узнал вещи которые не знал, попробую проанализировать.
(0) > под каждую базу создается свой рпхост
Зачем?
Этой фигнёй имеет смысл страдать в исключительных случаях в целях расследования проблем. Например, когда никак не удаётся вычислить, какая именно ИБ сбоит.
(4) > сервер перегружается каждую ночь
Зачем? Вам больше заняться нечем?
(8) > это было сделано для разгона юзеров
Зачем? Чем вам мешают работающие юзеры?
> остановка службы 1с батниками и запуск через час тоже не помогали
Это от того, что кому-то лень почитать документацию. Пример "правильного" батника от 1С (для 64-битного сервера, у которого папка кластера размещена по нетиповому пути "F:\srvinfo\reg_1541", а пользователь, от имени которого работает служба 1С называется Admin_1C):
set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-
64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
При необходимости в батник следует добавить еще остановку службы сервера хранилища и службу агента ЦКК.
Потом не забыть всё это хозяйство запустить. У 1С на ИТС есть соответствующий батничек для старта всех служб.
А вообще по сути дела.
Перестаньте маяться ерундой.
Настройте технологический журнал и счетчики производительности винды.
(35) Что дадут счетчики производительности винды, покажет что у меня проц на серваке загружен до 100%, я и так это знаю. Мои счетчики производительности в виде юзеров мне сразу сообщают об этом. Дальше то что?
Технологический журнал попробую включить посмотреть, но плохо себе представляю что там смотреть, пару раз всего пользовался когда искал ошибку.
А почему не создавать проц. под каждую иб, в этом есть что-то что может привести к проблемам?
(38) в (34) писал, это разве большие показатели для отсчета с утра. Да и база которая показывает масимум появилась уже после проблем с производительностью
Долго гадал, почему из трех практически идентичных компьютеров Core I7 одного и того же поколения 1С на двух работает быстро, а на третьем существенно медленнее.
Так как там серверная БД, пришлось серьезно вникать в анализ производительности БД, купил даже курс
"Ускорение и оптимизация систем на 1С:Предприятие 8.3" и кстати не сочтите за рекламу - очень доволен остался. Парни просто профи в вопросе и умении излагать материал.
По советам из этого курса внедрил подсистему, фиксирующую время выполнения операций и стал изучать на 3х секундном процессе открытия определенной формы сколько тратится на запрос БД /процессорную обработку / Передачу данных на клиент.
Начал анализировать, у каких пользователей, в какое время, с какого сервера/клиента получается быстро или медленно.
Конечно же, поменял сервера местами, снова измерил время работы и выяснил что одинаковые сервера с чрезвычайно похожими сетапами дают разное время открытия формы. Хоть тресни.
Пошел к бородатому и чрезвычайно толковому сисадмину, рассказал про этот парадокс и он дал ответ, от которого во мне что-то перевернулось.
А я говорит, в одном сервере на днях в настройках электропитания поставил режим "Высокой производительности". Ну или в дополнительных параметрах питания, нашел раздел "Управление питанием процессора" - "Минимальное состояние процессора" - и поставил настройку 100%
Каково же было мое удивление, когда я замерил скорость открытия формы.
Я думаю, пояснять этот график не надо.
Конечно, грамотный айтишник скажет, что еще в БИОС надо выставлять максимальную производительность процессора, что бы в Windows уже не требовалось за этим следить. Но для сервера лезть в БИОС это целая история, причем ночная. А изменить сделать предложенную настройку настолько просто и очевидно - что стало стыдно за то, что потребовалось так много лет, что бы дойти до этой простой истины.
Ну и на всякий случай перечислю другие рекомендации, что записал для себя как обязательные..
- Использование скоростного SSD (можно SATA3, можно M.2)
- Запас оперативной памяти
- Windows тоже ставить на SSD или же обязательно переносить на SSD диск
- файл подкачки
- КЭШ сервера 1С (в реестре отредактировать команду запуска сервера)
- Терминальных пользователей вынес в отдельную виртуальную машину (тоже на SSD)
- Если используем решения на "обычных формах" - то никакой PostgreSQL - только MS SQL (Реагирую на гневный комментарий. - дело, конечно не в формах, а в технологии запросов, которые применялись в старых конфигурациях, когда допускалось соединение виртуальных таблиц без их предварительной записи во временную таблицу).
- Если решение на управляемых формах, то используем Web сервер для доставки приложения. Особенно заметно на файловых базах - ускорение получается даже на том компьютере, где лежит эта база (что казалось бы парадокс). А у сетевых клиентов - просто космос.
- Регулярное тестирование БД с пересчетом итогов.
- Если SQL - не забываем про регламентное обслуживание SQL базы.
Переводим сервер на старый вариант ведения логов журнала регистраций
В каждой папке с базой есть каталог 1Cv8Log, а в нем 2 файла: 1Cv8.lgd и 1Cv8.lgd-journal. Их надо удалить и вместо них в этой папке создать пустой файл 1Cv8.lgf. Проделать такую операцию нужно со всеми базами, где будете менять формат лога. Старый не обязательно удалять, лучше его перенести куда-нибудь, вдруг пригодятся записи из него.
После этого можно запускать службу Агента Сервера 1С:Предприятия. После перехода на старый формат журнала регистрации, нагрузка процесса rmngr.exe упала практически до 0, а сервера в целом до приемлемых 40-60%.
Специальные предложения
SerVer1C; papami; vadimlp77; Дмитрий74Чел; mirco; sevushka; WellMaster; user921389; kuzyara; 24rus; dandykry; akimych; starik-2005; + 13 – Ответить
Кэп, кэп, кэп. Про это уже написано, рассказано. много много.
Перепечатка курса?
Про pg vs ms хрень полная. Автор выставляет себя дилетантом. И как можно путать формы, режим приложения и режим блокировок?
Про Postgre vs MS не хрень. Выполнение запросов в старых конфигурациях, где не используют временные таблицы, а делают сразу объединение виртуальных таблиц на postgre делается неэффективно и по времени в 3-5 раз медленнее. Это зафиксировано в официальной документации и хорошо видно при формировании прайс листа в УТ 10 в двух разных sql.
(4) Попробую угадать. Вам не понравилось упоминание о неэффективности использования PostGre на приложениях с обычными формами. Что ж. Это понятно. Здесь, вероятно, надо было указать длинную цепочку событий:
Обычные формы -> это старые конфигурации -> 1С в старых конфах использовала старую методологию в запросах -> В таких конфигурациях не редкость объединение виртуальных таблиц без их предварительного выделения во временные -> PostGre медленно работает, если использовалась эта "старая" методология. -> в старых конфах PostGre не эффективен.
(5) только наверно не объединение, а соединение)
Я за точность высказываний. Чтобы человек, не понимающий темы не делал смысловой привязки к формам. Потому что этим человеком может оказаться заказчик, который увидит ОФ и сделает абсолютно идиотский вывод плохой работе ПГ.
Спасибо за исправление. Извините за резкость и "гневность")))
Я рад, что у вас глубокие знания и опыт. Но нужна ответственность перед более неопытными коллегами за каждое свое слово. Поэтому давайте не оставлять за кадром такие важные моменты, тем более в статье.
Справедливости ради замечу, что такой сильной корреляции между формами и качеством запросов я не замечал. Наверно потому что в УФ ПГ тоже часто отказывается работать. Соединения со срезами, по два полных соединения в запросе и т.д. Последние конфигурации для РФ вроде хороши, но локализованные решения или сильно отстают, или сделаны некачественно. Поэтому для меня нет такой аналоги с формами и не будет никогда.
Делается уже на автомате, когда в плане энергосбережения ставишь Высокая производительность, чтобы компьютер не засыпал.
(8) Я только ЗА.
Если кто-нибудь напишет утилиту или скрипт позволяющий делать подобные настройки на этапе установке сервера 1С в автоматическом режиме, было бы замечательно.
(9) Если кто-нибудь напишет утилиту. Остальные будут бояться ее запускать. Особенно в эпоху вирусов-шифровальщиков.
Капитан очевидность, приветствую тебя
Надо было для начала стартовать 1С с дискеты, тогда в заголовке можно было написать - Элементарный способ ускорить вашу 1С в миллион раз!
Спасибо автору, наткнулся на публикацию буквально в тот момент, когда у меня выполнялась ресурсозатратная операция. Настроил сервер - сэкономил время.
Может конечно и очевидные вещи. И уже об этом говорилось ранее.
Но я пробовал изменял параметры энергосбережения и не могу сказать, дало мне это изменение какой-то эффект или нет.
Автор провел практическую работу, сделал замеры и говорит, что есть положительный эффект.
Поэтому публикация однозначно +.
Бородатый админ - маст хэв!
Вообще, про режим высокой производительности я пишу в комментариях примерно раз в неделю - до сих пор, оказывается, есть народ, который не знает, почему это 1С (и не только) начинает работать быстрее раза этак в два. Автор, ты-то хоть знаешь, почему?
(18)А на файловых базах поможет? Часто для скорости приходится что-то тестировать до того, как на сервер обновления загружат.
Поможет, если алгоритм написан неоптимально. Т.е. процесс обработки данных сменяется процессом получения данных из хранилища. Если такое поведение в алгоритме частое (пример - запрос в цикле), то даже на файловой системе данная операция повысит производительность (хоть и не в два раза). Если же сначала все данные выбираются, потом обрабатываются, потом записываются в систему, то изменения будут не такими большими, но тоже будут - интерфейс начнет реагировать быстрее на действия пользователя.
Интересная и полезная статья. Новый, достаточно сложный материал изложен грамотно и доходчиво! Автор, огромное спасибо.
. Читая автора сложилось впечатление, что курс только куплен, но не пройден (с домашними заданиями), т.к. в данном курсе о данной настройке так же говориться.
PS Я, про "Этот курс" . Спасибо за курс Андрею и всей команде портала за его доступность, как в денежной, так и в интеллектуальной составляющей.
А сколько Алексея ждет открытий когда он научится план запроса анализировать, да виртуалку настраивать.
Спасибо за статью! В жизни всегда так - пока сам не разберешься, никто помочь не может, а как разберешься так сразу баян! Никого не слушай, особенно тех кто про баяны поет. Правильно сделал, что статью написал.
Мастерство заголовка, блин.
"Где можно натупить с настройкой сервера и просесть в производительности в два-три раза" - было бы ближе к телу.
На всякий случай. M2 это форм-фактор диска(даже семейство форм-факторов), а sata - протокол. Есть, и не мало, ssd в форм-факторе m2, которые работают по протоколу sata.
Более быстрый протокол называется NVM.
В принципе все очевидно, но напомнить никогда не мешает. Статья кратенько так написана, в самый раз чтобы вспомнить. Автору плюс. По PG vs MS можно подробнее, где и что написано, кто проводил замеры?
Замеры проводил я лично. А где написано - искать надо. Год назад это очень внимательно изучал. Теорию уже не найду, а практику - очень легко воспроизвести самому.
(40) Это значит, что в реестре нужно найти ветку [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent] в которой лежит команда запуска сервера ImagePath = "C:\Program Files (x86)\1cv8\8.3.13.1644\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files (x86)\1cv8\srvinfo" -debug
Кстати именно в ней мы ставим флаг -debug.
Посмотрев внимательно на эту строку увидим такой поддекст: -d "C:\Program Files (x86)\1cv8\srvinfo". В этом каталоге вы как раз и найдете "серверный" кэш всех использовавшихся вами баз.
(41) обычно debug я ставлю в такой последовательности, и отладка работает: "C:\Program Files\1cv8\8.3.13.1644\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -debug -d "C:\Program Files\1cv8\srvinfo"
Имеется ввиду что кэш можно перенести на другой диск ускорив тем самым работу сервера?
(42) Сам по себе перенос кэша имеет смысл только если системный диск перегружен, а диск на который переносите - способен работать в разы быстрее.. Что касается порядка команд - это едва ли имеет значение.
Когда я работал серваком ИТС в давние, но, не очень, времена, у одного клиента комплексная автоматизация 1.1 на ноутбуке(впарили чуваку на одно рабочее место, а, он кроме накладных в ней ничего и не делал, что, впрочем, на время обновления не влияло, поскольку, ноутбук был не из дорогих и быстрых), обновлялась около часа
Ну, обновлялась бы и обновлялась, у клиента положено быть не больше часа, пить кофе и болтать, так что укладывался во время. Но, райончик был "густонаселенным" клиентами, а, работа сдельная, сколько оббежишь столько и твое. И, вот, как в сабже, от нечего делать, копался винде во время зависшего процесса обновления и в диспетчере случайно обнаружил что двухгигагерцевый процессер работает на частоте 0,9 ГГц. мне это не понравилось и, малость нагуглив, узнал что это из - за экономичного плана питания. Недолго думая, залез и выставил наилучшую производительность, подняв вышеупомянутый параметр состояния процессора до 100%
Частота тут же подпрыгнула к 2ГГц как положено, а, зависший процесс обновления отвис буквально через несколько минут(перешел к следующему действу"обновить конфигурацию базы данных?"), а, еще минут через пять с конфигурацией базы данных благополучно справился и предложил принять изменения. ну, клиенту не сказал ничего про эту находку, а, повесил лапшу что новые обновления теперь ставятся быстрей чем раньше
Ну и после обновления питание вернул на место, чтобы, на всякий случай клиент не офигел от быстрого разряда батареи)))
Так короче и делал, приходил, включал перформанс, уходил - выключал
И не только у этого клиента
(44) Спасибо, может пригодится. Но я бы рекомендовал таки оставлять "100% перфоманс". Клиент, уверен, будет только в выигрыше.
спасибо полезная статья."тошнотики" и "умники" как всегда отличились.У кого корона шире так и не поняли,за то все умные учителя-"дилетант","капитан очевидность",прочие задросткие выражения ботаников самоучек.
Автор спасибо за статейку!
А вот, кстати, додавил переход на Linux у нас в конторе для отдельного чудо-"сервера" (машинка с 64-мя гигами на райзене 3600-м с памятью 3333). Сегодня коллега протестил - в Гилеве 120. Ладно, думаю, протестирую на клиент-сервере (режим сбалансированной производительности) - 45! (это постгрес + убунту сервер последний + xRDP и авторизация в домене).
До этого машина работала под вендой эссенциал, пускала, соответственно, двух юзеров всего. В Гилеве из-за старого ядра винды проц не аиделся толком и показывал в файловой 74 в Гилеве (у меня дома 1600-й показывал 89). Кароче, народ, крайне рекомендую новые райзены (ZEN+) в качестве "недосерверов". Надо будет завтра включить режим высокой производительности - должен серверный под 60 попугаев скакнуть.
Кстати, вот протестил несколько раз Гилевским тестом:
1. Снял режим совместимости - 104-110.
2. Оставил режим совместимости - 120.
А вот тут притесался Хеон Голд за дохрена денег с дохрена памяти, но, увы, всего 60 в файловой ))) У меня RYZEN 3600 за 12к с воздушным обдувалом. И это все в режиме ONDEMAND, т.е. "сбалансированная производительность", на SQL 44 попугая. Даже не представляю, сколько будет, если включу PERFORMANCE! )))
не слушайте глупого дядю, что вам скажет выставлять минимальное состояние процессора 100% - перегреваться будет процессор очень сильно, и сервак будет аварийно вырубаться. а поставить более мощьное охлаждение вам влетит в копейку, и не на все матери его можно прикрутить нормально. процессор сам нагрузится как ему нужно и во время простоя будет охлаждаться.
(51) Игорь, вероятно, вы очень трепетно относитесь к своей технике и не позволяете ей работать "сверхмеры". Это очень трогательно. Уверен, ваш ноутбук вас боготворит!
Тема хорошая и дискуссия тоже, автору плюс.
Включил режим высокой производительности на сервере с файловыми базами, опубликовал базы на IIS, завтра буду пользователей запускать, надеюсь поможет )
Всем доброго времени суток. Надеюсь получить полезный совет.
В последние несколько дней заимел проблемы с сервером и, как следствие, проблемы на тонких клиентах, которые работают очень медленно. Нагрузка на серверный процессор возросла до 100% и держится непрерывно. Диспетчер задач указывает, что основная проблема в rmngr.exe, который вкупе с процессами rphost.exe полностью загружает процессор. Анализ mngr.exe с помощью Process Monitor от Windows Sysinternals показал, что идет непрерывный доступ к C:\Program Files (x86)\1cv8\srvinfo\reg_1541\xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\1Cv8Log\1Cv8.lgd, где "xxx" — абсолютно разные каталоги. Если бы это был доступ к логам какой-то определенной базы, то можно было бы выявить закономерность, но доступ идет к разным и в основном это операции чтения. Процесс rmng.exe это менеджер сервера и я не могу понять, почему он стал настолько активным. Раньше все работало гладко.
Конфигурация: Windows Server 2008 R2 + MS SQL Server 2008 R2 + 1C 8.3.7.1776. На сервере находятся 18 баз данных: стандартные БП, ЗУП и парочка самописных. Отключение самописных баз не повлияло и нагрузка на процессор осталась. Доступ к базам данных ведется с рабочих станций доменов через локальную сеть и VPN, а также через сервер терминалов.
по умолчанию 1С усыпляет сеансы на сутки, иногда она начинает сходить с ума и начинает каждую секунду порождать по 2-3 спящих сеанса.
Т.е. нужно в консоли посмотреть так ли это. И если это так то в параметрах базы уменьшить время жизни таких сеансов с 24 часов хотя бы до минут 10
Aleksey, системный планировщик каждую ночь перезапускает все службы, связанные с сервером 1C и MS SQL. По идее, все должно убиваться.
(4) Ты будешь смеяться но ни перезагрузка компьютера, ни переустановка сервера 1С не убивает эти процессы. Походу он куда то в блокнотик себе пишет и при восстановлении сервера автоматом восстанавливает и эти сеансы
Dmitrii, спасибо за информацию, я попробую. Есть ли какая-нибудь тенденция того, что новый формат журнала регистрации становится причиной таких проблем и совместима ли моя версия сервера со старым форматом?
(7) Ошибка с неконтролирумым ростом нагрузки на процесс при использовании нового формата журнала регистрации обсасывалась на партнерском форуме. Пост (5) взят оттуда.
1С обещала проблему устранить, но сроки не озвучивала. В 8.3.7 проблема пока есть.
Конкретных причин возникновения проблемы не знаю. У нас журнал работает нормально (тьфу-тьфу-тьфу).
(9) Я замечал что ппц начинается если усиленно в журнале чтото искать и делать отборы, причём в динамическом режиме
Dmitrii, можешь расписать алгоритм моих действий поподробнее? Правильно ли я понял?
1. Остановить 1С сервер.
2. Переименовать каталог 1Cv8Log в 1Cv8Log.bak для каждого GUID.
3. Для каждого GUID создать новый каталог 1Cv8Log и создать внутри файл 1Cv8.lgf.
(11) Можно и так, чтобы сохранить имеющиеся логи (п.2)
Недостаток данного метода в том, что ведение журнала начнется с нуля. Все предыдущие логи останутся в папках 1Cv8Log.bak
Но другого способа возвращения на журнал старого формата увы нет.
Меня сейчас логи мало волнуют, больше интересует стабильность сервера, тем более, под конец года. Если ты говоришь, что у тебя нет проблем с журналами, то посмотри, пожалуйста, сколько весят твои lgd-файлы.
Еще не совсем понятно, почему появились эти проблемы. Релиз был установлен 12 декабря и после установки сервер работал быстро, но примерно три дня назад начались проблемы. Размер журналов меня мало интересовал раньше. Сейчас глянул — 25 ГБ на все 18 баз данных. Базы мигрировали с файловой версии на MS SQL примерно полгода назад.
Garikk, этим можно было бы объяснить причины, но они явно в другом, потому что нагрузка на процессор достигает 100% даже ночью, когда точно никто не работает.
(13) Лог основной рабочей базы - 23Гб.
Сама база ~50Гб. БП 3.0. За период с марта по настоящее время.
Лог не сокращали и не выгружали.
(14) Ошибка журнала плавающая. Если я правильно понял, то часто возникает при обменах данными (РИБ) и интенсивной работе с журналом по типу (10).
Хм, спасибо. Сегодня в 13:00, когда все юзвери уйдут обедать, я постараюсь вернуться к старой системе журналирования. О результатах отпишусь позже.
Кстати вместо сохранения логов в папки 1Cv8Log.bak лучше воспользоваться типовым методом СкопироватьЖурналРегистрации с указанием имени выходного файла. Получите файл, который потом сможете смотреть в 1С в конфигураторе или в пользовательском режиме.
Такой метод займет много времени, если я буду ковырять все 18 баз данных. Если приспичит, то я потом перекину логи на другой аналогичный сервер с такой же конфигурацией, где пока нет таких проблем.
Думаю, будет проще и быстрее остановить сервер, пробежаться руками по каждому GUID через проводник и в каждый GUID вставить заранее заготовленный 1Cv8Log с пустым 1Cv8.lgf.
Отписываюсь, как и обещал. Первые 20 минут работы сервера после проделанных манипуляций. Сервер пишет журналы в .lgf и автоматический созданные .lgp-файлы. Первый запуск баз данных после перезапуска служб был очень долгим, однако работа вполне быстрая. Процесс rmngr.exe загружает процессор на 1-5%, однако я заметил, что процессы rphost.exe начали потреблять больше, но сервер все равно не загружается на 100%. Нагрузка не постоянная, а скачкообразная, в среднем около 80%.
Оставляю этот комментарий на тот случай, если вдруг кто-то столкнется с подобной проблемой. Возможно, через Яндекс или Google он сможет наткнуться на эту тему. Всем спасибо.
У меня проблема точно такая же. за неделю логи достигают 28 Гб и грузят проц на 60-70%. Помогает только чистка логов.
Попробовал заменить логи на старый формат, как написано тут.
Запустил сервер, в базы заходит, но при попытке посмотреть любой отчет, базы зависали и не реагировали никак. поменял логи обратно - все работает. что я делаю не так?
(24) >> при попытке посмотреть любой отчет, базы зависали
Речь об отчетах по журналу регистрации или отчетах вообще (любых, по регистам и пр.).
(24) >> за неделю логи достигают 28 Гб . Помогает только чистка логов
Если для вас логи не так сильно важны, то может имеет смысл попробовать настроить журнал регистрации, чтобы вообще не регистрировать никакие события или только ошибки?
Именно попробовать, чтобы убедиться, что проблема именно в этом.
Еще можно попробовать в свойствах рабочего сервера кластера установить галку "Менеджер под каждый сервис". Под сервис журналов регистрации будет выделен отдельный менеджер rmngr.exe. Понаблюдать за ним.
в общем фиг знает, сегодня подложил туже самую папку со старым форматом лога, что и до этого - все заработало. Фиг знает, что с ним было до этого. спасибо, буду наблюдать
Думаю стоит сразу предупредить, что работаю системным администратором а не 1с программистом.
Поэтому: С кодом программы не дружу, решение проблемы искал в интернете и просьба не флудить.
Началось не понятно когда и не понятно с чего.
Но на сегодняшний день такая ситуация:
1. Постоянные зависания у клиентов. (Которые подключаются по RDP, но не все)
-Проверял канал связи, оборудование, и ним все нормально.
-Грешил на модем, поменял.
3. Загружается ЦП на 100%
-Такое ощущение что процесс 1С входит в какой то цикл или еще как то.
Выписки из журнала:
Имя сбойного приложения: PrintIsolationHost.exe, версия: 6.1.7600.16385, отметка времени: 0x4a5bd3b1го модуля: ntdll.dll, версия: 6.1.7600.16915, отметка времени 0x4ec4b137
Код исключения: 0xc0000374
Смещение ошибки: 0x00000000000c6ae2
Идентификатор сбойного процесса: 0x109f4
Время запуска сбойного приложения: 0x01cec3eebb6c7009
Путь сбойного приложения: C:\Windows\system32\PrintIsolationHost.exe
Путь сбойного модуля: C:\Windows\SYSTEM32\ntdll.dll
Код отчета: 0edfd1ab-2fe2-11e3-a1c3-0050fca17504
Имя сбойного приложения: 1cv8.exe, версия: 8.2.19.68, отметка времени: 0x5225f7b5
Имя сбойного модуля: ntdll.dll, версия: 6.1.7600.16915, отметка времени 0x4ec49d10
Код исключения: 0xc0000374
Смещение ошибки: 0x000ce903
Идентификатор сбойного процесса: 0xc4b8
Время запуска сбойного приложения: 0x01cec3a9bb6abcc8
Путь сбойного приложения: C:\Program Files (x86)\1cv82\8.2.19.68\bin\1cv8.exe
Путь сбойного модуля: C:\Windows\SysWOW64\ntdll.dll
Код отчета: 4c2527dd-2fab-11e3-a1c3-0050fca17504
Посмотрите в журнал 1С и/или спросите у вылетающих клиентов, что они делали в 1С при вылете.
Имхо, отсюда и надо искать.
Некоторые неграмотные пользователи запускают отчеты с огромным выводом информации, за большой период и потребляющие немерянные ресурсы.
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
ИО Капитана Очевидности
Имя сбойного приложения: PrintIsolationHost.exe, версия: 6.1.7600.16385, отметка времени: 0x4a5bd3b1го модуля: ntdll.dll, версия: 6.1.7600.16915, отметка времени 0x4ec4b137 » |
Модуль "изоляции" принтера. По идее должен выделять каждому пользователю отдельную службу печати, чтобы сбой в драйвере принтера у одного пользователя не вызвал проблем с печатью у других пользователей. По какой-то причине всё-таки вызывает ошибку.
Возможно на рабочем месте какого-то клиента стоит глючное устройство.
3. Загружается ЦП на 100% -Такое ощущение что процесс 1С входит в какой то цикл или еще как то. » |
-------
Самое совершенное оружие, которым забиты арсеналы богатых и процветающих наций, может легко уничтожить необразованного, больного, бедного и голодного. Но оно не может уничтожить невежество, болезнь, нищету и голод. (Фидель Кастро)
Почему всех осужденных за измену Родине при Сталине реабилитировали при Горбачёве по отсутствию состава преступления? Потому что при Горбачёве измену Родине перестали считать преступлением.
Один из серверов 1С, который я обслуживаю, очень странно себя вел. Загрузка процессора на машине с сервером 1С почти всегда была 100%, даже когда на нем никто не работал. Базы хранились в MSSQL, их было относительно много, но реально людей, которые с ними работали - мало. Одновременно работало не больше 10-15-ти пользователей в очень вялом режиме.
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный теcт.
Введение
Этот сервер привлек мое внимание сразу же, как только я стал с ним работать. Предыдущий администратор безрезультатно бился над производительностью, приобрел 2 внешних корзины для отдельного рейда под базы данных mssql и временные данные пользователя 1С, но существующую проблему по загрузке процессора это не решало, хотя немножко разгрузило диски, но реальная проблема была не в них.
На сервере размещались примерно 30-35 баз, в которых работали по 1-2 человека и пару баз были, где работали по 3-5 человек одновременно. Все это крутилось вместе с MSSQL сервером на отдельном железном сервере с одним стареньким ксеоном и 32 гб оперативы. В принципе, для этих задач железо было более чем.
Первое, на что я обратил внимание, это то, что процессор был загружен даже ночью, когда на сервере никто не работал. Полез в консоль администратора смотреть, что нагружает процессор. Оказалось, что это фоновые задачи. Для большинства баз они были не нужны и все лишнее отключил. Нагрузка процессора сразу упала до приемлемого уровня в 60-70%, а диски вообще полностью разгрузились. Я про сервер забыл на какое-то время.
Снова к нему вернулся, когда пользователи стали жаловаться на очень медленную работу баз 1С. Процессор к тому времени почти всегда был загружен на 100%. Лишних фоновых задач уже не было. Надо было разбираться более внимательно, в чем тут проблема.
Заключение
После того, как вы решите все проблемы на сервере 1С, процессы менеджера кластера нужно снова объединить в 1, убрав отвечающую за этот параметр галку в свойствах рабочего сервера. 1С не рекомендует постоянно использовать такой режим работы, так как он является отладочным.
В очередной раз я победил тормоза 1С в виде 100% загрузки процессора сервисом rmngr.exe. С базами 1С никогда не приходится скучать, постоянно решаешь какие-нибудь вопросы и проблемы, которые возникают чаще всего после обновлений. С настороженностью смотрю на рост потребления ресурсов процессами rphost.exe. Чутьем чую, что скоро придется решать вопросы загрузки процессора именно ими.
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Проверьте себя на вступительном тесте и смотрите подробнее программу ссылке.
Специальные предложения
SerVer1C; papami; vadimlp77; Дмитрий74Чел; mirco; sevushka; WellMaster; user921389; kuzyara; 24rus; dandykry; akimych; starik-2005; + 13 – Ответить
Кэп, кэп, кэп. Про это уже написано, рассказано. много много.
Перепечатка курса?
Про pg vs ms хрень полная. Автор выставляет себя дилетантом. И как можно путать формы, режим приложения и режим блокировок?
Про Postgre vs MS не хрень. Выполнение запросов в старых конфигурациях, где не используют временные таблицы, а делают сразу объединение виртуальных таблиц на postgre делается неэффективно и по времени в 3-5 раз медленнее. Это зафиксировано в официальной документации и хорошо видно при формировании прайс листа в УТ 10 в двух разных sql.
(4) Попробую угадать. Вам не понравилось упоминание о неэффективности использования PostGre на приложениях с обычными формами. Что ж. Это понятно. Здесь, вероятно, надо было указать длинную цепочку событий:
Обычные формы -> это старые конфигурации -> 1С в старых конфах использовала старую методологию в запросах -> В таких конфигурациях не редкость объединение виртуальных таблиц без их предварительного выделения во временные -> PostGre медленно работает, если использовалась эта "старая" методология. -> в старых конфах PostGre не эффективен.
(5) только наверно не объединение, а соединение)
Я за точность высказываний. Чтобы человек, не понимающий темы не делал смысловой привязки к формам. Потому что этим человеком может оказаться заказчик, который увидит ОФ и сделает абсолютно идиотский вывод плохой работе ПГ.
Спасибо за исправление. Извините за резкость и "гневность")))
Я рад, что у вас глубокие знания и опыт. Но нужна ответственность перед более неопытными коллегами за каждое свое слово. Поэтому давайте не оставлять за кадром такие важные моменты, тем более в статье.
Справедливости ради замечу, что такой сильной корреляции между формами и качеством запросов я не замечал. Наверно потому что в УФ ПГ тоже часто отказывается работать. Соединения со срезами, по два полных соединения в запросе и т.д. Последние конфигурации для РФ вроде хороши, но локализованные решения или сильно отстают, или сделаны некачественно. Поэтому для меня нет такой аналоги с формами и не будет никогда.
Делается уже на автомате, когда в плане энергосбережения ставишь Высокая производительность, чтобы компьютер не засыпал.
(8) Я только ЗА.
Если кто-нибудь напишет утилиту или скрипт позволяющий делать подобные настройки на этапе установке сервера 1С в автоматическом режиме, было бы замечательно.
(9) Если кто-нибудь напишет утилиту. Остальные будут бояться ее запускать. Особенно в эпоху вирусов-шифровальщиков.
Капитан очевидность, приветствую тебя
Надо было для начала стартовать 1С с дискеты, тогда в заголовке можно было написать - Элементарный способ ускорить вашу 1С в миллион раз!
Спасибо автору, наткнулся на публикацию буквально в тот момент, когда у меня выполнялась ресурсозатратная операция. Настроил сервер - сэкономил время.
Может конечно и очевидные вещи. И уже об этом говорилось ранее.
Но я пробовал изменял параметры энергосбережения и не могу сказать, дало мне это изменение какой-то эффект или нет.
Автор провел практическую работу, сделал замеры и говорит, что есть положительный эффект.
Поэтому публикация однозначно +.
Бородатый админ - маст хэв!
Вообще, про режим высокой производительности я пишу в комментариях примерно раз в неделю - до сих пор, оказывается, есть народ, который не знает, почему это 1С (и не только) начинает работать быстрее раза этак в два. Автор, ты-то хоть знаешь, почему?
(18)А на файловых базах поможет? Часто для скорости приходится что-то тестировать до того, как на сервер обновления загружат.
Поможет, если алгоритм написан неоптимально. Т.е. процесс обработки данных сменяется процессом получения данных из хранилища. Если такое поведение в алгоритме частое (пример - запрос в цикле), то даже на файловой системе данная операция повысит производительность (хоть и не в два раза). Если же сначала все данные выбираются, потом обрабатываются, потом записываются в систему, то изменения будут не такими большими, но тоже будут - интерфейс начнет реагировать быстрее на действия пользователя.
Интересная и полезная статья. Новый, достаточно сложный материал изложен грамотно и доходчиво! Автор, огромное спасибо.
. Читая автора сложилось впечатление, что курс только куплен, но не пройден (с домашними заданиями), т.к. в данном курсе о данной настройке так же говориться.
PS Я, про "Этот курс" . Спасибо за курс Андрею и всей команде портала за его доступность, как в денежной, так и в интеллектуальной составляющей.
А сколько Алексея ждет открытий когда он научится план запроса анализировать, да виртуалку настраивать.
Спасибо за статью! В жизни всегда так - пока сам не разберешься, никто помочь не может, а как разберешься так сразу баян! Никого не слушай, особенно тех кто про баяны поет. Правильно сделал, что статью написал.
Мастерство заголовка, блин.
"Где можно натупить с настройкой сервера и просесть в производительности в два-три раза" - было бы ближе к телу.
На всякий случай. M2 это форм-фактор диска(даже семейство форм-факторов), а sata - протокол. Есть, и не мало, ssd в форм-факторе m2, которые работают по протоколу sata.
Более быстрый протокол называется NVM.
В принципе все очевидно, но напомнить никогда не мешает. Статья кратенько так написана, в самый раз чтобы вспомнить. Автору плюс. По PG vs MS можно подробнее, где и что написано, кто проводил замеры?
Замеры проводил я лично. А где написано - искать надо. Год назад это очень внимательно изучал. Теорию уже не найду, а практику - очень легко воспроизвести самому.
(40) Это значит, что в реестре нужно найти ветку [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent] в которой лежит команда запуска сервера ImagePath = "C:\Program Files (x86)\1cv8\8.3.13.1644\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files (x86)\1cv8\srvinfo" -debug
Кстати именно в ней мы ставим флаг -debug.
Посмотрев внимательно на эту строку увидим такой поддекст: -d "C:\Program Files (x86)\1cv8\srvinfo". В этом каталоге вы как раз и найдете "серверный" кэш всех использовавшихся вами баз.
(41) обычно debug я ставлю в такой последовательности, и отладка работает: "C:\Program Files\1cv8\8.3.13.1644\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -debug -d "C:\Program Files\1cv8\srvinfo"
Имеется ввиду что кэш можно перенести на другой диск ускорив тем самым работу сервера?
(42) Сам по себе перенос кэша имеет смысл только если системный диск перегружен, а диск на который переносите - способен работать в разы быстрее.. Что касается порядка команд - это едва ли имеет значение.
Когда я работал серваком ИТС в давние, но, не очень, времена, у одного клиента комплексная автоматизация 1.1 на ноутбуке(впарили чуваку на одно рабочее место, а, он кроме накладных в ней ничего и не делал, что, впрочем, на время обновления не влияло, поскольку, ноутбук был не из дорогих и быстрых), обновлялась около часа
Ну, обновлялась бы и обновлялась, у клиента положено быть не больше часа, пить кофе и болтать, так что укладывался во время. Но, райончик был "густонаселенным" клиентами, а, работа сдельная, сколько оббежишь столько и твое. И, вот, как в сабже, от нечего делать, копался винде во время зависшего процесса обновления и в диспетчере случайно обнаружил что двухгигагерцевый процессер работает на частоте 0,9 ГГц. мне это не понравилось и, малость нагуглив, узнал что это из - за экономичного плана питания. Недолго думая, залез и выставил наилучшую производительность, подняв вышеупомянутый параметр состояния процессора до 100%
Частота тут же подпрыгнула к 2ГГц как положено, а, зависший процесс обновления отвис буквально через несколько минут(перешел к следующему действу"обновить конфигурацию базы данных?"), а, еще минут через пять с конфигурацией базы данных благополучно справился и предложил принять изменения. ну, клиенту не сказал ничего про эту находку, а, повесил лапшу что новые обновления теперь ставятся быстрей чем раньше
Ну и после обновления питание вернул на место, чтобы, на всякий случай клиент не офигел от быстрого разряда батареи)))
Так короче и делал, приходил, включал перформанс, уходил - выключал
И не только у этого клиента
(44) Спасибо, может пригодится. Но я бы рекомендовал таки оставлять "100% перфоманс". Клиент, уверен, будет только в выигрыше.
спасибо полезная статья."тошнотики" и "умники" как всегда отличились.У кого корона шире так и не поняли,за то все умные учителя-"дилетант","капитан очевидность",прочие задросткие выражения ботаников самоучек.
Автор спасибо за статейку!
А вот, кстати, додавил переход на Linux у нас в конторе для отдельного чудо-"сервера" (машинка с 64-мя гигами на райзене 3600-м с памятью 3333). Сегодня коллега протестил - в Гилеве 120. Ладно, думаю, протестирую на клиент-сервере (режим сбалансированной производительности) - 45! (это постгрес + убунту сервер последний + xRDP и авторизация в домене).
До этого машина работала под вендой эссенциал, пускала, соответственно, двух юзеров всего. В Гилеве из-за старого ядра винды проц не аиделся толком и показывал в файловой 74 в Гилеве (у меня дома 1600-й показывал 89). Кароче, народ, крайне рекомендую новые райзены (ZEN+) в качестве "недосерверов". Надо будет завтра включить режим высокой производительности - должен серверный под 60 попугаев скакнуть.
Кстати, вот протестил несколько раз Гилевским тестом:
1. Снял режим совместимости - 104-110.
2. Оставил режим совместимости - 120.
А вот тут притесался Хеон Голд за дохрена денег с дохрена памяти, но, увы, всего 60 в файловой ))) У меня RYZEN 3600 за 12к с воздушным обдувалом. И это все в режиме ONDEMAND, т.е. "сбалансированная производительность", на SQL 44 попугая. Даже не представляю, сколько будет, если включу PERFORMANCE! )))
не слушайте глупого дядю, что вам скажет выставлять минимальное состояние процессора 100% - перегреваться будет процессор очень сильно, и сервак будет аварийно вырубаться. а поставить более мощьное охлаждение вам влетит в копейку, и не на все матери его можно прикрутить нормально. процессор сам нагрузится как ему нужно и во время простоя будет охлаждаться.
(51) Игорь, вероятно, вы очень трепетно относитесь к своей технике и не позволяете ей работать "сверхмеры". Это очень трогательно. Уверен, ваш ноутбук вас боготворит!
Тема хорошая и дискуссия тоже, автору плюс.
Включил режим высокой производительности на сервере с файловыми базами, опубликовал базы на IIS, завтра буду пользователей запускать, надеюсь поможет )
Всем доброго времени суток. Надеюсь получить полезный совет.
В последние несколько дней заимел проблемы с сервером и, как следствие, проблемы на тонких клиентах, которые работают очень медленно. Нагрузка на серверный процессор возросла до 100% и держится непрерывно. Диспетчер задач указывает, что основная проблема в rmngr.exe, который вкупе с процессами rphost.exe полностью загружает процессор. Анализ mngr.exe с помощью Process Monitor от Windows Sysinternals показал, что идет непрерывный доступ к C:\Program Files (x86)\1cv8\srvinfo\reg_1541\xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\1Cv8Log\1Cv8.lgd, где "xxx" — абсолютно разные каталоги. Если бы это был доступ к логам какой-то определенной базы, то можно было бы выявить закономерность, но доступ идет к разным и в основном это операции чтения. Процесс rmng.exe это менеджер сервера и я не могу понять, почему он стал настолько активным. Раньше все работало гладко.
Конфигурация: Windows Server 2008 R2 + MS SQL Server 2008 R2 + 1C 8.3.7.1776. На сервере находятся 18 баз данных: стандартные БП, ЗУП и парочка самописных. Отключение самописных баз не повлияло и нагрузка на процессор осталась. Доступ к базам данных ведется с рабочих станций доменов через локальную сеть и VPN, а также через сервер терминалов.
по умолчанию 1С усыпляет сеансы на сутки, иногда она начинает сходить с ума и начинает каждую секунду порождать по 2-3 спящих сеанса.
Т.е. нужно в консоли посмотреть так ли это. И если это так то в параметрах базы уменьшить время жизни таких сеансов с 24 часов хотя бы до минут 10
Aleksey, системный планировщик каждую ночь перезапускает все службы, связанные с сервером 1C и MS SQL. По идее, все должно убиваться.
(4) Ты будешь смеяться но ни перезагрузка компьютера, ни переустановка сервера 1С не убивает эти процессы. Походу он куда то в блокнотик себе пишет и при восстановлении сервера автоматом восстанавливает и эти сеансы
Dmitrii, спасибо за информацию, я попробую. Есть ли какая-нибудь тенденция того, что новый формат журнала регистрации становится причиной таких проблем и совместима ли моя версия сервера со старым форматом?
(7) Ошибка с неконтролирумым ростом нагрузки на процесс при использовании нового формата журнала регистрации обсасывалась на партнерском форуме. Пост (5) взят оттуда.
1С обещала проблему устранить, но сроки не озвучивала. В 8.3.7 проблема пока есть.
Конкретных причин возникновения проблемы не знаю. У нас журнал работает нормально (тьфу-тьфу-тьфу).
(9) Я замечал что ппц начинается если усиленно в журнале чтото искать и делать отборы, причём в динамическом режиме
Dmitrii, можешь расписать алгоритм моих действий поподробнее? Правильно ли я понял?
1. Остановить 1С сервер.
2. Переименовать каталог 1Cv8Log в 1Cv8Log.bak для каждого GUID.
3. Для каждого GUID создать новый каталог 1Cv8Log и создать внутри файл 1Cv8.lgf.
(11) Можно и так, чтобы сохранить имеющиеся логи (п.2)
Недостаток данного метода в том, что ведение журнала начнется с нуля. Все предыдущие логи останутся в папках 1Cv8Log.bak
Но другого способа возвращения на журнал старого формата увы нет.
Меня сейчас логи мало волнуют, больше интересует стабильность сервера, тем более, под конец года. Если ты говоришь, что у тебя нет проблем с журналами, то посмотри, пожалуйста, сколько весят твои lgd-файлы.
Еще не совсем понятно, почему появились эти проблемы. Релиз был установлен 12 декабря и после установки сервер работал быстро, но примерно три дня назад начались проблемы. Размер журналов меня мало интересовал раньше. Сейчас глянул — 25 ГБ на все 18 баз данных. Базы мигрировали с файловой версии на MS SQL примерно полгода назад.
Garikk, этим можно было бы объяснить причины, но они явно в другом, потому что нагрузка на процессор достигает 100% даже ночью, когда точно никто не работает.
(13) Лог основной рабочей базы - 23Гб.
Сама база ~50Гб. БП 3.0. За период с марта по настоящее время.
Лог не сокращали и не выгружали.
(14) Ошибка журнала плавающая. Если я правильно понял, то часто возникает при обменах данными (РИБ) и интенсивной работе с журналом по типу (10).
Хм, спасибо. Сегодня в 13:00, когда все юзвери уйдут обедать, я постараюсь вернуться к старой системе журналирования. О результатах отпишусь позже.
Кстати вместо сохранения логов в папки 1Cv8Log.bak лучше воспользоваться типовым методом СкопироватьЖурналРегистрации с указанием имени выходного файла. Получите файл, который потом сможете смотреть в 1С в конфигураторе или в пользовательском режиме.
Такой метод займет много времени, если я буду ковырять все 18 баз данных. Если приспичит, то я потом перекину логи на другой аналогичный сервер с такой же конфигурацией, где пока нет таких проблем.
Думаю, будет проще и быстрее остановить сервер, пробежаться руками по каждому GUID через проводник и в каждый GUID вставить заранее заготовленный 1Cv8Log с пустым 1Cv8.lgf.
Отписываюсь, как и обещал. Первые 20 минут работы сервера после проделанных манипуляций. Сервер пишет журналы в .lgf и автоматический созданные .lgp-файлы. Первый запуск баз данных после перезапуска служб был очень долгим, однако работа вполне быстрая. Процесс rmngr.exe загружает процессор на 1-5%, однако я заметил, что процессы rphost.exe начали потреблять больше, но сервер все равно не загружается на 100%. Нагрузка не постоянная, а скачкообразная, в среднем около 80%.
Оставляю этот комментарий на тот случай, если вдруг кто-то столкнется с подобной проблемой. Возможно, через Яндекс или Google он сможет наткнуться на эту тему. Всем спасибо.
У меня проблема точно такая же. за неделю логи достигают 28 Гб и грузят проц на 60-70%. Помогает только чистка логов.
Попробовал заменить логи на старый формат, как написано тут.
Запустил сервер, в базы заходит, но при попытке посмотреть любой отчет, базы зависали и не реагировали никак. поменял логи обратно - все работает. что я делаю не так?
(24) >> при попытке посмотреть любой отчет, базы зависали
Речь об отчетах по журналу регистрации или отчетах вообще (любых, по регистам и пр.).
(24) >> за неделю логи достигают 28 Гб . Помогает только чистка логов
Если для вас логи не так сильно важны, то может имеет смысл попробовать настроить журнал регистрации, чтобы вообще не регистрировать никакие события или только ошибки?
Именно попробовать, чтобы убедиться, что проблема именно в этом.
Еще можно попробовать в свойствах рабочего сервера кластера установить галку "Менеджер под каждый сервис". Под сервис журналов регистрации будет выделен отдельный менеджер rmngr.exe. Понаблюдать за ним.
в общем фиг знает, сегодня подложил туже самую папку со старым форматом лога, что и до этого - все заработало. Фиг знает, что с ним было до этого. спасибо, буду наблюдать
Думаю стоит сразу предупредить, что работаю системным администратором а не 1с программистом.
Поэтому: С кодом программы не дружу, решение проблемы искал в интернете и просьба не флудить.
Началось не понятно когда и не понятно с чего.
Но на сегодняшний день такая ситуация:
1. Постоянные зависания у клиентов. (Которые подключаются по RDP, но не все)
-Проверял канал связи, оборудование, и ним все нормально.
-Грешил на модем, поменял.
3. Загружается ЦП на 100%
-Такое ощущение что процесс 1С входит в какой то цикл или еще как то.
Выписки из журнала:
Имя сбойного приложения: PrintIsolationHost.exe, версия: 6.1.7600.16385, отметка времени: 0x4a5bd3b1го модуля: ntdll.dll, версия: 6.1.7600.16915, отметка времени 0x4ec4b137
Код исключения: 0xc0000374
Смещение ошибки: 0x00000000000c6ae2
Идентификатор сбойного процесса: 0x109f4
Время запуска сбойного приложения: 0x01cec3eebb6c7009
Путь сбойного приложения: C:\Windows\system32\PrintIsolationHost.exe
Путь сбойного модуля: C:\Windows\SYSTEM32\ntdll.dll
Код отчета: 0edfd1ab-2fe2-11e3-a1c3-0050fca17504
Имя сбойного приложения: 1cv8.exe, версия: 8.2.19.68, отметка времени: 0x5225f7b5
Имя сбойного модуля: ntdll.dll, версия: 6.1.7600.16915, отметка времени 0x4ec49d10
Код исключения: 0xc0000374
Смещение ошибки: 0x000ce903
Идентификатор сбойного процесса: 0xc4b8
Время запуска сбойного приложения: 0x01cec3a9bb6abcc8
Путь сбойного приложения: C:\Program Files (x86)\1cv82\8.2.19.68\bin\1cv8.exe
Путь сбойного модуля: C:\Windows\SysWOW64\ntdll.dll
Код отчета: 4c2527dd-2fab-11e3-a1c3-0050fca17504
Посмотрите в журнал 1С и/или спросите у вылетающих клиентов, что они делали в 1С при вылете.
Имхо, отсюда и надо искать.
Некоторые неграмотные пользователи запускают отчеты с огромным выводом информации, за большой период и потребляющие немерянные ресурсы.
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
ИО Капитана Очевидности
Имя сбойного приложения: PrintIsolationHost.exe, версия: 6.1.7600.16385, отметка времени: 0x4a5bd3b1го модуля: ntdll.dll, версия: 6.1.7600.16915, отметка времени 0x4ec4b137 » |
Модуль "изоляции" принтера. По идее должен выделять каждому пользователю отдельную службу печати, чтобы сбой в драйвере принтера у одного пользователя не вызвал проблем с печатью у других пользователей. По какой-то причине всё-таки вызывает ошибку.
Возможно на рабочем месте какого-то клиента стоит глючное устройство.
3. Загружается ЦП на 100% -Такое ощущение что процесс 1С входит в какой то цикл или еще как то. » |
-------
Самое совершенное оружие, которым забиты арсеналы богатых и процветающих наций, может легко уничтожить необразованного, больного, бедного и голодного. Но оно не может уничтожить невежество, болезнь, нищету и голод. (Фидель Кастро)
Почему всех осужденных за измену Родине при Сталине реабилитировали при Горбачёве по отсутствию состава преступления? Потому что при Горбачёве измену Родине перестали считать преступлением.
Один из серверов 1С, который я обслуживаю, очень странно себя вел. Загрузка процессора на машине с сервером 1С почти всегда была 100%, даже когда на нем никто не работал. Базы хранились в MSSQL, их было относительно много, но реально людей, которые с ними работали - мало. Одновременно работало не больше 10-15-ти пользователей в очень вялом режиме.
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный теcт.
Сервис журнала регистраций 1С нагружает процессор
Я выяснил, что конкретно дает чрезмерную нагрузку на сервер. Посмотрел на объем журналов регистраций. У некоторых баз он достигал размера в 10-15 гигов. После чистки серверу стало заметно легче, нагрузка снова опустилась, но где-то до 80-90% и я на несколько месяцев забыл про сервер.
Он напомнил о себе тормозами и загрузкой процессора в 100%. Проделанные выше операции уже не давали результата. Баз стало немного больше и нужно было думать, как разгрузить сервер. Он работал на все 100% даже в нерабочее время, когда на нем не было ни одного реального пользователя. Сервис журнала регистраций потреблял 30-40% процессорного времени.
Я стал внимательно шерстить интернет на заданную тему и нашел несколько заметок. Находились люди, которые обратили внимание на чрезмерную нагрузку сервиса журнала регистраций. Как вариант решения проблемы они предлагали откатиться на старую версию ведения логов lgf вместо новой lgd. Я не знаю, что принципиально изменилось в формате ведения лога журнала регистраций, но по отзывам попробовавших, нагрузка на процессор падала. Забегая вперед скажу, что мне этот совет помог.
Разбираемся что конкретно в rmngr.exe грузит процессор
Загрузку процессора в равной степени давал процесс rmngr.exe и rphost.exe. Rphost уже ранее был настроен и оптимизирован. Вот такие настройки дали стабильную работу без необходимости перезапускать сервер месяцами:
Нагрузку rphost давал за счет оставшихся фоновых задач и что с ним еще сделать, я не знал. А с rmngr хотелось разобраться и узнать, что конкретно пожирает процессорное время. В этом процессе собраны все процессы менеджера кластера:
Есть возможность разделить сервисы менеджера кластера по разным системным процессам rmngr.exe и по pid определить, какая именно служба нагружает процессор. Включить такое разделение можно в свойствах рабочего сервера:
После того, как вы поставите галку, агент сервера 1С сам перезапустится с новыми настройками. После этого в диспетчере задач у вас будет порядка 15-ти процессов rmngr.exe с разными pid. Смотрите, какой из процессов больше всего использует процессор и в консоли управления 1С в разделе Менеджеры кластера по pid смотрите описание процесса.
В моем случае это был сервис журнала регистраций. Чтобы это узнать, дважды щелкните мышкой по процессу с необходимым pid:
Пол дела сделали, нашли виновника тормозов. Я скрины делал, когда уже решил проблему, так что у меня нагрузки нет.
Читайте также: