Доброго всем времени суток.
  Решил поинтересоваться. В одной из наших фирм, с которыми мы работаем в данный момент есть серверные проблемы. Ресурсов не хватает, в дальнейшем это решится покупкой нового сервера, но когда пока не известно.
  Проблема же заключается в том, что в клиент-серверном варианте не работает отладка 1С. Причем включить её, поставив ключ -dedug в соответствующей ветке реестра не составляет труда и админы об этом знают.  
  Не делают они это (как мне объясняют) из-за того, что в этом случае разрастутся логи 1С, причем чуть ли не в геометрической прогрессии. А поскольку сейчас и так ресурсов не хватает, то это критично.
   Отсюда вопрос.... Правда ли это критично и логи могут неимоверно разрастись?

Бред какой-то. Отладка не кошерна в проде по другим причинам.

Ложь и провокация

Похоже парни путают технологический журнал и режим отладки.

(3) +100

Более того, даже полный техножурнал ничего не забивает, если настроить нормальный интервал хранения.

(3) По набирают здоровых, а спрашивают - как с умных. (с)

Админы молодцы, когда лень работать, отмазка должна быть максимально правдоподобной.

(1) по каким?

(3) Поддерживаю. Но даже в этом случае можно настроить время жизни технологического журнала.

(8) возможно небольшое снижение производительности.

(8) Незначительное просидание производительности. Ну и можно повесить всех пользователей при отладке :-) при определенном умении.

(10) да хрен с ней, с производительностью, фраза "ща быстро починю", и дальнейший останов продакшена, вот это классический случай.

То есть можно считать, что это уверенная ложь? Или ест ьдругие мнения?

(1) Можно подробнее про "другие причины"?

(13) Или перепутали включение технологического журнала и режима отладки, или просто вредничают.

(14) см. (11)

(15) думаю второй вариант.... потому как самый умный из них написал заявление на увольнение. Видимо не хочет под конец революции устраивать в "налаженной" системе

(16) Вот это драма)

(16) Слово "налаженной" очень говорящее. Было бы интересно потом послушать, чем закончилась ваше противостояние "1С против админов".

(18) Они всегда работали слаженно, слажали и в этот раз. (с)

Для полного ответа на данный вопрос необходимы данные:
1. Количество баз
2. Какие конфигурации
3. Количество рабочих 1С-серверов
4. Производительность сервера.
5. Свободное место на дисковой подсистеме

Ответ:
1. Количество баз - 35 рабочих баз
2. В основном УТ
3. 4 запущенных сервера 1С-предприятия
4. Intel S5520UR\Xoen E5506 х 2 \ 32 ГБ ОЗУ \ RAID 1 500 ГБ \ Random Read 4KB (QD=1): 0.583 MB/s [142.2 IOPS]
  Random Write 4KB (QD=1): 1.211 MB/s [295.7 IOPS]
  Random Read 4KB (QD=32): 0.775 MB/s [189.2 IOPS]
  Random Write 4KB (QD=32): 1.462 MB/s [356.9 IOPS]
5. 50 ГБ свободно
Этот же сервер служит как терминал для 50 пользователей.
1С-предприятие с включенным флагом -debug значительно тормозит систему. Разрастается КЭШ при отладке, и шанс зависания пользователей очень велик.
"Простой" данного сервера недопустим, так как он является боевым сервером.
При том "топик стартер" забыли упомянуть в топике форума про этот маленький нюанс!
С уважением, "самый умный" увольняющийся админ.

(20) Ну запусти пятый сервер в режиме отладки.При работе одного пользователя вообще будет незаметно.

(20)терминалка вызывает довольно большое количество контекстных переключений, что может очень значительно просаживать производительность сервера 1с.
Расскажите. сколько у вас сейчас дескрипторов на сервере в среднем?

(0) зачем админы лезут туда, куда им лезть не положено?

(23) Все успокоились и пошли ставить новый инстанс.Делов то)А оставлять 1с ника без отладки это полный дурдом.

(20) "и шанс зависания пользователей очень велик" похоже кто-то ходил в отладке в обработке проведения. :-)

(21) Ты забыл, что для этого нужны деньги на серверный ключ.

(26) Не нужны. В рамках одного сервера достаточно одного ключа.

(20) Кто скушал терабайт 50 пользователей или сервер 1С?

(0) Присмотрись к админу. Если на его морде нет отпечатка клавиатуры- это паршивый админ.

(20) "Этот же сервер служит как терминал для 50 пользователей"

Это как это вы так умудрились скрестить? Терминалку всегда отдельно ставят, от 10 пользователей.

