понедельник, 22 июня 2015 г.

Настройка разрешения экрана в консоли при использовании проприетарных видеодрайверов

Наверное вы заметили, что после установки проприетарного драйвера Nvidia или Ati, разрешение в консоли tty, а также во время начальной загрузки, стало очень низким. Всё дело в том, что проприетарные драйвера не поддерживают KMS (Kernel Modesetting) - важный компонент, который отвечает за переключение видеорежимов в ядре.

четверг, 11 июня 2015 г.

Гайд по настройке PulseAudio. Часть первая.

PulseAudio, ранее известный как Polypaudio, - звуковой сервер для UNIX-подобных систем (Linux, BSD и прочих) и Windows. Это замена звуковому серверу ESD с намного меньшим временем задержки, лучшим качеством микширования и дискретизации и лучшей общей архитектурой.
Вот некоторые возможности PulseAudio:

среда, 10 июня 2015 г.

Устраняем тормоза системы при операциях ввода-вывода, или вспомним о #12309

Баг #12309 - самый знаменитый баг в ядре Linux, довольно долго досаждавший пользователям Linux на десктопах. Сам баг исправлен в ядре Linux 3.3, но симптомы, похожие на таковые при 12309, могут проявляться на некоторых конфигурациях до сих пор. В сети можно найти много инструкций по лечению этих симптомов. Приведу в пример статью с сайта linux.org.ru, оригинал которой можно найти по ссылке с некоторыми дополнениями.



На самом деле 12309 — это не один, а несколько багов, смешанных в кучу. Можно выделить следующие случаи появления:

    при копировании больших объемов данных с диска на диск (или с раздела на раздел одного диска);
    при нехватке ОЗУ (и, соответственно, диком своппинге);
    при копировании на USB-девайсы;
    при использовании зашифрованных разделов;

Соответственно, фиксы тоже будут разные.


Сначала тест: восприимчива ли ваша система к 12309? введите в терминале:

dd if=/dev/zero of=/tmp/test bs=1M count=1M


и понаблюдайте за отзывчивостью системы. Если всё по-прежнему быстро - то читать статью можно разве что для профилактики и расширения кругозора.


Оптимистическое выделение памяти


Возможно, в научных программах какого-нибудь толка позволить выделить терабайт ОЗУ при наличии 3 Гб физической памяти и считается приемлемым, но на десктопе, где много процессов должны спокойно сосуществовать, такой расклад неприемлем — зажравшаяся программа спокойно вытеснит все остальное, после чего система практически остановится. Хуже всего то, что суть бага 12309 в том, что ядро принимает решения о том, какие страницы вытеснять, мягко говоря, неоптимально, а чинить это долго, муторно, и не в каждой ситуации решение будет приемлемым.

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

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

Для этого нужно прописать в /etc/sysctl.conf

vm.overcommit_memory = 2

Максимум памяти, который можно будет выделить, будет равен в сумме
объему свопа + некоторому проценту физической памяти. Этот процент по
умолчанию равен 50, но можно его несколько увеличить. Во всяком случае, я
выставил его в 80 и пока что катастроф нет.

vm.overcommit_ratio = 80



Подкачка нужна


Некоторые люди полагают, что если отключить своп, то 12309 исчезнет. А вот как бы не так. Своп (swap) — это хранилище анонимных страниц памяти. Код исполняемых программ и всяких библиотек не анонимен и по умолчанию не изменяем. В то время как на 32-битных системах исполняемый код зачастую зависим от позиции (начального адреса), что приводит к тому, что, во-первых, динамический линковщик проводит вычисление смещений каждый раз при загрузке и, соответственно, страницы кода анонимны (это несет с собой недостаток в виде наличия нескольких копий одной и той же библиотеки, но и преимущество в виде невозможности вытеснить страницы кода для освобождения памяти), то на 64-битных системах практически весь код линкуется в независимом от позиции виде (PIC).

Это означает, что, во-первых, загрузка такого кода — это фактически всего лишь mmap() на исполняемый файл, во-вторых, можно держать только одну копию страниц кода на каждый процесс, сколько раз его ни загружай. Это достоинства. Недостаток в том, что даже при отсутствии свопа ядро может в случае нехватки освободить память за счет страниц со спящим кодом. Когда код надо будет выполнять, поднимать его надо будет с диска, и хорошо бы тогда иметь место в очереди ввода-вывода, а то система встанет в неудобную позу, причем надолго.

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


