Зарегистрируйтесь без указания e-mail всего за 1 минуту! Скорее нажмите сюда!
Amor Ex Machina? Maybe.
 

Ко всем записям блога

Хозяин дневника: Позывной Leshy  

Дата создания поста: 16 апреля, 21:15

Я в нипонятках

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

Всего дисконтных карт (живых и мертвых) у нас порядка 850 тысяч. Код штатного процесса писали знатные извращенцы (одного знаю лично), у меня мозги раком встают. Я пока во все это вникал, параллельно искал пути, как этого тормоза оптимизировать. И в итоге решил кое-что проверить и наваял на T-SQL (язык запросов непосредственно в самой базе данных) небольшой скриптик, который должен мне был все это посчитать с точки зрения здравого смысла, и без кучи реверансов, которые были в коде самого Navision (основная система). Отладил запрос, запустил.

Время работы — 4 секунды. 125 тысяч "живых" (т.е. тех, по которым были продажи в течении последних 12 месяцев) карт обработано. Проверка подтверждает, что мои результаты тютелька в тютельку бьются с теми, что были рассчитаны существующим процессом.

4 секунды!!!!
Не 6 часов.
Не 4 часа.
Не 40 минут.
И даже не 4 минуты!
4, СУКА, СЕКУНДЫ!

Я, реально, в непонятках. Так не бывает.


Отредактировано: 16 Апр 2025, 21:16.

Комментарии:

udagan  
Как может быть куча реверансов на 6 часов
Куда там постоянно шло обращение?)))
Позывной Leshy  
udagan,
было подозрение, что там какая-то времянка пухнет, к которой обращение не оптимизировано. Пока она маленькая это незаметно, но когда она разрастается, то система может начать тупить.
Что до "обращений", то для каждой дисконтной карты читаются десятки (а иногда и сотни) записей из нескольких таблиц, по этому общее количество курсорных фетчей в БД может достигать 75 миллионов. С учетом замороченной логики процесса вот время и набегает такое.
udagan  
достигать 75 миллионов
достигать 75 миллионов...
Позывной Leshy  
udagan,
ну да, 75 миллионов фетчей. А что Вас смущает?

База размером под терабайт. Одних заголовков чеков почти 9 лямов. Так что ничего удивительного.
udagan  
А меня всегда смущают большие объемы
Хоть я и работаю в них..

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

(кнопку "ВХОД" в правом верхнем углу страницы хорошо видно? :)

Попасть в "15 мин. Славы" ⇩