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

Система построена на базе стека EHK (Elasticsearch/Heka/Kibana), с прицелом на работу практически в реальном времени. Особый упор сделаю на тонкие места и нюансы обработки миллиардов строк текста в сутки.

Мои ощущения от процесса работы

Недавно я решил заняться ускорением восстановления нашей базы данных в dev-окружении. Как и во многих других проектах, база вначале была небольшой, но со временем значительно выросла. Когда мы начинали, ее размер было всего несколько мегабайт. Теперь упакованная база занимает почти 2 ГБ (несжатая — 30 ГБ ). Мы восстанавливаем dev-окружение в среднем раз в неделю. Старый способ проведения операции перестал нас устраивать, а вовремя подвернувшаяся в Slack-канале картинка “DB restore foos?” побудила меня к действию.

Ниже описано, как я ускорял операцию восстановления базы данных.

• Сжать все многочисленные скрипты JS и стили CSS
• Соединить все полученные файлы в один JS и в один CSS
• Сжать полученные два файла в формат GZIP, который понимают почти все браузеры и умеют распаковывать на лету
• Прописать такой .htaccess, который заставляет браузеры кэшировать данные два файла

• JS: сжато в gzip 26 698 B, сжато без gzip 95 796 B, было 120 147 B
• CSS: сжато в gzip 46 049 B, сжато без gzip 160 001 B, было 281 870 B

<link rel="stylesheet" type="text/css" href="min/styles_1349888114.cssgz" />
<script src="min/all_1349888114.jsgz" /></script>

Усаживайтесь поудобнее, ребята! Сегодня мы с вами разберём следующий увлекательный вопрос: что будет, если заинлайнить вообще всё?

Если вы пока не знакомы с техникой встраивания (inlining) то примите к сведению, что в сообществе специалистов по разработке компиляторов многие, в том числе очень авторитетные фигуры (например, Чендлер Каррут) считают этот приём наиважнейшим при оптимизации компиляторов. Подробнее о том, как устроено встраивание, рассказано здесь — мы беззастенчиво хвалимся той презентацией, с которой выступили перед участниками конференции LLVM Developers' Meeting по межпроцедурной оптимизации. Я рассказывал о встраивании и очень рекомендую вам посмотреть хотя бы первые 6 минут. В этом видео я рассказываю, почему встраивание — очень простое преобразование, а вот тут вашему вниманию предлагается реализация встраивания, предложенная великим Крисом Латтнером уже около 20 лет назад — в ней всего около 200 строк кода. К сожалению, сегодня даже само преобразование пропорционально выросло: в качестве примера взгляните хотя бы на InlineFunction.cpp.

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

• Уязвимость к hash flooding.
• В случае защиты от hash flooding случайными seed порядок итераций становится недетерминированным, что мешает при тестировании снэпшотов, создании воспроизводимых сборок и так далее.
• При вставке может требоваться рехэширование, что в наихудших случаях создаёт для больших хэш-таблиц ужасные задержки.
• Многократное увеличение больших распределений памяти без фрагментации сложно реализовать в целевых платформах wasm, потому что трюки с виртуальной памятью недоступны, а для страниц невозможно выполнить unmapping.
• Векторные команды в wasm ограничены, а команды AES отсутствуют. Это делает многие хэш-функции ещё более медленными.

У каждого образа Docker есть свой размер, который он занимает на жёстком диске. Порой бывает так, что контейнер с запущенным приложением на языке программирования Go, который содержит в себе всего лишь одну строчку с выводом фразы «Hello, world!» может занимать сотни Мб, в то время как существуют образы содержащие легковесные ОС весом всего лишь 5 Мб (alpine).

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

Введение

Привет, меня зовут Евгений. Я разрабатываю инфраструктуру поиска Яндекс.Маркета. Хочу рассказать, как graceful degradation помогает нам обрабатывать больше запросов, чем физически могут выдержать наши сервера, и что происходит с поиском в Маркете, если один из дата-центров отключается.

		
if a > b && c*2 > d {
	....
}
// и
if a <= b  { 
  continue;
}
if c*2 > d {
 ....
}

