0. Kaval88 70 27.06.18 18:35 Сейчас в теме

Улучшаем производительность 1С. Рекомендации

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

Перейти к публикации

Лучшие комментарии
26. starik-2005 2021 15.02.20 12:49 Сейчас в теме
А я вот не совсем понял, с чего столько критики? Чел совершенно верно говорит о том, что нужно сократить ожидания пользователей, которые работают одновременно, а для этого надо перевести мелкософтовский скул в режим работы версиоионника, максимально сократить вероятность эскалации блокировок и стараться, чтобы эскалации не было в будущем, ну и максимально обслуживать итоги, чтобы они были чистенькими и опрятненькими. Ну и железяги в режим высокой производительности и, как говорят геймеры, ТДП процессора перевести в сторону увеличения (включить турбобуст, ну и водянку поставить, чтобы троттлинга не было, и проц не снижал частоту сам по себе - это и к серверным процессорам относится, если кто не в курсе).

Так что статья - самое то.
Dnki; Kaval88; +2 Ответить
Остальные комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Sapiens_bru 1 23.01.20 21:09 Сейчас в теме
На один нормальный пост о повышении технологического качества работы информационной системы приходится десять вот таких. С призывом постучать в разные бубны.

Зачем мониторить оборудование, определять ключевые операции, собирать ТЖ и смотреть в dmv sql сервера. Зачем настраивать сервера 1С и SQL по официальным гайдам фирмы 1С. Зачем искать узкие места, переписывать плохой код. Вот это вот всё.
Можно же просто брать случайные скрипты с Инфостарта и наугад применять.
life-wayfarer; capitan; Redokov; DarkAn; Dach; Kent_killer; ZOMI; kolya_tlt; mirco; t278; sapervodichka; coolseo; BigB; +13 2 Ответить
2. Kaval88 70 23.01.20 22:00 Сейчас в теме
(1)Все правильно, но не для этой статьи. Статья представляет собой базу, которую приходилось применять на практике в самом начале анализа проблем производительности. Далее, обычно, проводится более детальный анализ.
20. capitan 1504 24.01.20 11:07 Сейчас в теме
(2)
Статья представляет собой базу, которую приходилось применять на практике в самом начале анализа проблем производительности.

Великая и могучая русская языка)
На самом деле надо сначала настроить сервер и базы по методике ИТС, на этом этапе база у вас небольшая и эти рекомендации закроют все вопросы производительности на 100% потому, что они как раз must have, потом проводить детальный анализ, а потом точечно пробовать повышать производительность танцами с бубном, замеряя каждый раз результаты
18. capitan 1504 24.01.20 11:01 Сейчас в теме
(1)Тот случай, когда комментарий наберет больше плюсов, чем публикация)
25. capitan 1504 24.01.20 12:11 Сейчас в теме
(1)Обычно мальчики в коротких штаншках так делают - получили минус и пошли минусовать всех кто поставил минус )
Мне интересно, вроде как модераторы как раз говорили, что такого не должно быть, чтобы йуные писатели вели себя спокойнее.
Эта статья и стиль общения автора - это лучший пример как не надо делать.
Некоторые стати нужны как раз для этого.
Не надо так оптимизировать производительность и не надо так себя вести.
3. sapervodichka 3031 24.01.20 02:24 Сейчас в теме
Есть реальный пример внедрения архивных регистров?
4. stepan_s 24.01.20 05:30 Сейчас в теме
(3) по поводу архивных регистров склонен согласится :)
Использую несколько таких реализаций.
Самый яркий пример "История изменений" сделан еще до типовой реализации на регистрах сведений.
Все записи Старше недели сбрасываются в подобный, но архивный регистр сведений.
За счет этого нет проблемы с записью в регистры,
так же запросы как правило по истории строятся по оперативному регистру, т.к. как правило надо понять кто и что сделал недавно, и чем дальше от сегодняшнего дня - тем реже надо знать кто и что наделал :)

Но это про регистры сведений, можно рассмотреть оборотные регистры....
Думаю к агрегирующим регистрам применять опасно :)
5. kolya_tlt 20 24.01.20 08:31 Сейчас в теме
(3)
Есть реальный пример внедрения архивных регистров?

есть пример когда тупо начали жить в новой базе с 01 января на той же конфигурации, перенеся остатки
6. Kaval88 70 24.01.20 09:00 Сейчас в теме
(3) Перенос регистров расчета + регистра Графика работы по видам времени для ЗУП 2.5. Вообще в каждой конфигурации есть проблемные регистры, которые периодически необходимо переносить в архив.
7. sapervodichka 3031 24.01.20 09:05 Сейчас в теме
(6) можете дать примеры регистров в новых конфигурациях на управляемых формах (не ЗУП 2.5, не КА 1, не УПП 1.3, не УТ 10 и т.п.) и главное каким образом переносить в архив?
Вообще для новых конфигураций ваши рекомендации состоятельны или это все для старых релизов 1С на обычных формах?
8. Kaval88 70 24.01.20 09:09 Сейчас в теме
(7) Абсолютно для всех конфигураций. Предлагаю вывести способы получения таких регистров и последующий их перенос в архив в отдельную статью.
9. sapervodichka 3031 24.01.20 09:17 Сейчас в теме
10. Kaval88 70 24.01.20 09:19 Сейчас в теме
(9) Как будет время, думаю на выходных начну.
11. sapervodichka 3031 24.01.20 09:22 Сейчас в теме
(10) вы понимаете, что описанные умозаключения маловероятно применимы на практике, без будущей статьи с примерами и подробным описанием указанных процессов (я про "Большие таблицы")?
Kent_killer; +1 Ответить
12. Kaval88 70 24.01.20 09:30 Сейчас в теме
(11)Это только зависит от квалификации разработчика, я лишь предложил идею, которая успешно показала себя на практике.
13. Dach 293 24.01.20 09:57 Сейчас в теме
Включаем на сервере СУБД уровни изоляции транзакций ALLOW_SNAPSHOT_ISOLATION и READ_COMMITTED_SNAPSHOT


