Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
Сообщество - Лига Новых Технологий
Добавить пост

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

1 807 постов • 16 833 подписчика

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

Все посты  Горячее  Лучшее  Поиск
0 просмотренных постов скрыто
3

Ученые превращают воду в электричество⁠⁠

Ученые превращают воду в электричество Энергия, Энергетика (производство энергии), Электричество, Физика, Вода, Пожар

Ученые превращают воду в электричество для питания нового датчика обнаружения пожара. Исследователи из Университета Чунг-Анг в Южной Корее разработали датчик пожара, который питается от миниатюрных гидроэлектростанций вместо батарей. Устройство может генерировать 0,42 В напряжения и 16-20 микроампер тока под инфракрасным светом. Время реагирования составило менее 10 секунд.

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

«Наша система высокого напряжения имеет потенциал стать устойчивым источником питания для различных сенсорных систем, таких как системы мониторинга здоровья и окружающей среды, которые требуют бесперебойной работы» — сказал Бёнгиля Хванга, руководитель проекта, доцент Школы интегративной инженерии Университета Чунг-Анг.

Показать полностью
Энергия Энергетика (производство энергии) Электричество Физика Вода Пожар
1

Москва 2045: Город будущего, который мы знаем⁠⁠

Вы когда-нибудь задумывались, какой будет Москва через 20 лет? Это уже не футуристические фантазии — всё, что мы описываем, базируется на реальных тенденциях и научных прогнозах.

🌆 Город-экосистема

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

🚀 Транспорт, который больше не стоит в пробках

Забудьте про московские пробки — их просто не существует.

  • Гиперпетли перемещают пассажиров на сверхскорости.

  • Автономные капсулы подбирают вас у дома и доставляют прямо к нужному зданию.

  • Летающие дроны-такси заменили дорогие поездки в аэропорт.

  • Пешеходные улицы на разных уровнях позволяют ходить пешком, не мешая транспорту.

🤖 Искусственный интеллект во всём

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

🧬 Люди будущего

Москва уже давно не просто город — это хаб знаний, науки и технологий. Здесь живут люди, которые работают не по 9 часов в офисе, а в цифровых пространствах. Большая часть рутины автоматизирована, а высшим искусством стала креативность.

🌱 Экология и чистый воздух

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

Москва 2045 — это не фантастика, а логичное продолжение трендов, которые мы наблюдаем уже сегодня. И знаете что? Этот город может стать реальностью быстрее, чем мы думаем.

📌 Как вам такая Москва? Делитесь своими мыслями в комментариях! 🚀

Москва 2045: Город будущего, который мы знаем Будущее, Технологии, Москва, Футуризм, Архитектура, Наука, Экология, Транспорт, Робот, Киберпанк, Тренд, Автоматизация, Космос, Инновации

Концепт-арт

Показать полностью 1
[моё] Будущее Технологии Москва Футуризм Архитектура Наука Экология Транспорт Робот Киберпанк Тренд Автоматизация Космос Инновации
41

PG_HAZEL - тактический уровень анализа метрик производительности(пример)⁠⁠

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

PG_HAZEL - тактический уровень анализа метрик производительности(пример) Postgresql, Субд, Производительность, Мониторинг, Анализ данных, Длиннопост

Начало и описание метрик производительности : PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL .

Продолжение : PG_HAZEL - оперативный уровень анализа метрик производительности.

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

Задачи по анализу производительности СУБД решаемые на тактическом уровне:

  1. Какая База Данных оказывает наибольшее влияние на производительность кластера в целом?

  2. Какой/какие SQL запросы оказывают наибольшее влияние на снижение производительности ?

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

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

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

PG_HAZEL - тактический уровень анализа метрик производительности(пример) Postgresql, Субд, Производительность, Мониторинг, Анализ данных, Длиннопост

Ось X - точка времени . Ось Y - комплексный индикатор производительности СУБД

Таким образом из графика можно сделать следующий вывод: наибольшее влияние на производительность кластера оказывает нагрузка в ходе нагрузочного тестирования при 33, 58 и 84 клиентских сессий pgbench.

Операционная скорость СУБД

PG_HAZEL - тактический уровень анализа метрик производительности(пример) Postgresql, Субд, Производительность, Мониторинг, Анализ данных, Длиннопост

Ось X - точка времени . Ось Y - операционная скорость СУБД

Benchmark СУБД

PG_HAZEL - тактический уровень анализа метрик производительности(пример) Postgresql, Субд, Производительность, Мониторинг, Анализ данных, Длиннопост

Ось X - точка времени . Ось Y - медианное время работы BENCHMARK СУБД

Вывод по анализу производительности СУБД

Нагрузка на тестовую СУБД оказывает влияние на производительность СУБД в целом при количестве клиентов pgbench = 33, 58, 84.

Ожидания СУБД

PG_HAZEL - тактический уровень анализа метрик производительности(пример) Postgresql, Субд, Производительность, Мониторинг, Анализ данных, Длиннопост

Ось X - точка времени . Ось Y - отношение времени ожиданий к общему времени работы СУБД

Вывод по анализу ожиданий СУБД

При количестве клиентов pgbench = 15 ожидания резко возрастают.

Выводы

По итогам анализа метрик производительности СУБД на тактическом уровне , можно сделать следующие выводы по производительности данной СУБД при данном характере нагрузки :

  1. Штатная нагрузка на СУБД составляет 15 клиентов.

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

Ближайшие планы развития оперативно-тактического комплекса "pg_hazel"

  1. Сбор и статистический анализ информации по ожиданиям клиентских SQL запросов

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

Показать полностью 5
[моё] Postgresql Субд Производительность Мониторинг Анализ данных Длиннопост
0

PG_HAZEL - оперативный уровень анализа метрик производительности⁠⁠

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

PG_HAZEL - оперативный уровень анализа метрик производительности Postgresql, Субд, Производительность, Мониторинг, Статистика, Анализ данных, Длиннопост

Начало и описание метрик производительности : PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL .

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

Сценарий нагрузочного тестирования

Стандартный сценарий аналогичный TPC-B.

Рост нагрузки , экспоненциально : --client=клиенты

Число имитируемых клиентов, то есть число одновременных сеансов базы данных.

Продолжительность тестового прохода = 10 минут.

Максимальная нагрузка = 100 клиентов.

Общее число проходов = 20

Результаты нагрузочного тестирования

Нагрузка на СУБД

PG_HAZEL - оперативный уровень анализа метрик производительности Postgresql, Субд, Производительность, Мониторинг, Статистика, Анализ данных, Длиннопост

Ось X - номер прохода. Ось Y - количество клиентов.

Операционная скорость тестового SQL запроса

PG_HAZEL - оперативный уровень анализа метрик производительности Postgresql, Субд, Производительность, Мониторинг, Статистика, Анализ данных, Длиннопост

Ось X - количество клиентов. Ось Y - операционная скорость.

Медианное время работы тестового SQL запроса

PG_HAZEL - оперативный уровень анализа метрик производительности Postgresql, Субд, Производительность, Мониторинг, Статистика, Анализ данных, Длиннопост

Ось X - количество клиентов. Ось Y - медианное время работы SQL запроса

Решение задач оперативного уровня

Как было определено в статье PG_HAZEL : оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL - общее описание.

В процессе анализа производительности СУБД , во-первых необходимо решить задачи оперативного уровня :

  1. В каком состоянии находится производительность СУБД в данный момент времени?

  2. Какая тенденция развития производительности СУБД на текущий момент или в прошлом?

  3. На сколько снизилась производительность СУБД по сравнению с выбранным промежутком из прошлого?

В каком состоянии находится производительность СУБД в данный момент времени? Какая тенденция развития производительности СУБД на текущий момент или в прошлом?

Для ответа на данные вопросы достаточно проанализировать график изменения комплексного индикатора производительности в ходе нагрузочного тестирования.

PG_HAZEL - оперативный уровень анализа метрик производительности Postgresql, Субд, Производительность, Мониторинг, Статистика, Анализ данных, Длиннопост

Ось X - точка времени снятия данных . Ось Y -комплексный индикатор производительности СУБД

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

На сколько снизилась производительность СУБД по сравнению с выбранным промежутком из прошлого?

Снижение производительности в ходе нагрузочного тестирования составило -20,1969%

Итог

Использование оперативно-тактического комплекса pg_hazel позволяет решать задачи анализа производительности СУБД на оперативном уровне.

Показать полностью 4
[моё] Postgresql Субд Производительность Мониторинг Статистика Анализ данных Длиннопост
0
3

PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL ⁠⁠

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

PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL Postgresql, Субд, Производительность, Мониторинг, Длиннопост, Статистика, Анализ данных

Предисловие и предыстория

Рgpro_pwr — инструмент стратегического мониторинга нагрузки на базу данных, который помогает DBA выявлять самые ресурсоёмкие операции.

pg_profile и pgpro_pwr: анализируем производительность БД

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

Задачи решаемые на оперативном уровне:

  1. В каком состоянии находится производительность СУБД в данный момент времени?

  2. Какая тенденция развития производительности СУБД на текущий момент или в прошлом?

  3. На сколько снизилась производительность СУБД по сравнению с выбранным промежутком из прошлого?

Задачи тактического уровня:

  1. Какая База Данных оказывает наибольшее влияние на производительность кластера в целом?

  2. Какой/какие SQL запросы оказывают наибольшее влияние на снижение производительности ?

Предпосылки создания инструмента pg_hazel.

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

В ходе предварительных исследований были проверены разные способы расчета метрики производительности СУБД .

Подробнее здесь: Производительность СУБД PostgreSQL — расчет метрики, временной анализ, параметрическая оптимизация

Однако , методы описанные в статье , к сожалению имеют свои аномалии.

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

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

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

Структура pg_hazel

Источником данных являются представления расширения pgpro_stats

G.3.4.1. Представление pgpro_stats_statements

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

G.3.4.2. Представление pgpro_stats_totals

Агрегированная статистика, собранная модулем, выдаётся через представление pgpro_stats_totals. Это представление содержит отдельные строки для каждого отдельного объекта БД

Данные собираются ежеминутно и агрегируются на 3-х уровнях:

  1. Уровень Кластера

  2. Уровень Базы Данных

  3. Уровень SQL запроса

Дополнительные данные pg_hazel

Как было указано ранее данные о среднем времени выполнения запроса собираемые в расширениях pg_stat_statements или pgpro_stats имеют очень серьезную проблему - среднее арифметическое не устойчиво к выбросам.

Подробнее здесь О проблеме использования mean_exec_time при анализе производительности PostgreSQL

Поэтому для корректного расчета среднего времени выполнения запроса используется не среднее арифметическое , а медиана.

К сожалению, расчет проводимый на уровне БД требует специальной подготовки для тестового запроса и дополнительных ресурсов для хранения и статистического анализа данных. Поэтому применяется не для всех SQL запросов а только для конкретных тестовых запросов:

  1. Benchmark кластера - медианное время выполнения тестового запроса для оценки производительности кластера в целом.

  2. Тестовый запрос стресс-тестирования - медианное время выполнения запроса по выбранному сценарию в ходе проведения стресс-теста(нагрузочного тестирования)СУБД.

Данные собираемый pg_hazel

1. Уровень Кластера

  1. Операционная скорость - количество завершенных операций и сформированных строк за период .

  2. Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за период.

  3. Активные сессии - количество активных сессий на точку времени.

  4. Ожидания - количество событий ожидания СУБД за период.

  5. BUFFERPIN - количество событий ожидания bufferpin за период.

  6. EXTENSION - количество событий ожидания extension за период.

  7. IO - количество событий ожидания io за период.

  8. IPC - количество событий ожидания ipc за период.

  9. LOCK - количество событий ожидания lock за период.

  10. LWLOCK - количество событий ожидания lwlock за период.

  11. WAITING_RATIO - относительная доля ожиданий СУБД в общем времени работы СУБД за период.

  12. CORRELATION - коэффициент корреляции между количеством активных сессий и операционной скоростью.

  13. BENCHMARK - медианное время выполнения тестового запроса.

  14. CPI - комплексный индикатор производительности = Операционная скорость / BENCHMARK .

2.Уровень Базы данных

  1. Операционная скорость - количество завершенных операций и сформированных строк за период .

  2. Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за период.

  3. Активные сессии - количество активных сессий на точку времени.

  4. Ожидания - количество событий ожидания БД за период.

  5. BUFFERPIN - количество событий ожидания bufferpin за период.

  6. EXTENSION - количество событий ожидания extension за период.

  7. IO - количество событий ожидания io за период.

  8. IPC - количество событий ожидания ipc за период.

  9. LOCK - количество событий ожидания lock за период.

  10. LWLOCK - количество событий ожидания lwlock за период.

  11. WAITING_RATIO - относительная доля ожиданий БД в общем времени работы БД .