Уменьшение размеров дисковых буферов


С одной стороны, отдавать под дисковые буферы практически всю свободную память — здравая идея. А с другой стороны, чем больше ОЗУ, на самом деле, тем сильнее это способно ударить в критической ситуации.

Это работает вот как. У ядра есть буфер файловой системы. Мы пишем много данных. Этот буфер заполняется грязными страницами, а потом выполняется системный вызов sync() и буфер сбрасывается на носитель. Чем больше буфер, тем больше данных надо будет сбрасывать. Все бы ничего, да вот когда кому-то вдруг вздумается выделить себе памяти, в первую очередь будут сбрасываться все эти буферы, и если при этом вдруг надо будет закачать страницы с исполняемым кодом, им опять-таки придется ждать в очереди. Опять слайдшоу, с возможной цепной реакцией.

То есть, кеш на чтение — это ничего так, а слишком большой кеш на запись способен встать поперек горла в критических случаях.

Есть еще одна неприятная особенность, связанная трудно сказать, с чем — возможно, с реализацией DMA, но вполне возможно, что не с ней, или не только с ней. Берем какой-нибудь медленный для записи носитель, типа той же USB-флешки, и пробуем записать на него данных побольше, фильм какой или что-то навроде. Мы увидим, что происходит это рывками — сначала заполняется буфер, сколько влезет, а потом весь сбрасывается, потом весь заполняется... и так далее. При этом суммарно потраченное время почему-то ощутимо больше, чем как если бы мы примонтировали носитель с -o sync, а скорость записи на, собственно, носитель невообразимо мала.

Но если уменьшить порог количества грязных блоков, после которого начнется их сброс на носитель, не до сверхмалых величин, но все же — это позволит проводить зачитку данных из источника и запись на носитель параллельными DMA-трансферами. Я у себя выставил этот объем равным 2 мегабайтам, что, с одной стороны, уменьшает количество перезаписей в случае частой смены маленьких файлов и значительно увеличивает скорость переноса больших объёмов данных. Возможно, если поиграться размером, можно найти оптимальное быстродействие, но не думаю, что буфер больше 16 мегабайт будет эффективным.

echo 2097152 >/proc/sys/vm/dirty_bytes
echo 2097152 >/proc/sys/vm/dirty_background_bytes

Для сохранения после перезагрузки, прописать в /etc/sysctl.conf

vm.dirty_bytes = 2097152

vm.dirty_background_bytes = 2097152

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

Значение dirty_bytes должно делиться на 4096 нацело.

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


Кеш файловых систем


Иногда бывает такая проблема: у вас относительно новое ядро, тесты с dd проходят на ура, а вот когда надо много маленьких файликов создавать/менять/убивать, например, командой dpkg, система встает колом и не может даже регистрами пошевелить.

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

vm.vfs_cache_pressure = 50

По умолчанию оно почему-то 100, что просто безумно на десктопных нагрузках.

Прочие решения:

    Установить параметр swappiness равным 10 или 5, чтобы подкачка задействовалась только при исчерпании 90 и 95% памяти соответственно:

    sudo nano /etc/sysctl.conf

    Добавить в конец vm.swappiness = 10

    Сохранить и выполнить sudo sysctl -p

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

    самому (в некоторых дистрибутивах, например Calculate Linux, BFQ по умолчанию). В остальных же случаях можно сменить планировщик на лету.

    Перевесить системные прерывания на одно ядро (на многоядерном процессоре) скриптом:

    #!/bin/sh

    for interruption in `grep usb /proc/interrupts | awk '{print $1}'| sed 's/\://g'` ; do

      echo 1 > /proc/irq/${interruption}/smp_affinity;

    done

    При самостоятельной сборке ядра, задействовать 100Hz таймер ядра и опцию No Force Preemption (Server) mode.

    Выставить приоритет ionice для ядра 1 (realtime) для пространства пользователя (userspace) - 3.

    Установить ядро с патчами для реализации режима реального времени (linux-lowlatency, есть по умолчанию в репозиториях

    большинства дистрибутивов).

Подводя итог, можно отметить: самого бага давно нет, но на некоторых конфигурациях могут возникнуть его симптомы, по совершенно

разным причинам, от нехватки памяти до аппаратных проблем с дисками. Пугаться этого не стоит, ибо например в Windows, эта проблема

ещё более серьёзна, а самое главное - никак не решаемая. Система может с лёгкостью встать колом при копировании больших объёмов данных,

и её придётся перезагружать кнопкой Reset. Неоднократно с этим сталкивался. А вот симптомы 12309 удалось увидеть лишь при копировании фильма с

NTFS-раздела на старую, потрёпанную жизнью, флешку. И то потом проблему так и не удалось воспроизвести, потому списал на случайность.


Дополнительный материал:

Обзор планировщиков ввода-вывода

Статья о решении проблем с 12309 (на английском).



суббота, 6 июня 2015 г.

Настройка после установки Debian 8 "Jessie"

Свежеустановленный Debian нуждается в небольшой доводке до ума. Здесь я опишу несколько типовых шагов, которые я рекомендую проделать после установки Debian. Начнём.

Установка Ubuntu на файловую систему Btrfs

Btrfs - продвинутая файловая система, разработанная компанией Oracle в 2007 году и опубликованная под лицензией GNU GPL. Изначально, целью было создание достойного конкурента файловой системе ZFS, но впоследствии, компания отошла от этого направления. Btrfs может похвастаться следующими возможностями:

пятница, 5 июня 2015 г.

Подключение и настройка ИБП (Источника бесперебойного питания)


Многие источники бесперебойного питания (далее ИБП) имеют интерфейс для подключения к компьютеру, для возможности безопасно отключить его после исчерпания заряда батареи. Как правило, это интерефейс RS-232 (или COM-порт), но на некоторых моделях также присутствует USB (а на новых он единственный). У меня есть ИБП Ippon Back Power Pro 600. Думаю многим он знаком:

среда, 3 июня 2015 г.

Установка и настройка Wine - программы для запуска приложений Windows

Wine (WINE Is Not an Emulator) – специальная программа, слой совместимости, для запуска Win32 приложений в UNIX-подобных системах. Проще говоря, эта штука позволяет запускать виндовые проги и игры в вашем уютном Линуксе :).

вторник, 2 июня 2015 г.

SteamOS


SteamOS – это операционная система от компании Valve, дистрибутив Linux, основанный на Debian 7 и ориентированый на использование в консолях Valve "Steam Machines". Однако возможна установка и на обычный ноутбук или ПК (ведь по сути, Steam Machines это и есть ПК). Данная ОС затачиватся разработчиками именно для игр и мультимедиа, использует стабильную и надёжную основу Debian и платформу цифровой дистрибуции Steam (разумеетяся и все его дополнительные сервисы). Данная ОС имеет "под капотом":

понедельник, 1 июня 2015 г.

Steam в Linux


Steam – это система цифровой доставки игрового контента от компании Valve. Сейчас трудно назвать Стим только магазином игр. Это теперь целая вселенная (Steam Universe). Это и магазин, и платформа для разработчиков, и социальная сеть и многое другое. В 2012 году, клиент Стим вышел для Linux, и на данный момент

Улучшение работы игр в Debian/Ubuntu/Linux Mint


Большинство игр в Linux, расчитаны на работу в 32-х битной системе. Следовательно, они могут не работать или иметь проблемы с запуском в 64-битных системах. Решение:

Обновление Debian 7 "Wheezy" до Debian 8 "Jessie"

27 апреля, вышла новая версия одного из самых популярных и стабильных дистрибутивов Linux - Debian 8, под кодовым именем "Jessie". Debian 7 "Wheezy" ещё довольно продолжительное время будет актуальным, но если вы хотите обновить свою систему до новой версии, не потеряв всех своих настроек - читаем дальше.

Раздача интернета 3G в локальную сеть

Бывает такая ситуация, когда интернет подключён через 3G модем, но в доме больше одного компьютера. И всем нужен интернет. Выхода из положения тут 3: