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

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

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

207
В статье речь пойдет про взаимодействие сервера 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 в 2016 году.

Больше статей можно прочитать здесь.
Приглашаем вас на новую конференцию INFOSTART EVENT 2019!

207

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

Комментарии
Избранное Подписка Сортировка: Древо
1. spezc 587 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. корум 311 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 1079 13.07.17 15:44 Сейчас в теме
(4)
Статистики и итоги до поры до времени будут спасать, но со временем база наберет критический объем и эти меры уже не помогут
почему?
Особых проблем не вижу, итоги рассчитываются, запрос всегда строится к таблице итогов за месяц и union по таблице движений (максимум за месяц).
6. brr 177 11.07.17 12:39 Сейчас в теме
7. Vovan1975 14 11.07.17 12:51 Сейчас в теме
А можно по подробнее рассказать почему решили отключить текущие итоги?
8. asved.ru 36 11.07.17 13:12 Сейчас в теме
(7) Они не нужны, т.к. точка актуальности в далеком будущем и остатки берутся почти всегда задним числом.
10. корум 311 11.07.17 15:04 Сейчас в теме
(8) "как быстро починить чтобы пореже падало".

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

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

Единственная зрелая мысль во всей статье - порядок использования итогов. Однако даже это решение неверно, т.к. с дальнейшим ростом объемов данных работать перестанет.
Здесь необходима переработка архитектуры хранения данных в целом.
ZOMI; aKomper; zarucheisky; Dem1urg; Dach; gortol; FarhadIlyazov; GreenDragon; +8 Ответить
11. Kopman 18 12.07.17 04:54 Сейчас в теме
Статья в 4 словах:
Мы настроили регламент MSSQL.
Kinestetik; ZOMI; manlak; Dem1urg; корум; rovenko.n; +6 Ответить
13. echo77 1093 12.07.17 07:58 Сейчас в теме
(11) Не только, здесь и очистка таблицы текущих итогов и расчет итогов по месяцам и наведение порядка во внешних отчетах
12. AlexeyFreeLife 12.07.17 07:41 Сейчас в теме
вопрос не по теме: зачем столько картинок ? после пролистывания статьи не читая текст уже подустал.
ZOMI; KAV2; perpleks; +3 Ответить
15. echo77 1093 12.07.17 08:08 Сейчас в теме
(12) Не соглашусь, картинки разбавляют текст, его становится легче читать. То что листать приходится дольше - это да :-)
Kinestetik; Gang031; Artem-B; inf012; Rego1337h; gortol; rovenko.n; +7 Ответить
14. echo77 1093 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 1959 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 1959 12.07.17 17:05 Сейчас в теме
(19)
отчеты для второй группы перенести в копию базы, размещенной на другом сервере...
в итоге нагрузка упадет

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

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

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

Воистину.

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

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

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

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

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

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


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

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

См. также

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

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование данных 1С

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

13.09.2019    3360    Repich    4       

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

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

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

10.09.2019    6832    Sloth    11       

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

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

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

31.08.2019    2581    93    YPermitin    7       

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

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

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

19.07.2019    4095    Филин    12       

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

Статья Системный администратор Программист Нет файла v8 v8::blocking MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

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

16.07.2019    3458    fhqhelp    0       

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

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

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

02.07.2019    5930    igordynets    119       

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

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

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

27.06.2019    4073    YPermitin    16       

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

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

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

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

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

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

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

13.06.2019    7044    Repich    117       

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

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

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

13.06.2019    2583    slayer-ekb    10       

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

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

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

28.05.2019    7040    ivanov660    5       

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

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

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

21.05.2019    4309    vasilev2015    21       

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

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

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

20.05.2019    3703    zhichkin    15       

Как работают управляемые блокировки 120

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

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

29.04.2019    12999    comol    198       

Странное потребление места на диске С 33

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

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    10551    kuzyara    12       

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С 49

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

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    8109    Elf1k    26       

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С 201

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

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

