Сообщество - Лига Новых Технологий

Лига Новых Технологий

1 892 поста 16 906 подписчиков

Популярные теги в сообществе:

59

Что такое наземное лазерное сканирование, и как с ним бороться?

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

Красавец на фото - прибор Leica RTC360, мося на первом плане моя.

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

Технология не самая новая, но бурно развивающаяся. Изначально пришла в геодезию, но сейчас используется во многих смежных областях - строительство, обследование, деформационный мониторинг, реставрация и сохранение памятников исторического наследия, археология, дизайн, маркшейдерия (если рассматривать данную дисциплину отдельно от геодезии), создание цифровых 3D-туров. Возможно, что-то еще упустил.

Небольшой дисклейм. Уже предвижу, как набегут в тему "знатоки", которые с радостью объяснят, что данная технология зло, фигня и как они с ней обожглись. А еще наверняка будут тошнотики, которые вставят свои 5 коп., про мои неточности в описании физики процесса и т.п. Поэтому сразу расскажу вкратце о себе и как я столкнулся с НЛС. Я геодезист и большую часть времени проработал техническим специалистом в одном из филиалов российского представительства концерна Hexagon group (широко известный в узких кругах в первую очередь брендом Leica Geosystems). Сейчас данный концерн ушел из России, а клоуны остались. То есть моя специальность разобраться в приборе на столько, чтобы можно было учить на нем работать других. А также разбираться в разных тонкостях, аксессуарах, настройках, багах, мелком ремонте. Начинал свою карьеру в 2008г. с классической уже связки тахеометр - спутниковое оборудование, ну и всякая мелочевка, типа нивелиров и т.п. За свою продолжительную карьеру успел даже преподавать геодезию в одном из ВУЗов. НЛС-ом наш филиал заинтересовался практически сразу, как данная технология появилась в России, это год 2010г. кажется был (имеется в виду именно коммерческие продажи, а то найдется тип, который будет кричать, как в их институте сканер был уже в году 2008). Итого с НЛС я работаю уже лет 15. В первую очередь, НЛС появился для нужд строительной и промышленной геодезии, а вскоре и для маркшейдерии.

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

Первое фото мое - тахеометр Leica MS60, две другие взял из интернета, там Trimble и Sokkia, тоже очень популярные бренды.

Очень кратко о принципе работы тахеометра. Он ставится на точку с известными координатами (необязательно, но пока опустим), ориентируется на другую точку с известными координатами, компьютер внутри понимает, где находится прибор в координатной сетке X,Y, Z (для душнил, Z можно заменить h - высотой). Далее прибор наводится на интересующую геодезиста точку (если она на земле, в траве, как раз используется палка - вешка) и делается замер. Прибор испускает фазовый (или импульсный. тоже углубляться отдельно не стоит) сигнал, тот отражается от препятствия, возвращается в прибор и вычисляется расстояние до данной точки. А так как тахеометр получил часть ген своего предка теодолита в виде горизонтального (лимб) и вертикального (алидада) кругов, то может высчитать положение своей зрительной трубы относительно ориентирования, а следовательно, высчитывает и направление, куда был направлен данный луч. Итого, прибор вычисляет положение данной точки в той же координатной сети, что и прибор - то есть ее положение, относительно осей X, Y, Z. Вот так все просто.

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

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

Первый наземный лазерный сканер изготовила компания Cyrex (это как меня учили гуру из Leica Geosystems. Возможно, могу ошибаться, но другой информации не встречал), которую очень быстро перекупил концерн Leica Geosystems, и стал изготавливать уже свои приборы. Первый прибор, который попал к нам в руки был Leica ScanStation (он же HDS3000). Вот его основные характеристики, попытайтесь запомнить, дальше я выложу характеристики современных сканеров. Почувствуете разницу, как за ~20 лет продвинулась технология. Скорость измерений 4000 точек в секунду. Вес 16кг + 2 внешних аккумулятора по 8кг каждый + ноутбук для управления. Дальность 170 метров, точность одной точки 4мм (В точность в этом посте углубляться не буду. Просто запомните, что довольно точно для большинства задач).