Для включения "версионника" достаточно включить READ_COMMITTED_SNAPSHOT[

При одновременном включении этих двух флагов, RCSI будет работать как более приоритетный (я тестировал).

Отличия этих двух режимов работы можно легко нагуглить:

https://www.sql.ru/forum/779484/allow-snapshot-isolation-vs-read-committed-snapshot

https://habr.com/ru/post/305600/

SNI : "чистые" данные при выполнении запроса внутри транзакции возвращаются на момент старта самой транзакции
RCSI: "чистые" данные при выполнении запроса внутри транзакции возвращаются на момент выполнения самого запроса

Рекомендация включать оба флага идет давно, кто-то один написал, все повторили и у всех в головах укоренилось.
Кстати, если с нуля развернуть новую БД на 8.3, то там изначально будет включен только один флаг: RCSI, что лишний раз подтверждает верность моих слов.

https://hkar.ru/10Sr0
sapervodichka; +1 Ответить
14. capitan 1504 24.01.20 10:12 Сейчас в теме
Вспоминается ...
Приходит мужик к доктору, жалуется: "Доктор не могу, все болит. Суда
пальцем ткну - больно, сюда пальцем ткну - больно, сюда пальцем ткну -
больно".
Доктор: "Э батенька, да у вас палец сломан".

Рекомендации которые должны быть просто must have по определению находятся на ИТС
Как и регулярная свертка и очистка базы, это понятно даже на примере ночного горшка
Остальные рекомендации я бы продавал в режиме реальных результатов нагрузочного тестирования.
Было столько то - стало столько то
А иначе это не must have, а опрос населения методом тыка
15. user774630 24.01.20 10:35 Сейчас в теме
(14) как часто вы выполняете "свертку" баз. Каких?
17. capitan 1504 24.01.20 10:59 Сейчас в теме
(15)УТ раз в два года
А чищу раз в месяц, часть регистров раз в неделю чистится регламентно
В принципе если знать и соблюдать методики от 1С то скорость работы базы не должна линейно зависеть от количества документов
23. user774630 24.01.20 12:07 Сейчас в теме
(17)
скорость работы базы не должна линейно зависеть от количества документов

Я поэтому и спросил, что с учетом наличия итогов в регистрах необходимость свертки не очень понятна...
24. capitan 1504 24.01.20 12:08 Сейчас в теме
(23)Свертка есть свертка ,ее никто не отменял
16. DarkAn 927 24.01.20 10:49 Сейчас в теме
Можно вопрос автору? Большие таблицы это сколько записей ???

п1. Если у Вас проблема с большой таблицей - значит у Вас проблема с архитектурой, с индексами, с запросами, ну на крайний случай с железом.
п2. Если У вас нет выше указанных проблем - смотри п1.
19. Kaval88 70 24.01.20 11:04 Сейчас в теме
(16) Для каждой инфраструктуры большие таблицы свои. Для одной инфраструктуры большой таблицей будет считаться 1 млн. записей, для другой 1 триллиард и т.д.. Что по вашему мнению проще переписать типовую архитектуру или перенести часть неиспользуемых данных в архив?
21. DarkAn 927 24.01.20 11:37 Сейчас в теме
(19)
1 триллиард

Это сколько? Такого числа нет :)

(19)
о по вашему мнению проще переписать типовую архитектуру или перенести часть неиспользуемых


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

Поэтому если у Вас проблема в архитектуре, и при этом таблицы достигают размеров 1 триллион записей - это однозначно требует исправления.

Обычно большие таблицы при правильных индексах и запросах проблем не вызывают (если на сервере SQL выполняются регламентные задания, о которых Вы в данной статья ни слова не написали)
22. Kaval88 70 24.01.20 11:41 Сейчас в теме
(21) Спасибо за мнение, но зачем переписывать запросы для использования ненужных данных? Они же перенесены в архив, про них забыли.
26. starik-2005 2021 15.02.20 12:49 Сейчас в теме
А я вот не совсем понял, с чего столько критики? Чел совершенно верно говорит о том, что нужно сократить ожидания пользователей, которые работают одновременно, а для этого надо перевести мелкософтовский скул в режим работы версиоионника, максимально сократить вероятность эскалации блокировок и стараться, чтобы эскалации не было в будущем, ну и максимально обслуживать итоги, чтобы они были чистенькими и опрятненькими. Ну и железяги в режим высокой производительности и, как говорят геймеры, ТДП процессора перевести в сторону увеличения (включить турбобуст, ну и водянку поставить, чтобы троттлинга не было, и проц не снижал частоту сам по себе - это и к серверным процессорам относится, если кто не в курсе).

Так что статья - самое то.
Dnki; Kaval88; +2 Ответить
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Специалист внедрения и сопровождения 1С
Москва
зарплата от 80 000 руб.
Полный день

Product Owner (Менеджер по продукту 1С)
Москва
зарплата от 100 000 руб. до 170 000 руб.
Полный день

Тим лид по разработке 1С (Team Lead 1С)
Москва
зарплата от 100 000 руб. до 200 000 руб.
Полный день

Программист, аналитик, эксперт 1С
Санкт-Петербург
По совместительству