18.04.2019    17722    ivanov660    40       

Как разбить базу на файлы и не сойти с ума 108

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

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    8562    YPermitin    29       

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз 124

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

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    9717    w.r.    23       

Простое программное решение проблем с блокировками SQL 17

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

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    5793    dmitrydemenew    38       

Производительность сервера 1С и фоновые задания 63

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

В падении производительности сервера 1С зачастую виноваты не регламентные / фоновые задания, они выполняют полезную работу. Но задания нельзя оставлять «наедине» с базой.

05.02.2019    10644    user715208    38       

Новый режим реструктуризации (обновление базы данных на сервере в режиме v2) 168

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

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

31.10.2018    18225    Dach    46       

Нетривиальные подходы в решении всем известных проблем: ускорение «больших» документов в 1С и ускорение поиска по подстроке. Как добиться эффекта в разы? 62

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

Часто у пользователей 1С поиск информации по большим спискам данных по подстроке занимает продолжительное время. Павел Баркетов рассматривает причины торможения запросов с поиском по подстроке и описывает возможности и подходы к их оптимизации и ускорению. Также в статье разобраны причины длительного проведения «больших» документов (более 10 000 строк) и даны рекомендации по ускорению этих операций.

30.08.2018    10730    gallam99    31       

Кейс: как мы разрабатывали систему автоматизации анализа ошибок, связанных со скоростью работы 1С 42

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

Бурмистров Андрей рассказывает о создании инструмента по автоматизации анализа неоптимальных запросов в коде 1С. Он поднимает вопрос о предпосылках создания этого инструмента, рассказывает о возникших форс-мажорных ситуациях, с которыми столкнулась команда в процессе разработки, и о том, как они с ними справлялись.

27.08.2018    7421    Andreynikus    20       

3000 пользователей на трехъядерном Athlon – сверхтонкий веб-клиент для 1С 97

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

Юрий Лазаренко поделится опытом ускорения 1С нестандартными методами, в том числе с помощью http-сервисов. Он расскажет, как с помощью сверхтонкого клиента для 1С и интеграции с сайтом удалось добиться ускорения 1С на порядок. Также в статье приведена статистика по отчету о нагрузочном тестировании сверхтонкого клиента для 1С:ITIL.

16.08.2018    11237    TitanLuchs    28       

Когда условие в срезе последних даже вредит 20

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

Спойлер: оптимизатор MSSQL видит внешние, по отношению к срезу, условия, и строит план с их учетом.

05.08.2018    7668    nicxxx    105       

Оптимизация без оптимизации: как мы ускорили 1С в 10 раз без трудоемкой оптимизации запросов и алгоритмов. Практический опыт 80

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

Можно ли ускорить 1С, не оптимизируя запросы, не разбивая транзакции и не наращивая оборудование? В статье Аверьянова Алексея рассмотрены три практических кейса повышения производительности системы без трудоемкой оптимизации: отложенное резервирование «в один поток», отложенное создание и проведение реализаций.

26.07.2018    13054    avryanovalexey    100       

Альтернативные технологии нагрузочного тестирования серверной части кода прикладных решений на платформе 1С 56

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

Евгений Филиппов знакомит с альтернативными технологиями нагрузочного тестирования серверной части кода прикладных решений на платформе 1С. Он рассказывает об узких местах традиционной технологии нагрузочного тестирования и методах их обхода путем переноса работы с клиентских соединений на фоновые задания и изменения способа управления сеансами. Также автор приводит примеры с реальных проектов, подтверждающие жизнеспособность предложенных технологий.

12.07.2018    8124    jf2000    10       

Архитектура ИТ-системы на базе 1С в крупной организации. Часть 2. Чудес не бывает 81

Статья Системный администратор Нет файла v8 УТ11 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Развернуто отвечаю, как мы боремся с зависаниями системы и вообще решаем проблемы. С примерами, но без слайдов.

04.07.2018    12116    Repich    74       

Архитектура ИТ-системы на базе 1С в крупной организации 101

Статья Системный администратор Нет файла v8 УТ11 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

В данной статье я хотел бы очень крупными мазками обрисовать архитектуру ИТ системы на базе 1С в крупных (более 1 тысячи пользователей) организациях. Она не несет какой либо образовательной цели, это просто попытка показать – «а как у нас».

02.07.2018    14627    Repich    112       

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

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

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

18.06.2018    9896    Sergey.Noskov    27       

Простые регулярные выражения 59

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

Шпаргалка к экзамену "Эксперт по технологическим вопросам".

30.04.2018    11600    3    vasilev2015    30       

Неоптимальная работа запроса 128

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

Шпаргалка к экзамену "Эксперт по технологическим вопросам".

27.04.2018    16912    vasilev2015    32       

Неоптимальности вида «план исполнения запроса "испортился"» - поиск и исправление 69

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

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

05.02.2018    13665    fhqhelp    20       

Пример поиска неоптимальности при загрузке SQL-сервера по CPU на 100% 83

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

Вечер пятницы, ничто не предвещало.. Звонок из техподдержки: "центральная база розничной сети лежит". Далее расследование причин.

23.12.2017    15195    fhqhelp    32       

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

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

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

30.10.2017    24155    MrWonder    38       

Вопросы разработки, анализа производительности и оптимизации приложений 1С под управлением СУБД ORACLE 16

Статья Системный администратор Программист Нет файла v8 Oracle Бесплатно (free) Производительность и оптимизация (HighLoad)

Я являюсь сотрудником Комсомольского-на-Амуре филиала компании «Сухой». Наше предприятие производит боевую авиационную технику и комплектующие для гражданской авиационной техники. В статье я вам расскажу про свой опыт работы со связкой 1С и СУБД ORACLE.

05.09.2017    10399    user597755_vices2015    2       

Планы запросов - это просто! 290

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

Наверное, каждый 1С-ник задавался вопросом "что быстрее, соединение или условие в ГДЕ?" или, например, "сделать вложенный запрос или поставить оператор В()"? В данной статье я не дам вам исчерпывающих инструкций по чтению планов запроса. Но я постараюсь объяснить доходчиво - что это такое и с какой стороны к ним подойти.

04.07.2017    31023    Evil Beaver    58       

PostgreSQL на Windows – реальная альтернатива для высоконагруженных систем на базе 1С 157

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

Многие интересуются PostgreSQL, но не знают, насколько хорошо будет она работать с уже существующими системами. «Инфософт» - одна из первых компаний, кто опробовал PostgreSQL на Windows. О своем опыте перехода рассказывает руководитель отдела информационных технологий компании.      

23.06.2017    37054    a.doroshkevich    113       

Ускорение в 100 раз. Решаем проблему блокировок 328

Статья Программист Нет файла v8 v8::УФ 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Я являюсь автором и тренером курсов по оптимизации и повышению производительности в 1С. Большинство людей приходят ко мне на обучение, желая разобраться со своими проблемами, и я очень часто слышу от них: «эти блокировки замучили, достали, жизни нет, что делать – не знаем. Технологический журнал включали, галочки ставили, форумы читали – ничего не помогает». Я уверен, что эта тема актуальна для многих из вас, поэтому в статье, не вдаваясь глубоко в подробности, я хочу вам дать некоторые конкретные рекомендации, которые вы сможете применить у себя и сразу получить ощутимый эффект. Например, если у вас запрос из-за блокировок выполняется 15 секунд, то после оптимизации он начнет выполняться за 15 миллисекунд. Это обычная практика, никакой фантастики – все это можно сделать.

13.06.2017    60020    Andreynikus    34       

Настройка зеркалирования базы для MS SQL 55

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Архивирование (backup) Производительность и оптимизация (HighLoad)

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

19.05.2017    23718    MsDjuice    13