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

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 (см команды выше).

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

Реклама

Организация локального поиска файлов через locate — дешево и сердито

2017-02-10

В командной строке есть утилита locate, которая ежедневно сканирует файловую систему с помощью утилиты updatedb и позволяет быстро находить файлы на диске по названию. Мне часто удобнее искать не по всему диску, а только по домашней директории или вообще по каким-то отдельным папкам. Обычно я использую find, но, читая man updatedb я обнаружил что поиск можно организовать в локальную базу таким вот образом:

updatedb -l 0 -o db_file -U source_directory

db_file — куда сохранять, source_directory — что сканировать.

Захотелось сделать свой локальный кэшируемый поисковик. Задача — сканировать домашнюю папку /home/vik, кэш хранить в /home/vik/.local/share/mlocate.db (еще одна полезная папка — ~/.local) и иметь возможность задать не locate а «local locate» — llocate.

Сделал отдельный скрипт на сканирование диска:

~/bin/locate/local_updatedb

С содержимым:

#!/bin/sh
updatedb -l 0 -o /home/vik/.local/share/locate.db -U /home/vik -n ".git .bzr .hg .svn .dropbox.cache"

Расшифровка ключей:

-l 0 не проверять права на доступ к базе данных

-o — где сохранить базу данных

-U — что сканировать

-n — какие имена игнорировать (очень удобно, чтобы не получать в поиске имен из папок контроля версий).

Дал скрипту права на запуск:

$ chmode a+x ~/bin/locate/local_updatedb

Обновлялку вынес в крон:

$ crontab -e

и вписал в файл:

@reboot /home/vik/bin/locate/local_updatedb 

«на каждой перезагрузке запускать сканирование диска»

Внимание: если вы редактируете crontab-файл — в конце нужно обязательно оставить пустую строку — иначе не заработает.

Последний штрих — добавил alias llocate в ~/.bash_aliases

alias llocate='locate -d /home/vik/.local/share/mlocate.db'

Пример:

vik@firefly:~$ llocate Войников

/home/vik/av/mp3/Виктор Войников - Честный стрелок.mp3
/home/vik/av/mp3/1_сборки/pulsar/Модель Для Сборки - Виктор Войников - Резонанс.mp3
/home/vik/book/hub/одессика/1914_Вся Одесса_Войников_737.png
...
/home/vik/zbox/yandex/Яндекс.Фотки/memorial Войников_new.jpeg.jpg

«Маскарад в красном смещении»

2016-04-23

Леди coala-the-bear на днях упомянула f.lux и то, что подкрашивание монитора в красные цвета (и уборка синего спектра) хорошо влияет на сон. Для меня, как для совы-заполуношника это зело актуально. Но f.lux проприетарная и под linux работает не ахти, посему озаботился поиском подходящего свободного софта. Причем как на десктоп, так и на андроид, с которого я ночью читаю и на котором у меня стоит dimmer который хорош, но недостаточно.

Быстро выяснилось, что для андроида есть не менее свободный Red Moon, который более чем хорошо справляется со своими задачами. При этом нужно учитывать, что пока он работает не получится устанавливать apk-файлы — собственно, как я понимаю это верно для всех экранных фильтров. Поэтому сначала отключить, а потом обновлять софт.

Для десктопа есть redshift который работает аналогично. gtk-версия у меня не запустилась, поэтому я просто использую коммандлайновый вариант, запуская его из комстроки, через меню или на старте через ~/.config/openbox/autostart.sh и при необходимости убивая через killall redshift. Утилита хорошая, единственное что я бы советовал сделать — сразу положить в ~/.config/ файл redshift.conf (пример есть на сайте) с забитыми в него координатами и режимом manual.


FBReader — чтение и допиливание

2015-07-05

Некоторое время назад перешел с CoolReader на FBReader — польстившись главным образом на сетевую систему синхронизации (которая до сих пор работает у них с каким-то скрипом). В принципе помимо системы синхронизации выяснилось, что FB за прошедшее время допилен до вменяемого состояния, в то время, как CoolReader практически не обновляется — поэтому, оставив обе программы, сейчас пользуюсь FB.

Неудобств у этой софтины пока всплыло два.

Первое — она категорически не хочет открывать .fb2.zip файлы, считая их прерогативой CoolReader. К счастью, есть человек, который не поленился сделать костыль к этому, что сильно облегчило работу с системой.

Второе — скачивая книги из флибусты по OPDS (или вообще из любой сетевой библиотеки), она складывает их в отдельные каталоги не называя по имени-названию, а просто нумеруя.

Скажем Кутузов Лидии Ивченко выкачивается не как Ivchenko_Zhizn-zamechatelnyh-lyudey_1372_Kutuzov.335158.fb2.zip, а как целое дерево вложенных папок: <родная папка fbreader'а>/flibusta.net/b/335158.zip, что ужасно неудобно.

Моя система хранения книг опирается в первую очередь на файловую систему — осмысленные названия файлов и иерархия папок по которым эти файлы тасуются. Ничего более удобного пока нет и, скорее всего, не будет придумано в ближайшее время. Иерархия “папка-файл” выглядит скучновато в отличие от всяческих all-inside хранилищ типа Calibre или той же встроенной библиотеки FBReader, зато надежна, минимальна по занимаемому месту, вообще не требует стороннего софта для упорядочивания, хорошо упорядочивается дельта-итерациями (тема отдельного разговора) и — как я начинаю понимать — нейрологически обоснованна (очень рекомендую такую книгу, как Daniel J. Levitin “The Organized Mind Thinking Straight in the Age of Information Overload” — написано хорошо, не заумно, без утомляющего выпендрежа и по делу).

