Взгляд на ошибки и платформу через призму HI-Load

18.06.18

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

Поговорим об ошибках в целом и их влиянии на Hi-Load системы в частности. Может ли тут помочь платформа 1С? (да и должна ли в принципе?) Немного про сам Hi-Load на примере крупной БД. PS Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

Всем привет!

Я уже второй раз выступаю на конференции Infostart. В первый раз, это было в 2014 году, я выступал от компании «Деловые линии». Но в том же году весь ИТ-департамент «Деловых линий» был выделен в отдельное юридическое лицо BIA Technologies, и «Деловые линии» стали нашим основным заказчиком.

Итак, Hi-Load.

HI-Load бывает разный. В википедии вообще написано, что HI-Load – это просто высокая нагрузка и всё.

Договоримся на берегу, что буду говорить только о Hi-Load, отвечающих двум аспектам:

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

Второй. Это система уровня Энтерпрайз. Т.е. когда работоспособность базы напрямую влияет на работу бизнеса.  Грубо говоря, остановилась база - остановился бизнес.

Тут важный момент. Это должен быть не просто факт такого влияния, но и осознание этого самим бизнесом. Проще говоря, если владелец базы данных НЕ ставит отдельную цель обеспечить мощность, доступность и непрерывность работы своей базы, то значит он её НЕ ценит. А если НЕ ценит, значит это НЕ Энтерпрайз.

Что еще важно. Энтерпрайз не обязательно большая база данных с высокой нагрузкой, она вполне может быть маленькой, но бизнес её бережет и сдувает с неё пылинки.

Оба этих аспекта сочетаются в информационной системе нашего основного Заказчика.

Поэтому давайте про саму систему. Кратко.

 

  • Это – самописная конфигурация на платформе 1С.
  • В базе одновременно работает более 3000 пользователей в 129 городах России.
  • Режим работы круглосуточный.

На стороне сервера СУБД показатели следующие:

  • MS SQL 2014
  • Среднее число запросов 35'000 в секунду, пиками до 50'000.
  • Больше 10'000 транзакций в секунду, пиками до 30'000.
  • Нагрузка на процессор меньше 15%, пиковая до 40%.

Суммарный размер базы более 9 ТБ. Из них:

  • Чуть меньше половины занимают регистры сведений.
  • На втором месте – регистры накопления.

Интенсивность работы:

  • В сутки записывается и перепроводится (включая создание новых) более миллиона документов;
  • Справочников – порядка 380 тысяч;
  • И ежедневно пользователи формируют около 300 тыс. отчетов.

Повторюсь, это показатели за сутки. Режим работы 24 на 7, но почти 80% этой нагрузки приходится на 12-ти часовой промежуток времени. Примерно с 9 утра до 9 вечера.

Про платформу.
Используемая платформа: 1С 8.3.10

 

Переходу на 8.3 предшествовал достаточно длительный проект по нагрузочному тестированию, который мы провели совместно с центром корпоративной технической поддержки (ЦКТП) от 1С. Это тестирование мы проводили практически год.

Целью нагрузочного тестирования было:

  • Добиться стабильной работы платформы и базы;
  • Понять, выдержит ли вообще железо такие нагрузки – может быть, нам потребуется менять сервера, конфигурацию;
  • Оценить перспективы роста (и для бизнеса в том числе).
  • Понять, что будет с базой в ближайшие 3-5 лет.

 

В чем состояло само тестирование?

  • На протяжении 8 часов 10 тысяч виртуальных пользователей должны были работать в системе;
  • При этом итоговый APDEX должен быть на уровне «отлично».
  • И никто из этих пользователей не должен аварийно завершить работу.
  • Также отделом тестирования проводились еще и пользовательские (функциональные) тесты,

На скриншоте вы можете видеть 15 тысяч пользователей – это реальный скриншот с проведения теста. 15 тысяч – потому, что помимо 10 тысяч виртуальных пользователей были COM-соединения и работал фоновые задания. У нас такая специфика работы, что мы для построения отчетов подключаемся к копии базы по COM-коннекту. Поэтому нам важно было удостовериться, что кластер выдержит работу еще и с большим количеством COM-коннектов.

