Оптимизируй это! Или MS SQL и Экспертный подход творят чудеса!

Публикация № 635161

Администрирование - Производительность и оптимизация (HighLoad)

В статье речь пойдет про взаимодействие сервера 1С с MS SQL. Мы очень часто слышим, как важно оптимизировать все критические участки системы заблаговременно, в плановом режиме, как надо, «от и до» во всех деталях. Но в реальной жизни бывает по-другому. Очень часто клиенты обращаются к нам, когда система уже не дает работать: «спасите, помогите, болит очень сильно, надо решать». Об одном из таких случаев я и хотел бы вам сегодня рассказать.

Рассматриваемая ситуация

Подробнее о ситуации:

  • Заказчик занимается микрофинансовой деятельностью – у них большая сеть.
  • Очень много пользователей, работающих в online (в пике доходит до 1000 человек). Нагрузка на базу достаточно серьезная.
  • По факту база должна работать стабильно практически 24/7. Регламентное время есть (не 24 часа полной работы базы), но оно очень маленькое, в пределах 4 часов, и желательно не каждый день. За это время нужно успеть произвести с базой все регламентные операции.
  • Но, по сути, у заказчика все успешно работало.

И к нам они обратились в таком формате: «У нас все было отлично, но вдруг начали возникать проблемы, причем значительные».

Начали разбираться. С чем столкнулись?

  • В их оперативной базе использовался регистр накопления, где было более миллиарда записей – это был такой «собирательный образ», с которым работало очень много пользователей. Возвращаясь к докладу Андрея Бурмистрова, хочу сказать, что в этом регистре было включено разделение итогов, и когда мы в нем измеряли количество записей итогов, их было 1.2 миллиарда. Это вообще «жесть». Но проблема была скорее не в количестве записей этого регистра, сколько в том, что большая часть запросов выполнялась именно к нему.
  • Работали с этим регистром, по факту, три группы пользователей:
    • Первая группа пользователей – это, так скажем, группа пострадавших, их работа заключалась в заведении договоров на эти микрофинансовые займы. Сами они создавали минимальную нагрузку на систему, но когда из базы формировались какие-то сложные выгрузки, они ничего не могли делать, у них работа просто вставала.
    • Вторая группа пользователей – это аналитики, основные зачинщики проблем. Они создавали на базу достаточно большую нагрузку, потому что делали оперативные отчеты, которые формировались по 3-5 минут. В течение этого времени с базой вообще никто не мог работать, а аналитикам эти отчеты были нужны достаточно часто.
    • Третья группа пользователей – это группа коллекторов. Они делали еще более дикие выборки, общее время формирования которых доходило до получаса. Но им оперативные данные были не нужны, и в этом была принципиальная разница между второй и третьей группой, поэтому мы с ними работали очень по-разному.
  • И тут начинается интересное. Дело в том, что в этом регистре очень много записей (по факту, примерно 40%) находилось в будущем. Помните слова Андрея, который говорил о том, что какие-то случайные записи «из будущего» могут сломать работу системы? У нас в будущем была просто тонна записей, и это не было случайностью, это было, по факту, осознанным самостоятельным решением заказчика. Они, таким образом, решали вполне конкретную проблему. Дело в том, что ранее для сведения взаиморасчетов они ежемесячно делали один регламент, в рамках которого рассчитывали все взаиморасчеты по всем имеющимся договорам. Поначалу все было хорошо, но с определенного  момента они увидели, что не укладываются в регламентное время, и решили сделать по-другому – не тратить операционное время на заведение регламента, а заблаговременно рассчитывать весь график платежей, чтобы понимать на будущее вперед, какие суммы задолженности возникнут к определенному моменту. Поначалу с этим тоже все было хорошо, пока они не рассчитали все договора, которые были заведены когда-то в прошлом, после чего у них в базе сформировался такой объем записей, что все начало «ложиться» и начались серьезнейшие проблемы.
  • Тут еще важно отметить и тот факт, что итоги были включены, но не рассчитаны.
  • И регламенты по обновлению статистики MS SQL тоже были настроены, но за ночь они выполниться не успевали.

Как поступает сервер 1С в случае, когда регламент MS SQL не успевает сделаться в нужное время? Как вообще работает сервер, когда у вас столько записей в будущем? Например, если вы захотите взять данные на сегодня (сегодня у нас 26 октября), а у вас последние ежемесячные итоги рассчитаны на конец сентября, тогда сервер будет всегда пытаться брать текущие итоги. Но если в обычной деятельности текущие итоги – это конец октября (что-то близкое к текущей дате), то в их случае это было сильно далеко впереди. К тому же текущие итоги, по сути, всегда берутся на конец эпохи, на 3099 год. И в данном случае, если бы даже у нас ежемесячные итоги бы рассчитаны на конец сентября, сервер все равно бы лез максимально вперед в будущее, где находятся самые последние записи. И потом такой вот лавиной цунами выкручивал бы оттуда дикие обороты полностью всего до текущей даты. Это собственно и происходило. Но даже если бы у них не было записей в будущем, то из-за того, что ежемесячные итоги у них были два с половиной года назад, а работали они чаще всего с текущими датами, они бы все равно никакого профита не получили – не смогли бы просто. А тут еще и такая ситуация наложилась.

Принятые решения по оптимизации

Конечно, ситуация печальная, но что с ней делать-то?

Закономерным решением было:

  • Рассчитать ежемесячные итоги. Конечно, их нужно рассчитать не все сразу, а последовательно, потому что этот процесс занимает много времени, а регламентное окно узкое.
  • И, конечно же, надо было полностью снести текущие итоги – прямо снести и отключить. Почему? Причины две. Помимо того, что они там создают паразитическую нагрузку, они же еще и постоянно плодятся – пока они включены на регистре, эти паразитические записи будут постоянно появляться. А если еще и сервер 1С будет брать всегда именно их, то от них очевидно, надо избавляться.
  • Ну и все-таки надо обновить статистику.

 

 

Но все это не просто. Я бы даже сказал, что это очень непросто, потому что если использовать стандартный подход, который исповедует 1С, то у нас бы все это заняло около 13 часов. Что бы при этом происходило?

  • При стандартном отключении текущих итогов на регистре из него последовательно начали бы удаляться записи. Построчно. А вы представляете, сколько там записей  – там 1.2 миллиарда. Даже на мегамощностях заказчика на это ушло бы 13 часов. Мы предложили заказчику: «давайте отключим это по всем канонам 1С». Они говорят: «нет, нам такой вариант не подходит, давайте что-то думать дальше».
  • И кстати, про интерфейсные настройки MS SQL – в сервере MS SQL нет никакой такой интерфейсной настройки, которая бы позволяла обновлять какие-то таблицы выборочно. А полное обновление статистики происходит целиком по всему и занимает достаточно большое время. Соответственно, просто запуск регламента еще не означает, что он будет успевать проходить.

В результате, мы приняли решение просто снести таблицу итогов и напрямую сделали truncate table из MS SQL. Сразу оговорюсь, что трюк был выполнен профессиональными каскадерами, в домашних условиях не повторять. Тем более что 1С не просто так запрещает прямые запросы к базам данных. Почему? Потому что текущие итоги и обычные ежемесячные итоги – это одна и та же таблица. И когда мы ее снесли, снеслись также и ежемесячные итоги. А 1С помнит, что там были итоги, рассчитанные два с половиной года назад. И она пытается к ним обратиться, а база ей отвечает: «какие итоги? тут ничего нет». И все, коллапс. Такие случаи надо предусматривать.

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

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

После этого нагрузка на базу в целом резко уменьшилась, и если изначально запросы выполнялись по 3.5-5 минут, они стали отрабатывать гораздо быстрее, чаще всего секунд за 15.

«Подводные камни»

Но все равно остались и аномальные случаи, когда база на небольших запросах «подвисала» очень долго.

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

Казалось бы, наконец, все заработало: запросы начали выполняться быстро, оперативная работа пошла, и заказчик вздохнул с облегчением.

Но не тут-то было. Приходит начало месяца и у заказчика опять все «ложится». Там была печаль печальная.

Обычно при обращении к оперативным объектам в базе – открываешь, одна секунда, и ты уже все получил. А тут они начали открываться по 16, по 25, а некоторые еще и больше секунд. Откуда такая аномалия – непонятно. Заказчик говорит: «Вы нам сказали рассчитывать итоги и обновлять статистику – мы все делаем. Вот вам план запроса, только решите проблему, потому что у нас начался сезон, и мы однозначно не можем тратить на это время. У вас есть полчаса, час, давайте, что-то решайте».

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

