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

В статье речь пойдет про взаимодействие сервера 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 2024 DEVELOPER. Больше статей можно прочитать здесь.

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

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

32 Comments

  1. spezc

    Интересная подача материала)))) слог и картинки заслуживают звезду

    Reply
  2. genayo

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

    Reply
  3. корум

    (2) Случай интересный.

    кейс из крокодиловой кожи 🙂

    Reply
  4. Waanneek

    (2) Плюсанул! В начале статьи уже было понятно что надо архитектуру пересматривать. Либо распределенную базу делать, либо разносить проблемный регистр на несколько, чтобы данные на тек. момент и на будущий период брались из разных мест как вариант. Статистики и итоги до поры до времени будут спасать, но со временем база наберет критический объем и эти меры уже не помогут (не будут давать приемлемую скорость работы).

    Думал речь пойдет о разделении на несколько баз с синхронизацией, те кто оперативно работают будут в основной базе, те у кого дикая нагрузка, но не оперативно — в отдельную базу с задержкой получения информации на Xч/мин. Это позволило бы реально снизить нагрузку на оперативную базу.

    Reply
  5. genayo

    (3) Чемодан из крокодиловой кожи тогда уж.

    Reply
  6. brr

    Интересно, спасибо

    Reply
  7. Vovan1975

    А можно по подробнее рассказать почему решили отключить текущие итоги?

    Reply
  8. asved.ru

    (7) Они не нужны, т.к. точка актуальности в далеком будущем и остатки берутся почти всегда задним числом.

    Reply
  9. asved.ru

    На счет «MS SQL не имеет гибких интерфейсных настроек для обновления статистики» — чушь полная, бред сивого DBA.

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

    Единственная зрелая мысль во всей статье — порядок использования итогов. Однако даже это решение неверно, т.к. с дальнейшим ростом объемов данных работать перестанет.

    Здесь необходима переработка архитектуры хранения данных в целом.

    Reply
  10. корум

    (8) «как быстро починить чтобы пореже падало».

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

    Кто мешал сделать нормальный регистр планирования с датой в измерении?…

    Reply
  11. Kopman

    Статья в 4 словах:

    Мы настроили регламент MSSQL.

    Reply
  12. AlexeyFreeLife

    вопрос не по теме: зачем столько картинок ? после пролистывания статьи не читая текст уже подустал.

    Reply
  13. echo77

    (11) Не только, здесь и очистка таблицы текущих итогов и расчет итогов по месяцам и наведение порядка во внешних отчетах

    Reply
  14. echo77

    (0) Опечатку на слайде поправьте http://infostart.ru/upload/iblock/09b/09b70ceaa97acb6f38273c481f638e72.jpg

    Маленькие замечания:

    максимальная дата в 1С — 3999 год

    неплохо бы сразу в статье сказать, что регистр накопления остатков

    на сколько оправдано разделение итогов в этом регистре?

    странно, что «профессиональные каскадеры» не вспомнили про то, что текущие итоги и обычные ежемесячные итоги – это одна и та же таблица.

    Reply
  15. echo77

    (12) Не соглашусь, картинки разбавляют текст, его становится легче читать. То что листать приходится дольше — это да 🙂

    Reply
  16. manlak

    За статью плюс, понравилось!

    Только небольшое замечание, а нельзя было вместо «скриншотов» обновления статистики и текста тех.журнала, код выставлять по человечески, который можно было б скопировать в буфер обмена? )

    Reply
  17. starik-2005

    (16)

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

    ИМХО, код вставлять без понимания его сути — это зло абсолютно неэкспертное. Любой копипаст — это риск, что:

    1. То, что кописастишь — полная хрень (как в данном случае);

    2. То, что копипастишь, сложно изменить;

    3. То, что копипастишь, сложно понять.

    Reply
  18. aKomper

    Феерично

    Reply
  19. Herby

    статья про типичную русскую проблему — сначала делаем, а потом думаем.

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

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

    отчеты для вашей третьей группы пользователей перенести в BI.

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

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

    иначе так и будете упираться в пробки.

    Reply
  20. starik-2005

    (19)

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

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

    Даже если на одном сервере — и то упадет.

    Reply
  21. teller

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

    вот так и оттачивается мастерство

    Reply
  22. iliabvf

    Гениальная подача материала! Дизайн заказывали у школьников?

    Reply
  23. ansh15
    Даже на мегамощностях заказчика на это ушло бы 13 часов

    Можно про «мегамощности» более детально рассказать, если не секрет?

    Reply
  24. rozer

    (22) когда вышел фильм этот с Киану Ривзом вы были школьником а может и в д/с ходили еще ) норм статья но это оч частный случай про откл итогов — лучше архитектуру пересмотреть, да

    Reply
  25. Sergey.Noskov

    (4)

    Статистики и итоги до поры до времени будут спасать, но со временем база наберет критический объем и эти меры уже не помогут

    почему?

    Особых проблем не вижу, итоги рассчитываются, запрос всегда строится к таблице итогов за месяц и union по таблице движений (максимум за месяц).

    Reply
  26. Yashazz

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

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

    Воистину.

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

    Reply
  27. logarifm

    поистину есть еще понятия кривых итогов — это некорректное закрытие регистров. Провисшие записи. Вот что точно паразит!!!

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

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

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

    Вот такие вещи конечно будут порождать паразитов на итогах…

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

    Статья зачетная. И нет придела совершенству в поисках производительности и самое главное нет одного эликсира или панацеи … (ИМХО)

    Reply
  28. Fatov_DI

    Спасибо за статью! Мне оформление понравилось, по крайней мере читается легко….

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

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

    Reply
  29. Gilev.Vyacheslav

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

    Reply
  30. Red_Devil

    Все проблемы как всегда из-за коллекторов!!!

    Reply
  31. tiniji

    Хороший способ объяснить заказчику куда ушли его деньги. На написание презентации )

    P.S. Думаю проф. уже эта информация известна давно. Ну а новички не поймут, что такое статистика и с чем его едят.

    Reply
  32. o.nikolaev

    Для тех кто сотрудничает с «микрофинансовыми» организациями, в аду отдельная сковородка. Каждый день +1000% от предыдущей температуры.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *