Укрощение лисы

2018-04-12

…или как снизить потребление памяти прожорливого firefox и заставить linux жить по средствам.

Сейчас иногда использую в качестве мобильного рабочего места ноут Samsung R522 — впечатляющая даже по сегодняшним меркам машинка, но всего с 2G RAM на борту. В основном я работаю либо с совсем низкоуровневыми программами (vim, tmux, mutt, mbsync, mercurial, pandoc, … что еще нужно человеку для полного счастья?) и прельстиво и любовно допиленным openbox. Однако, quantum firefox способен сожрать всю память и завесить систему. Ко всему прочему, чтобы пощадить винт, я принципиально отключил своп. Посему начали случаться моменты когда система зависала. Это не совсем зависание — как написали на одном из форумов «just highly unresponsible» — но обычно у меня не хватало терпения ждать и я перезагружал машину.

Некоторое время я пытался настроить firefox на меньшую прожорливость, проверял плагинки, обновлял базы — в общем все необходимые ритуальные танцы. В конце-концов стало понятно, что проблема не в браузере.

Я забрался в докуметацию и выяснил интересную штуку. Оказывается, в ядре есть такая настройка, как memory overcommit — выделение приложению памяти больше, чем есть в наличии. Я не копал глубоко вопрос почему и зачем это сделано — по моим предположениям такой режим выгоден (а) когда запущено много разных приложений и есть шанс, что недостающая память случайным образом высвободится за счет закрытия другой программы, к моменту когда она понадобится программе текущей (привет теории массового обслуживания), (б) расчет идет на то, что если лимит памяти будет превышен — пойдет сброс лишнего в своп (которого у меня нет) и (в) если будет совсем плохо запустится task killer и прибьет какое-нибудь ненужное приложение (на практике killer обычно тупит).

За режим выделения памяти отвечают переменные vm.overcommit_memory — которая задает режим выделения памяти и vm.overcommit_ratio, которая определяет насколько можно превысить пределы.

По дефолту у меня были режим 0 и 50% соответственно:


cat /proc/sys/vm/overcommit_memory
0

cat /proc/sys/vm/overcommit_ratio
50

Я их поменял на «режим 2» (не выдавать память авансом — давать только то, что есть в наличии) и 98% (расходовать всю память минус 2% для баша на всякий пожарный) соответственно. Все равно памяти больше не станет — поэтому лучше, чтобы система «жила по средствам» и не тщилась съесть больше, чем есть в наличии.

Это можно сделать из-под рута на один сеанс (до перезагрузки — посмотреть, как поведет себя система):


echo 2 > /proc/sys/vm/overcommit_memory
echo 98 > /proc/sys/vm/overcommit_ratio

Либо открыть из-под рута в текстовом редакторе /etc/sysctl.conf

и добавить туда пару строчек:

# профилактируем оверкоммиты памяти
vm.overcommit_ratio = 98
vm.overcommit_memory = 2

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

В теории это может вызвать подтормаживание лисы, но я побочных эффектов пока не заметил, зато система стала работать стабильно, что не может не радовать.


old good stable

2016-03-07

Чем больше вожусь с «новейшими» библиотеками python, тем сильнее понимаю политику debian stable.


Openshot, ImageMagick и красноглазая магия…

2014-11-30

На днях осваивал программу для нелинейного видеомонтажа под Debian GNU Linux. Требовалось смонтировать простенькое слайд-шоу плюс несколько видеофайлов.

Из всех программ выбор пал на OpenShot — как лучший компромисс и аналог Movie Maker’а фирмы M$.

Все хорошо, однако на over 100 фотографиях OpenShot начал тормозить. Непродолжительный поиск подсказал, что проблемой может быть то, что все эти фотки грузятся в трек as is (а там фотографии на десяток мегабайт каждая) и OpenShot’у приходится каждый раз прокручивать все это богатство в памяти.

В теории фотографии можно уменьшить чем-нибудь типа ImageMagick — причем сделать это «одним чохом» в командной строке, но как? То есть я помню что в «Магике» есть утилита convert, но вопрос в том в какой размер конвертировать файлы и как быть с тем, что фотографии в моей подборке разной ориентации?

Ответ нашелся достаточно быстро. Где-то на ЛОРе на аналогичный вопрос советовали использовать связку bash+ffmpeg+imagemagick (что мне не подходило категорически — поскольку подборка требовала еще некоторой подгонки в ручном режиме). После чего я нашел ссылку на скрипт конверсии. Сам скрипт не понадобился — я извлек из него следующие строки:

RESOLUTION=1920x1080
mogrify -resize $RESOLUTION *.JPG

И тупо вбил их в комстроку в моей директории. mogrify — еще одна утилита пакета ImageMagick и она прекрасно справилась с конверсией. Фотографии стали весить порядка пары сотен килобайт, OpenShot перестал тормозить, а клип получился хорошего качества

Разрешение можно было задать и вот так:

mogrify -resize "1920x1080" *.JPG

И скорее всего уменьшить еще. Но это было часа три ночи и для вникания в детали у меня не было настроения.


Пришла весна — готовь коньки

2013-03-24

Вчера из-за непогоды сидел в основном дома — поэтому нашел время заняться уютненьким дебианом. Для начала разобрался-таки в чем была проблема с пульсаудио — оказалось (внезапно!) в драйверах к видеокарте, которые перехватывали на себя контроль. Вдохновился советом сэра Шамана и переставил дрова на свободные nouveau — все заработало как часы, к тому же включился фреймбуфер, которого мне недоставало.

Ну и по инерции таки собрался поменять конфиг conky. Сейчас у меня рабочий стол без всяких рисунков — только navy blue фон.

а коньки в правом углу выглядят так


Сортировка файлов для китайского плейера

2012-07-20

Для полевых условий я пользуюсь дешевыми китайскими плейерами — в наглоязычном интернете такие плейера иронично называют чайподами — chinese ipod — chipod. Для полевых условий чайподы подходят идеально: дешевы, не жалко потерять-разбить-утопить и к тому же всегда можно найти модель работающую от батареек (незыблемое правило — все что в городе должно заряжаться от usb, все что в поле — работать на батарейках). Один из основных недостатков таких моделей (особенно тех, у которых нет дисплея) это то, что они играют музыку так как Бог на душу положит — точнее в том порядке, в котором файлы писались на карточку. А это далеко не всегда, точнее почти всегда не совпадает с алфавитным порядком.

В принципе из командной строки можно писать файлы и в алфавитном порядке. Это можно сделать, например, так:
Читать далее…


%d такие блоггеры, как: