Про реагирование на OutOfMemoryException в Java

Есть такая неприятная ситуация, когда память в куче заканчивается, и сборщик мусора тратит все больше и больше времени, пытаясь ее безрезультатно освободить, потому что объекты еще используется. Когда на это тратится почти 100% процессорноного времени, JVM может внезапно выбросить OutOfMemoryException в треде, который попытался выделить еще память. Как правило, это означает полную смерть треда, а может и всего приложения. Что еще неприятнее, отловить эту ситуацию изнутри практически нереально.
Но, как оказалось, можно хотя-бы сообщить об этом наружу, что можно использовать чтобы послать, скажем, письмецо с сервера о том что сервис помер, или даже убить и перезапустить его.

Делается это опцией для JVM:
java ... -XX:OnOutOfMemoryError="shell command; ..."

Ну а что туда подставить, сами можете догадаться. Это может быть шелл-скрипт, который через mail пошлет вам письмо, либо найдет pid этой JVM, пристрелит и запустит ее или что угодно еще.

Наслаждаясь Clojure

После месяцев троллинга в IRC по поводу Clojure, я, наконец, достал книжечку по этой теме и решил почитать, надеясь что простыми и понятными описаниями что, куда и как, как-то понять как писать на этом языке программирования какие-то полезные применимые в реальности программы, решающие реальные задачи. Книжечка эта - Joy Of Clojure, на английском языке, и я уже прочел 13 страниц из примерно 300 (что, как это нетрудно посчитать, является 4% от всего объема, что немного). Но я так ничего толком и не понял из того что там написано. В общем смысл пока такой - Clojure это реально классный и полезный язык и его делали реально классным и полезным языком для написания полезных программ, а не для изучения каких-то аспектов программирования, поэтому все просто обязаны его попробовать, потому что он позволит программистам увидеть бога. Пока что информация была предоставлена для тех, кто еще не имеет никакого понимания функционального программирования совсем (а таких людей большинство). Я помолчу о том, что я узнал много новых интересных слов английского языка, которые раньше я даже не встречал (несмотря на то что часто читаю техническую литературу, в том числе и по программированию, не используя словарей и переводчиков), и то что они там, в общем-то, никакого специального места не имеют. Это были не новые термины из математики или области компьютерных наук. Просто используется такой язык.. :)

Была и парочка примеров коротких программ, делающих простые вещи. Но смысл этой мешанины сокращенных слов, скобочек и двоеточий пока понять не удалось. Ну, то есть можно догадываться, что это делает, обозревая вывод программы, но никак не понять место всех этих символов. Сомневаюсь, что такое вообще кому-то без спецподготовки будет понятно, а с учетом того что смысл этого не был разъяснен, вообще с трудом угадывается место этих примеров в книге. Такое чувство, что она была написана только с одной целью - чтобы не очень глупые люди чувствовали себя полными идиотами. Но надеюсь, это чувство пропадет у меня по мере того как я снова и снова перечитаю эти 13 страниц, составлю конспект и схему этих непонятных понятий. Еще есть надежда, что я не стану таким же обфускатором, как автор этой книги (а может и автор языка - я не сомневаюсь, что это именно Clojure повлиял на автора книги таким причудливым образом).

У меня есть надежда, что Clojure как-то поможет мне шире мыслить при решении задач, и что, может быть, сам язык пригодится при решении некоторых задач, так что бросать чтение я пока не собираюсь, но мне страшно за мой мозг. Я постараюсь писать по мере продвижения, и оценить, как мои записки будут меняться по мере этого продвижения, чтобы можно было сравнивать состояние ума до и после.

В общем, резюме - Clojure - это такой простой непонятно путанный неведомый язык для инопланетян, почти как LISP, и на самом деле это еще один LISP, который почему-то не будет медленно тлеть как и LISP. Это я понял из абзацев про то как Clojure упрощает программирование, разделяя вещи, которые создают путаницу и позволяет концентрироваться на решении самих проблем, а не на раздумываниях о реализации решений этих проблем.

