Как-то было свободных полчаса перед встречей. Ни туда, ни сюда. Дай, думаю, сниму трейс с приложения. Вдруг что-то интересное найдётся.
А в качестве бонуса: использование var может привести к багам? Узнаем в самом конце ;)
Приложение тормозит. Пользователи в ярости. Продакшн-сервер гудит кулерами, а дашборды показывают красные пики. Первый инстинкт — звонить админам, требовать больше памяти и процессоров. Но чаще всего проблема не в железе. Она сидит глубже. В самом сердце системы — в базе данных. Имя этой проблемы — индексы. Или, точнее, их кривое использование.
Индекс — это как указатель в толстенном справочнике. Без него, чтобы найти нужный термин, вы обречены листать страницу за страницей. С ним — вы мгновенно открываете нужный раздел. Но что, если указатель сам размером с полкниги? Или ведет не туда? Такой помощник только вредит. С индексами в БД всё то же самое. Грамотная стратегия индексирования — это полет. Ошибочная — это бег в мешках по болоту.
Привет, Хабр!
Сегодня рассмотрим, как работает fillfactor в PostgreSQL — тот самый параметр, который никто не трогает, пока таблицы не начинают раздуваться как на дрожжах. Разберём, зачем он нужен, что происходит при UPDATE, когда стоит менять его вручную и как не наломать дров.
В первой части нашего исследования мы провели сравнительный анализ облачных хранилищ, рассматривая предложения различных провайдеров, включая крупные компании и менее известные игроки на рынке. Мы изучили ключевые аспекты, такие как уровень технической поддержки, доступные конфигурации серверов и дополнительные услуги, что позволило оценить сильные и слабые стороны различных решений в контексте конкурентной среды.
Теперь мы переходим ко второй части нашего анализа, в которой сосредоточимся на ценовой политике облачных хранилищ. Мы сравним тарифные планы различных провайдеров, чтобы выяснить, как они позиционируются на рынке с точки зрения стоимости услуг. Этот анализ поможет понять, насколько конкурентоспособны цены и как они соотносятся с качеством предоставляемых услуг.
PHPBench - это, кажется, крайне не популярный фреймворк для тестирования производительности кода на PHP. По крайней мере за 18 лет он мне ни разу нигде не встретился, а услышал об нём примерно года назад. Фреймворк PHPUnit-подобный, где бенчмарки, как и тесты из PHPUnit объединяются в классы, группы и т.д. и т.п. Чтобы много не болтать, давайте напишем чуть кода и отбенчмаркаем его.
Я пошагово опишу всё, чтобы вы могли быстро повторить всё это у себя. Вначале создаём директорию в которой будем химичить и переходим в неё:
Микросервисы перевернули игру в разработке приложений. Они сулят гибкость, отличную масштабируемость, командам — больше независимости. Но вот переход на них принес с собой и новые головные боли. Особенно когда дело доходит до развертывания. Управлять кучей мелких, отдельно выкатываемых кусочков — задачка та еще. Старые приемы тут часто пасуют. Нужны свежие идеи, другие инструменты, а главное — по‑другому смотреть на вещи.
Оптический бюджет в ВОЛС: Невидимая грань между работоспособностью и отказом. Как не оступиться в эпоху 100G+ и плотных ЦОД?
Представьте: вы спроектировали идеальную магистраль, выбрали "качественные" компоненты, смонтировали... И линк не поднимается. Или работает, но с ошибками. Или стабилен сегодня, но "падает" при нагреве летом. Часто корень зла кроется в нарушении оптического бюджета мощности (Optical Power Budget - OPB). Это не абстрактная цифра из даташита – это фундаментальный закон сохранения энергии в мире оптики. Игнорируете его – гарантируете себе головную боль. Сегодня, с ростом скоростей (100G, 400G, 800G) и плотности в ЦОД, понимание и точный расчет OPB критичны как никогда. Давайте разберемся, что это, из чего складывается, где поджидают ловушки и как избежать фатальных ошибок.
1. Суть Оптического Бюджета: Проще, Чем Кажется (На Словах)
По сути, OPB – это разница между мощностью, которую передатчик (Tx) излучает в волокно, и минимальной мощностью, необходимой приемнику (Rx) для корректной работы (чувствительностью) с учетом требуемого запаса (System Margin).
Упрощенная формула:OPB = P_Tx_min - P_Rx_min - System_Margin
Где:
Сложная и тяжелая статья с непропорционально простым выводом. Вспомним фон Неймана, затронем процессорный кеш, поговорим про регистры и компиляторы. Тем, кому не хочется погружаться в детали, достаточно прочитать только Введение и Выводы.
Усаживайтесь поудобнее, ребята! Сегодня мы с вами разберём следующий увлекательный вопрос: что будет, если заинлайнить вообще всё?
Если вы пока не знакомы с техникой встраивания (inlining) то примите к сведению, что в сообществе специалистов по разработке компиляторов многие, в том числе очень авторитетные фигуры (например, Чендлер Каррут) считают этот приём наиважнейшим при оптимизации компиляторов. Подробнее о том, как устроено встраивание, рассказано здесь — мы беззастенчиво хвалимся той презентацией, с которой выступили перед участниками конференции LLVM Developers' Meeting по межпроцедурной оптимизации. Я рассказывал о встраивании и очень рекомендую вам посмотреть хотя бы первые 6 минут. В этом видео я рассказываю, почему встраивание — очень простое преобразование, а вот тут вашему вниманию предлагается реализация встраивания, предложенная великим Крисом Латтнером уже около 20 лет назад — в ней всего около 200 строк кода. К сожалению, сегодня даже само преобразование пропорционально выросло: в качестве примера взгляните хотя бы на InlineFunction.cpp.
В вышеупомянутом видео я рассказываю, что у встраивания есть свои недостатки. Иными словами, встраивание позиционируется как супер-пупер инструмент в арсенале компиляторщика, но пользоваться этой штукой следует с осторожностью. И следует ли вообще?
Поток — это последовательность элементов данных, предоставляемых за некоторое время. Концепция потока (stream) позволяет обрабатывать или передавать данные поэлементно, а не как одно целое. Потоки особенно полезны в сценариях, когда приходится работать с большими множествами данных, непрерывными данными или данными реального времени.
Данных в современных приложениях становится все больше, прямо как снежный ком. И рано или поздно многие системы начинают задыхаться – база данных не справляется. Когда старые добрые методы вроде подкрутки запросов, добавления индексов или покупки сервера помощнее уже не помогают (или стоят как крыло от самолета), на помощь приходит горизонтальное масштабирование.
Данный материал предназначен для быстрой и последовательной установки драйверов NVIDIA, в том числе для видеокарт 50xx серии, а также настройки NVIDIA Container Toolkit. Эта инструкция актуальна для Linux-систем на базе Ubuntu и других Debian-совместимых дистрибутивов.
Prometheus прекрасно подходит для краткосрочного мониторинга, но у этого решения есть свои ограничения по масштабу, и если вы столкнулись с высоким потреблением памяти/CPU, снижением скорости запросов или вам требуются уникальные лейблы вида user ID, то стоит подумать над внедрением альтернатив. На наш взгляд следующими после Prometheus в линейке стоят Thanos, Cortex, Mimir или VictoriaMetrics. Объективное, насколько это возможно, сравнение характеристик этих решений мы и проведем ниже.
Приложения тормозят. Пользователи уходят. Бизнес недоволен. Знакомая картина? Часто корень зла – медленный доступ к данным. Кеширование может стать спасательным кругом. Но это не серебряная пуля. Неправильно настроенный кеш – источник новых проблем, иногда похуже старых.
Когда в проекте используется составной B-tree индекс, важно не просто "создать индекс", а сделать это правильно — иначе запросы могут не только не ускориться, но и начать работать медленнее. Возникает логичный вопрос: как выбрать порядок колонок, чтобы индекс действительно работал эффективно? Брутфорсом? По интуиции? По селективности?
В этой статье я расскажу, как подходить к построению составных индексов в PostgreSQL, на что реально влияет порядок колонок. Также разберём простое правило ESR, которое помогает упростить выбор и получать стабильный прирост производительности на всех стендах.
Сейчас в сети много инструкций по установке GUI-панелей, таких как Marzban, 3x-ui или новая RemnaWave. Однако, все они избыточны для домашнего использования, так как предназначены для крупных проектов и отличаются высокой сложностью настройки.
Мануал, который необходимо пройти до получения первого рабочего конфига, занимает более 10 страниц. Кроме того, подходящий конфиг для Xray нужно ещё поискать и правильно настроить — с этим отлично справляется Bash-скрипт autoXRAY.
Без GUI и базы данных Xray потребляет меньше ресурсов сервера и отлично подходит для запуска на слабых VPS-конфигурациях!
При каждом запуске autoXRAY генерирует новые UUID, ключи и пароли для защиты пользователей, а также выбирает случайные SNI из списка для маскировки.
В прошлом году, просматривая пул-реквесты по поводу компилятора Rust, я обратил внимание на #126013. В нём к некоторым пакетам компилятора добавлялась проверка unreachable_pub. Естественно, меня это заинтересовало, так как на тот момент я о такой проверке не знал. Но, разобравшись с её описанием, я тем более удивился, так как эта проверка показалась мне абсолютным нонсенсом! Поговорив об этом с авторами пул-реквеста, я осознал, что, пожалуй, достаточно странно представляю себе, как устроена видимость в Rust. Как минимум, я воспринимал её не «так, как она была задумана».
Эта тема показалась мне достаточно интересной, чтобы раскрыть её в блоге. В этой статье я коротко объясню, как именно работает видимость в Rust, а потом опишу два достаточно разных способа её использовать. Если вы знаете, как в Rust устроена видимость, можете смело пропускать введение и переходить к главной теме. Оговорюсь, что в этом посте я просто вывалил различные мысли на данную тему, скопившиеся у меня, так что не ожидайте найти здесь каких-либо супер-откровений :).
В этой статье мы рассмотрим, что такое Kubernetes, в каких случаях его использование оправдано, и разберем вопросы, которые вы можете встретить на собеседованиях.
Вопрос "какая репликация MySQL лучшая?" звучит часто. Ответ, как водится в сложных системах, – "зависит от ситуации". Нет универсального решения. Выбор оптимального метода репликации всегда компромисс. Приходится искать золотую середину между тем, насколько данные должны быть одинаковыми везде, скоростью работы, бесперебойностью и тем, насколько сложно все это настроить. Посмотрим внимательнее на главные способы. Это поможет сделать осознанный выбор.
