Архитектура ИТ-системы на базе 1С в крупной организации. Часть 2. Чудес не бывает

04.07.18

База данных - HighLoad оптимизация

Развернуто отвечаю, как мы боремся с зависаниями системы и вообще решаем проблемы. С примерами, но без слайдов.

Как то отвечая на комментарии предыдущей статьи (//infostart.ru/public/857978/) родилась идея следующей, которая позволит развернуто ответить на некоторые вопросы.

Основной комментарий, подтолкнувший к ниженаписанному таков:

Чудны дела, твои.... зависшие фоновые задания, сеансы и/или блокировки - известный бич, все его знают и в случае глюков сервера - чистят сеансовые данные. А вы говорите "не сталкивался". Поделитесь опытом, чтоль - как так пролучается у вас?

Я начну, пожалуй, с конца, то есть с вывода. Чудес не бывает. Да, именно так, астрология лженаука, благодатный огонь зажигают сами монахи, используя несложные химические фокусы, молния — это не гнев Зевса, а всего лишь электрический разряд.

В нашей, ИТ среде всё то же самое, чудес не бывает. К любой проблеме есть рациональное объяснение, поэтому, когда мы в Компании сталкиваемся с какой-то проблемой, первое, что мы делаем – стараемся максимально окружить её красными флажками, чтобы никто, не дай бог не нарушил шаткое равновесие работающей проблемы, после чего начинаем тщательно рассматривать её со всех сторон.

Немного отступлю от темы, так как текст данной статьи не согласован ни с моим руководством ни с компанией 1С я извещаю, что все нижеописанные примеры являются выдуманными от начала до конца.

Итак, что именно зацепило меня во фразе – «как вы боретесь с зависаниями системы». Но что такое зависания системы? Зависания клиента? Сервера? Медленно открывается форма — это зависание? Если да – то с какого момента мы начинаем считать зависание проблемой?

В части проблем я стойкий приверженец ITIL, несмотря на всю его академичность написан он исходя из реального опыта тысяч людей. Не буду вдаваться в теорию, просто скажу, что, по моему мнению, нельзя задавать вопрос – как вы боретесь с зависаниями. Правильней спросить – какое обходное решение вы используете для проблемы №739. Да, не все проблемные ситуации 1С фиксирует как дефекты, зачастую мы получаем сообщение – данная ситуация не является проблемной, но наша задача, как технических специалистов доказать в том числе и тех поддержке 1С то, что та проблема, которую мы зафиксировали именно проблема и её надо устранить, сначала предложив обходное решение.

Ладно, хватит теории, примеры.

История первая.

Всем работающим в сезонной рознице известно, что декабрь год кормит, так что любой сбой системы в декабре, особенно в заключительной декаде, зачастую приводил к увольнению даже топ-менеджеров от ИТ, что уж говорить об обычных админах. Так что, когда мы заметили, что наш application сервер уходит в 100% нагрузку началась лёгкая паника.

Итак, развитие событий.

1 декабря.

Небольшой пик, всё нормально, средняя нагрузка на уровне 80 процентов, нечего беспокоиться.

5 декабря. Нагрузка уже на уровне 90%.

 

10 декабря. Всё, мы уже в 100% и пользователи начинают испытывать проблемы с производительностью.

Сразу скажу, та авария многому меня научила и об этом в конце, а пока – что делать? Известно, что понять, чем занимается application-сервер невозможно, нет таких метрик ни в ТЖ ни в консоли (напомню, это 8.3.6). Принимаем единственно возможное решение, подключаем топов, выходим на специалистов из 1С, начинаем работать непосредственно с ними. Снимаем дампы, отправляем на анализ. Выясняется, что у нас есть кусок кода, в котором формируется текст запроса. Ну что то вроде: ТекстЗапроса  = «Первая часть запроса» + «Вторая часть запроса» + «Третья часть запроса». Как мне потом говорили разработчики – это еще из типовой нам досталось, кусок по акционной механике, то есть данный код вызывается при каждом пробитии чека, причем несколько раз. Рекомендация 1С – заменить данный код на СтрСоединить.

Изменения в код были внесены 29 декабря. Результат виден на графике:

Выводы, которые мы сделали после той аварии:

  • Запас мощности системы должен быть минимум 50%, лучше 100%, то есть система должна спокойно переживать двукратный рост нагрузки. Если какие-либо показатели превышают 50% от максимального значения – начинайте нервничать.
  • У проблемы есть причина, при решении идите двумя путями, устраняйте последствия (поставьте еще один сервер, увольте 50% пользователей чтобы снизить нагрузку и т.п.), но параллельно ищите причину. Часто, устранив последствия, пропадает мотивация искать причину, всё же уже хорошо, поэтому иногда мы запрещаем устранять последствия обходным путём, если это стоит бизнесу не слишком дорого, а ищем причину сразу, не отходя от кассы.
  • Если вам 10 человек сказали, что причина неизвестна и найти её не представляется возможным – ищите одиннадцатого.

История вторая.

Зависающее фоновое задание.

Появилось некое фоновое задание, которое могло длиться часами и не завершиться ничем. Причем судя по косвенным данным оно чем то занималось, причем весьма активно, так как после удаления сеанса нагрузка на application падала сразу на 10-20%, на SQL сессии естественно не было, иначе мы легко могли бы понять, что оно делает, что то крутилось именно внутри app.

Урок, который я извлек из этой истории таков. Любую (!!!) проблему с зависаниями можно решить с помощью технологического журнала. Если её нельзя решить с помощью ТЖ – значит её смогут решить только сотрудники 1С, так как тут требуется анализ дампов и доступ к исходникам. В нашем случае всё оказалось достаточно банально, в коде была ошибка, в результате которой задание уходило в пустой бесконечный цикл. Поправили код, еще одной загадкой стало меньше.

История третья.

Зависающие rphost-ы.

Периодически в системе возникала странная ошибка, пользователи не могли войти в неё, текст ошибки уже точно не помню, то ли «Нет доступных серверов» то ли что-то похожее, надо в почте порыться, но ситуация была странна тем, что те, кто уже зашёл в систему успешно продолжали работать. Некоторые пользователи всё-таки заходили, иногда с первого раза, иногда с пятого. Поиск ошибок по ТЖ показал, что все «неудачники» пытались подключиться к одному и тому же процессу, если этот процесс убить – проблема исчезала. Дальше схема уже стандартная по решению проблем. Ищем обходное решение и ищем причину проблемы. Ждать жалоб от пользователей, а потом убивать зависший процесс решение так себе. В итоге выяснили, что в ТЖ есть четкие записи – «вот плохой процесс, менеджер, убей его». Если в ТЖ одна такая запись – всё хорошо, менеджеру приказали, он убил, а вот если записей больше одной – это означает что менеджер попытался убить процесс, но у него не удалось и агент снова и снова приказывает убить отщепенца. Обходное решение – ставим данный процесс на мониторинг, в почту сообщаем о зависшем процессе, убиваем руками. Причина – дефект в движке, исправлено в 8.3.12. Справедливости ради скажу, что воспроизводится данный дефект по моей информации только у нас. У нас вообще в связи с объемами много такого, что не воспроизводится больше нигде, поэтому на всякий случай напоминаю – все случаи выдуманы!

История четвертая.

Зависающий клиент.

У нас порядка 8 тысяч работающих клиентов и вот появился ОН. При запуске система зависает. Висит окно запуска и всё, ни в какую, переустановка платформы не помогла, очистка кеша не помогла. В ТЖ всё очень аскетично.

17:25.704000-0,EXCP,0,process=1cv8c,OSThread=7856,setTerminateHandler=setTerminateHandler

17:26.297001-1,LIC,1,process=1cv8c,OSThread=7212,Func=initialize,txt='local Application, hasp HL SOFT local, ORGL8 local net, ORG8A local net, ORG8B local netBase local net'

17:26.297003-1,LIC,1,process=1cv8c,OSThread=7212,Func=getLicense,res=error,txt='0, client, error, local Application;

  hard, local, Base, absent;

  hard, net, Base, absent'

Делаем дамп процесса, отправляем в 1С – результат – система не может определить принтер по умолчанию. Проблема в драйвере принтера, попробуйте его переустановить.

Переустанавливаем, всё начинает работать. Что это было и почему в ТЖ пустота — это проблема, но мы сейчас пытаемся доказать, что это дефект в движке и зафиксировать его.

Как видите, все выше приведенные примеры разные, есть проблемы в движке, есть в коде, но на вопрос «что делать с зависаниями системы» у меня ответ один – разбираться, что именно зависает. Начните с анализа ТЖ, в 99% случаев вы найдете ответ там. Если ответа нет, нужно либо искать специалиста, обладающего достаточной квалификацией чтобы докопаться до причины либо передавать запрос в техподдержку 1С.

Чудес не бывает.

P.S. Начал перечитывать статью и понял, что не ответил на сам вопрос. Да. Мы чистим сеансовые данные, но не из-за глюков системы, а просто потому, что, когда 7 тысяч пользователей одновременно пытаются их прочитать, дисковая подсистема проседает и вместо запуска в течение 1 минуты пользователям приходится ждать по 10-15 минут. Когда обновление плановое, ночью, очищать сеансовые данные нет необходимости, нагрузка растет постепенно.

См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    2969    spyke    26    

42

Быстродействие типовой 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    5105    vasilev2015    19    

37

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7632    158    ZAOSTG    67    

96

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5973    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8861    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    5100    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16173    skovpin_sa    14    

98
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Alien_job 190 04.07.18 09:31 Сейчас в теме
Спасибо за статью! Очень интересно читать такие выдуманные истории с полезными техническими подробностями, а не ту воду которая заливает этот сайт из окон одной графоманской компании.
Dentaky; Yakud3a; LordKim; Igor_K_; jONES1979; primat; Mantis; Dimkasan; dunpil; dabu-dabu; PLAstic; AlexGroovy; GOshaSaveiko; Vladimir Litvinenko; Art1387; user621724_Dimav1979; CSiER; t.v.s.; morohon; Infactum; +20 1 Ответить
2. Evil Beaver 8107 04.07.18 10:00 Сейчас в теме
молния — это не гнев Зевса

Ну начинается... Вы еще скажите, что 1С лучше САПа :)
Berckk; Bronislav; kraynev-navi; pbabincev; +4 1 Ответить
5. Dzenn 870 04.07.18 10:19 Сейчас в теме
(2) а что, 1С хуже САПа, по твоему? Ты откуда такой динозавр выкопался?
Yakud3a; nvv1970; +2 1 Ответить
11. Evil Beaver 8107 04.07.18 11:18 Сейчас в теме
(5) Не помню, чтобы пил с Вами брудершафта, коллега, ну да Бог с ним.... перечитайте мой комментарий еще раз, особенно вводную цитату про Зевса. Может быть, Ваш вопрос снимется сам собой.
20. AlexGroovy 04.07.18 15:12 Сейчас в теме
(11)Андрей,мне очень нравятся ваши статьи на Инфостарте,но вот смысла этого выражения "Вы еще скажите, что 1С лучше САПа"- я не понял.
22. Evil Beaver 8107 04.07.18 15:23 Сейчас в теме
(20) пояснять шутки неблагодарное занятие, но попробую, раз уж вас двое....

Итак, автор утверждает, что "молния - это не гнев Зевса, а электрический разряд". Я с ним якобы не соглашаюсь и говорю что молния - это все же гнев Зевса, а САП - лучше чем 1С. Оба утверждения одинаково достоверны с "моей" точки зрения.
AlexK_2012; JohnyDeath; NoPlayer; strange2007; LordKim; +5 Ответить
23. genayo 04.07.18 15:26 Сейчас в теме
(22) Смайлов не было - не шутка. Такая молодежь пошла :)))
JohnyDeath; +1 Ответить
25. AlexGroovy 04.07.18 15:30 Сейчас в теме
(23)Смайлик есть,я просто никогда не смеялся над английским юмором.
26. genayo 04.07.18 15:32 Сейчас в теме
(25) Тогда непонятно - ну не поняли вы шутки, но поняли, что это шутка, зачем тогда её объяснить просите?
27. AlexGroovy 04.07.18 15:37 Сейчас в теме
(26)Я вообще не понял ,что это шутка .Я в этом просто увидел сарказм ,что SAP лучше 1С,но никаких аргументов к этому нету.Я хотел получить аргументы ,почему SAP лучше 1С,потому что для меня- это новость.
28. genayo 04.07.18 15:38 Сейчас в теме
(27) Вы понимаете, надеюсь, что вопрос хуже/лучше не имеет смысла, если не определены критерии для сравнения?
30. AlexGroovy 04.07.18 15:39 Сейчас в теме
(28)Согласен,что нужны критерии сравнения,но можно и дать более менее правильную "общую" оценку в совокупности критериев.
24. AlexGroovy 04.07.18 15:27 Сейчас в теме
(22)Т.е. по вашему мнению SAP лучше 1С?
29. Evil Beaver 8107 04.07.18 15:39 Сейчас в теме
(24) Блин.. ну наоборот же!
51. mbreaker 1413 06.07.18 08:47 Сейчас в теме
(24) Решить вопрос поможет опрос:

Что лучше?
1) Грейпфрут
2) Мандарин
3) Сэр Элтон Джон
4) Спагетти №7
5) Windows 10

Варианты ответов присылайте по адресу whocares@holywars.com

P.S. )))
P.P.S. sarcasm )))
P.P.P.S. любые совпадения с реальными объектами случайны!!!
AlexK_2012; LordKim; RustIG; +3 Ответить
45. buganov 200 05.07.18 10:18 Сейчас в теме
(22) надо было табличку сарказм прикрепить
Прикрепленные файлы:
48. pm74 199 05.07.18 13:57 Сейчас в теме
(45) слово "sarcasm" нечеткое , нужно по русски , Arial 40 , жирный шрифт
49. Repich 562 05.07.18 14:17 Сейчас в теме
(48)
В ТЗ не было указано таких подробностей, разработчик сделал на свое усмотрение, если не устраивает - заводите новую задачу, плановая дата выхода задачи в продуктив - октябрь 2018 г.
AlexK_2012; +1 Ответить
50. pm74 199 05.07.18 15:15 Сейчас в теме
74. brr 182 05.09.18 14:53 Сейчас в теме
(49) что-то слишком быстро, у вас задач нет?
3. morohon 04.07.18 10:06 Сейчас в теме
Очень интересно, спасибо за выдуманные истории!
4. pbabincev 132 04.07.18 10:18 Сейчас в теме
Такие интересные выдуманные истории и вредные советы)
6. FesenkoA 57 04.07.18 10:25 Сейчас в теме
Расскажите больше о примерах "неожиданной" оптимизации. Таких как в 1 примере: всегда считал что конкатенация строк быстрее процедур платформы. Разрабатываю системы на 10-20 пользователей, проблема производительности стоит только в "узких местах", хотелось бы изучить чужой опыт подводных камней 1С.
7. nicxxx 254 04.07.18 10:55 Сейчас в теме
(6) Почитайте про конкатенацию здесь и удивитесь. https://helpf.pro/faq8/view/1519.html
shard; PLAstic; +2 Ответить
12. Evil Beaver 8107 04.07.18 11:21 Сейчас в теме
(7) выучите С++ и больше никогда не будете удивляться медленной конкатенации )))