Но возник закономерный и интересный вопрос – а как так получилось? Откуда в базу закралась такая барабашка? Почему так себя ведет планировщик? Что такое вообще обновление статистики для планировщика?

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

Как планировщик работает?

  • Пока вы статистику не обновили, он видит, что есть итоги на конец сентября, и у него указано, какой там индекс, он знает, что раз таблица огромная, искать надо в индексе. Он находит какую-то запись, выбирает из нее все связанные подзапросы, получает данные, и никаких проблем нет.
  • А тут происходит расчет итогов, который добавляет в таблицу сколько-то записей, о которых планировщик и понятия не имеет. И он начинает просто как слепой шариться по этой таблице, и искать, а где там нужные ему записи?
  • А когда ты статистику обновляешь, планировщик прозрел, увидел, что все понятно, вот он, индекс, можно делать поиск по индексу и сканировать всю таблицу ему уже не надо. Он нашел нужную запись и ее отдал.

Когда таблица 10 тысяч записей – это может быть не критично. А когда в таблице сотни миллионов записей и итогов за один месяц там очень много, тогда это становится колоссально критично. Поэтому очень важно понять эту логику, как планировщик все это подтягивает. Ну и собственно, сервер 1С так же работает, потому что он тоже не особо напрягается, думая, как MS SQL сервер будет формировать эти выборки.

Инструменты для изучения проблем производительности

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

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

Например, консоль сервера. Этим инструментом очень часто пренебрегают, а ведь по факту он дает ответ на многие вопросы. В нем можно посмотреть какой сеанс, какую нагрузку создает, где какие аномалии. Где у тебя длительный запрос к базе данных, а где у тебя уже длительный ответ от сервера 1С, где математика, а где диски – и дальше уже в эту сторону анализировать. Более того, в консоли сервера можно «отрубить» сеанс, который создает аномальную нагрузку, сохранив тем самым работоспособность базы. Убили сеанс, сохранили работоспособность, а потом занимаемся анализом, потому что бывает, что базу нельзя просто так рестартовать.

И здесь важно еще вот о чем сказать. Убивать сеансы – это замечательная возможность, но если вы этим сеансом проводили какой-то длительный регламент типа расчета себестоимости выпуска, восстановления последовательности партионного учета или что-то еще в этом духе, то вам придется все начинать заново, потому что никакой результат не сохранится – это очень важно иметь в виду. Потому что вся операция расчета себестоимости может длиться 8.5 часов, а если она длилась 8 ч, и вы решили ее прервать, чтобы дать работать пользователям, то вам придется все начинать заново. А надо было всего-то подождать полчаса и все.

Следующий очень важный инструмент – технологический журнал 1С. Он вроде бы тривиальный, но, тем не менее, помогает решать огромное количество вопросов. Здесь на экране показана настройка – тут максимум 15 строчек кода. С помощью этой настройки вы можете вывести все события выполнения запроса, которые длились более 10 секунд, тем самым, сразу отсечь все то, что неинтересно, и проанализировать только длительные запросы. И дальше уже, если будет нужно, погрузиться в их какой-то более детальный анализ.

И еще один инструмент – это SQL Management Studio, тоже очень интересная вещь, особенно в контрасте того, что профайлер MS SQL надо настраивать, на это требуется время, а его иногда нет. А Management Studio – это достаточно простой инструмент, и более того, он включен в любую версию MS SQL (и в SQL Express в том числе – он там в комплекте не идет, но его можно установить, лицензия это позволяет делать). Пользоваться им достаточно удобно и легко.

Ну и конечно, если время позволяет, настраиваем профайлер MS SQL, чтобы он нам выдавал то, что мы хотим видеть, потому что многие ответы находятся только там. Тем более что в отличие от технологического журнала 1С, он позволяет увидеть все запросы – это, наверное, чуть ли не главное преимущество MS SQL. У технологического журнала 1С есть ограничение, что он позволяет увидеть только те запросы, которые были успешно выполнены – это одно из серьезных ограничений при анализе подобных аномалий для СУБД PostgreSQL. А профайлер MS SQL позволяет увидеть все запросы. Можно запустить запрос, тут же его отключить, получить полный план запроса и анализировать его дальше, что там вообще происходит. Это очень большое преимущество и важно правильно этим пользоваться.