3.Уровень SQL запроса

  1. Операционная скорость - количество завершенных операций и сформированных строк за период .

  2. Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за за период .

  3. Активные сессии - количество активных сессий на точку времени.

  4. Ожидания - количество событий ожидания SQL запроса за период.

  5. BUFFERPIN - количество событий ожидания bufferpin за период.

  6. EXTENSION - количество событий ожидания extension за период.

  7. IO - количество событий ожидания io за период.

  8. IPC - количество событий ожидания ipc за период.

  9. LOCK - количество событий ожидания lock за период.

  10. LWLOCK - количество событий ожидания lwlock за период.

  11. WAITING_RATIO - относительная доля ожиданий SQL запроса в общем времени работы SQL запроса .

Важное уточнение

Для данных используется медианное сглаживание - короткий период 10 минут , долгий период 60 минут.

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

Показать полностью 1
[моё] Postgresql Субд Производительность Мониторинг Длиннопост Статистика Анализ данных
0
124

Беспилотный трамвай самостоятельно переводит стрелки. Новую систему разработали в Москве⁠⁠

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

Инновационное решение включает в себя:

🔹 Защищенный канал связи между трамваем и «умными» стрелками.

🔹 Модернизированные стрелочные переводы с системой обогрева для холодной погоды.

🔹 Программный код для управления стрелками.

🔹 Специальное оборудование возле каждого стрелочного перевода и внутри трамвая.

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

Первый в России беспилотный трамвай проехал 2 тысячи км по улицам Москвы

Какие устройства помогают беспилотному трамваю «видеть»

Показать полностью
[моё] Транспорт Общественный транспорт Трамвай Беспилотный транспорт Москва Технологии Разработка Инновации Видео Короткие видео
73
4

Системные проблемы в ИТ⁠⁠

Предисловие

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

Полностью статья : Системные проблемы в ИТ

Избранные отдельные самые яркие цитаты .

Подписываюсь Под Каждым Словом.

Раболепие

Немаловажная проблема — осознать зависимость, которая напрочь тормозит развитие как человека, так и все остальное. Такое качество человека, как целеустремленность, не играет никакой роли. Никто не будет подставлять свою ипотеку или иные финансовые обязательства. Лучше промолчать, чем двигать дела в нужно русло. Работая немало лет на одном производстве мороженого, я поражался подходу в работе под лозунгами «исторически сложилось». Такое можно встретить сплошь и рядом, я бы даже сказал, так почти везде. Это всего лишь маска, под которой, можно сказать, «сидеть на попе ровно». Как ни звучит противоречиво, но высокий уровень ЗП лишь только усугубляет эту ситуацию. Так проще во всех смыслах.

Банальный бардак

Наверное, нигде не видел за свой опыт такого бардака, как в ИТ. За последние 15 лет активно занимаюсь тем, что привожу все в порядок. Чаще всего приходится начинать с разрухи в головах. Такие базовые вопросы, как «что такое ITIL», «в чем суть его», «что такое процесс или процессно‑ориентированный подход» и т. д. Это всего лишь следствие того, что, по сути, все заточено под временщичество. Ты приходишь в новую организацию, осознаешь проблемы, вкладываешься в решение этих проблем в угоду кармана собственника, правда, не совсем ясно, зачем. Любое изменение приводит к сопротивлению, грызне, волюнтаризму, и, самое главное, итог этого — минимум благодарности.

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

Роль в компании

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

Низкая квалификация руководящего состава

За многие года своей работы в этой сфере никогда не видел руководителя, за которым можно идти, способного вытянуть ИТ-процессы, или способного даже предложить цель. Конечно, мой опыт достаточно субъективен, но за десятки лет обучения разного рода специалистов глаз совсем не видит.

Право

Вишенкой на торте является то, что в ИТ-отрасли право и законы находятся где‑то в стороне. Причем начинается это с процесса принятия на работу. Даже тогда, когда ИТ-отрасль, как структура, обязана соблюдать законы с целью автоматизации процессов, но нет. Конечно, многим может показаться, что тут в этой статье я перегибаю палку, но нет. Далеко за примерами не надо идти. Офер — ну такая бумажка, которая не имеет никакой юридической силы на данный момент. Есть более существенные нарушения, если служба персонала термирует кандидатов. Еще напрямую нарушают ТК РФ, если Вам говорят про оверквалифайд, то есть если ваши навыки и опыт сильно больше, чем нам необходимо. Вообще такое и без ТК РФ в здравом уме не может приходить в голову, тогда как в нормальной системе людей с опытом должны хотя бы немного ценить. Все это несет системный характер.

Показать полностью
IT Менеджмент Itil Глобальные проблемы Работа
3
Отличная работа, все прочитано!