Leica ScanStation. По габаритам он был размером с пивную кегу. И весил 16кг. Его постоянно нужно было поднимать на штатив и опускать с него.

Leica ScanStation. По габаритам он был размером с пивную кегу. И весил 16кг. Его постоянно нужно было поднимать на штатив и опускать с него.

И этот прибор был "бомба". Без преувеличений. Когда мы демонстрировали результат его работ тертым геодезистам, снимающим промышленные заводы, они были в восторге. На выходе получалась не кучка координированных точек в пространстве, как в случае с тахеометрами, а "облако точек" (термин мигом вошел в обиход и сейчас результат лазерного сканирования официально именуется - облако точек). Для примера, как работает классический геодезист с тахеометром? Наводит зрительную трубу на нужную точку, жмет точку измерить, прибор делает измерение (примерно секунд занимает), наводится на следующую и т.д. сколько можно отснять точек за час? При съемке фасада, то есть не нужно переставлять прибор, не нужно гонять человека с вешкой - наводись и снимай, у меня выходило максимум 150 точек. И после этого у меня болели глаза, спина и тряслись руки. Сканер делал 4000 измерений в секунду! Конечно, максимальной скорости достигнуть можно было лишь в идеальных условиях, на практике получалось за 10 минут съемки облако из 1 000 000 точек. Сканеру нужно было только задать нужные границы съемки (сразу скажу, это занимало значительную часть времени), указать через какой шаг нужно записывать точки и нажать точку старт.

Для примера. Первое фото, так выглядит обычная тахеометрическая съемка. На второй облако точек, полученное с лазерного сканера. На третьем совмещенно в одном проекте съемка тахеометра и облако точек.

Все упиралось в стоимость прибора. Она была такая же космическая, как и полученный результат. Позволить себе такое оборудование могли лишь самые богатые предприятия. А потратить такие огромные деньги на новую, еще толком не обкатанную, технологию и вовсе решались единицы. Для примера, стоил прибор, на сколько я помню, столько же, сколько два Лэнд Крузера 200 в полном фарше.

Отпугивал потенциальных клиентов еще и сам результат сканирования. Красиво, в 3Д можно повращать, любые расстояние измерить за секунду прямо в компьютере. А что дальше с этим делать? На то время уже существовали программы для трехмерного проектирования, но с облаками точек они начнут работать ой, как не скоро. Было ПО от самой Leica Geosystems, позволявшее по облакам выстроить твердотельные трехмерные модели и после перевести их в любой CAD продукт. Но все справедливо опасались, а что если не зайдет? Опыта тогда практически ни у кого не было, а становиться первопроходцами и собирать на себя все шишки, чтобы своим конкурентам проторить дорогу никто не спешил.

Лично нам помог случай. Проходила реконструкция одного из крупных заводов, на который мы ездили с демонстрацией этого сканера. И во время реконструкции была задача разобрать один аппарат (величиной с пятиэтажный дом), снять все размеры коммуникаций, заказать по этим размерам другой аппарат на это место и смонтировать его. Делали классическими тахеометрами. Все разобрали, размеры отправили на завод в 300км от места установки. Там эту штуку собрали и потащили на двух КРАЗах обратно. Тащили медленно, по ночам, даже пришлось местами провода поднимать, чтобы пролезло. Привезли, а эта штука не лезет! Забыли отснять одну трубу, а труба важная. Чтобы перенести эту трубу нужно ползавода разобрать. Что делать? Повезли эту штуку обратно на завод изготовления и там переделывали и везли обратно... чувствуете затраты? Сколько ланд крузеров можно было купить на эти деньги? Приобрети они сканер, он бы уже дважды окупился. Фишка сканера в том, что он снимает все вокруг себя. Данные избыточные. Он просто не может пропустить какую-то там деталь. Бывают конечно слепые зоны, но их довольно быстро учишься устранять при работе со сканером. Просто чаще переставляешь прибор и не экономишь на станциях. Вот так мы поставили наш первый сканер.