Подробно об этом проекте я рассказывать не буду, поскольку он похож на предыдущий проект, который освещался на Event 2014. Доклад назывался «Нагрузочное тестирование на 5 тыс. пользователей». Как видите, оказалось, что пользователей может быть еще больше.

Из интересно отмечу сам процесс перехода с 8.2 на 8.3.
Нам сказали: «Ребята, надо снять режим совместимости с 8.2, но пользователи могут не работать только один час, а дальше – пожалуйста, будьте любезны предоставить доступ».

Что было для этого сделано?

  • Мы использовали свою собственную систему репликации, построенную на планах обмена.
  • Развернули копию рабочей базы, включили обмены.
  • На копии базы выполнили реструктуризацию типовыми средствами. Получили копию рабочей базы на новой платформе.

  • Настроили обмен из рабочей базы 8.2 в эту копию 8.3. Обмен шел порядка двух суток. В планах обмена было около миллиарда изменений.
  • Когда база 8.3 актуализировалась, мы просто переназначили ярлыки. Для пользователей это было буквально за 5 минут и все – они стали работать дальше.

Кому интересно, описание железа, использованного на проекте, есть на сайте 1С http://v8.1c.ru/expert/cts/cts-330-001.htm
 

 

Возвращаемся к теме HiLoad.
В чем же особенности при такой высокой интенсивности работы?

 

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

Например:

  • 3 тыс. пользователей;
  • у каждого третьего раз в секунду срабатывает обработчик ожидания;
  • В этом обработчике выполняется запрос, который потребляет 0.1 секунды CPU.

Соответственно, для того, чтобы вам обеспечить работоспособность этого потока запросов, вам нужен сервер минимум на 100 ядер. При этом он все равно будет загружен на 110% и работать не сможет (формула немного утрированная, но суть отражает верно).

Что мы делаем для того, чтобы снизить эту чувствительность? Мы буквально тюнингуем самые частовыполняемые запросы, добиваемся максимальной эффективности и минимального потребления ресурсов.

Периодически снимаем трассу всех запросов – собираем не долго, буквально 10-15 минут. За одну секунду такого сбора в трассе получается порядка одного гигабайта данных. Мы группируем эти запросы, "вырезая" имена временных таблиц, смотрим, какие из них самые часто выполняемые и самые «тяжелые». Решаем, что с самыми «тяжелыми» запросами делать дальше – переписать либо попробовать вообще от них отказаться.

  • Самый оптимальный запрос – это отсутствие запроса. Поэтому, если удается отказаться (достаточно часто бывают и такие ситуации) – это для нас очень хорошо.

 

 

Вторая проблема, которую я хочу отметить, – это "Рост".

  • За счет того, что бизнес развивается;
  • Увеличивается документооборот;
  • Увеличивается количество пользователей;
  • Усложняется сам учет.

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

В итоге достоверно спрогнозировать, что будет через полгода, год очень сложно…
Поэтому у нас уже профессиональная деформация – мы все постепенно становимся параноиками – пытаемся все зарезервировать, замасштабировать, добиться того, чтобы везде был запас по железу.

Перефразируя цитату про бэкапы: «Вы либо УЖЕ параноик, либо ЕЩЁ НЕ параноик». Конечно, в хорошем смысле этого слова))

Про резервирование и отказоустойчивость.

Придерживаемся следующих принципов:
- кластеризация СУБД и 1С;
- наличие «холодного» и «горячего» резерва;
- запас прочности по железу, как СУБД так и серверов 1С.

Как это выглядит в жизни на примере кластера СУБД:

Кластер СУБД собран из трех серверов, за кластеризацию отвечает windows server failover cluster. На одном из серверов рабочая база, на другом вторичный узел репликации AlwaysOn. Это типовая возможность MS SQL Server. База - реплика доступна только на чтение.

У заказчика эта копия отдельно подключена к серверу 1С и в неё можно интерактивно зайти, сформировать отчет, найти нужную информацию. С обычными (толстыми) формами это делается достаточно просто, а вот с управляемыми формами будут проблемы. При их открытии в первый раз платформа пытается сделать запись в таблицу _SystemSettings и получает от сиквел-сервера ошибку.

В копию AlwaysOn, по СОМ соединению, подключаются отчеты, которые пользователь формирует в рабочей базе. А сам запрос отчета выполняется в копии, тем самым распределяя нагрузку.

