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

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.


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

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


Система бэкапов mysql moodle на двух машинах через scp ssh

2013-12-27

После вчерашнего танца с бубнами… Гм. Лучше по порядку. Вчера вышел из строя основной сервер. Я запустил резервный сервер, перекинул коммутацию интернетов в обход сервера. Этим я обеспечил интернеты. Потом поднял из бэкапов мудл, который у нас основным рабочим продуктом.

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

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

Из всего, что необходимо для работы мудла самую большую ценность представляет его база данных. Все прочее развертывается и ставится по отработанной схеме. А вот в MySQL хранятся все результаты, опросы и так далее. Читать далее…


Развертывание простой samba-шары, борьба с autorun.inf на samba-сервере или сисадмину на заметку

2013-10-04

Пока писал еще один пост про Гринпис, подошел один из инженеров и пожаловался, что какой-то из классов заела эпидемия «авторанов». Причем, авторанов, распространяющихся через сервер. Я насторожился, поскольку сервером у нас работает (с моей подачи) уютненький Debian GNU Linux.
Читать далее…


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