Предлагаю ознакомиться с расшифровкой доклада Николая Самохвалова "Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных"

Shared_buffers = 25% – это много или мало? Или в самый раз? Как понять, подходит ли эта – довольно устаревшая – рекомендация в вашем конкретном случае?

Пришло время подойти к вопросу подбора параметров postgresql.conf "по-взрослому". Не с помощью слепых "автотюнеров" или устаревших советов из статей и блогов, а на основе:

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

Используя Nancy CLI (https://gitlab.com/postgres.ai/nancy), мы рассмотрим конкретный пример – пресловутые shared_buffers – в разных ситуациях, в разных проектах и попробуем разобраться, как же подобрать оптимальную настройку для нашей инфраструктуры, БД и нагрузки.

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

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


Однако, наш опыт оказался весьма продуктивным в этом плане, поскольку хранилище почти любого мониторинга по своей природе является большей частью append-only с точки зрения записываемых данных. И если вам интересно, как можно научить базу писать на диск вместо 200MB/s вдвое меньше — прошу под кат.

Недавно я рассказал, как с помощью типовых рецептов увеличить производительность SQL-запросов «на чтение» из PostgreSQL-базы. Сегодня же речь пойдет о том, как можно сделать более эффективной запись в БД без использования каких-либо «крутилок» в конфиге — просто правильно организовав потоки данных.

#1. Секционирование

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

Несколько месяцев назад мы анонсировали explain.tensor.ru — публичный сервис для разбора и визуализации планов запросов к PostgreSQL.

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



Прислушивайтесь к ним, и ваши запросы «станут гладкими и шелковистыми». :)

А если серьезно, то многие ситуации, которые делают запрос медленным и «прожорливым» по ресурсам, типичны и могут быть распознаны по структуре и данным плана.

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



Давайте чуть подробнее рассмотрим эти кейсы — как они определяются и к каким рекомендациям приводят.

Single-page Application (SPA) – это набор статических JavaScript и HTML файлов, а так же картинок и других ресурсов. Поскольку они не изменяются динамически, опубликовать их в интернете очень просто. Для этого существует большое количество дешёвых и даже бесплатных сервисов, начиная с простого GitHub Pages (а для кого-то даже с narod.ru) и заканчивая CDN вроде Amazon S3. Однако мне нужно было другое.

Мне нужен был Docker-образ с SPA, чтобы его легко можно было запустить как в продакшене в составе Kubernetes-кластера, так и на машине back-end разработчика, который понятия не имеет, что такое SPA.

UPD 07.07.20: Посмотерть самому на то, что в итоге получилось, можно тут: https://github.com/alexxxnf/spa-docker-example

Я для себя определил следующие требования к образу:

• простота в использовании (но не в сборке);
• минимальный размер как с точки зрения диска, так и с точки зрения RAM;
• настройка через переменные окружения, чтобы образ можно было использовать в разных средах;
• максимально эффективная раздача файлов.

Сегодня я расскажу как:

• выпотрошить nginx;
• собрать brotli из исходников;
• научить статические файлы понимать переменные окружения;
• ну и конечно как собрать из всего этого Docker-образ.

Цель этой статьи поделиться моим опытом и спровоцировать опытных участников сообщества на конструктивную критику.

Добрый день, хабровчане. Сегодня я хочу рассказать о такой интересной вещи, как PgTune.

Автор: Вячеслав Михайлов, Solutions Architect

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

Мы разберемся с процессом аутентификации пользователя, работой технологии единого входа (Single sign-on/SSO), дадим общее представлении о технологии OAuth2 и принципах ее работы, не углубляясь в особенности конкретной технической реализации. В следующей статье в качестве примера удачной реализации мы рассмотрим библиотеку Thinktecture Identity Server v3, подробнее остановимся на ее функциональных возможностях, поговорим, как собрать минимальный набор компонент, необходимый для работы в микросервисной архитектуре и достойный использования в боевой системе. В третьей части мы покажем, как расширять эту библиотеку, подстраиваясь под нужды вашей системы, а завершит цикл статей разбор различных сценариев, встречавшихся в жизни многих разработчиков с рекомендациями для каждого случая.

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

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

Как известно, для обработки соединений NGINX использует асинхронный событийный подход. Вместо того, чтобы выделять на каждый запрос отдельный поток или процесс (как это делают серверы с традиционной архитектурой), NGINX мультиплексирует обработку множества соединений и запросов в одном рабочем процессе. Для этого применяются сокеты в неблокирующем режиме и такие эффективные методы работы с событиями, как epoll и kqueue.

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

