0. Филин 112 19.07.19 16:54 Сейчас в теме

Неочевидные проблемы производительности: важность системного подхода при анализе

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

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

Комментарии
Избранное Подписка Сортировка: Древо
1. capitan 1245 19.07.19 17:51 Сейчас в теме
Надеюсь что не скоро достигну предела DDR3 SDRAM )
А так все логично- Порядок бьёт класс
Отличное подтверждение этой фразы.
Если писать код изначально хорошо, можно на многие грабли и не наступать
Интересно что при поиске англоязычного эквивалента Порядок бьёт класс выводится
Football is a simple game; 22 men chase a ball for 90 minutes and at the end, the Germans win.
)
2. Repich 290 19.07.19 22:13 Сейчас в теме
Странно, мне даже в голову не приходило оптимизировать запрос увеличением железа не посмотрев сначала на код.
Fox-trot; +1 Ответить
8. Филин 112 22.07.19 10:21 Сейчас в теме
(2) Ну я и не говорил, что заливать проблему железом -- правильный путь.

Да и вообще смысл этого случая -- не показать, как ловко можно оперативкой ускорить плохой запрос, а наоборот, продемонстрировать предел такой "оптимизации"
A_Max; gallam99; +2 Ответить
3. acanta 64 19.07.19 23:21 Сейчас в теме
Добавление памяти решает проблему объединения доработанных конфигураций.
Если около часа идёт только сравнение метаданных, а тестирование базы проходит за 20-25 минут, то какие могут быть претензии к СУБД ? Это даже близко не хайлоад.
Только неумение дорабатывать конфигурации вероятно.
Конфигурации с расширениями надеюсь менее требовательны к железу.
4. YPermitin 3928 20.07.19 12:32 Сейчас в теме
(0) Отличный доклад и статья. +
5. Dach 275 20.07.19 16:57 Сейчас в теме
Прошу прояснить и уточнить терминологию в статье:

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


Простите, но очень неоднозначная и неаккуратная фраза. Что это значит? Перед какой такой "любой" записью? Речь об управляемых блокировках 1С? Или о транзакционных СУБД? НаборЗаписейРС.Записать() - какая тут нужна блокировка "перед записью" по Вашему?

Еще, в том же духе:

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


Что значит "не закрыл"? Как надо "закрывать"? О чем речь? Надо ли "закрывать", если у документа свойство "Удаление движений = удалять автоматически при отмене проведения"? Вот честно, с 1С уже много лет работаю, ни разу никакую отмену проведения дополнительными блокировками "закрывать" не приходилось.

Я то смысл понял на самом деле и звучит он так:

1 документ при удалении движений в ходе перепроведения наложил исключительную транзакционную блокировку СУБД на большой пул строк в таблице. Блокировка эта держится до конца транзакции, разумеется.

2 документ запросом в обработке проведения анализирует какие-то данные, перед чтением ставит управляемую блокировку 1С (которая тоже держится до конца транзакции конечно же), что-то вычисляет, пытается записать полученные данные в ту же саму таблицу БД, которую держит документ 1. Натыкается на транзакционную X блокировку. Включается тайм-аут СУБД для документа 2.

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

Ну и дальше - какой из тайм-аутов первый истечет - та сессия и отвалится.

Ну и насчет неочевидности.

Вот прекрасная статья: https://infostart.ru/public/202199/

Автор - издатель известного курса по оптимизации производительности.

Так что про "закрывать" непонятно.
7. Филин 112 22.07.19 10:19 Сейчас в теме
(5)
Прошу прояснить и уточнить терминологию в статье:


Ок, по пунктам:

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

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

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

НаборЗаписейРС.Записать() - какая тут нужна блокировка "перед записью" по Вашему?
-- тут нужна управляемая блокировка. Если код выполняется в платформе 8.3, платформа сама поставит эту блокировку (что не означает, что блокировка "не нужна"). Если, как в примере из доклада, мы говорим о старой конфигурации на старой платформе, управляемую блокировку поставить не получится.
К слову, транзакционная блокировка СУБД тут, конечно, тоже нужна, но она сама появится непосредственно при выполнении записи.

Надо ли закрывать если у документа свойство <...>
--см. выше, закрывать не надо, но помнить, про то, что управляемая блокировка есть, необходимо.

ни разу никакую отмену проведения дополнительными блокировками "закрывать" не приходилось
-- я тоже видел такие ситуации от силы пару раз. Именно поэтому доклад называется "неочевидные проблемы" и именно поэтому хотелось рассказать о любопытном случае, чтобы коллеги потом меньше ломали голову.
6. PerlAmutor 45 20.07.19 18:34 Сейчас в теме
Сколько не расследовал причин тормозов и долгого выполнения чего-то - в большинстве случаев виновником был 1С (платформа, кривой код программистов 1С). Памяти не хватало по причине утечек памяти из-за цикличных ссылок в той же БСП, в самой платформе. В раздутых метаданных ролей. Дорогущий сервер - постоянно "холодный", а работа идет со скрипом.

Кстати сам SQL сервер от Microsoft тоже сюрпризы приподносит. Простая ситуация - в базе одна... база. Есть процедура использующая CTE и временные таблицы. Из таблицы в 1 млн строк - создает таблицу на 30 млн строк. Ограничение по памяти выставлено в 30Гб. Первый запуск процедуры выполняется 30 минут и заполняет память до 25Гб. Второй запуск процедуры (после удаления всего что она нагенерила) - 5 часов. Память SQL сервером не освобождается. Если после каждого запуска процедуры перезапускать SQL сервер, то процедура всегда выполняется за 30 минут (чистка процедурного кэша, обновление статистики не помогает, добавление индексов к таблице усугубляет ситуацию еще больше)...

Был один случай недавно. Пользователи Windows XP жаловались на долгий запуск 1С, который долгим стал после перехода на новую платформу. Первая мысль - если XP, значит мало ресурсов, значит слабые компьютеры, надо модернизировать. Вторая мысль - но раньше у них проблем ведь не было?

Причина оказалось в том, что админы порезали прохождение пакетов протокола SMB1 (netbios), чтобы предотвратить распространение вируса типа WannaCry. А ходить пакеты перестали именно в ту подсеть, где располагался новый сервер под новую платформу. В XP в этом случае идет 2-х минутная задержка, после чего идет использование другого протокола (более защищенного). Выяснилось все это только с помощью настроенного ТЖ на стороне клиента. С другими программами на той же машине таких проблем нет. Стало быть дело в механизме создания защищенного соединения на стороне 1С.
user890287; +1 Ответить
9. Филин 112 22.07.19 10:27 Сейчас в теме
(6) Мой опыт как минимум 6 последних лет работы в Софтпоинт с обращениями заказчиков говорит о том, что проблемы могут быть где угодно -- и на 1С, и на СУБД, и на уровне железа... И ваш последний пример отлично это иллюстрирует (и, кстати, ложится в тему статьи). Действительно, первая реакция в таком случае -- это обвинить во всех проблемах обновленную платформу. Хотя более глубокая причина лежит в другой плоскости, в настройках сети.
10. PerlAmutor 45 22.07.19 18:48 Сейчас в теме
(9) Только это не проблема сети, а то как ведет себя 1С при таких настройках, с другим софтом проблем нет.
Вот еще один пример - есть виртуалка на Hyper-V, в момент снятия бэкапа средствами Volume Shadow Copy возникают проблемы с таймаутом на драйвере диска. При этом менеджер кластера - зависает совсем не надолго. Агент кластера видит, что завис менеджер кластера и его.... убивает. При этом 1С не предоставляет никаких настроек для увеличения времени ожидания отклика менеджера и т.д. Другой софт реагирует адекватно, ничего не падает и не завершается.
11. YanSergey 23.07.19 16:56 Сейчас в теме
(10)
При этом 1С не предоставляет никаких настроек для увеличения времени ожидания отклика менеджера и т.д



Есть настройки запуска службы агента, которые вероятно Вам помогут, посмотрите

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

/pingPeriod <время> /pingTimeout <время>
12. PerlAmutor 45 23.07.19 22:20 Сейчас в теме
(11) Эта настройка работает только для рабочих процессов, агент сервера (ragent) не пытается пинговать менеджер клстера (rmngr), а просто его убивает, если тот решил "подвиснуть" на пару секунд. Настройка pingTimeout уже давно стоит и суммарное время там больше минуты. Не действует она на менеджер, хоть тресни.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Екатеринбург
зарплата от 120 000 руб. до 120 000 руб.
Полный день

Бизнес-аналитик 1С
Москва
зарплата от 140 000 руб. до 200 000 руб.
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день