Поэтому 335158.zip меня не устраивал категорически, хотя сам OPDS-доступ к сетевой библиотеке (т.е. скачивание книги через FBReader) оказался вполне удобным. Первым делом я попробовал переименовывать файлы вручную и раскладывать их по своим папкам — меня хватило файла на два.

К счастью, быстро выяснилось, что внутри у скачанного 335158.zip лежит вполне приличный по названию Ivchenko_Zhizn-zamechatelnyh-lyudey_1372_Kutuzov.335158.fb2 — дальше дело заключалось в написании простенького скрипта:

#!/bin/bash
# основная идея избавиться от закачки безымянных файлов с флибусты

# находит и раззиповывает в корень файлы в каталогах
find . -type f -name "*.fb2.zip" -exec unzip {} \;

Простенький однострочник на самом деле — find спускается вниз по дереву папок, находит файлы (-type f), которые заканчиваются на .fb2.zip (-name "*.fb2.zip") и запускает unzip, который над ними операцию распаковки (-exec unzip {} \; — вместо {} подставляется имя найденного файла). Разумеется, чтобы это работало, в системе должен быть установлен unzip (у меня он стоит по умолчанию — если его нет надо сделать что-нибудь типа sudo apt-get install unzip)

Этот файл (unzipper.sh) был положен в корень (то, что выше названо <родная папка fbreader'а>) и — дррррр! — тридцать файлов, которые к тому времени скопились в дереве папок, оказались найдены, раззипованы и аккуратно сложены в папке со скриптом.

На этом можно было бы остановиться — FBReader в принципе читает и раззипованный .fb2, но почему бы не упаковать все назад в зип? Для этого нужен примерно такой однострочник:

find . -type f -name '*.fb2' -exec zip '{}'.zip '{}' \;

Находим файлы, которые оканчиваются на .fb2 и зипуем их. -exec zip '{}'.zip '{}' \; выполнит операцию zip (он тоже должен быть в системе — sudo apt-get install zip) и подставит в нее найденные название файла ({}) и имя новосоздаваемого архива ({}.zip — старое имя + расширение .zip).

Итого:

#!/bin/bash
# основная идея избавиться от закачки безымянных файлов с флибусты

# находит и раззиповывает в корень файлы в каталогах
find . -type f -name "*.fb2.zip" -exec unzip {} \;

# зипует их обратно
find . -type f -name '*.fb2' -print -exec zip '{}'.zip '{}' \;

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


Чтение электронных книг — 2.5

2015-02-19

или «Dropsync не нужен»

В предыдущей серии ваш покорный слуга описывал свою систему, в которой чтение и архивация небольших заметок (в противовес чтению «больших книг» и книг, сгенерированных из собственных заметок) опирается на .epub и .maff форматы (по сути — зипованные .html) и творческое использование dropbox. Некоторое время назад я отказался от dropsync’а в пользу синхронизации через usb с помощью Unison. Причины, технические подробности, плюсы и минусы перечислены в предыдущей статье.

Вынужденное изгнание и смартфон меняют стереотипы. Смартфон, как «девайс в том числе для чтения» постепенно перетягивает одеяло на себя. Я привык читать с небольших экранов (Palm + WeaselReader), а смартфон (в отличие от более громоздкой читалки) постоянно с собой. Кроме того, появились программы вроде Dimmer’а которые позволяют настраивать яркость и цветовую гамму (например, убирать пресловутый «синий свет») — что сильно сокращает разрыв по разнице в качестве чтения.

Еще у смартфона есть симкарта и (почти всегда) бесплатный gprs-интернет. Сейчас у меня дошли руки до установки dropbox’а (я стараюсь держать на телефоне как можно меньше программ) — и я понял, что мне не нужен не только dropsync (см предыдущую заметку), но скорее всего и синхронизация заметок по шнурку.

На смартфоне интернет есть практически везде и всегда. Epub копеечные по размерам — и даже плохонького gprs вполне хватает для вытягивания файлов «по одному за раз». Прочие операции (удаление-переименование-сортировка) тоже можно делать без доступа ко всему архиву сразу — в самом приложении.
Большие заметки, которые хочется читать в отсутствии сети можно скопировать в отдельную папку, или (сейчас это проще) пометить «звездочкой» — и dropbox будет держать их на диске все время. Получается самое то, при минимальном использовании трафика.


Чтение электронных книг — 2

2014-12-12

В предыдущей заметке о чтении, я разделил свои материалы для чтения на три основные категории: большие книги, мои собственные заметки (в виде Большого Текстового Файла) и «клипы» или «вырезки» — набор разношерстых html-страничек, посты, микротексты, микрозаметки и так далее. Если с большими книгами и большим файлом все было более или менее понятно, то промежуточная категория — заметки, «клипы» и вырезки, была совершенно неопределенной и требовала осмысления.

За прошедший год система чтения изменилась. Многие моменты назрели уже давно, фундаментальным поворотом стал момент, когда я оказался в Метрополии с очень плохим интернетом. Связь через некоторое время наладилась, но момент вынужденной автономности и некоторые исследования, попавшие в мое поле зрения, заставили задуматься.
Читать далее…


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

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


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