Каждый процесс расходует память и каждое переключение между ними требует дополнительных циклов процессора, а также приводит к вымыванию L-кэшей

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

Но даже в текущей реализации NGINX не всегда возможно избежать блокировок. И для решения данной проблемы в NGINX версии 1.7.11 был представлен новый механизм «пулов потоков». Что это такое и как его применять разберем далее, а для начала познакомимся с нашим врагом в лицо.

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

Путь записи «звуковых комментариев» в PowerPoint и экспорта презентации в видео мы отметаем, как тривиальный и не дающий десятой доли тех возможностей, какие нужны для по-настоящему классного ролика.

Для начала определимся, какие кадры нам понадобятся:

1. Собственно слайды с закадровым голосом
2. Смена слайдов
3. Цитаты-перебивки из популярных фильмов
4. Несколько кадров с физиономией лектора и любимым котом (опционально)

Долго искал книгу, в которой было бы разжёвано, как использовать FFmpeg-подобную библиотеку, известную как libav (название расшифровывается как library audio video). Обнаружил учебник «Как написать видеоплеер и уложиться в менее чем тысячу строк». К сожалению, информация там устаревшая, так что пришлось создавать мануал своими силами.

Большая часть кода будет на C, однако не волнуйтесь: Вы легко всё поймёте и сможете применить на любимом языке. У FFmpeg libav уйма привязок ко многим языкам (в том числе и к Python и к Go). Но даже если Ваш язык прямой совместимости не имеет, всё равно можно привязаться через ffi (вот пример с Lua).

Начнём с краткого экскурса о том, что такое видео, аудио, кодеки и контейнеры. Затем перейдем к ускоренному курсу, посвященному использованию командной строки FFmpeg, и, наконец, напишем код. Не стесняйтесь переходить сразу в раздел «Тернистый путь изучения FFmpeg libav».

Есть мнение (и не только моё), что потоковое интернет-видео уже приняло эстафету от традиционного телевидения. Как бы то ни было, FFmpeg libav точно достоин изучения.

Оглавление

• Вступление
  • Видео — это то, что ты видишь!
  • Аудио — это то, что ты слышишь!
  • Кодек — сжатие данных
  • Контейнер — удобный способ хранения аудио/видео
• Командная строка FFmpeg
  • Инструмент в виде командной строки FFmpeg 101
• Основные операции над видео
  • Транскодирование
  • Трансмультиплексирование
  • Трансрейтинг
  • Трансайзинг
  • Бонус: адаптивный стриминг
  • Выходя за рамки
• Тернистый путь изучения FFmpeg libav
  • Глава 0 — простенький «Hello World»
    • FFmpeg libav архитектура
    • Требования
    • Собственно, код
  • Глава 1 — синхронизация аудио и видео
  • Глава 2 — ремультиплексирование
  • Глава 3 — транскодирование
    • Трансмультиплексирование
    • Транскодирование

Приходилось ли вам экспериментировать с кодом или системными утилитами в Linux так, чтобы не трястись за базовую систему и не снести всё с потрохами в случае ошибки кода который должен запустится с root-привилегиями?

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

С виртуальными машинами управляемые гипервизором такие задачи решить может и получится, но какой ценой? Например, контейнер в LXD на базе дистрибутива Alpine Linux минимально потребляет всего 7.60MB ОЗУ, и где корневой раздел после запуска занимает 9.5MB! Как тебе такое, Илон Маск? Рекомендую ознакомиться с базовыми возможностями LXD — системы контейнеров в Linux

После того, как в целом стало ясно, что такое контейнеры LXD, пойдем дальше и подумаем, а что, если бы была такая платформа-комбайн, где можно было бы безопасно запускать код для хоста, генерировать графики, динамически (интерактивно) связывать UI-виджеты с твоим кодом, дополнять код текстом с блекджеком... форматированием? Что-то типа интерактивного блога? Вауу… Хочу! Хочу! :)

Заглядывай под кат где мы запустим в контейнере JupyterLab — следующей генерации пользовательского интерфейса вместо устаревшего Jupyter Notebook, а также установим такие модули Python как NumPy, Pandas, Matplotlib, IPyWidgets которые позволят вытворять всё перечисленное выше и сохранять это всё в специальном файле — IPython-ноутбуке.

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

Но что делать, когда ваш код “идеален”, все тяжелые запросы вынесены в фон, все, что можно, было закэшировано, а сервер все так же не дотягивает до нужных нам показателей SLA? Если есть возможность, то конечно можно докупить новых машин, распределить часть трафика и забыть о проблеме еще на некоторое время.

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