В добрый путь админу с такой организайцией!
Может, ещё и сервер весь виртуальный?

(20) > Разрастается КЭШ при отладке

С чего бы это вдруг?...
Может причин роста кэша в другом? И рост кэша чего именно наблюдается - СУБД, 1С, сеанса пользователей.... Вообще что именно понимается Вами под кэшем?

Кроме того так и не получен ответ на вопрос "А при чем тут логи сервера, упомянутые в (0)?"
Кто и что напутал - вы, когда конопатили мозг бедному автору ветки, или автор ветки, когда этот свой пост заводил?

PS Я сам отношусь к стану ярых противников отладки на продуктивных серверах. Для этого всегда можно развернуть копию или в крайнем случае отдельный инстанс сервера 1С на продуктивном сервере. Но, как мне кажется, вы тоже что-то мутите, приплетая какие-то мифически растущие логи и кэш.
Отладка нежелательна на продуктивных серврерах, но не из-за логов и кэша.

+ к (32) Ну и совсем забыл. Скрещивание сервера терминалов с сервером приложения и СУБД на таком количестве пользователей несёт значительно бОльшую опасность для производительности и устойчивости.

(32) "PS Я сам отношусь к стану ярых противников отладки на продуктивных серверах." Самое главное не делать полное соединение в запросах, а так, одна база, один пользователь, один документ/отчёт на день  ? - если из-за такой доп.нагрузки сервер начинает хромать, это уже под завязку, надо предпринимать.

(34) Основная причина нежелательности отладки в продуктиве не в снижении производительности, а риски повесить базу на блокировках.

> одна база, один пользователь, один документ/отчёт на день

В режиме отладки загрузка объектов конфигурации производится по мере необходимости, а не при начале работы системы, как в обычном режиме работы сервера. Это ускоряет процесс запуска «1С:Предприятия» при изменении конфигурации, то есть ускоряет процесс разработки.
Но это может замедлять работу пользователей. Ведь в таком режиме будет работать не только один сеанс разработчика, а все пользователи. Вместо того, чтобы чуть-чуть потупить при запуске сеанса 1С-ки все они будут тупить прямо в процессе работы каждый раз по мере обращения к новым и новым объектам конфигурации.

> главное не делать полное соединение в запросах

Во-первых, это не единственный способ повесить сервер.
Во-вторых, надо помнить золотое правило: если можно накосячить, то рано или поздно кто-нибудь (пусть даже мега-спец) обязательно накосячит. Естественно случайно, не специально.
В-третьих, на серверах типа (20), где цена простоя слишком велика, подобные риски просто недопустимы.

И ещё по законам Мерфи: Если вы отделили в изолированный сферический куб в вакууме всё что может накосячить, обязательно найдётся ещё пяток возможностей сразу после первого же косяка, который не заставит себя ждать, ибо все остальные причины косяков вы уже изолировали.

Отладка на серверах включена. 12 лет - полёт нормальный.

(20) А сейчас, со всей этой фигней мы попытаемся взлететь! (с)

Сочувствую админам и программистам этой конторы.

(31) для окончательного счастья эту виртуалку надо еще поместить в Docker.

(36) Идеальной системы, застрахованной от любого сбоя на все случаи жизни, не существует. Но риски надо снижать. Чем выше цена простоя или сбоя, тем бОльшее количество рисков следует исключать.

> Отладка на серверах включена. 12 лет - полёт нормальный.

При всём уважении, но это не говорит вообще ни о чём. Может у вас там запас по производительности настолько велик, что никакая отладка не будет заметна вообще никак. А то, что никто из разработчиков за 12 лет еще ни разу не сумел повесить сервер в отладчике - это просто волшебство какое-то. Если честно, то с большим трудом в это верится.

(39) Это правильно, что верится с трудом, но не будем об этом, т.к. с отладкой, кстати, об отладке, это не было связано ни разу - вот я о чём. А кеш чистить постоянно приходится. Запас по производительности сервера? Вы серьёзно? Любой домашний ноутбук даст запас по производительности только из-за производительности самой 1С. Формочки несколько медленнее открываются? Ну, разве что - первый раз, а далее - не заметно, дольше чай отхлёбывается.

(20) КЭШ не разрастается. Простой возможен при кривых руках программиста который пытается отлаживать проведение документа.
Всегда можно добавить отдельный сервер приложений на этой же машине с включенной отладкой. Ограничить выделенную память.

(41) И как ему поможет отдельный сервер приложений, если он хочет в рабочей базе иногда пользоваться отладкой вне транзакции?

Как правило, хватает переноса идентичных для восстановления картины и отладке в сторонке, а не в рабочей. И данные менять можно, экскрементировать

(10) (11) насколько нежелательно включать серверную отладку на производительном серваке (2 проца по 10 ядер, 256 гБ ОЗУ), рабочая база одна - ERP.

Сейчас -debug включен, вот интересно, насколько это влияет на производительность. В диспетчере задача загрузка ЦП обычно на уровне 8-15%, ОЗУ - 30-50%

(40) > Любой домашний ноутбук даст запас по производительности

Если честно, не совсем понятно о чем это.

> ...с отладкой ... это не было связано ни разу

Вот в это я и не верю. Извини.
Или за 12 лет отлаживали процесс в продуктиве всего несколько раз, или ты чего-то не договариваешь.
Сама по себе отладка нужна, как правило, в двух случаях - найти сбойное место (уже опасная ситуация с точки зрения стабильности), посмотреть значения каких-либо переменных или показателей на реальных боевых данных, которые по каким-либо причинам никак нельзя получить в тестовой системе. В любом из этих случаев возможна установка блокировок на таблицы, которые нужны другим пользователям. Типичный пример - отладка обработки проведения какого-нибудь документа типа Поступление или Реализация, которые блокируют одновременно кучу регистров. Разработчик пока разглядывает значения переменных в отладке, все сидят и ждут его на блокировках.

(45) Вот, представь - от отладки никогда сервант не падал. От кривого запроса подвисали и тормозили все - да, документ не могли записать/провести при определённых условиях из-за кривой доработки прямо на боевой базе - да. Но отладка?
Куча регистров управляемой блокировкой - да 5-6 звонков поступит, что не могут провести что-то. 5-6, Карл! Велика потеря... больше чай пьют, чем попадают параллельно отладке.
Да и чего там разглядывать - не понял сразу, значит - изучай сиди часами, а это точно уже не на рабочей, разворачивается копия, если переносом актуальных данных не воспроизвести.
Первый раз в 1С?

(45) Мой Й3-ССД-ДЖИТИ походный даже на УТ загружается на 8 процентов, а 1С тормозит. Думает, шевелит данные, шатает таблицы, а ноут не загружается больше, чем на 8 процентов.
Что изменило выключение отладки? Ни-че-го. Даже что что-то быстрее открываться стало - не заметил.

(46) > 5-6 звонков поступит

Тогда мы говорим о системах с разным уровнем сервиса.
Пока у нас на серваке крутились только бухя и ЗУПы, мы тоже вполне могли себе позволить подобную безолаберность и пофигизм по отношению к пользователю.

> от отладки никогда сервант не падал

А тут кто-то говорит о падении? Возможно я где-то не так выразился. Под стабильностью я понимал стабильную работу сервака (без тормозов и зависаний сеансов), а не то что он может упасть (хотя и это не исключено). В (0) о падении ни слова. Ключевая проблема, на которую жалуются админы, - это некий мифический рост каких-то то ли кэшей то ли логов (в этом показания автора ветки в (0) и админов в (20) расходятся) при включенной отладке.
Отладка не должна приводить к тормозам в работе пользователей. Никогда и не при каких обстоятельствах.

(48) Если -debug кладет твой сервер по производительности, то у тебя что-то не так с сервером.

(42) На отдельном сервере поднимается копия рабочей базы. Там можно делать что угодно.

(49) на мисте срач на тему включать отладку на проде или нет возникают с завидной регулярностью и участники делятся на примерно равные группы, которые не могут убедить друг друга. История точно как тупоконечники и остроконечники.

(48) Идеалист-начальник детектед. Всегда... Никогда... Вопрос закрыт.
Слово "идеалист" не случайно на первом месте.

(47) > ноут не загружается больше, чем на 8 процентов

Да при чем тут ноут, когда речь идет о клиент-сервере с кучей баз и кучей пользователей?

У меня xeon e5-2690 3.0Ghz на серваке постоянно загружен на 30-50%%, а в периоды особой активности пользователей по долгу держится около 70-75%. И это при том, что кроме 1С, СУБД и IIS на этом сервере ничего нет (никаких почт, файловых шар, терминалов и прочих сервисов, не относящихся непосредственно к 1С).

(49) Кто тебе сказал, что сервер падает по производительности в отладке?

(51) За тем лишь исключением, что убеждают только те, кто подозревает, не имея какого либо опыта, что что-то будет очень плохо, т.е. рассказывают сказки о вкусе бананов тем, кто их ел.
А лагерь два - рассказывает, что нет никаких проблем с пользователями.
Так что - вы не правы, извините.