И да, им очень нужны новые адепты.

Админское чутье

Есть некоторые вещи, которые админам приписывают. Пляски с бубном, какую-то непостижимую магию или еще чего. Да, это реально существует. Все зависит от количества мидихлориан и умения админа пользоваться Силой.
Вот было у меня много таких случаев. Скажем, было время ложиться спать, но ворочаешься, жарко, спать не можешь. Берешь и открываешь почту, смотришь, а там как раз недавнее сообщение от системы мониторинга что все плохо и что-то нужно и важное отвалилось. Идешь и чинишь. Или, бывало, раннее утро, но ты внезапно просыпаешься, хотя не было никакого шума или звонка будильника. И не можешь уснуть. И оказывается, да, прямо сейчас, несколько минут назад у тебя в почте появилось письмо про отвалившийся сервис. Такие дела.

На самом деле можно было бы долго верить в эти феномены, мистику и прочие непостижимые вещи, но у всего этого простое объяснение. Лето. Жара. Спится плохо. Да я очень часто просыпаюсь раньше обычного. И так уж вышло, что пару раз на этот момент выпало какое-то такое событие, которое я хорошо запомнил. Поэтому кажется, что есть какая-то связь, которой нету. То есть, нет магии, мидихлориан и Силы, которая движет админами.

О мифических профитах tmpfs при компиляции

Возвращаясь к "бенчмарку" сборкой ядра, табличка на результаты которого будет чуть ниже, прошу обратить внимание на выделенные зеленым строчки. Это ничто иное как попытка увидеть профит от размещения исходников и каталога для сборки на tmpfs, который целиком влазит в оперативу. Как видим, профит ничтожно мал и составил 18 секунд от 678, то есть всего около 2.6%. Если при этом учесть еще что tmpfs зажирает место, которое могло использоваться всей системой под кеш (ну, ведь гентушники же не подключают /var/tmp/portage перед каждой сборкой?), я думаю что это можно смело называть непонятно откуда взятым мифом. :)

Тут-то и сами результаты

Штирлиц получил новую шифровку из Центра

Мы тут случайно наткнулись на очень необычную функцию древнейшего UNIX-калькулятора, и именно свойство печатать цифры из стека в виде букв. Нам это так понравилось, что я сначала написал черновую версию преобразователя текста в такие цифры, а потом, кучей итераций на #linux скриптик медленно преобразовался в такое вот коротенькое:

echo some text | perl -Mbigint -pe 'map{($s<<=8)|=$_}unpack"C*";$_="dc -e ${s}P\n"'

на выходе получается готовая команда для запуска dc, которая печатает some text. Этот окончательный вариант принадлежит перу ams, так что можете считать его perl-гуру. Другой гуру - ramok, он же komar, тоже приложился к этому делу.
Конечно, это не имеет никакой практической ценности, но является само по себе забавной вещью.

rlwrap - используем readline в приложениях, в которых его нет

rlwrap позволяет обернуть ввод в приложение, снабдив его функциями редактирования строки от readline. То есть, мы запускаем через rlwrap любую программу, которая просто читает ввод с терминала, например cat, telnet, netcat и получаем историю ввода, передвижение по строке курсорными клавишами, редактирование строки и прочие плюшки нормального, удобного ввода.
Устанавливается rlwrap в виде отдельного одноименного пакета и есть в репозиториях большинства дистрибутивов.

Пример использования:

$ rlwrap netcat localhost 25

- подключаемся к локальному SMTP-серверу и имеем чуть более удобную возможность говорить с ним напрямую.

Как скопировать файлы из другой ветки репозитория git

Кросспост из ЛинСовета

Что же делать, если нужно скопировать файлик из одной ветки git в другую? Браться за голову и делать это руками? Совсем нет. :)


Достаточно сделать в нашей ветке, где файла нет вот такое действие:

$ git checkout другая_ветка путь_к_файлу

и файл магически скопируется из другая_ветка. Останется добавить его и закоммитить.