Третий сервер кластера СУБД сейчас просто в резерве, но долгое время там также была копия базы, только реплика делалась средствами 1С. Это тот же механизм на планах обмена, что использовался при переходе на 8.3.

Что эта схема позволяет сделать?

  • При проблемах на рабочем сервере (например, у вас планка памяти сгорела или еще что-то), Windows Failover Cluster Server просто мигрирует вашу базу данных на другой сервер:

  • Второй момент – если у вас проблема с самой базой данных (например физическое повреждение дисков), тогда можно в качестве рабочей базы использовать базу Always On:

 

Переключение происходит быстро, единственный момент, необходимо перезапустить службу 1С.

 

 

 

А это уже кластер 1С – он состоит из 5 серверов. Его основные особенности:

  • На центральном сервере мы отказываемся от rphost (эта особенность у нас сохранилась еще со времен 8.2).
  • Отдельный сервер отдан под фоновые задания. Их у нас тоже достаточно много.
  • И оставшиеся три сервера отданы под пользователей. Там не только пользователи – там все, кроме фоновых.

При этом сами сервера имеют запас по железу, и если один из них выходит из строя, то оставшиеся четыре продолжают работать.

Такая схема позволяет нам защищаться от ошибок и пользователей, и разработчиков, и, в том числе, от ошибок железа.

Кстати про косяки в коде, следующая часть доклада как раз им и посвящена.
Разработчики, как и везде, совершают примерно схожие ошибки. Работа с составными типами данных, попытка обойтись без регистров, излишняя универсальность.
Но есть еще другая сторона баррикад… А именно Заказчики.

 

Текущие реалии таковы, что сейчас модно говорить об Agile и DevOps. Почему это модно?

Ответ прост. Бизнес хорошо понимает, что новая фишка нужна чем раньше, тем лучше. Раньше предоставишь новую услугу, привлечешь больше клиентов, займешь бо'льшую долю рынка.

Основным принципом становиться высокая скорость разработки при приемлемом уровне качества. Повторюсь, ПРИЕМЛИМОЕ качество… Т.е. у вас не будет ни идеальной, ни близкой к ней архитектуры. 
Плюс к этому, если на очередной итерации доработок заказчик, вдруг, меняет курс партии на 180 градусов, вы, как исполнитель, должны быстренько переобуться и так же быстренько всё переделать.
Вывод простой, вероятность просчетов и ошибок повышается. Это не хорошо и не плохо, просто к этому надо быть готовыми. И тот же DevOps уделяет внимание возможности быстро "фиксить" ошибки.
И что меня постоянно смущает, так это отношением к косякам и ошибкам..
И то возникающее недоумение, когда ты говоришь «Я вот это сделал так, потому, что текущая архитектура уже устарела» или «Мне нужен такой то функционал для решения ошибок и просчетов». Первая реакция, которая обычно следует: «Что? Нет! Это не кошерно! Просто всё перепишите заново.». 
Ну не бывает так в жизни. В жизни вы всегда ищите компромисс. Используя тот же принцип – обеспечить работоспособность минимальными затратами.
 

Про ошибки я хотел бы отдельно заметить две важных вещи, два основных мифа:

  • Идеальной архитектуры не бывает. Если она и бывает, то только в какой-то конечной замкнутой неразвивающейся среде (возможно, даже никому уже давно не нужной).
  • Второй момент – все ошибаются. Ошибки – это нормально. Перефразируя доктора Хауса – все «косячат», это наша с вами человеческая природа. И к этому надо быть готовым.

 

Хотелось бы поговорить про то, чего нам не хватает со стороны платформы 1С на таких масштабных проектах. На слайде перечислены «хотелки» из реальных кейсов, из попыток решить какие-то конкретные задачи, какие-то проблемы. На самом деле все уже придумано и давно есть во взрослых СУБД.

Тут не все "хотелки", тут только приоритетные по нашему мнению. Это то, что нам реально требовалось в ходе решения различных задач.

Отдельные из этих пунктов – холиварные, возникают из-за «бурления масс». Например:

  • Использование хинтов в запросах;
  • Или возможность создавать индексы произвольной структуры.

Основной довод против – всё, что надо, в платформе уже есть, надо просто всё это знать и уметь. 
И самые главные: «НАДО было думать раньше!» «Вы пытаетесь исправить костылем чей то косяк…» фу-фу-фу…

Я даже не говорю о том, что есть какие то реальные задачи, которые этого требуют.., ладно, упростим ситуацию и согласимся с упреками оппонентов: нам это нужно только для того, чтобы компенсировать ошибки... Но ошибки – это ведь нормально, мы про это уже говорили. Да, в идеале надо все переписать с нуля, но в жизни так не бывает. В жизни вы обычно добиваетесь какого-то компромисса и ищете возможность сделать это максимально эффективно, быстро, качественно. Удовлетворить заказчика, в конце концов.

Мое мнение, что ошибки это норма, и это не может быть доводом против расширения возможностей. Наоборот, надо готовиться к тому, что объемы ошибок и их "качество" будет только возрастать.

Заключение

Лично от меня. Отдельная огромная просьба к компании 1С – пересмотреть свое лицензионное соглашение в части использования средств СУБД.

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

Сообществу нужна универсальная платформа для всего и всех, а не только для разработки типовых.

Спасибо за внимание!

 

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


нагрузочное тестирование переход на 8.3 отказоустойчивый кластер

См. также

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

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

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

13.03.2024    2336    spyke    25    

38

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

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

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

1 стартмани

15.02.2024    7345    148    ZAOSTG    66    

95

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

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

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

09.01.2024    5760    doom2good    48    

63

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

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

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

20.11.2023    8573    ivanov660    6    

75

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

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

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

15.11.2023    4998    a.doroshkevich    20    

72

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

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

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

11.10.2023    15954    skovpin_sa    14    

97

Как эффективно настроить autovacuum в Postgres для 1С

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

Кто не любит убирать мусор? Думаю, практически все, а вот в Postgres это обязательный ритуал для эффективной работы. Как эффективно настроить уборку за 1С в Postgres, можно прочитать в этой статье и еще раз задуматься о бесплатности Postgres.

05.08.2023    4971    1CUnlimited    5    