А всего за 15 лет, при непосредственно моем содействии, было поставлено чуть более 100 сканеров для различных задач и работ. Был и неудачный опыт. Смотрели, все нравилось, приобретали, а работ не было... валялся без дела. Но тут не в приборе дело. Такие приборы нужно брать уже под конкретные работы, а не в надежде, что они появятся. И прежде, чем приобрести такой прибор себе на склад, лучше пригласить специалистов на свой объект и попросить их выполнить работы, если конечный результат (не красивое облако точек, а готовая 3Д-модель или отчеты о деформации, или план фасада) устроил заказчика - брать. Сейчас рынок НЛС в России довольно неплохо наполнен. Есть компании, которые уже полностью ушли от классической геодезии и занимаются чисто лазерным сканированием. Практически на каждом крупном заводе есть свой сканер, либо они часто обращаются к сторонним проектным институтам, у кого есть такой прибор.

Сканеров на рынке сейчас появилось множество. На любой вкус, цвет и кошелек. Ситуация напоминает авторынок. Есть зарекомендованные игроки с качественными моделями, такие как Leica, Faro, Z+F, Trimble... есть много марок из поднебесной, обычно просто копирующих какую-либо удачную модель перечисленных брендов. Отличаться могут по точности, скорости, удобству...

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

Для окончания напишу характеристики одного из самых популярных наземных лазерных сканеров на сегодня (у нас именно такой) Leica RTC360. Прибор вышел на рынок уже 5 лет назад и совершил переворот в НЛС настолько, что и сегодня по характеристикам его кажется никто не обошел, возможно подобрался вплотную. Информации актуальной по всем сканерам, которые производятся в мире у меня к сожалению нет. Так вот, скорость сканирования 2 млн. измерений в секунду (напомню у ScanStation было 4 тысячи), вес 8 кг (это с установленными аккумуляторами), дальность 170 метров (существют специальные горные сканеры, которые могут снимать до 2км, но с значительно меньшей скоростью), управление все на борту через сенсорную панель. Температурный диапазон работы от -20 до 50 (практически все сканеры до него работали исключительно от 0 градусов). Встроенный датчик наклона (не нужно при установке каждый раз выставлять уровень. Можно даже перевернуть вверх ногами, чтобы сканировать например резервуары через люк). Автоматическая сшивка станций (очень полезная технология, которая отслеживает положение прибора во время движения от станции к станции, очень ускоряет время дальнейшей обработки). Возможность подключения планшета или телефона, для удаленного запуска или просмотра прямо в поле полученного результата. Вот так продвинулась технология за 20 лет. По мне, это все равно, что сравнивать паровоз с современным поездом, типа Сапсан. Или первый смартфон HTC с последним iPhone.

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

На этом наверно и закончим для начала. Слишком уж длинно получилось. Примеры работ будут в следующих постах. Либо, если кому не терпится посмотреть, погуглите на ютубе - наземное лазерное сканирование и работа с облаками точек. Роликов предостаточно. Еще есть серия фильмов "Невидимые города Италии" 2016 года, там при помощи НЛС, а также МЛС снимают красивейшие объекты культурного наследия, например Собор во Флоренции и много другого красивого.

Благодарю за внимание.

Показать полностью 9

Производительность PostgreSQL для разных ОС - часть 3

Взято с основного технического канала Postgres DBA

Продолжение цикла статей о статистическом анализе результатов нагрузочного тестирования СУБД PostgreSQL :

Часть 3 - Сценарий нагрузочного тестирования "Heavyweight"

Нужно выбирать

Нужно выбирать

Задача эксперимента

Необходимо провести количественный анализ влияния версии Linux на производительность СУБД для разных дистрибутивов Linux : OS-1 и OS-2 .

СУБД расположены на разных виртуальных машинах. Гипервизор - один. Конфигурация файловых систем - одинаковая. Ресурсы хоста - одинаковые.

Сценарий "Heavyweight"

Тестовый запрос состоит только из выражений SELECT с использованием JOIN ,ORDER BY и математических функций.

Все блоки использующиеся в запросе - находятся в распределенной области.

Для создания нагрузки используется pgbench.

Количество сессий к СУБД растет экспоненциально для каждого прохода теста.

Производительность СУБД

До 78 соединений - разница в производительности не более 3%

До 78 соединений - разница в производительности не более 3%

Резкий рост относительной разницы производительности после 76 соединений

Резкий рост относительной разницы производительности после 76 соединений

До 78 соединений - разница в производительности практически отсутствует.

При высокой нагрузке - OS-2 существенно производительнее.

Время выполнения тестового запроса

Явная аномалия в районе 78 соединений

Явная аномалия в районе 78 соединений

Имеется аномалия значений

Имеется аномалия значений

За исключением аномалии при 78 соединений, относительная разница времени выполнения не превышает 5%.

Итог

Для сценария "Heavyweight", при нагрузке свыше 78 сессий - производительность СУБД развернутой на ОС Linux версии OS-2 превосходит производительность СУБД развернутой на ОС Linux версии OS-1 более чем на 10%.

P.S. Аномальное значение при 78 сессиях нуждается в повторном эксперименте.

Показать полностью 5

Корреляционный анализ для определения причин деградации производительности СУБД PostgreSQL

математическая статистика в целом не подходит для общего анализа и сравнения производительности СУБД.

Эпиграф

Чем же может оказаться полезной математическая статистика или комментарий к комментарию.

Тренды на график метрики производительности СУБД

Тренды на график метрики производительности СУБД

Активные соединения и утилизация CPU

Активные соединения и утилизация CPU

Для сглаживания данных используется медианное сглаживание:

  • Долгая скользящая: 1 час(красная линия).

  • Короткая скользящая: 10 минут(синяя линия).

  • Активные соединения и утилизация CPU: стандартные метрики Zabbix.

Как видно из графика - имеет место деградация производительности СУБД:

  1. Количество активных сессий растет, но производительность падает

  2. Утилизация CPU растет , но производительность падает

Ситуация, принципиально отличается от описанной в казалось бы похожих кейсах:

  1. CPU Utilization = 100%. Это проблема СУБД?

  2. CPU Utilization = 100%. Это проблема СУБД?

Поэтому и решаться данный инцидент будет по другому.

Использование статистического анализа

1.Выделение трендов на графике производительности

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

  • 13:00 - 13:28 : Горизонтальный тренд - высокая производительность

  • 13:28 - 13:47 : Деградация производительности

  • 13:57 - 14:05 : Горизонтальный тренд - низкая производительность. Нагрузка на СУБД уменьшилась.

13:00 - 13:28 : Горизонтальный тренд - высокая производительность

Статистические показатели производительности СУБД

Рис.1. Статистические показатели горизонтального тренда 13:00-13:28

Рис.1. Статистические показатели горизонтального тренда 13:00-13:28

Прямая корреляция между количество активных сессий и производительностью СУБД . Или другими словами - чем выше нагрузка на СУБД , тем выше производительность.

Статистические показатели ожиданий СУБД - корреляция ожиданий и производительности СУБД

Рис.2. Корреляционный анализ ожиданий и производительности 13:00-13:28

Рис.2. Корреляционный анализ ожиданий и производительности 13:00-13:28

Количество пользовательских запросов по которым имеются события ожидания СУБД - минимально.

13:28 - 13:47 : Деградация производительности

Статистические показатели производительности СУБД

Рис.3. Статистические показатели нисходящего тренда 13:28 - 13:47

Рис.3. Статистические показатели нисходящего тренда 13:28 - 13:47

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

Статистические показатели ожиданий СУБД - корреляция ожиданий и производительности СУБД

Рис.4. Корреляционный анализ ожиданий и производительности СУБД нисходящего тренда 13:28 - 13:47

Рис.4. Корреляционный анализ ожиданий и производительности СУБД нисходящего тренда 13:28 - 13:47

Как видно из таблицы - количество ожиданий кардинально увеличилось. Явный признак - имеются серьезные проблемы с производительностью СУБД.

2.Определение наиболее значимой причины деградации производительности СУБД

Из Рис.4 видно, что наибольшая обратная корреляция между событиями ожидания и снижением производительности СУБД имеется для события LWLock / BufferMapping

Рис.5. Ожидание LWLock / BufferMapping

Рис.5. Ожидание LWLock / BufferMapping

Как видно - количество ожиданий менее чем за 20 минут - весьма существенно.

Итак, первый результат