Заключение

Весь наш опыт подсказывает, что все гениальное – просто, и что чудеса очень часто решаются достаточно простыми и тривиальными способами.

Еще раз подытожим наши выводы

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

Лично от себя хочу добавить, что, несмотря на то, что мы достаточно давно уже занимаемся оптимизацией (в сумме, наверное, больше двух лет), меня искренне удивляет тот факт, что при решении большинства проблем помогает просто расчет итогов и обновление статистики. Прямо серьезно. Мало кто этим озадачивается – либо просто забывают, либо что-то еще. Поэтому не забывайте, обращайте внимание, это крайне важно.

Пользуйтесь инструментами, будьте молодцами!

***************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие.

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. spezc 654 11.07.17 10:20 Сейчас в теме
Интересная подача материала)))) слог и картинки заслуживают звезду
Kinestetik; wowik; VladC#; DrAku1a; EliasShy; sansys; Gang031; inf012; METAL; gortol; rovenko.n; kare; +12 2 Ответить
2. genayo 11.07.17 11:05 Сейчас в теме
Кейс интересный, показывает, к каким последствиям может привести изначально неправильный выбор архитектуры приложения.
Kinestetik; VladC#; EliasShy; sansys; amoarok; Gang031; Nelli_A86; delete; inf012; gortol; echo77; Waanneek; +12 1 Ответить
3. корум 284 11.07.17 11:51 Сейчас в теме
(2) Случай интересный.

кейс из крокодиловой кожи :)
the1; Rego1337h; Dmitri93; +3 Ответить
5. genayo 11.07.17 12:02 Сейчас в теме
(3) Чемодан из крокодиловой кожи тогда уж.
4. Waanneek 84 11.07.17 12:00 Сейчас в теме
(2) Плюсанул! В начале статьи уже было понятно что надо архитектуру пересматривать. Либо распределенную базу делать, либо разносить проблемный регистр на несколько, чтобы данные на тек. момент и на будущий период брались из разных мест как вариант. Статистики и итоги до поры до времени будут спасать, но со временем база наберет критический объем и эти меры уже не помогут (не будут давать приемлемую скорость работы).

Думал речь пойдет о разделении на несколько баз с синхронизацией, те кто оперативно работают будут в основной базе, те у кого дикая нагрузка, но не оперативно - в отдельную базу с задержкой получения информации на Xч/мин. Это позволило бы реально снизить нагрузку на оперативную базу.
Rego1337h; +1 Ответить
25. Sergey.Noskov 1144 13.07.17 15:44 Сейчас в теме
(4)
Статистики и итоги до поры до времени будут спасать, но со временем база наберет критический объем и эти меры уже не помогут
почему?
Особых проблем не вижу, итоги рассчитываются, запрос всегда строится к таблице итогов за месяц и union по таблице движений (максимум за месяц).
6. brr 179 11.07.17 12:39 Сейчас в теме
7. Vovan1975 13 11.07.17 12:51 Сейчас в теме
А можно по подробнее рассказать почему решили отключить текущие итоги?
8. asved.ru 35 11.07.17 13:12 Сейчас в теме
(7) Они не нужны, т.к. точка актуальности в далеком будущем и остатки берутся почти всегда задним числом.
10. корум 284 11.07.17 15:04 Сейчас в теме
(8) "как быстро починить чтобы пореже падало".

Надёжней исключить работу будущей датой, и держать точку актуальности текущим днём.

Кто мешал сделать нормальный регистр планирования с датой в измерении?...
9. asved.ru 35 11.07.17 13:25 Сейчас в теме
На счет "MS SQL не имеет гибких интерфейсных настроек для обновления статистики" - чушь полная, бред сивого DBA.
В целом статья технологически инфантильная, даже объяснение природы проблемы на уровне планировщика - детский сад, штаны на лямках. Ничего он там не ищет, а принимает решение о выборе того или иного оператора плана, основываясь на неверных данных. Например, считает, что в одной из сторон джойна строк мало, и ставит nested loops, который действительно выгоден в таких условиях, но очень печален, когда число строк растет.

Единственная зрелая мысль во всей статье - порядок использования итогов. Однако даже это решение неверно, т.к. с дальнейшим ростом объемов данных работать перестанет.
Здесь необходима переработка архитектуры хранения данных в целом.
ZOMI; aKomper; zarucheisky; Dem1urg; Dach; gortol; FarhadIlyazov; GreenDragon; +8 Ответить
11. Kopman 20 12.07.17 04:54 Сейчас в теме
Статья в 4 словах:
Мы настроили регламент MSSQL.
Kinestetik; ZOMI; manlak; Dem1urg; корум; rovenko.n; +6 Ответить
13. echo77 1156 12.07.17 07:58 Сейчас в теме
(11) Не только, здесь и очистка таблицы текущих итогов и расчет итогов по месяцам и наведение порядка во внешних отчетах
12. AlexeyFreeLife 12.07.17 07:41 Сейчас в теме
вопрос не по теме: зачем столько картинок ? после пролистывания статьи не читая текст уже подустал.
ZOMI; KAV2; perpleks; +3 Ответить
15. echo77 1156 12.07.17 08:08 Сейчас в теме
(12) Не соглашусь, картинки разбавляют текст, его становится легче читать. То что листать приходится дольше - это да :-)
Kinestetik; Gang031; Artem-B; inf012; Rego1337h; gortol; rovenko.n; +7 Ответить
14. echo77 1156 12.07.17 08:06 Сейчас в теме
(0) Опечатку на слайде поправьте http://infostart.ru/upload/iblock/09b/09b70ceaa97acb6f38273c481f638e72.jpg
Маленькие замечания:
максимальная дата в 1С - 3999 год
неплохо бы сразу в статье сказать, что регистр накопления остатков
на сколько оправдано разделение итогов в этом регистре?
странно, что "профессиональные каскадеры" не вспомнили про то, что текущие итоги и обычные ежемесячные итоги – это одна и та же таблица.
16. manlak 77 12.07.17 10:13 Сейчас в теме
За статью плюс, понравилось!
Только небольшое замечание, а нельзя было вместо "скриншотов" обновления статистики и текста тех.журнала, код выставлять по человечески, который можно было б скопировать в буфер обмена? )
Gang031; mytg; Rego1337h; 1Concept; perpleks; +5 Ответить
17. starik-2005 2176 12.07.17 11:18 Сейчас в теме
(16)
код выставлять по человечески, который можно было б скопировать в буфер обмена
ИМХО, код вставлять без понимания его сути - это зло абсолютно неэкспертное. Любой копипаст - это риск, что:
1. То, что кописастишь - полная хрень (как в данном случае);
2. То, что копипастишь, сложно изменить;
3. То, что копипастишь, сложно понять.
18. aKomper 12.07.17 15:57 Сейчас в теме
19. Herby 12.07.17 16:15 Сейчас в теме
статья про типичную русскую проблему - сначала делаем, а потом думаем.

весь ваш огромный двухгодичный опыт в области оптимизации тратится на борьбу со следствием. бесполезное это дело.

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

отчеты для вашей третьей группы пользователей перенести в BI.
отчеты для второй группы перенести в копию базы, размещенной на другом сервере (на дворе 21 век и решений по репликации БД достаточно много).

в итоге нагрузка упадет в сотни раз.

иначе так и будете упираться в пробки.
20. starik-2005 2176 12.07.17 17:05 Сейчас в теме
(19)
отчеты для второй группы перенести в копию базы, размещенной на другом сервере...
в итоге нагрузка упадет

Даже если на одном сервере - и то упадет.
21. teller 13.07.17 06:46 Сейчас в теме
статья о том как администраторы субд решали проблемы проектировщиков :)
вот так и оттачивается мастерство
22. iliabvf 13.07.17 09:25 Сейчас в теме
Гениальная подача материала! Дизайн заказывали у школьников?
24. rozer 268 13.07.17 11:35 Сейчас в теме
(22) когда вышел фильм этот с Киану Ривзом вы были школьником а может и в д/с ходили еще ) норм статья но это оч частный случай про откл итогов - лучше архитектуру пересмотреть, да
23. ansh15 13.07.17 10:24 Сейчас в теме
Даже на мегамощностях заказчика на это ушло бы 13 часов

Можно про "мегамощности" более детально рассказать, если не секрет?
stroganov_ru; +1 Ответить
26. Yashazz 3260 14.07.17 12:04 Сейчас в теме
Один конкретный кейс, один из множества способов решения. Зато много картинок и потому много плюсов.

статья о том как администраторы субд решали проблемы проектировщиков :)

Воистину.

...надо мне в следующий раз полуголых женщин в публикацию напихать, авось модераторы пропустят. Тогда точно статья выйдет в топ)))
27. logarifm 1076 14.07.17 15:28 Сейчас в теме
поистину есть еще понятия кривых итогов - это некорректное закрытие регистров. Провисшие записи. Вот что точно паразит!!!

Надо сверять учет насколько велика вероятность записей

Товар Заполненая аналитика Движение приход
Товар пустая аналитика Движение расход

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

Статья зачетная. И нет придела совершенству в поисках производительности и самое главное нет одного эликсира или панацеи ... (ИМХО)
28. Fatov_DI 20.07.17 10:31 Сейчас в теме
Спасибо за статью! Мне оформление понравилось, по крайней мере читается легко....

В результате, мы приняли решение просто снести таблицу итогов и напрямую сделали truncate table из MS SQL.


Т.е. Вы грохнули таблицу итогов, потом запустили пересчет итогов? Сколько он длился по времени?
29. Gilev.Vyacheslav 1851 23.07.17 11:46 Сейчас в теме
всего то надо было не хранить миллиард строк в одной таблице, а не бороться с последствиями хранения
AlX0id; Kinestetik; ZOMI; Silenser; +4 Ответить
30. Red_Devil 159 10.08.17 10:31 Сейчас в теме
Все проблемы как всегда из-за коллекторов!!!
31. tiniji 154 10.08.17 14:28 Сейчас в теме
Хороший способ объяснить заказчику куда ушли его деньги. На написание презентации )

P.S. Думаю проф. уже эта информация известна давно. Ну а новички не поймут, что такое статистика и с чем его едят.
32. o.nikolaev 197 12.08.17 22:51 Сейчас в теме
Для тех кто сотрудничает с "микрофинансовыми" организациями, в аду отдельная сковородка. Каждый день +1000% от предыдущей температуры.
gimalaj; d4rkmesa; +2 1 Ответить
Оставьте свое сообщение

См. также

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    28739    0    MrWonder    42    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    1755    0    ivanov660    12    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

Обычно предметом оптимизации являются заранее определенные ключевые операции, т.е. действия, время выполнения которых значимо для пользователей. Причиной недостаточно быстрого выполнения ключевых операций может быть неоптимальный код, неоптимальные запросы либо же проблемы параллельности. Если выясняется, что основная доля времени выполнения ключевой операции приходится на запросы, то осуществляется оптимизация этих запросов. При высоких нагрузках на сервер СУБД в оптимизации нуждаются и те запросы, которые потребляют наибольшие ресурсы. Такие запросы не обязательно связаны с ключевыми операциями и заранее неизвестны. Но их также легко выявить и определить контекст их выполнения, чтобы оптимизировать стандартными методами.

24.05.2020    5889    0    DataReducer    22    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

18.05.2020    1603    0    Aleksey.Bochkov    3    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    40017    0    Gilev.Vyacheslav    1    

Настоящий краудфандинг. Даешь сравнение двух СУБД!

Администрирование СУБД v8 Бесплатно (free)

Первый вариант сравнения двух СУБД. Каждый может внести правку и получить SM. Приветствуются конструктивные комментарии, начинающиеся словами "Автор ничего не понимает".

11.05.2020    2213    0    Mari_Kuznetzova    25    

Эти занимательные временные таблицы

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

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    9941    0    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

Производительность и оптимизация (HighLoad) Практика программирования v8 Бесплатно (free)

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    3213    0    feva    14    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    66414    0    yuraos    112    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    11058    0    informa1555    21    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

31.03.2020    2732    0    vasilev2015    9    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

20.03.2020    4013    0    vasilev2015    21    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

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

21.06.2013    53204    0    Антон Ширяев    116    

Многопоточность

Практика программирования Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    6046    0    kaliuzhnyi    43    

1С + Apache + SSL: Перевод опубликованной базы на защищенное соединение https с сертификатом от Let's encrypt windows

Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Есть куча инструкции про связку с ISS, решил добавить свои 5 копеек, как я это настраивал на Apache на Windows.

02.03.2020    2864    0    rst_filippov    5    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    53847    0    Gilev.Vyacheslav    46    

Ошибка при обновлении: Записи регистра сведений стали неуникальными: Двоичные данные файлов

Администрирование СУБД v8 Бесплатно (free)

Способ обойти ошибку обновления Записи регистра сведений стали неуникальными: ДвоичныеДанныеФайлов.

26.02.2020    3722    0    dubovenko_m    11    

Контроль места на дисках

Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Один из последних случаев на работе. Диск, на котором хранились файлы базы, "развалился", база потеряна. Начали искать копию базы. Копии базы делались на другой диск, но оказалось, что на том диске нет места и копии не делались несколько дней. Так было потеряно несколько дней работы фирмы, кому-то выговор, кого-то уволили((.

20.02.2020    3016    0    wowik    20    

Нюансы лицензирования 1С

Администрирование СУБД v8 1cv8.cf Россия Бесплатно (free)

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

19.02.2020    8171    0    fixin    112    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    29608    0    gallam99    19    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    7983    0    Evil Beaver    13    

Как мы научились автоматически отслеживать ошибки в 1С

Администрирование СУБД v8 1cv8.cf Россия Бесплатно (free)

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

04.02.2020    12344    0    slozhenikin_com    27    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Продолжение статьи об оптимизаторе запросов. Во второй части мы попробуем создать свой оптимизатор и попутно разберемся с такими вопросами, как: хранение файлов; индексы; статистика.

23.01.2020    5822    0    darkdan77    59    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    41798    0    madmpro    32    

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

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

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

23.01.2020    7109    0    Kaval88    26    

Автономный сервер. Часть 2 - утилита управления

Администрирование СУБД v8 Бесплатно (free)

Утилита управления "Автономным сервером" может не только управлять. Какие возможности можно использовать уже сегодня? Разбираем с примерами и ищем отличия от привычных методов.

21.12.2019    8842    0    -vito-    26    

Автономный сервер. Часть 1 - новый вариант сервера

Администрирование СУБД v8 Бесплатно (free)

В Платформе версии 8.3.14 появился новый вариант серверной архитектуры - "Автономный сервер" (бета-версия). Выясняем, что это такое, какова сфера его применения, что он позволяет уже сейчас, чего можно ожидать.

21.12.2019    11068    0    -vito-    19    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    9860    0    ivanov660    16    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    6912    0    EugeneSemyonov    11    

Обслуживание баз данных. Не так просто, как кажется

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

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    16307    0    YPermitin    28    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    8454    0    Repich    5    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    17408    0    Sloth    24    

Хранение файлов - как уменьшить размер базы данных

Чистка базы Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 Россия Бесплатно (free)

Хранение файлов в базе 1С можно оптимизировать для уменьшения размера хранимых данных.

09.09.2019    7930    0    2tvad    17    

Анализ производительности APDEX

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    9765    2    YPermitin    7    

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

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

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

19.07.2019    8435    0    Филин    12    

Ловля блокировок на связке "Microsoft SQL server - 1С"

Производительность и оптимизация (HighLoad) v8 v8::blocking Бесплатно (free)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    9073    0    fhqhelp    0    

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка v8 Бесплатно (free)

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    10565    0    igordynets    119    

Ускорение чтения правил обмена в УПП 1.3 в 20 раз!

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    9303    0    YPermitin    16    

Хотите снизить нагрузку на процессор сервера в 2 раза?

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

В статье рассмотрено влияние частого запуска регламентных заданий на процессор сервера 1С.

27.06.2019    8894    0    Дмитрий74Чел    6    

Непридуманные истории по оптимизации. История 1

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    12064    0    Repich    117    

Оптимизация: неэффективные запросы

Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

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

13.06.2019    5568    0    slayer-ekb    10    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    22759    0    dmurk    144    

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    17658    0    ivanov660    9    

Не думать о секундах свысока...

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    7578    0    vasilev2015    21    

Альтернативная стратегия управления блокировками

Производительность и оптимизация (HighLoad) v8 v8::blocking 1cv8.cf Россия Бесплатно (free)

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    6798    0    zhichkin    15