51
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. qwinter 671 18.06.18 13:47 Сейчас в теме
Я что то пропустил и 1С все таки решили сделать возможность делать свои индексы? Где можно почитать?
2. Sergey.Noskov 1374 18.06.18 14:38 Сейчас в теме
(1) Не пропустили. Это только мои ожидания.
3. qwinter 671 18.06.18 15:09 Сейчас в теме
(2) (( Жаль. Ожидания этого далеко не только у вас.
6. Sergey.Noskov 1374 18.06.18 18:10 Сейчас в теме
(3) вот и надо чаще про это говорить.
29. Serj1C 483 04.04.23 20:29 Сейчас в теме
(1) Вначале опубликовали планы на 8.3.24, потом перенесли в планы 8.3.25. Ждем
29 Возможность создавать дополнительные индексы для таблиц хранимых данных Перенесена на 8.3.25
источник https://wonderland.v8.1c.ru/blog/obnovlyen-plan-zadach-na-versiyu-8-3-24-platformy-1s-predpriyatie-2/
4. grumagargler 723 18.06.18 17:25 Сейчас в теме
Интересное подтверждение того, что могут существовать противоположные подходы одновременно. По своему опыту: терпимость к ошибкам приводит к загниванию системы, особенно в больших проектах, где ошибки стоят дороже, чем наличие функционала (не сталкивался, чтобы большие компании постоянно стресовали новым функционалом, обычно чем больше, тем всё инертней). Уже не говоря о технических долгах, которые всегда приходится отдавать с процентом. А хороший код всегда проще изменить под модифицированное заказчиком требование, чем плохой. Не раз проводил эксперимент, предоставляя программистам больше времени на задачу - качество при этом существенно не меняется. Те, кто пишет хорошо - делает это еще лучше, а те, что говорят, дайте больше времени - так и продолжают делать ошибки.
8. Sergey.Noskov 1374 19.06.18 13:38 Сейчас в теме
(4) А кто говорит про терпимость к ошибкам? Я точно не говорил. Речь лишь о том, что они неизбежны. И, что самое интересное, для бизнеса наличие функционала сейчас, но с тех.долгом, выгоднее, чем функционал без оного, но через пол года.

По поводу инертности - объемы прироста функционала не снижаются.
starik-2005; +1 Ответить
5. Glebis 13 18.06.18 17:42 Сейчас в теме
- Возможность задавать в запросах свои имена временных таблиц СУБД.

Почему бы просто не добавлять дополнительное поле с уникальным строковым идентификатором в каждую временную таблицу под одним и тем же именем?
9. Sergey.Noskov 1374 19.06.18 13:40 Сейчас в теме
(5) нужна повторяемость текста запроса, для использования одного скомпилированного плана запроса.
7. Serg O. 224 19.06.18 12:35 Сейчас в теме
Дастиш фантастиш...
база 9 ТЕРРА-байт ?! сколько серверов? этаж или здание?
нам такое только в страшных снах и то не снилось

прямая поддержка ЦКТП... бюджет такой же... в этажах или зданиях мерялся...
это нам даже в лучших снах не снилось

APDEX 0,99 - это значит заниженные требования
или пора повышать требования...
если 0,94-0,95 макс.было на 5-ку
10. Sergey.Noskov 1374 20.06.18 16:52 Сейчас в теме
(7)
APDEX 0,99 - это значит заниженные требования
Обоснуйте.
17. triviumfan 91 06.11.18 17:02 Сейчас в теме
(10) Приведите хотя бы несколько примеров целевого времени самых популярных ключевых операций.
А то я могу задать открытие формы в 10с, запись в 20, а проведение в 30. Для меня клиента это может быть норм требованием.
apdex будет стремиться к 1.
19. Sergey.Noskov 1374 08.11.18 13:59 Сейчас в теме
(17)
А то я могу задать открытие формы в 10с, запись в 20, а проведение в 30
а смысл, что бы обмануть себя? Пользователи и Заказчик молчать не будут - если тормозит, то ответ "проблемы не видим, апдекс отличный" никто не примет. АПДЕКС, в первую очередь, делается тех, кто занимается эксплуатацией и поддержкой этой системы. И к значению апдекса должно быть доверие.
У нас есть три операции с целевым временем больше 10 секунд, но они объективно длительные.
АРМ Call центра. Входящие 8800 3,00
АРМ Call центра. Оповещение о приходе груза 3,00
Ввод нового контрагента запись элемента 2,00
Выдача накладной 2,00
Групповая выдача: Список накладных по контрагенту 3,00
Запись документа задание группе пользователей 2,00
Запись документа Звонок 2,00
Запись документа Служебная записка 2,00
Запись контрагента 2,00
Проведение выгрузки машины 24,00
Проведение выданной накладной 5,00
Проведение загрузки машины 20,00
Проведение заявки экспедитора 3,00
Проведение приемной накладной 4,00
Проведение рейса автодоставки 12,00
20. triviumfan 91 08.11.18 14:19 Сейчас в теме
(19) Ну вот, что и требовалось доказать. Где-то видел (в каких-то курсах), что на открытие 1с, запись 2с, на проведение 3с. А у вас вон чего.
Слышал, что целевое время зависит от заказчика.
Стырено

К примеру, для него проведение рейса может и 20с приемлемо, поэтому apdex по сей операции будет стремиться к 1, а на самом деле какой-нибудь Вася там кривой запрос написал и все ок.
22. Sergey.Noskov 1374 08.11.18 15:02 Сейчас в теме
(20) тут нет открытий, запись - только две операции связанные с контрагентами (обе кстати 2с как и в придуманных кем то нормах), остальное - проведение документов (Запись документа Звонок и т.п. это по факту проведение), опять таки большинство операций 3с из "тех самых норм".
АПДЕКС не характеризует идеальность системы. А целевое время не равно идеальному.
И да, пользователь должен подтвердить, что вот эта скорость работы его целиком устраивает.
Не вижу противоречий. Только вот что именно Вы доказали совсем не понятно)
23. triviumfan 91 08.11.18 15:46 Сейчас в теме
(22) Я ссылался на "Проведение рейса автодоставки 12,00".
Ладно, проехали, на самом деле мне просто завидно, ведь у нас apdex 0.7+ (но и оборудование старое) :)
24. Sergey.Noskov 1374 08.11.18 19:16 Сейчас в теме
(23) пользователи при этом сильно жалуются? Показатель 0.7 у нас приравнивается к недоступности услуги и вызывает большой поток жалоб.
25. triviumfan 91 08.11.18 20:40 Сейчас в теме
(24) В том то и прикол, что им всё равно (да и железо вот:xeon x5650, 24гб озу, ~70 юзеров, УТ11)
26. triviumfan 91 08.11.18 21:38 Сейчас в теме
(25) а нагрузочный тест гилёва TPC-1C выдаёт 11 баллов. Очень подозрительно...
27. Sergey.Noskov 1374 09.11.18 12:33 Сейчас в теме
(25) вообще это странно. Пользователям, особенно если их под 100 человек, обычно не всё равно. Возможно они привыкли или считают такую скорость нормальной.
11. zinal 46 20.06.18 17:25 Сейчас в теме
С моей колокольни, в наибольшей степени платформе 1С:Предприятие не хватает поддержки партиционирования таблиц (вероятно, на вашем слайде это "сегментирование").
Другой важный вопрос вопрос - допустимость ручного (на стороне СУБД) управления размещением данных на разных устройствах, тут действительно может быть противоречие с условиями лицензионного соглашения 1С.
Причём технически коду 1С совершенно всё равно, в каком табличном пространстве (файле) лежит какая таблица.
Sergey.Noskov; +1 Ответить
13. Sergey.Noskov 1374 21.06.18 13:51 Сейчас в теме
(11) именно это и подразумевалось
12. Serg O. 224 21.06.18 05:59 Сейчас в теме
(42)
(10)сравните средне-арифметич. Время выполнения и время ожидания apdex, если они различаются в разы... Значит время в оценке apdex можно еще уменьшить. Неплохо бы еще оценить средне-квадратичное отклонениние и сделать время ожидания apdex =среднее + ср.кв.отклонение или меньше и тогда уже искать apdex,, как анализ дисперсии
Конечно не спорю 0,99 это афигительно круто...
14. пользователь 22.06.18 16:05
Сообщение было скрыто модератором.
...
15. DonAlPatino 176 27.06.18 15:36 Сейчас в теме
А можно вопрос про Always on. Все-таки 1С гарантирует что транзакции платформы на уровне сервера приложений один-в-один превратятся в транзакции SQL сервера? Не может ли быть ситуация что из-за падения скажем основного SQL Server в момент проведения документа на резервном он окажется "полупроведенным"? Где бы подробно про разбор такой ситуации почитать? На ИТС как-то в основном про транзакции на сервере приложений и что все будет хорошо.
18. Sergey.Noskov 1374 08.11.18 08:39 Сейчас в теме
(15)Always on технология не 1С, это функция MS SQL Server. Транзакционная целостность сохраняется, "полупроведение" принципиально не возможно.
16. asemenyuk 29.06.18 14:38 Сейчас в теме
Добрый день!
В реализованной у Вас схеме, Центральный сервер 1С никаким образом не зарезервирован. Как поведет себя кластер 1С, если Центральный сервер 1С (тот что без rphost) станет недоступен? Какие ограничения будут наложены на схему в случае его недоступности? Интересуют реальные факты тестирования данного события.
21. Sergey.Noskov 1374 08.11.18 14:25 Сейчас в теме
(16) Добрый день!
Если центральный сервер 1С станет недоступным, то и система станет недоступной, все пользователи завершат работу аварийно и не смогут зайти.
Вероятность этого есть всегда, но она тем меньше, чем больше разгружен центральный сервер. Если с центрального убрать клиентские сессии, фоновые задания, полнотекстовый поиск, журнал регистрации и использовать флаг "менеджер под каждый сервис", то риск потери сервера крайне низкий, по сути он равен риску невосстановимого отказа физической машины.
Отказоустойчивость мы использовали в нагрузочном тесте на 10'000 пользователей. Первые тесты показали наличие проблем - кластер работал не стабильно, пользователи "падали", апдекс проседал с 0.99 до 0.94. В последних релизах 8.3.10 работало уже лучше, производительность снижалась заметно меньше (апдекс падал до 0.97).
Планируем в следующем году протестировать свежие версии платформы и будем принимать решение по результатам.
28. acanta 28.04.19 14:56 Сейчас в теме
В запросе 1с для динамического списка нет возможности ограничить методами языка запросов количество записей в результате и их диапазон?
Это касается только журналов или вообще любых списков?
Оставьте свое сообщение