Первой( но конечно не единственной) причиной деградации производительности СУБД в период 13:28 - 13:47 является - большое количество ожиданий LWLock / BufferMapping при выполнении пользовательских запросов.

Чуть подробнее об ожидании BufferMapping

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

Postgres Pro Enterprise : Документация: 16: 27.2. Система накопительной статистики : Компания Postgres Professional

LWLock - buffer_mapping

This event occurs when a session is waiting to associate a data block with a buffer in the shared buffer pool.

Context

The shared buffer pool is an PostgreSQL memory area that holds all pages that are or were being used by processes. When a process needs a page, it reads the page into the shared buffer pool. The shared_buffers parameter sets the shared buffer size and reserves a memory area to store the table and index pages. If you change this parameter, make sure to restart the database. For more information, see Shared Buffer Area.

The buffer_mapping wait event occurs in the following scenarios:

  • A process searches the buffer table for a page and acquires a shared buffer mapping lock.

  • A process loads a page into the buffer pool and acquires an exclusive buffer mapping lock.

  • A process removes a page from the pool and acquires an exclusive buffer mapping lock.

LWLock - buffer_mapping | Redrock Postgres Documentation (rockdata.net)

3. Определение запросов с максимальным количество ожиданий

Рис.6. Запросы с ожиданием LWLock / BufferMapping c количество более 100.

Рис.6. Запросы с ожиданием LWLock / BufferMapping c количество более 100.

Далее, дело техники, используя утилиту pgpro_pwr по queryid, находим проблемный запрос за период 13:30 - 13:50(снимки pgpro_pwr формируются каждые 10 минут).

Запрос передается разработчикам , для анализа .

Дальнейшие события ожидания анализируются схожим образом. Если отсортировать таблицу Рис.4. по количеству пользовательских запросов(более 100) , то можно и нужно сформировать список проблемных запросов для передачи группе разработки на оптимизацию и доработку.

Рис.7. Список ожиданий отсортированный по количеству пользовательских запросов.

Рис.7. Список ожиданий отсортированный по количеству пользовательских запросов.

Итог

Статистический анализ производительности СУБД позволяет подтвердить наличие деградации производительности не дожидаясь деградации на уровне приложения.

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

P.S.

В настоящее время ведутся работы по разработке и тестированию новой версии инструментария по мониторингу и анализу производительности СУБД PostgreSQL - "Орешник".

Методология статистического анализа производительности СУБД PostgreSQL будет довольно существенно дополнена и доработана.

Показать полностью 9

Производительность PostgreSQL для разных ОС - часть 2

Взято с основного технического канала Postgres DBA

Продолжение цикла статей о статистическом анализе результатов нагрузочного тестирования СУБД PostgreSQL :

Часть 2 - Сценарий нагрузочного тестирования "OLTP"

Выбирай сердцем

Выбирай сердцем

Задача эксперимента

Необходимо провести количественный анализ влияния версии Linux на производительность СУБД для разных дистрибутивов Linux : OS-1 и OS-2 .

СУБД расположены на разных виртуальных машинах. Гипервизор - один. Конфигурация файловых систем - одинаковая. Ресурсы хоста - одинаковые.

Сценарий "OLTP"

Тестовый запрос состоит только из выражений SELECT - UPDATE.

Все блоки использующиеся в запросе - находятся в распределенной области.

Для создания нагрузки используется pgbench.

Количество сессий к СУБД растет экспоненциально для каждого прохода теста.

Производительность СУБД

Разница производительности от 5-9%

Разница производительности от 5-9%

Относительная разница производительности OS-1 и OS-2

Относительная разница производительности OS-1 и OS-2

Время выполнения тестового запроса

Разница времени выполнения тестового запроса от -5% до 7%

Разница времени выполнения тестового запроса от -5% до 7%

Относительная разница времени выполнения тестового запроса

Относительная разница времени выполнения тестового запроса

Итог

Для сценария "OLTP", при нагрузке до 111 сессий - производительность СУБД развернутой на ОС Linux версии OS-1 превосходит производительность СУБД развернутой на ОС Linux версии OS-2 на 5-9% .

Показать полностью 5
0

Мысли вслух - DBA ремесло или наука ?

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

