Admin Oracle, Linux, AIX, Kafka, devops
В данной статье я покажу на практическом примере как устроена многопоточность в Python, расскажу про потоки, примитивы синхронизации и о том зачем они нужны.
Изначально я планировал что это будет простая и короткая заметка, но пока готовил и тестировал код нашел интересный неочевидный момент связанных с внутренностями CPython, так что не спешите закрывать вкладку, даже если вы уверены что вы знаете о потоках в Python всё :)
Одержимость водой начала заходить за какие-то крайности. Рекомендации по ее употреблению можно услышать уже от любого эксперта. Хочешь больше зарабатывать - пей 8 стаканов воды. Хочешь наладить отношения - пей больше воды. Хорошо учиться? Построить бизнес? Лучше спать? Ну, вы поняли.
"Ну пили бы и пили! Калорий нет, в туалет сходит, все вышло. Это же лучше, чем не пить!" Только все далеко не так безобидно, что ученые уже давно обеспокоены нездоровым отношением к гидрации организма.
Буквально на секунду представьте, что у вас есть парочка здоровенных кластеров Apache Kafka, каждый из которых держит по нескольку миллионов rps. И тут вас попросили зеркалировать топик из одного кластера в другой. Максимально близко к реалтайму, да ещё и с некоторыми специфическими условиями. Если стало страшно, интересно или страшно интересно, то это статья для вас.
Под катом я расскажу, что такое зеркалирование и зачем оно нужно. Как нам перестало хватать Mirror Maker’а. Поговорим о возможных решениях и выборе между ними. И дам подробную инструкцию, как вам развернуть такое решение у себя.
На одном крупном проекте мы, инженеры компании «Инфосистемы Джет», столкнулись с типичной проблемой стандартных инсталляций Zabbix на больших объемах - производительностью и низкой отказоустойчивостью базы данных. Конфигурация Zabbix была следующей:
• один Zabbix-сервер;
• множество прокси;
• сервер БД PostgreSQL с расширением TimescaleDB;
• сервер Grafana для визуализации данных.
При обычной нагрузке (12000 NVPS) система работала стабильно, но стоило произойти массовой аварии на инфраструктуре или перезагрузке сервера/прокси, как производительности БД не хватало. В такие моменты очень быстро накапливались очереди обработки данных, заканчивались кэши – система фактически прекращала работу. Непростую ситуацию ухудшали еще ложные срабатывания (данные не всегда могли попасть в БД) и рассылка уведомлений ответственным администраторам, проверявшим состояние систем в WEB-интерфейсе. Для восстановления работы приходилось перезапускать компоненты друг за другом, контролируя нагрузку на БД.
Проблему оперативно решили при помощи снижения количества чанков для хранения трендов. Причина происходящего крылась в некорректном партиционировании трендовых данных. Детально о проблеме и методах решения можно почитать в баг-репорте производителя (ZBX-16347). Он помог нам в устранении аварии, но ограничиваться только им не стали – одного репорта, на наш взгляд, было недостаточно. Мы стали смотреть шире и задумались над альтернативными решениями.
А какие варианты есть?
Начнём с того, что наибольшая нагрузка на БД в Zabbix создается на операциях с историческими данными и происходящими в мониторинге событиями. Это таблицы: history, history_uint, history_text, history_str, history_log, events, problems. Производитель предлагает использовать следующие БД: MySQL, PostgreSQL и Oracle DB. Кроме того, исторические данные можно отправлять и в Elasticsearch.
google.combaidu.cnyandex.ru
Привет, Хабр! Мы продолжаем цикл статей, посвященных сборке игрового ПК. Даже если вы планируете поручить это профессиональным сборщикам как в XCOM-SHOP.RU, есть ряд факторов, о которых лучше всего узнать самостоятельно, чтобы будущая сборка радовала вас как можно дольше.
Сегодня мы поговорим о твердотельных накопителях. Несмотря на то что нередко их выбор оставляют напоследок, при ответственном подходе имеет смысл заранее определиться с тем, какие SSD вы будете использовать в своей сборке и в каком количестве.
В современном быстро меняющемся цифровом мире автоматизация является важной частью стратегии любой организации. С распространением облачных вычислений, DevOps, непрерывной интеграции и доставки спрос на инструменты автоматизации вырос в геометрической прогрессии. Ansible — инструмент автоматизации с открытым исходным кодом, который стал одним из самых популярных решений для автоматизации управления инфраструктурой, развертывания приложений и управления конфигурацией.
В этом посте мы рассмотрим, как Ansible может помочь вам автоматизировать всё в вашей инфраструктуре.
Приветствую, Хабр! Одной из интереснейших тем для обсуждения из современной криптографии, на мой взгляд, является тема эволюции криптографических ключей и связанных с ними протоколов, обеспечивающих наличие ряда дополнительных полезных свойств систем, основанных на асимметричных криптоалгоритмах.
Различные методы эволюции ключей (терминология не устоялась, предпочитаю использовать такой перевод словосочетания «key-evolving techniques») асимметричных криптоалгоритмов позволяют защититься от компрометации секретных ключей путем периодической модификации ключевых пар. Подобная защита направлена не на предотвращение компрометации секретного ключа, а на минимизацию последствий такой компрометации: поскольку ключи периодически модифицируются, эволюционируют, данные методы позволяют ограничиться отрицательным воздействием компрометации ключа на свойство целостности или конфиденциальности сообщений, зашифрованных или подписанных только в течение определенного, относительно короткого периода, оставляя защиту сообщений других периодов ненарушенной. Большинство протоколов с эволюцией ключей подразумевает достаточно активный обмен сообщениями между сторонами защищенного обмена данными. При этом бывают сценарии, когда возможности для интерактивного взаимодействия у сторон отсутствуют.
Далее предлагаю обсудить различные известные методы эволюции ключей (обеспечивающие различные полезные свойства криптосхем: от секретности в будущем до устойчивости к вторжениям), после чего описать возможный вариант протокола модификации ключевых пар для неинтерактивных применений.
Довольно часто встречаются статьи про разные варианты обмана покупателей в интернет магазинах. То пришлют кусок камня вместо Айфона, то внутри твердотельного диска будет обычная флешка с гайками как на КДПВ. Поэтому при оформлении новой покупки нужно строго подходить к выбору продавца (не новый, высокий рейтинг, мало отрицательных отзывов и пр.) и не менее важно, в каком магазине совершается покупка.
Сам я вроде не новичок в плане интернет покупок, да и Алиэкспресс довольно неплохой магазин в плане оформления возвратов и разрешения споров с продавцами. Но как оказалось и на старуху бывает проруха. В результате я столкнулся возможно с новым видом развода покупателей на Алиэкспресс о котором раньше не читал. Ну или информация о подобной схеме развода прошла мимо меня.
Как говорится, предупрежден, значит вооружен. И данная статья — предупреждение другим возможным потенциальным жертвам, а так же простые рекомендации как не попадать на ту же самую уловку, на которую попался я при оплате очередного "выгодного" предложения из Китая.
В предыдущих статьях мы рассмотрели архитектуру решения Apache Kafka, развернули продукт и разобрались с отправкой и получением сообщений. Можно было бы, конечно, дальше погрузиться в тему использования данного решения, но в Интернете есть множество различных публикаций с примерами использования Kafka для различных задач и различных сред разработки. Поэтому данная статья будет целиком и полностью посвящена такой важной теме, как обеспечение безопасности Apache Kafka.
По своему предназначению Kafka является посредником между различными системами при их обмене сообщениями. Для этого, как мы помним, есть топики и разделы. Но проблема заключается в том, что при стандартной настройке Kafka по умолчанию, любой пользователь или приложение может писать любые сообщения в любой топик, а также считывать данные из любых топиков. Естественно, для сколько-нибудь промышленного применения системы такой подход недопустим. Например, в случае, когда несколько приложений используют один и тот же кластер Kafka, или когда кластер используется в качестве облачного сервиса для сторонних приложений, ну и естественно, когда в Kafka начинает обрабатываться конфиденциальная информация.
В статье мы будем говорить о встроенных в Kafka механизмах защиты и не будем касаться использования каких-либо наложенных средств.
Я уже рассказал об этапах выполнения запросов и о статистике и перешел к способам доступа к данным. В прошлый раз темой статьи было последовательное сканирование, а сегодня поговорим о сканировании индексном.
Прежде чем погружаться в детали индексного доступа, надо было бы рассказать про интерфейс индексных методов. Но я это уже делал в статье про индексы, и, хотя та серия несколько устарела, повторяться не буду. Если слова «класс операторов» и «свойства методов доступа» не находят отклика в душе, статью лучше перечитать.
В условиях современности не составляет особенных проблем использовать готовую нейросеть для обучения ее на основе своих данных. В зависимости от типа модели, структуры и прочего можно получить различные прогнозные данные. Тут на первый план выходят задача обучения и тестирования модели.
Мы, коллектив из Московского Энергетического Института, написали эту заметку, для того чтобы сложный мир нейронных сетей стал для вас чуточку проще.
Машинное обучение это незаменимый инструмент для решения задач, которые легко решаются людьми, но не классическими программами. Ребенок легко поймет, что перед ним буква А, а не Д, однако программы без помощи машинного обучения справляются с этим весьма средне. И едва ли вообще справляются при минимальных помехах. Нейросети же уже сейчас решают многие задачи (включая эту) намного лучше людей. Их способность обучаться на примерах и выдавать верный результат поистине очаровывает, однако за ней лежит простая математика. Рассмотрим это на примере простого перцептрона.
Данная статья представляет собой пересказ-конспект первой части книги Тарика Рашида "Создай свою нейросеть" для тех, кто начал изучать тему, не понял отдельные детали или с трудом охватывает общую картину.
У нас не подгорит!
Как PostgreSQL хранит большие значения столбцов? Какие явные и неявные ограничения есть у существующего механизма хранения? Что за проблемы вызваны этими ограничениями? И как можно решить эти проблемы, и расширить возможности PostgreSQL? Об этом, и чуть больше - данная статья.
В этой статье мы разберём несколько аномальных случаев высокой нагрузки в СУБД PostgreSQL. Что это такое? Обычно PostgreSQL хорошо показывает себя под нагрузкой и оправдывает ожидания в отношении производительности — она остаётся высокой. Но при определённых профилях нагрузки СУБД может вести себя не так, как мы ожидаем. Это и есть аномалии, на которых мы сосредоточимся в данной статье (для тех, кто предпочитает видео, эта информация доступна в виде записи доклада на HighLoad++).
Наша компания помогает обслуживать мультитерабайтные базы данных в крупных проектах, поэтому мой рассказ об аномалиях основан на реальном опыте промышленной эксплуатации СУБД в Postgres Professional — порой мы сталкиваемся с тем, что СУБД ведёт себя не так, как мы ожидали.
Также в рамках статьи мы рассмотрим следующее:
Вы можете использовать это руководство для получения практической информации о том, как найти и установить последнюю версию Java, понять различия между дистрибутивами Java (Adoptium, AdoptOpenJdk, OpenJDK, OracleJDK и т. д.), а также получить обзор функций языка Java, включая версии 8–19.
Кофеин хуже наркотиков, и тот, кто его пьет живет в постоянной зависимости. Эту фразу я слышал в свой адрес каждый раз, когда приглашал друзей домой. Четыре разных сорта кофе, пара френч-прессов и турка для заваривания. Не то, чтобы все это было жизненно необходимо, но если начал варить, то остановиться достаточно сложно. Впрочем, как оказалось, остановиться вообще не проблема.
Предлагаю ознакомиться с расшифровкой доклада начала 2019 года Алексея Лесовского — «Поиск и устранение проблем в Postgres с помощью pgCenter»
Время от времени при эксплуатации Postgres'а возникают проблемы, и чем быстрее найдены и устранены источники проблемы, тем благодарнее пользователи. pgCenter это набор CLI утилит которые является мощным средством для выявления и устранения проблем в режиме "здесь и сейчас". В этом докладе я расскажу как эффективно использовать pgCenter для поиска и устранения проблем, в каких направлениях осуществлять поиск и как реагировать на те или иные проблемы, в частности, как:
