Показываю:
@timoil94, включил первое видео, которое позволяет записать его. Хотел с Попкорна, но там запрет на захват экрана. А еще пикабу заставляет обрезать, соотношение сторон ему не нравится, видите ли... И качество пришлось ухудшить, тоже не загружалось.
Одна пикабушница (почти глухая) как-то пожаловалась мне, что не может посмотреть многие фильмы и сериалы просто потому, что на них нет субтитров. Вообще нет. И количество такого контента огромное: старые фильмы, любительские записи, авторское кино, документалки. Есть онлайн сервисы или видеоредакторы, но они либо платные, либо нужно совершить много кликов. Загрузить первый попавшийся фильм на ютуб для генерации субтитров особо не получится, прилетит блокировка на ролик.
Меня это сильно зацепило. Да и сам, если честно, страдаю от этой проблемы т.к слабослышащий. Особенно от актёров, которые экономят воздух и бубнят себе под нос.
И я подумал, а почему бы не сделать инструмент, который сам генерирует субтитры для любого видео в один клик?
Я создал Whisper Subtitles это веб-приложение, которое:
Автоматически распознаёт речь на 99 языках с помощью нейронки Whisper
Принимает видео с компьютера, по ссылке, или даже через торрент/магнет
Поддерживает все форматы: MKV, MP4, AVI, MOV итд
Генерирует субтитры в SRT формате
Вшивает субтитры прямо в файл как отдельную дорожку, на выходе mkv файл
Можно смотреть mkv видео прямо в браузере с субтитрами
Демонстрация как это работает с видео из компьютера/телефона. Размер субтитров настраивается в браузере/системе. Можно скачать видео и открыть vlc или в другом плеере.
Демонстрация работы фильма из торрента
Торрент если несколько серий, разные дорожки. Здесь показываю что можно выбрать нужные серии, 1ю серию выбрать русскую озвучку, на 2й оригинальную английскую
Остальные фото можно посмотреть на гитхабе, ссылка ниже.
Открываете приложение в браузере
Выбираете файл или вставляете ссылку
Нажимаете кнопку
Ждёте
Скачиваете готовые субтитры или смотрите видео с ними онлайн
Всё. Никаких танцев с бубном, никаких командных строк, "установите Python версии 3.8.12 и библиотеку версии 2.3.1".
У меня приложение крутится на домашнем NAS Truenas Scale с процессором Intel N150 с 16гб ОЗУ. Скорость обработки чуть быстрее реального времени на модели Large V3 INT 8:
11 минутный ролик ~8 минут
1.5 часовой фильм ~65 минут
Да, это не мгновенно, но можно поставить на ночь фильм/сериал и утром получить готовые субтитры. На более мощном железе будет значительно быстрее. Оптимизацию сделал только на процессоры intel.
В настройках можно выбрать тип модели:
Нужен только Docker. Как это сделать на Windows я не знаю, погуглите как поставить git и докер. Для маков оптимизировать не стал т.к у них уже есть софт для субтитров реальном времени без инета и для arm нужные особые библиотеки.
git clone https://github.com/timoil/whisper-subtitles.git
cd whisper-subtitles
docker compose up -d
Три команды и готово. Открываете http://localhost:8000, логинитесь (admin / admin123), и пользуетесь.
Ссылка на GitHub: https://github.com/timoil/whisper-subtitles
Белорусы, простите.
Распознавание речи работает на 99 языках от русского и английского до хинди и арабского.
Полностью бесплатно и с открытым исходным кодом
Работает локально ваши видео никуда не отправляются
Оптимизировано для Intel использует OpenVINO для ускорения
Docker простая установка без головной боли
Слабослышащим и глухим людям смотрите любой контент!
Студентам субтитры для видеолекций
Изучающим языки включите субтитры на оригинальном языке
Всё это приложение было создано через нейронку Claude Opus 4.5. IDE для разработки Antigravity. Ловите вайбкодера!
Ссылка на GitHub ещё раз: https://github.com/timoil/whisper-subtitles
Этот Linux не новогодний, но зато мой самый первый. 1999 год. На местном радиорынке натыкаюсь на красивую коробчонку с дистрибутивом BeOS. Как и все лини для домашнего пользования он был сырой, как могила. Но для работы с текстами, серфингу по сети и прочими нетривиальными задачами вполне подходил. Правда были нюансы. Например с бубном приходилось поплясать даже чтобы прикрутить русский язык (не к интерфейсу, а чтобы просто писать). Ну и приложений было раз-два и обчелся. Но по сравнению с вин-95 все равно это было свежо и приятно.
Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).
От хаоса к порядку: настройка Linux для рекордов СУБД
Данный чек-лист представляет собой структурированное руководство по оптимизации операционной системы Linux для развертывания высоконагруженных систем управления базами данных (СУБД). Он основан на анализе критических проблем производительности, таких как высокий I/O wait, блокировка процессов и неэффективное использование памяти. Материал систематизирован по приоритетам — от критических изменений, без которых невозможна стабильная работа, до тонкой настройки для достижения максимальной эффективности. Следуя этим рекомендациям, администраторы смогут значительно повысить отказоустойчивость и скорость отклика инфраструктуры, особенно в средах с интенсивной транзакционной (OLTP) или аналитической (OLAP) нагрузкой.
Параметры, напрямую влияющие на критические проблемы: высокий I/O wait, процессы в состоянии D, нехватка RAM.
Команда проверки: sysctl vm.dirty_ratio
Целевое значение: 10-15
Обоснование: Ключевой параметр! Определяет порог, при котором процессы блокируются на запись. Высокое значение (20-30) приводит к накоплению "грязных" страниц и массовым блокировкам (состояние D).
Команда проверки: sysctl vm.dirty_background_ratio
Целевое значение: 3-5
Обоснование: Порог фоновой записи. Слишком высокое значение откладывает запись, затем вызывает "взрывную" нагрузку. Для OLAP-нагрузки с большими чтениями нужен более агрессивный фоновый сброс.
Команда проверки: cat /sys/block/vd[d,x]/queue/scheduler
Целевое значение: none (noop) для KVM/VirtIO
Обоснование: В виртуальной среде (KVM) планировщик none (noop) минимизирует накладные расходы, передавая запросы гипервизору. mq-deadline или kyber могут создавать излишнюю очередь.
Команда проверки: sysctl vm.swappiness
Целевое значение: 1-10
Обоснование: При почти полной загрузке RAM (free <5%) система может начать готовиться к свопингу. Резкое снижение заставляет ядро в первую очередь сбрасывать кэш файловой системы, а не искать кандидатов на своп.
Команда проверки: sysctl vm.dirty_expire_centisecs
Целевое значение: 1000-1500 (10-15 секунд)
Обоснование: Время жизни "грязной" страницы. Уменьшение делает запись более частой, но менее объемной "пачками", что сглаживает нагрузку на диск и снижает пики wa.
Параметры, влияющие на общую производительность и стабильность под нагрузкой.
Команда проверки: su - postgres -c 'ulimit -n'
Целевое значение: 65535
Обоснование: При max_connections=1000 и большом количестве таблиц/индексов PostgreSQL может быстро исчерпать лимит. Это вызовет ошибки "Too many open files".
Команда проверки: sysctl vm.vfs_cache_pressure
Целевое значение: 50-80
Обоснование: Управляет тенденцией ядра к высвобождению памяти, занятой кэшем inode и dentry. Уменьшение значения сохраняет кэш файловой системы дольше, что полезно для OLAP с частыми чтениями.
Команда проверки: mount | grep -E "(data|wal|log)"
Целевое значение: noatime,nodiratime,barrier=0 (если диск с батарейным кэшем)
Обоснование: noatime исключает запись времени доступа, снижая нагрузку на запись. barrier=0 отключает барьеры для дисков с батарейным кэшем (только если уверены в надежности).
Команда проверки: cpupower frequency-info | grep governor
Целевое значение: performance
Обоснование: Фиксирует CPU на максимальной частоте, исключая задержки на переключение частот. Критично для виртуальных машин, где гипервизор может "тормозить" CPU в powersave.
Команда проверки: grep HugePages /proc/meminfo
Целевое значение: Рассчитать исходя из shared_buffers (например, для shared_buffers=2GB выделить 1GB hugepages)
Обоснование: Уменьшает накладные расходы на управление памятью, но требует настройки PostgreSQL (параметр huge_pages).
Параметры "тонкой настройки" или для устранения потенциальных проблем.
Команда проверки: sysctl net.core.somaxconn
Целевое значение: 1024
Обоснование: Максимальный размер очереди принятых соединений. При пиковых подключениях к БД может предотвратить отказы.
Команда проверки: sysctl net.ipv4.tcp_tw_reuse
Целевое значение: 1
Обоснование: Позволяет переиспользовать сокеты в состоянии TIME_WAIT для исходящих соединений. Снижает нагрузку на сетевой стек при активной работе.
Команда проверки: sysctl vm.min_free_kbytes
Целевое значение: 262144 (256MB)
Обоснование: Минимальный объем свободной памяти для ядра. Увеличение может предотвратить deadlock при нехватке памяти, но слишком высокое значение уменьшает доступную память для процессов.
Команда проверки: su - postgres -c 'ulimit -u'
Целевое значение: 4096-8192
Обоснование: С учетом max_connections=1000 и фоновых процессов autovacuum (max_workers=4) может потребоваться увеличение.
Команда проверки: iostat -dx 2 5 или iotop -o
Что оценивать: Утилизация дисков (%util), очередь (avgqu-sz), время отклика (await). Сравнить /data vs /wal.
Команда проверки: cat /proc/vmstat | grep -E "(dirty|writeback)"
Что оценивать: nr_dirty, nr_writeback. Если nr_dirty постоянно близко к лимиту — нужна оптимизация vm.dirty_*.
Команда проверки: cat /proc/pressure/io или cat /proc/pressure/memory
Что оценивать: Показывает, как процессы страдают от нехватки I/O или памяти. Значения >10% указывают на серьезные проблемы.
Команда проверки: cat /sys/block/vdd/queue/nr_requests и cat /sys/block/vdd/queue/read_ahead_kb
Что оценивать: Глубина очереди (128-256 нормально) и readahead (для OLAP можно увеличить до 4096-8192).
Сначала диагностика (пункты 15-18) — понять текущее состояние системы.
Критические параметры (1-5) — начинать оптимизацию с них, особенно с vm.dirty_* и I/O Scheduler.
Высокие параметры (6-10) — проверить и настроить после стабилизации I/O.
Средние параметры (11-14) — тонкая настройка после решения основных проблем.
Изменяйте параметры по одному и тестируйте после каждого изменения (нагрузочный тест аналогичный "Эксперименту-8").
Сохраняйте бэкапы конфигураций (sysctl -a > /root/sysctl_backup.conf, /etc/security/limits.conf.bak).
Для виртуальной среды (KVM) некоторые параметры могут контролироваться гипервизором (например, I/O Scheduler на хосте). Согласуйте изменения с администраторами виртуальной инфраструктуры.
Параметры файловой системы (barrier=0) применяйте только если диск имеет батарейный кэш (BBU) или вы готовы к риску потери данных при сбое питания.
Чек-лист охватывает ключевые аспекты настройки Linux для оптимальной работы СУБД, выделяя четыре уровня вмешательства: диагностика, критическая, высокая и средняя настройка.
Основное внимание уделяется управлению вводом-выводом (I/O) и памятью — параметрам vm.dirty_*, выбору планировщика дисков и настройке свопа. Регулировка этих параметров позволяет избежать лавинообразных блокировок и сгладить пиковую нагрузку на дисковую подсистему.
Дополнительно рассматриваются настройки сетевого стека, ограничений процессов и файловой системы, что в комплексе обеспечивает стабильную и предсказуемую работу базы данных под высокой нагрузкой.
Все изменения требуют поэтапного внедрения, тестирования и учета особенностей среды (виртуализация, оборудование).
Познакомитесь!: макропад 23procg
Привет! Меня зовут Нияз, и последние пять лет я веду, пожалуй, самый длинный и упорный личный проект в своей жизни создаю собственную макрос-клавиатуру с нуля: от логотипа до электроники и ПО.
Если коротко: я делаю устройство, которое экономит десятки минут в день тем, кто постоянно работает с графикой, фото, 3D или видео. Но путь к этой клавиатуре начался гораздо раньше.
Яндекс Еда — иконки фильтров основного экрана приложения сервиса доставки еды из ресторанов и продуктов из магазинов.
Я уже больше 11 лет занимаюсь рекламным дизайном и всем, что связано с производством визуального контента. За это время я стал настоящим «универсальным солдатом»:
могу снять продукт;
сделать 3D-визуализацию;
собрать макет;
отретушировать итог;
и настроить весь pipeline под задачу клиента.
Я работаю в Photoshop, Blender, Cinema 4D, After Effects, Premiere Pro, Capture One и ещё десятках программ.
И у всех у них одно общее — бесконечные горячие клавиши.
Работая по 6–10 часов ежедневно, я замечал две вещи:
я механически нажимаю одни и те же комбинации (Ctrl+Z, Ctrl+C, Ctrl+V, переключения инструментов и т. д.);
мизинец и запястье к концу дня просто болят.
Каждый дизайнер/ретушёр прекрасно понимает этот «пианизм»: бесконечный рояль из одинаковых нажатий, когда твои пальцы живут отдельной жизнью.
В какой-то момент я понял: я хочу удобный инструмент под свои задачи. И раз его нет — я сделаю его сам.
первые экспериментальные бумажки, как примерно будет выглядеть и какого размера она будет
Я начал собирать прототипы, разрабатывать корпуса, тестировать кнопки, писать софт. И постепенно появилась та самая маленькая клавиатура, которая стоит рядом с основной и закрывает 80% рутинных действий.
Задачи, которые я решил:
вынести горячие клавиши на физические кастомные кнопки;
избавить пальцы от «рояля»;
ускорить повторяющиеся процессы;
уменьшить количество ненужных движений по клавиатуре.
Что под капотом устройства
Я начал собирать прототипы, разрабатывать корпуса, тестировать кнопки, писать софт. И постепенно появилась та самая маленькая клавиатура, которая стоит рядом с основной и закрывает 80% рутинных действий.
Задачи, которые я решил:
вынести горячие клавиши на физические кастомные кнопки;
избавить пальцы от «рояля»;
ускорить повторяющиеся процессы;
уменьшить количество ненужных движений по клавиатуре.
Что под капотом устройства
Сейчас клавиатура умеет:
одиночное нажатие
двойное нажатие
удержание
Мой инженер (человек-легенда, о котором расскажу отдельно) сделал плату с продуманной логикой работы. А я со своей стороны написал приложение для управления макросами, их переназначения и настройки задержек.
Стабильность работы — на уровне, которого иногда не дают даже топовые устройства вроде Logitech MX.
О чём я буду писать
этапы проектирования корпуса
ошибки и фейлы при создании устройства
UX/UI приложения
оптимизацию workflow
мягкий backstage: как я строю свой мини-стартап
Если вам интересен такой путь — присоединяйтесь
Подписывайтесь, ставьте реакции — это реально мотивирует продолжать вести этот проект и делать его лучше.
Спасибо, что дочитали. Продолжаю работать.❤
Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).
От кэша в памяти до планировщика CPU: полный путь к производительности
На основе экспериментальных данных и анализа представлено руководство по оптимизации ядра Linux для серверов PostgreSQL, испытывающих высокую нагрузку с преобладанием операций чтения — типичную для аналитических запросов, отчётов и систем обработки данных. Цель настройки — полностью раскрыть потенциал современного оборудования путём точной коррекции ключевых параметров, отвечающих за работу с памятью, дисковыми операциями и распределением задач процессора. Особое внимание уделяется использованию высокоскоростных накопителей SSD/NVMe и значительных объёмов оперативной памяти для снижения задержек и повышения эффективности кэширования данных.
10 ключевых параметров операционной системы Linux для read-heavy (нагрузки с преобладанием чтения) работы PostgreSQL . Их оптимизация позволит максимально использовать кэширование, снизить задержки ввода-вывода и эффективно распределить ресурсы процессора.
Для удобства параметры разделены по категориям: память, ввод-вывод и планировщик процессов. Рекомендуемые значения ориентированы на современное оборудование (SSD/NVMe) и значительный объем оперативной памяти.
Описание: Уменьшает нагрузку на TLB процессора и фрагментацию памяти, повышая производительность операций с большими объемами данных (например, shared_buffers).
Рекомендуемое значение: Включить явно (vm.nr_hugepages в sysctl и huge_pages = on в PostgreSQL). Отключить Transparent Huge Pages (THP).
Описание: Определяют максимальный размер одного сегмента и общий объем разделяемой памяти. Необходимы для выделения shared_buffers PostgreSQL.
Рекомендуемое значение: kernel.shmmax ≥ размер shared_buffers. kernel.shmall ≥ общий объем разделяемой памяти / размер страницы.
Описание: Склонность ядра к выгрузке страниц памяти на диск (своп). Низкое значение помогает удерживать кэш БД в RAM.
Рекомендуемое значение: 1 (минимальное) — 10.
Описание: Стратегия выделения памяти. Вариант 2 предотвращает "OOM Killer" из-за чрезмерной памяти, выделенной процессам.
Рекомендуемое значение: 2 (рекомендовано для серверов БД).
Описание: Контролирует, как часто модифицированные данные в памяти записываются на диск. Оптимизация снижает пики ввода-вывода.
Рекомендуемое значение: Использовать абсолютные значения в байтах для точного контроля (например, vm.dirty_background_bytes=67108864, vm.dirty_bytes=536870912). Для read-heavy нагрузки можно немного увеличить лимиты.
Описание: Отключает запись времени последнего доступа к файлу, экономя дисковые операции.
Рекомендуемое значение: Добавить опции noatime,nodiratime в /etc/fstab для раздела с данными PostgreSQL.
Описание: Время, в течение которого планировщик будет держать задачу на том же CPU перед миграцией. Снижение может улучшить балансировку нагрузки для параллельных процессов PostgreSQL.
Рекомендуемое значение: Экспериментально, например 50000 (50 мкс) для систем с несколькими ядрами.
Описание: Объем данных, которые система предзагружает с диска при последовательном чтении. Для read-heavy и OLAP полезно.
Рекомендуемое значение: Включить и увеличить значение (например, до 16384 КБ) для томов с данными БД.
Описание: Гарантирует, что процессоры работают на максимальной частоте, исключая задержки из-за энергосбережения.
Рекомендуемое значение: Установить регулятор в performance и отключить балансировку NUMA (kernel.numa_balancing=0), если нет разнородного доступа к памяти.
Описание: Максимальное число одновременно открытых файлов и процессов для пользователя postgres. Критично при высоком max_connections.
Рекомендуемое значение: Значительно увеличить (например, soft/hard nofile = 500000, nproc = 500000).
Для нагрузок, где чтение сильно преобладает над записью (например, отчетные системы, аналитика), сделайте акцент на следующем:
Память и кэширование: Максимально увеличить shared_buffers (до 25-40% RAM), обязательно включите Huge Pages. Установите низкий vm.swappiness (1-10).
Планировщик процессов: Настроить kernel.sched_migration_cost_ns для лучшего распределения параллельных запросов. Установить регулятор CPU в performance.
Автоочистка (Autovacuum): Агрессивность может быть частично отключена, так как данные редко меняются. Это экономит CPU-циклы. Однако плановый VACUUM (например, по cron) в период низкой нагрузки необходим.
Проверка текущих значений: sysctl -a | grep <параметр> и tuned-adm active для просмотра текущей конфигурации.
Применение настроек:
Через tuned (рекомендуется для RHEL/CentOS): Создать пользовательский профиль, как в , и активировать его командой tuned-adm profile <имя_профиля>.
Через sysctl: Добавить параметры в файл /etc/sysctl.d/99-postgresql.conf и выполните sysctl -p.
Настройка Huge Pages: Рассчитать необходимое количество: (shared_buffers + другие затраты) / 2MB. Установитб через vm.nr_hugepages в sysctl и huge_pages = on в postgresql.conf.
Монтирование с noatime: Отредактировать /etc/fstab, добавив опции к разделу с данными, и перемонтировать (mount -o remount /path).
Увеличение лимитов ОС: Отредактировать файл /etc/security/limits.d/postgresql.conf и настроить службы в systemd (если используется).
Перезагрузка: Перезагрузить сервер для применения всех изменений, особенно связанных с Huge Pages и tuned.
Для PostgreSQL с нагрузкой, где преобладает чтение, критически важны настройки, уменьшающие латентность ввода-вывода и максимизирующие использование оперативной памяти под кэш.
Ключевые шаги: обязательное включение Huge Pages, увеличение shared_buffers, снижение swappiness, отключение ненужных обновлений атрибутов файлов (noatime), настройка планировщика процессов и регулятора CPU на режим производительности, а также увеличение системных лимитов. Агрессивность autovacuum может быть снижена для экономии ресурсов.
Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).
От latency — к velocity: как тонкая настройка IO разогнала PostgreSQL на 65%.
Часто при замедлении работы базы данных первым решением кажется увеличение вычислительных ресурсов: больше ядер, памяти, быстрые диски. Однако существует и другой, более экономичный путь — заглянуть глубже, на уровень операционной системы, управляющей этими ресурсами.
Данная статья — это практический разбор реального кейса, где скрупулёзная настройка параметров подсистемы ввода-вывода, кэширования и планировщика задач Linux позволила поднять производительность PostgreSQL на впечатляющие 65%. Без замены железа, без увеличения лицензий, только за счёт грамотной оптимизации «фундамента», на котором работает СУБД. Мы пройдём по всем ключевым экспериментам, от базовых значений до финального результата, и покажем, какие именно настройки стали решающими в этой «бесплатной» победе над latency.
СУБД: PostgreSQL 17
Инструмент нагрузочного тестирования: pg_expecto
Тестовая база данных: pgbench (10GB, простая структура)
Условия тестирования: параллельная нагрузка от 5 до 22 сессий по каждому тестовому сценарию.
Общие параметры производительности:
vm.dirty_ratio = 30
vm.dirty_background_ratio = 10
Параметры IO-планировщика:
[none] mq-deadline kyber bfq
Настройки кэширования и буферизации:
vm.vfs_cache_pressure = 100
Параметры файловой системы:
/dev/mapper/vg_data-LG_data on /data type ext4 (rw,relatime)
Размер буферов для операций с блочными устройствами
read_ahead_kb=4096
vm.dirty_ratio=10
vm.dirty_background_ratio=5
[mq-deadline] kyber bfq none
vm.vfs_cache_pressure=50
/dev/mapper/vg_data-LG_data on /data type ext4 (rw,noatime,nodiratime)
echo 256 > /sys/block/vdd/queue/read_ahead_kb
Сравнительный график изменения операционной скорости в ходе нагрузочного тестирования для Эксперимента-8(SPEED-8) и базовыми значениями параметров IO для Эксперимента-1(SPEED-1)
Среднее увеличение операционной скорости в результате применения изменений подсистемы IO по сравнению с базовыми значениями составило 65.09%.
График изменения операционной скорости в ходе экспериментов
График изменения ожидания СУБД в ходе экспериментов
График изменения IOPS в ходе экспериментов
График изменения MB/s в ходе экспериментов
График изменения aqu_sz в ходе экспериментов
График изменения r-await(ms) в ходе экспериментов
График изменения w-await(ms) в ходе экспериментов
Систематическая оптимизация параметров подсистемы IO — таких как настройки кэширования, планировщика операций ввода-вывода и параметров файловой системы — позволила достичь значительного повышения производительности PostgreSQL.
Суммарный эффект от внесённых изменений выразился в среднем увеличении операционной скорости на 65,09% по сравнению с базовой конфигурацией. Наиболее существенный вклад внесли корректировки размера буферов предварительного чтения (read_ahead_kb) и отключение избыточного обновления временных меток файлов (noatime, nodiratime).
Результаты подтверждают - целенаправленная настройка окружения ОС является критически важным этапом развёртывания высоконагруженных СУБД.
Первый первый Pentium завелся дома, и решил я посмотреть, а что такое Линукс.
И стал играться, пробовать разные программы (для сравнения с Вин95) и прочие развлекухи.
И каким то чудом вышел на xsnow, и тут такое на экране - и елочки зеленые, и Санта на санях разъезжает, и снег сыпет на окошки (его еще и стряхивать можно было, если верно помню). И все это в реальном режиме.
Картинка не моя, взята с интернетов.
И тут я понял, Линукс мне нравиться!!!
Всех с прошедшим Новым Годом, и с сегодняшним Рождеством!