За столько лет , организация работы обычного DBA не сильно изменилась.

За столько лет , организация работы обычного DBA не сильно изменилась.

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

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

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

А ведь в сущности нормальная работа администратора баз данных состоит в анализе результатов наблюдений.

Наблюдение и анализ данных - основа инженерного подхода к делу.

Наблюдение и анализ данных - основа инженерного подхода к делу.

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

Что ж , тем интереснее будет на чистом листе . Может , кому и пригодится и поможет в итоге. Для себя то уже есть первые результаты , но пока надо все аккуратно сформулировать и оформить. И конечно - набирать статистику наблюдений.

Показать полностью 2

Производительность PostgreSQL для разных ОС - часть 1

Взято с основного технического канала Postgres DBA

Продолжение цикла статей о статистическом анализе результатов нагрузочного тестирования СУБД PostgreSQL :

Часть 1 - сценарий нагрузочного тестирования "Select only"

Какой Linux выбрать ?

Какой Linux выбрать ?

Задача эксперимента

Необходимо провести количественный анализ влияния версии Linux на производительность СУБД для разных дистрибутивов Linux : OS-1 и OS-2 .

СУБД расположены на разных виртуальных машинах. Гипервизор - один. Конфигурация файловых систем - одинаковая. Ресурсы хоста - одинаковые.

Сценарий "Select only"

Тестовые запрос состоит только из выражения SELECT.

Все блоки использующиеся в запросе - находятся в распределенной области.

Для создания нагрузки используется pgbench.

Количество сессий к СУБД растет экспоненциально для каждого прохода теста.

Производительность СУБД

Разница производительности от 10 до 13%

Разница производительности от 10 до 13%

Относительная разница производительности OS-1 и OS-2

Относительная разница производительности OS-1 и OS-2

Время выполнения тестового запроса

Разница времени выполнения тестового запроса до 7%

Разница времени выполнения тестового запроса до 7%

Относительная разница времени выполнения тестового запроса

Относительная разница времени выполнения тестового запроса

Итог

Для сценария "Select only", при нагрузке до 111 сессий - производительность СУБД развернутой на ОС Linux версии OS-1 превосходит производительность СУБД развернутой на ОС Linux версии OS-2 не менее чем на 10% .

Показать полностью 5

Сравнение производительности PostgreSQL

Взято с основного технического канала Postgres DBA

Обе хороши, но различия все таки есть

Обе хороши, но различия все таки есть

Предисловие

Статья не о сравнении ОС, задача статьи - тестирование методологии сравнения производительности СУБД.


Задача

Имеется 2 виртуальных машины с развернутой СУБД PostgreSQL.

Версия СУБД - одинаковая.

ОС - одинаковая. Гипервизор - один.

Различие - системный диск HDD vs. SSD.

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


Реализация эксперимента - сценарии нагрузки

Для оценки производительности и среднего времени выполнения тестового запроса используются 3 сценария нагрузки:

  1. Select only (условный сценарий WEB): нагрузка в виде запроса .

  2. TPC-B (условный сценарий OLTP): Нагрузка в виде транзакции состоящей из UPDATE-SELECT

  3. Heavyweight (условный сценарий DSS): Нагрузка в виде тяжелого запроса SELECT..JOIN..ORDER BY + вычислительная нагрузка

  • Индекс производительности СУБД(CPI) : операционная скорость

  • Время выполнения тестового запроса: скользящая медиана с периодом 1 час.

  • Максимальная нагрузка: 100 одновременных запросов.

  • Рост нагрузки: экспоненциально, с коэффициентом 0.2

Результаты эксперимента

Select only

Производительность СУБД

Разница производительности не превышает 1%

Разница производительности не превышает 1%

Время выполнения тестового запроса

Разница времени выполнения не превышает 3.5%

Разница времени выполнения не превышает 3.5%

Итог по сценарию Select only :

Производительность СУБД - практически не отличается.

TPC-B

Производительность СУБД

Разница производительности не превышает 1.5%

Разница производительности не превышает 1.5%

Время выполнения тестового запроса

Разница времени выполнения не превышает 2.5%

Разница времени выполнения не превышает 2.5%

Итог по сценарию TPC-B

Производительность СУБД - практически не отличается.

Heavyweight

Производительность СУБД

Проявляется разница в производительности

Проявляется разница в производительности

  • До 54 соединений: разница производительности не превышает 3%

  • 65 - 93: Производительность ВМ2 выше до 17%

  • 111 соединений: резкая деградация производительности . Производительность ВМ2 на 21%

Время выполнения тестового запроса

Заметна разница времени выполнения тестового запроса

Заметна разница времени выполнения тестового запроса

  • До 45 соединений: разница времени выполнения не превышает 2%

  • с 54-111 соединений: Время выполнения тестового на ВМ2 увеличивается до 9%

  • 111 соединений: резкое увеличение времени выполнения тестового запроса. Время выполнения тестового на ВМ2 больше на 22%

Итог по сценарию Heavyweight

При сравнительно небольших нагрузках (до 45-54 соединений) производительность ВМ1 и ВМ2 не отличается.

При высоких нагрузках (54 и более) производительность ВМ2 выше. Однако и время выполнения тестового запросы тоже выше.

Общий итог

1.Только при использовании разных сценариев нагрузки можно получить полную картину производительности СУБД .

2. Для ОС использованной в тесте , при невысокой нагрузке на СУБД, расположение системного диска на HDD или SSD - несущественно .

Показать полностью 6
102

Наш мозг гниёт от коротких видео. Почему так?2

В декабре Оксфордский словарь признал "brain rot" (буквально "гниение мозга") словом года.

Про brain rot писали многие СМИ, но казалось, что это фигуральное выражение. Мол, если потреблять гору бессмысленного контента, то мы деградируем, и мозг "портится".

Но в мой пока ещё не совсем сгнивший (надеюсь) мозг закралось подозрение, что здесь есть более глубокий смысл. Я копнул и выяснил, что от тиктоков, шортсов и рилсов мозг гниёт в очень даже ПРЯМОМ СМЫСЛЕ. Алгоритмическая контентная жвачка ослабляет наше серое вещество в буквально, биологически. И вот как это работает:

В нашем мозге есть механизм под названием "хабенула" (иногда её называют уздечкой). Находится она в эпиталамической, задней части мозга. Это такая небольшая структура размером с горошину. Но у неё очень важная функция - по сути, это соединительный шлюз между разными отделами мозга, который регулирует и балансирует всю нашу систему вознаграждения.

Примерно так это выглядит.

Примерно так это выглядит.

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

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

Ну вы поняли...

Ну вы поняли...

В итоге, регулярный скроллинг ленты может очень серьезно расстроить (в смысле не "огорчить", а "сломать") всю работу этой системы. А если у человека сломалась хабенула, то он:

- Не может состредоточиться и сфокусироваться. Концентрация становится непозволительной роскошью.

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

- Испытывает одиночество и скуку, потому что не может "провалиться в поток" какого-то занятия. С отношениями и семейной жизнью у таких людей тоже всё непросто.

- Склонен к думскроллингу, и далее к депрессии.

- Да вообще ничего хорошего его не ждёт. Кроме новой порции дофамина от скроллинга, ведь если человек разучился фокусироваться, то остаётся лишь прокрастинировать.

В общем, brain rot - это не шутка. Это серьёзное негативное явление, которое сильно меняет наш мир прямо сейчас. Как там говорят: "Мир развалится, когда умрёт последний бумер"?

Но лично я думаю, что не всё потеряно. Да, тиктоки и алгоритмические ленты стали частью нашей жизни, и никуда они не денутся. Но мы всё ещё хозяева своего свободного времени. Лимитируйте время внутри ленты, ставьте таймеры и будильники, смотрите фильмы, читайте книги и общайтесь с родными БЕЗ ТЕЛЕФОНА. Ещё как вариант - приоритизируйте Телеграм над другими площадками. В Телеге нет ленты (большое спасибо за это П. Дурову), и потребление контента куда более осознанное. Надеюсь, так оно и останется.

Больше про нашу цифровую реальноть в моей Телеге, заходите (там точно нет алгоритмических лент и брейнрота).

Показать полностью 2
Отличная работа, все прочитано!