(54) Падает и Кладёт - ну, кагбэ, разные слова. Поэтому - этого вам никто не говорил.

(54) 1с мне сказал. Но мне плевать на эти 3-6 процента.

(51) О чем и речь)

Я вообще разрабатываю в файловых, на сервере -debug для замеров производительности.

(52) Идеалист? Да нет. Вполне обычный подход. Пока у вас 20-30 пользователей  - вполне можно пренебречь такой мелочью, как подвисания 5-6 из них пока программер отлаживает проведение какого-нибудь документа. Тем более, что случается такое реально не так уж и часто.
Но когда система разрастается до сотен пользователей, а подвисают уже не 5-6, это уже бардак. ИМХО.

(57) > плевать на эти 3-6 процента.

Это уже называется запас по производительнсти. Хорошо, когда он есть. Бывают случаи, когда на каждом проценте экономят.

(58) простите моё любопытство, о каком замере производительности идёт речь? Прогон процедур в отладчике с включением флажка "Замер производительности"?

(60) По моему, это уже в "Кащенко" )))

(61) Да.

(20) Да от куда вы берете про тормоза при отладке? уже давно ничего не тормозит

(60) Какой смысл обсуждать в этой работу баз уровня Магнит / Мегафон? С их нагрузками и требованиями надежности, а главное бюджетом - всё делается по другому. Особенно у них не бывает случаев сервер 1С, СУБД и сервер терминалов на одном сервере (еще и в виртуалке), плюс у программистов всегда под рукой копия свежих данных для оперативного поиска ошибок.

(64) Фирма 1С официально заявила о небольшой падении производительности при включении отладки. Другой вопрос, что часто это падение приносят в жертву оперативности реакции программиста на ошибки.

(57) "1с мне сказал"
а кто именно 1с?)

вы хотите сказать, что, к примеру, 100 документов в обычном режиме проведутся за 100сек, в режиме отладки проведутся за 105?

(67) Лично сам Борис Георгиевич сказал.

(68) этоже враньё

+(69) по опыту, очень заметно, даже на глаз (точно не 6%). А если включать замер производительности и подавно.

(69) Знакомо понятие "сарказм"?

https://its.1c.ru/db/v8312doc#bookmark:cs:TI000000119

Мотай до debug.

(70) А по моему опыту не заметно вовсе. Выбрось свой "сервер! и купи нормальный.

(67) Я лично наблюдал деградацию в 5-8%, гоняя базу тест-центром. И то далеко не всегда - чаще разницы не было вообще.  Что переводит вопрос в область статистической погрешности. Посему забил на религию в этом вопросе и считаю, что режим отладки никому не мешает. Хотя в рабочей базе максимум раз в полгода пользуюсь.

(72) Для протокола: сервер изолированный был?

А то я "Гилева" гонял на боевом, в рабочий день, сразу для двух SQL.

Пользователи не жаловались)))

Так давно уже привыкли пользователи, что "Адинэс не работает!". И не жалуются, потому как "бесполезные бездельники ничем помочь не могут". Знали бы они, как эти "бездельники" над базой издеваются онлайн...

(74) Это ты свой страшный сон рассказываешь или из личного опыта?)))

(75) На форуме читал. Не помню, что за форум, но тоже жёлтый, как 1С

(73) Да. Админы новый девайс прикупили и шаманили с ним. Попросили прогнать тестом производительность и сравнить с рабочим. Я и помучил его. Точнее коллеге поручил сценарий сделать и прогнать, а сам смотрел уже на результат.

(74) Всех на APDEX и гонять пока не надоест.

(78) Будьте здоровы!

(74) Мои дрессированные уже все и такие фразы в их лексиконе отсутствует. Потому что на один мой косяк приходится их 500 косяков, а мордой по батарее я водить умею особо наглых. Правильная форма обращения "Не соблаговолит ли многоуважаемый  джинн снизойти до нас бестолковых и найти место, где мы накосячили так, что не считается правильно налог на прибыль? Сами мы уже смотрели и тут, и там... И даже в бубен стучали... Причем бухгалтерам тоже..."

(80) Ыыыы))

А я своим выдал полные права и сказал: в случае косяка откат на вчера без разбирательств.


За 5 лет откатывал раза 3-4, вопросы типа: "где мы накосячили так, что не считается правильно налог на прибыль" решают сами)))

Так-то - вы не сравнивайте обращения пользователей к сотруднику другого отдела, который лично ему, пользователю, ничем не обязан, и обращение основного руководителя.
Уверен, что в приказах слова "соблаговолит" и "многоуважаемый" употребляются только в качестве сарказма)