Комментарии 20
Если есть системный код, то суём его в системные каталоги
%ProgramFiles%,%SystemRoot%.
Что за дурацкая привычка раскидывать скрипты и программы куда попало?Запускаете из под учётки пользователя человека с правами администратора? А он потом увольняется и если её заблокировать, то останавливается половина предприятия с криком "%№я!"
Чем вам не нравитсяLocalSystem?В общем код выглядит "грязным" и потенциально небезопасным.
Используете псевдонимы команд, не указываете использованные ключи.Get-Process -Name Proc1,Proc2,Proc3тоже сработает.PowerShell объектный язык и можно проверять значение свойств объектов без лишних переменных.
While ( $(Get-Process -Name rphost,rmngr,ragent).Count -eq 0) {}
И т.д....
А вы выполните код $path = get-item [какой-то путь] ; Write-Host "This is $path" с существующим путем и с неверным (или таким, к которому у текущего юзера нет доступа).
В PS есть терминирующие и нетерминирующие ошибки, в случае первых происходит остановка выполнения скрипта, в случае вторых - исполнение идет дальше, и вы потенциально рискуете исполнить дальнейший код с неверным значением переменных, если они присваивались в сфейлившемся куске. Причем это поведение еще и модифицируется параметрами запуска командлетов, скриптов или вообще умолчаниями среды. Поэтому там, где код должен идти в продакшен, обработка ошибок как минимум вокруг потенциально деструктивных операций - наше всё.
Далее этот файл помещаем в каталог, из-под которого он будет запускаться, например, %appdata%
За это коллеги вас тоже рано или поздно вспомнят словом, но отнюдь не добрым. :)
Remove-Item -recurse $ServiceDataDir$SessionDataDir
А вот за это так вообще и побить могут - у вас не делается обработка ошибок при вызове командлетов, которыми формируются указанные переменные, в результате рекурсивное удаление может дать немного неожиданный эффект.
спасибо за обратную связь=)
а разве в случае ошибок в ходе формирования данных переменных выполнение дойдет до команды Remove-Item ? или Вы про логические ошибки с неверным вычислением каталога?
А вы выполните код $path = get-item [какой-то путь] ; Write-Host "This is $path" с существующим путем и с неверным (или таким, к которому у текущего юзера нет доступа).
В PS есть терминирующие и нетерминирующие ошибки, в случае первых происходит остановка выполнения скрипта, в случае вторых - исполнение идет дальше, и вы потенциально рискуете исполнить дальнейший код с неверным значением переменных, если они присваивались в сфейлившемся куске. Причем это поведение еще и модифицируется параметрами запуска командлетов, скриптов или вообще умолчаниями среды. Поэтому там, где код должен идти в продакшен, обработка ошибок как минимум вокруг потенциально деструктивных операций - наше всё.
При всем уважении, но как перезагрузка по ночам решает проблему "плохого кода" 1С в рабочее время?
Если у пользователя все "тормозит" в 16:00 вы ему предлагаете подождать до 2:00, когда сервер перезагрузится?
Перезапускать 1С периодически и надо для того, чтобы не возникало ситуации "всё тормозит".
Если же надо перезапустить днём - это надо делать руками. Хотя днём, как правило, 1С предпочитают не перезапускать, даже если и тормозит у кого-то. Ибо работают десятки людей и лучше пусть один потерпит, чем всем всё ломать.
Тоже раздражает в 1с что с ней постоянно нужно что-то делать. Постоянные обновления платформы. "Танцы с бубном". У одного пользователя из сотни неожиданно все виснет при определенной операции, решилось выгрузкой загрузкой конфигурации (Это вообще нормально?). Организации настырно продолжают ставить 1с везде.
Постоянные обновления платформы.
Что сами разработчики платформу обновляют - это нормально.
А вот когда вы у себя постоянно платформу обновляете - это не особо нормально.
У себя мы это пару раз в год делаем примерно.
Вот на конфигурацию апдейты гораздо чаще ставятся.
Организации настырно продолжают ставить 1с везде.
Отраслевой стандарт. Да, где-то глючит, где-то косячит, где-то вообще с бубном танцевать приходится. Но альтернативы не лучше. Точнее, они могут быть лучше под вашу конкретную задачу, но вот в отрасли проще терпеть 1С, чем зоопарки разводить.
В статье в лоб написано "все тормозит" из-за "плохого кода".
Может все же надо причину устранить, а не симптомы маскировать?
А то у меня точно такая же нога, и не болит.
На устранение причин могут потребоваться месяцы срока и миллионы бюджета. Если костыль дает результат прямо сразу, то будут ставить костыль, а уж что там с кодом - будут решать позже (или не будут, в зависимости опять же от местной конкретики).
А то у меня точно такая же нога, и не болит.
Так в том-то и проблема, что нога у всех немножко отличается. Скелет (платформа) более-менее одинаковый, а мясо на нём (конфигурации, обработки и т.п.) - у всех разные. Ну, где дело вышло за файловую базу и трёх юзеров.
Потому дешевле может быть просто лечить симптомы - перезагрузка много времени не занимает и денег не стоит, особенно если у вас работа не 24/7 идёт.
Искать же причину проблем - это дорого, долго и не то, чтобы так уж многим надо.
Если есть системный код, то суём его в системные каталоги
%ProgramFiles%,%SystemRoot%.
Что за дурацкая привычка раскидывать скрипты и программы куда попало?Запускаете из под учётки пользователя человека с правами администратора? А он потом увольняется и если её заблокировать, то останавливается половина предприятия с криком "%№я!"
Чем вам не нравитсяLocalSystem?В общем код выглядит "грязным" и потенциально небезопасным.
Используете псевдонимы команд, не указываете использованные ключи.Get-Process -Name Proc1,Proc2,Proc3тоже сработает.PowerShell объектный язык и можно проверять значение свойств объектов без лишних переменных.
While ( $(Get-Process -Name rphost,rmngr,ragent).Count -eq 0) {}
И т.д....
В некоторых случаях при остановке службы некоторые процессы не останавливаются, а зависают навсегда (до их прибивания мануально администратором). В таком случае вы рискуете, что утром рано придут пользователи и будут вас проклинать. Я когда баловался таким скриптом, вместо бесконечного ожидания ставил большой таймаут, после которого прибивал оставшиеся рабочие процессы. Но если у вас несколько экземпляров служб, то нужно внимательно фильтровать нужные процессы, чтобы не прибить лишнее. У нас например сразу 3 службы: рабочая и разработческая для оперучета и еще одна для типовых
Доброго дня.
Да, вы правы, бывает, что зависает. Для "полировки" можно еще отдельным скриптом через "продолжительное время" прибивать процессы, если корректно завершиться они не смогли.
Что же до нескольких служб: да, данный скрипт применим только для "одна ОС - один кластер". На что-то более универсальное не было времени, к сожалению=)
Я к сожалению не сертифицированный специалист по 1С. И у меня не хватило аргументированных доводов против перезапуска 1С по расписанию. Но в докладах конференции INFOSTART уже два года настойчиво просят так не делать.
Если вам все же хочется "очистить" память сервера, то предлагается принудительно завершать распухшие рабочие процессы.
"Рарус" уже в далеком 2021 году опубликовал об этом статью с готовыми скриптами. Вот
Надеюсь это кому-то пригодится.
Добрый день. Да, действительно, вариант с "мягким перезапуском" РП по какому-то триггеру - решение более изящное, но все решения обычно рождаются сообразно проблеме. Их кейс требовал непрерывной работы и проблемы, видимо, часто происходили в рабочее время. Нам помог всего лишь регулярный перезапуск по расписанию ночью:)
Ссылка на статью апдекс на инфорстарт нерабочая
Автоматический перезапуск службы 1С на Windows Server с очисткой кеша-сеансов