Фотография пользователя Wonderlane, Flickr

NGINX великолепен! Вот только его документация по ограничению скорости обработки запросов показалась мне, как бы это сказать, несколько ограниченной. Поэтому я решил написать это руководство по ограничению скорости обработки запросов (rate-liming) и шейпингу трафика (traffic shaping) в NGINX.

Алексей Владышев ( alexvl )

Prometheus прекрасно подходит для краткосрочного мониторинга, но у этого решения есть свои ограничения по масштабу, и если вы столкнулись с высоким потреблением памяти/CPU, снижением скорости запросов или вам требуются уникальные лейблы вида user ID, то стоит подумать над внедрением альтернатив. На наш взгляд следующими после Prometheus в линейке стоят Thanos, Cortex, Mimir или VictoriaMetrics. Объективное, насколько это возможно, сравнение характеристик этих решений мы и проведем ниже.

СОДЕРЖАНИЕ

• 3.1. Что важнее: простота или масштаб?
• 3.2. Стоимость
• 3.3. Надёжность и высокая доступность
• 3.4. Насколько подходит по задачам?

• 6.1. Параллельный запуск и проверка
• 6.2. Мониторинг очередей remote_write
• 6.3. Аккуратное отключение Prometheus
• 6.4. Резервное копирование
• 6.5. Тестирование

• 10.1 Используйте recording rules для тяжёлых агрегаций
• 10.2 Не злоупотребляйте лейблами с высокой кардинальностью
• 10.3 Downsample старые точки данных
• 10.4 Осторожно с федерацией Prometheus

Я ненавижу код бенчмаркинга, как и любой другой человек. Гораздо веселее притвориться, что твоё кэширование значения увеличило производительность на 1000%, чем проверять это тестами. Увы, бенчмаркинг JavaScript по-прежнему необходим, особенно потому, что JavaScript используется (когда не должен?) во всё более чувствительных к производительности приложениях. К сожалению, из-за множества базовых архитектурных решений языка, JavaScript никак не упрощает выполнение бенчмаркинга.

Часть этого поста я написал, всё ещё находясь в Антарктиде, но уеду, ещё не закончив его.

Я просматривал свои старые черновики постов и понял, что этот почти завершён.

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

В течение 14 месяцев работы в Антарктиде доступ в Интернет у меня был только через крайне ограниченное число спутниковых каналов, предоставленных Антарктической программой США (United States Antarctic Program).

В начале поста нужно дать особое примечание:

Хотя я был ИТ-сотрудником United States Antarctic Program, всё, о чём я буду говорить в этом посте, основано или на публично доступной информации, или на моих личных наблюдениях как обычного участника программы, живущего во льдах.

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

При приёме на работу я подписал условия, ограничивающие публичное раскрытие непубличной информации о материалах, связанных с информационными технологиями. Я намерен полностью соблюдать эти ограничения. Такие ограничения типичны для сдельной работы на правительство США.

Маловероятно, что я смогу ответить на дополнительные вопросы по темам, обсуждаемым в этом посте. Я тщательно старался писать максимально подробно, не допуская при этом раскрытия непубличной информации о правительственных ИТ-системах.

Данная информация отражает мой личный опыт нахождения в Антарктиде с августа 2022 года по декабрь 2022 года в Мак-Мердо, а затем с декабря 2022 года по ноябрь 2023 года на Южном полюсе.

Привет! Меня зовут Антон Жуков, я руковожу группой разработки в Сбермаркете. В профессии я уже более 12 лет, с Golang работаю с 2016 года, а с Kubernetes — с 2018 года.

В этой статье расскажу об основах Kubernetes, возможных проблемах и решениях, а также о том, как грамотно использовать ресурсы этой платформы, чтобы выжать максимум из Go-приложений. Кроме того, в конце статьи я опишу кейс настройки GOMAXPROCS на примере нашего приложения и расскажу, как нам удалось повысить его производительность на 20-50%.

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

Мы в HOSTKEY решили попробовать пассивное охлаждение и внедрили разработку компании «Теркон» — создателя систем охлаждения для космических аппаратов.