Поделюсь с вами одной историей. Около двадцати лет назад я получил степень по физике, но занимался реверс-инжинирингом и криптоанализом. Наша компания AccessData работала в конце 90-х и начале 2000-х. Тогда правительство США постепенно снимало ограничения на экспорт криптографии, однако парольная защита в большинстве программ по-прежнему оставалась довольно бесполезной. Мы брали офисные программы, я проводил реверс-инжиниринг и выяснял алгоритм шифрования, а потом ломал криптозащиту.

Это был нескончаемый поток интересных, но не особенно сложных математических головоломок. За всё время я написал около сорока взломщиков паролей. Мы продавали их домашним пользователям, системным администраторам, местным и федеральным правоохранительным органам. Мне пришлось несколько раз съездить в федеральный центр подготовки сотрудников правоохранительных органов в Глинко, чтобы объяснить ребятам из Секретной службы, ФБР и АТФ основы криптографии и как использовать наши продукты.

Особенно ярко мне запомнились два проекта. Первым был Microsoft Word 97. До его появления файлы шифровались с помощью XOR байтов открытого текста и 16-байтовой строки, которая выводилась из пароля. Самыми распространёнными байтами в файле Word обычно были 0x00, 0xFF или 0x20 (пробел), поэтому мы просто выбирали самый распространённый символ в каждом столбце и проверяли 3¹⁶ вариантов. Восстановление ключа обычно происходило мгновенно, но чтобы людям не казалось, что они зря потратили деньги, мы вставили небольшую анимацию, похожую на голливудскую хакерскую сцену с множеством случайных символов, из которых постепенно проявляется правильный пароль.

Janus MQTT Proxy — это сервис, который я написал на Go в качестве хобби-проекта. Он подключается к MQTT-брокеру и подписывается на все события, а клиенты, в свою очередь, подключаются к proxy и общаются с ним как с MQTT-брокером.

Он позволяет:

• ограничивать доступ клиентов к разным топикам. В том числе раздельно ограничивать доступ на чтение и запись;
• подменять названия топиков и содержимое событий с помощью regexp-ов.

В этой статье я расскажу о том, как автоматизировать заказ и продление сертификатов от Let’s Encrypt (и не только) для Ingress’а в Kubernetes с помощью дополнения cert-manager. Но начну с краткого введения в суть проблемы.

Если вам не приходилось работать в команде, то, возможно, вы еще не используете эти вещи, а кто-то даже не знает про них. Работая один, вы сами себе хозяин.

Как только начали работать в команде  —  ситуация резко меняется. Если нет договоренностей, то каждый начинает писать код в таком стиле, в каком умеет. И даже если вы все же собрались и обсудили на словах codestyle на проекте и даже записали где-то, это, скорее всего, не поможет решить проблему, и вот почему.

Тут на Хабре уже десятки статей, повествующих, как люди переживали переход на удалёнку, как переживали первые дни удалёнки, потом – как прошла первая неделя, и всё такое прочее. Иногда между описанием эмоций проскакивали какие-то дельные советы. Мы как люди с 12-летним опытом удалённого администрирования серверов решили рассказать про инструмент, без которого удалёнка превращается в довольно опасное для вашего бизнеса мероприятие. Почему? — Потому что народ думает о чём угодно (в первую очередь, конечно, о проклятых бесплатных 40 минутах в «зуме»), но не о безопасности. Точнее, разумеется, вы задумывались об этом вопросе — но поспорим, что он не был первым в очереди?

И встречный вопрос: интересно, к чему привели ваши думы? Ведь ваши коллеги, рассевшись по уютным квартирам и домам, ходят с незащищённого оборудования по незащищённым каналам и буквально трогают всем этим серверы компании…

Мы хотим поделиться с вами open-source версией инструмента, используемого в нашей компании в роли бастионного сервера. Называется он «Сервер аутентификации DevOpsProdigy Isolate».

Материал, перевод которого мы сегодня публикуем, посвящён поиску узких мест в производительности серверов, исправлению проблем, улучшению производительности систем и предотвращению падения производительности. Здесь, на пути к решению проблем перегруженного сервера, предлагается сделать следующие 4 шага:

1. Оценка ситуации: определение узкого места производительности сервера.
2. Стабилизация сервера: применение срочных мер по улучшению ситуации.
3. Улучшение системы: расширение и оптимизация возможностей системы.
4. Мониторинг сервера: использование автоматизированных средств, позволяющих предотвращать возникновение проблем.

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



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