Ну или прочитайте классику от Джоэла http://russian.joelonsoftware.com/Articles/BacktoBasics.html
Yakud3a; PLAstic; fishca; CSiER; nicxxx; +5 Ответить
17. nicxxx 254 04.07.18 12:50 Сейчас в теме
72. strange2007 144 13.08.18 13:09 Сейчас в теме
(12) C++ это жуткие тормоза. Асм рулит и никак иначе!
(ухахахахахах)
8. kauksi 216 04.07.18 10:59 Сейчас в теме
(6) вам на курс Гилева по оптимизации для программистов
GreenDragon; +1 1 Ответить
13. FesenkoA 57 04.07.18 11:24 Сейчас в теме
(8) пока нет производственной необходимости, но чувствую что все же скоро придется..
9. Inkasor 28 04.07.18 11:05 Сейчас в теме
(6)эээ, што?
Правило производительности №1 - платформенный метод всегда быстрей, чем код на языке 1С. Если вдруг медленней, значит вы используете не ту комбинацию платформенных методов для решения задачи.
14. FesenkoA 57 04.07.18 11:25 Сейчас в теме
(9) не всегда все же. Те же сортировки можно организовать быстрее чем Сортитровать("поле")
10. CSiER 35 04.07.18 11:08 Сейчас в теме
(6) Почему конкатенация работает именно так хорошо описано в книге "Методическое пособие по эксплуатации крупных информационных систем 1С. 2-е издание" на стр. 248. Там же описан случай, когда не стоит применять СтрСоединить() вместо конкатенации.
33. Gureev 04.07.18 16:50 Сейчас в теме
(10) А можно привести цитату для тех, у кого нет второго издания. В первом нет страницы 248.
42. CSiER 35 05.07.18 03:29 Сейчас в теме
(33)
А можно привести цитату

в книге описывается пример конкатенации трех строк: рез = строка1 + строка2 + строка3 - при этом будет выделено 5 областей памяти (4 под переменные и одна для промежуточного значения строка1+строка2). Причина - строка является немутабельным объектом, который не может быть изменён на уровне платформы. Далее цитата с выводом:
Особенно явный негативный эффект такого поведения заметен при конкатенации больших строк – например, при формировании по частям текста длинных запросов в коде прикладных решений. Кроме большого объема занимаемой памяти возможны замедления, связанные с выделением (аллоцированием) областей памяти для помещения копий объектов. При интенсивном ее использовании память сильно фрагментирована, и на выделение памяти под большой объект может тратиться достаточно ощутимое время.

Про СтрСоединить:
В актуальных версиях платформы для сложения строк рекомендуется использовать метод СтрСоединить(), принимающий в качестве входного параметра массив складываемых строк. Данный метод оптимизирован в части использования памяти. Но при его использовании нужно учитывать, что для маленьких строк накладные расходы на создание исходного массива могут превысить эффект от самого оптимизированного сложения строк.

Про выделение памяти:
Строка
■ Размер – 40 байт для x86 и 64 байта для x64.
■ Может хранить короткие строки внутри себя (до 9 символов).
■ Для длинных строк используется дополнительная память размером 2*N символов.
Merkalov; LordKim; FTC; shard; RustIG; PLAstic; sanjabor; Gureev; +8 Ответить
15. genayo 04.07.18 12:05 Сейчас в теме
Из практики, примерно сколько процентов "пойманных" вами дефектов признаются и исправляются вендором, и насколько сложно "заставить" вендора признать дефект? Ну и спасибо за вашу работу, надеюсь, она приведет к повышению качества платформы в целом.
19. Repich 562 04.07.18 14:31 Сейчас в теме
(15)
Те, которые признаны дефектами - 100%, другое дело что от момента фиксации дефекта до его исправления может пройти год и более.
21. genayo 04.07.18 15:12 Сейчас в теме
(19) А сколько процентов из тех, что вами определены как дефекты, признаны как дефекты вендором?
32. Repich 562 04.07.18 16:42 Сейчас в теме
(21)
Мы умеем быть настойчивыми.
59. RustIG 1351 09.07.18 09:07 Сейчас в теме
(0) что из статьи можно взять и применить?!
только то, что учитесь делать дамп и отправлять его в техподдержку 1с.
в чем смысл иметь 7000 клиентов, и не иметь в штате крутого 1с-ника - который в отладке решит все вопросы с зависаниями и пиковыми нагрузками из-за кривого кода?
(15) вряд ли 1С примет к сведению такого рода ошибки - капля в море.
TerveRus; +1 Ответить
64. genayo 09.07.18 09:28 Сейчас в теме
(59) В теории как раз ошибки от таких клиентов, с КОРП лицензиями и большими нагрузками, 1С должна принимать и исправлять в первую очередь. На практике, видимо, все равно приходится затрачивать на это значительные усилия.
16. Gilev.Vyacheslav 1910 04.07.18 12:33 Сейчас в теме
Основная проблема всех крупных компаний - впадения в крайности по консолидации и уплотнению всего и вся мол так дешевле обслуживать
тоже самое касается таких поделок как ERP, я удивлен что 1С одной конфигурацией не попытались консолидировать вообще любое предприятие
FTC; Dem1urg; Danil.Potapov; fishca; neikist; ZOMI; +6 Ответить
38. Repich 562 04.07.18 22:38 Сейчас в теме
(16) А почему ты считаешь это проблемой? По сравнению с РТК данный проект я считаю гораздо более успешным и интересным.
55. Gilev.Vyacheslav 1910 07.07.18 21:35 Сейчас в теме
(38) потому что упрощение для админов по целентрирозованному бэкапированию например оборачивается сильным взаимным давлением разных базы,

если влияние двух или трех баз друг на друга еще как можно разобрать, то 50 разнородных баз с разнородной нагрузкой, а значит противоречивыми требованиями к дискам превращают всё в цирк

все умные, у всех попа прикрыта, только не работает и компания начинает нести убытки

у неискушенных руководителей шансов разобраться мало в том, откуда ноги растут, так как ошибка хоть и не слишком глубоко зарыта, но взять на себя ответственность учить подчиненных как организовывать ресурсоизолированность рискованно и вероятность сабатажа it-шниками такой инициативы 146%...
56. Repich 562 08.07.18 14:13 Сейчас в теме
(55)
Слава, честно - не понял о чём ты.
Мы решили работать в одной базе не для того чтобы прикрыть попу и не для удешевления, как ты понимаешь - стоимость нашей системы по сравнению с основной системой компании - копейки.
57. Gilev.Vyacheslav 1910 08.07.18 21:21 Сейчас в теме
(56) да это не важно, из каких соображений вы решили консолидировать в одну базу 7000 пользователей
важно что можно было ли сделать по-другому и был бы другой вариант лучше

у вас что все пользователи используют данные всех других пользователей? нет конечно...
58. Repich 562 09.07.18 01:00 Сейчас в теме
(57)
Что значит лучше? Тут же нет одномерной шкалы от -100 до +100, где -50 плохо, +36 нормально, а +90 хорошо.
Конечно большинство пользователей не использует данные друг друга, но возможность получать данные в онлайне для 1-2 ключевых пользователей, например для сайта оправдывает.... А что собственно оправдывает то? Какие варианты еще? РИБ?
65. Gilev.Vyacheslav 1910 09.07.18 14:19 Сейчас в теме
(58) если бы вы писали фейсбук на 1С, то вы бы тоже все загнали в одну базу

а надо делать систему горизонтально масштабируемой, чтобы новые пользователи спокойно бы усаживались на дополнительный сервер

что делать - это уже следующий вопрос

у нас - 14 000 пользователей, мы делаем микросервисы, каждую функцию в отдельную базу закидываем, при этом это не лучший вариант
еще более правильней людей сажать в разные базы исходя из пересекаемости данных

можно делить не по функциям, а по ролям пользователей "модули"

к сожалению в 1С нельзя динамически добавлять таблицы (да еще бы хорошо не в одну базу данных), это главная проблема масштабируемости 1С

но я тут в двух словах быстро большую и сложную тему не смогу изложить
VSOP_juDGe; farukshin; +2 Ответить
67. Repich 562 09.07.18 14:24 Сейчас в теме
(65)
Как раз последний год, когда мы выросли с 3500 до 7000 пользователей (это был внеплановый рост, мы под него не закладывались) показал, что с горизонтальным ростом как раз всё хорошо, добавили app-сервера, вынесли регламенты на отдельный сервер, вот пожалуй всё, что потребовалось. А, ну и лицензии купили.
dancer_petrovich@list.ru; +1 Ответить
70. Gilev.Vyacheslav 1910 16.07.18 09:38 Сейчас в теме
(67) ага, и базу данных размазали по серверам )))
61. RustIG 1351 09.07.18 09:12 Сейчас в теме
60. RustIG 1351 09.07.18 09:10 Сейчас в теме
66. Gilev.Vyacheslav 1910 09.07.18 14:21 Сейчас в теме
(60) можно объяснить всё, но не всем )))
zhichkin; +1 Ответить
18. PerlAmutor 129 04.07.18 14:17 Сейчас в теме
(0)
задание уходило в пустой бесконечный цикл

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

Причина – дефект в движке, исправлено в 8.3.12. Справедливости ради скажу, что воспроизводится данный дефект по моей информации только у нас.

Вас обманули. Мы с этим дефектом живем уже пару лет.

Делаем дамп процесса, отправляем в 1С – результат – система не может определить принтер по умолчанию. Проблема в драйвере принтера, попробуйте его переустановить.

А вот эта штука достаточно коварная. Частенько сталкиваемся с тем, что кто-то формирует печатную форму на одном компьютере, а потом переходит на другой и пытается сделать тоже самое там. Но настройки печати сохранены, в том числе и принтер по умолчанию и платформа падает/глючит, что угодно.

Спасибо за статью. Было бы интересно почитать еще с примерами анализа технологического журнала.
serge_focus; Yakud3a; TerveRus; RustIG; PLAstic; +5 Ответить
62. RustIG 1351 09.07.18 09:14 Сейчас в теме
(18) ну вот, наконец-то - взгляд на проблемы программиста 1С.
31. Kamikadze 46 04.07.18 16:41 Сейчас в теме
Зависающие rphost-ы.

В нас решили проблему отключением журнала регистрации. При объемах больше 18 ГБт записали отдельные хосты
37. Repich 562 04.07.18 18:26 Сейчас в теме
(31)
У нас он только ошибки регистрирует. Всё собираюсь сделать по человечески, подключив ElasticSearch, руки не доходят.
34. ansh15 04.07.18 17:17 Сейчас в теме
Выводы, которые мы сделали после той аварии:
Запас мощности системы должен быть минимум 50%, лучше 100%, то есть система должна спокойно переживать двукратный рост нагрузки. Если какие-либо показатели превышают 50% от максимального значения – начинайте нервничать.

Вопрос к автору публикации: руководство также прониклось этой мыслью и выделило достаточное финансирование на реализацию этой идеи? Или...?
36. Repich 562 04.07.18 18:19 Сейчас в теме
(34)
С этим проблем нет, если ты способен доказать, что так надо - деньги дадут. Сейчас у нас 6 app серверов со средней нагрузкой по ЦПУ где то на уровне 30%.
35. Sergey.Noskov 1376 04.07.18 17:31 Сейчас в теме
Запас мощности системы должен быть минимум 50%, лучше 100%, то есть система должна спокойно переживать двукратный рост нагрузки.
у нас схожая проф.деформация)) «Вы либо УЖЕ параноик, либо ЕЩЁ не параноик»
39. Repich 562 04.07.18 22:39 Сейчас в теме
(35)
Тут еще фишка в том, что 25-30 декабря мы реально испытываем двукратный рост нагрузки, поэтому к новогоднему периоду готовимся особенно тщательно.
63. RustIG 1351 09.07.18 09:18 Сейчас в теме
(39) в чем прикол 25-30 декабря испытывать колоссальную нагрузку, и не поменять до сих пор бизнес-процесс - 25-30 декабря - это пик продаж, то есть у вас кучка розничных магазинов.... так выделите отдельные базы только для розницы, а на январских праздниках перекинете сведения о продажах в основную базу.
68. Repich 562 09.07.18 14:27 Сейчас в теме
(63)
В том что мы не знаем, где стрельнёт. В 2016 году стрельнула смежная система, на которую мы завязаны, но на которую не можем повлиять.
В 2017 подготовились к ней, но стрельнуло в другом месте.
В итоге сейчас ставим нагрузочный стенд на 8 тысяч пользователей, но это достаточно трудозатратный процесс.
40. ivanov660 4330 04.07.18 23:43 Сейчас в теме
(35) Режет уши фраза про запас системы в 100%. Это как? Некоторые гуру говорят, что начинать переживать стоит в тот момент, когда average CPU load превысит 70-80% иначе это недоиспользованные мощности и лишние расходы.
Надо мониторить за изменением нагрузки и ждать момента "беспокойства". А вот наличие аномалий, к примеру, внезапного серьезного падения производительности стоит исследовать незамедлительно с установкой сигнализации на такие ситуации.
41. Repich 562 05.07.18 00:05 Сейчас в теме
(40)
Это означает что повышение нагрузки в 2 раза (на 100%) не приводит к остановке системы в связи с нехваткой ресурсов.
Про лишние расходы говорить не готов, с точки зрения бизнеса лучше (дешевле) платить год за недоиспользованные мощности, чем испытать часовой простой системы.
CheBurator; ansh15; +2 Ответить
43. genayo 05.07.18 06:11 Сейчас в теме
(41) Кстати, для минимизации затрат на избыточные мощности, обычно используются облака, Амазон и им подобные. Но, в свете последних событий, для России это не вариант...
44. ivanov660 4330 05.07.18 09:48 Сейчас в теме
(41) зависит от стоимости этих ресурсов, а рост нагрузки в два раза просто так не случается.
46. besica 05.07.18 11:03 Сейчас в теме
Зависающие rphost:

Справедливости ради скажу, что воспроизводится данный дефект по моей информации только у нас.

+1, причем только на проде, на тестовых повторить не получилось. В итоге мы то откатились на платформу на которой все еще было хорошо.
47. Evil Beaver 8107 05.07.18 11:10 Сейчас в теме
Любую (!!!) проблему с зависаниями можно решить с помощью технологического журнала.

Поделитесь примером - в каком именно направлении вы смотрите, выявляя проблемные/зависшие сеансы?
ivanov660; PSafonov; CSiER; +3 Ответить
52. zarucheisky 06.07.18 11:21 Сейчас в теме
Молодец, Олежек :)
Токмо вот с архитектурой скуля можно было поиграться да и... с серверами желтыми тож.
53. Repich 562 06.07.18 12:45 Сейчас в теме
(52)
А нафига, Жень? Ту цель, которую ставили - они вполне себе выполняют.
54. Patrio_O_Muerte 06.07.18 17:25 Сейчас в теме
По названию я ожидал более фундаментального труда, чем описание нескольких отловленных багов.
69. Mantis 137 11.07.18 07:48 Сейчас в теме
71. chng 20.07.18 17:26 Сейчас в теме
>... ищите одиннадцатого....
Никто не оценил.
73. teembox 04.09.18 11:20 Сейчас в теме
Спасибо. Статья норм, опыт пригодится.
Оставьте свое сообщение