На прошлой неделе состоялся успешный эксперимент по запуску нового решения для download-сервиса. Один достаточно скромный сервер (2 x Intel Xeon E5620, 64 GB RAM) под управлением Java-приложения собственной разработки принял на себя нагрузку восьми Tomcat'ов, обслуживая более 70 тысяч HTTP-запросов в секунду общей пропускной способностью 3000 Mb/s. Таким образом, весь трафик Одноклассников, связанный с пользовательскими смайликами, обрабатывался одним сервером.

Вполне естественно, что высокие нагрузки требовали нестандартных решений. В цикле статей о разработке высоконагруженного сервера на Java я расскажу о проблемах, с которыми нам пришлось столкнуться, и о том, как мы их преодолели. Сегодня речь пойдет о кешировании изображений вне Java Heap и об использовании Shared Memory в Java.

Не так давно для создания сервиса (да и «в загашник» положить модуль) потребовалось придумать способ как быстро из sql базы делать выборки точек расположенных на карте.
Кода будет мало, что бы не отвлекать от понимания системы в целом.

Сначала немного предыстории. Небольшое продолжение истории с медиаплеером GV2B, описанным мной ранее ту/т. Напомню, что изначально бокс покупался не как Android приставка к телевизору, а как более мощная замена Raspberry Pi, на который я оставил заявку ещё в апреле, но приедет который только в августе. А GV2B оказался у меня в руках через 8 дней после заказа, всего за $100 и с полным комплектом кабелей (что всего на $5 дороже, чем комплект Raspberry Pi с зарядкой, шнурами и корпусом).
Успокою злопыхателей из моего предыдущего поста, что Youtube и другие приложения, установленные с Play, заработали замечательно, и больше никаких недостатков у устройства обнаружено не было.

Совсем недавно появилось пара топиков, в которых рассказывалось, как на ARM устройства удалось поставить Puppy Linux, Arch Linux и Ubuntu. Это уникальная особенность Allwinner A10, недооценить которую тяжело, но всё-таки система физически запускается с SD карты, а не встроенного флеша. Я начал активнее работать над вопросом, и наткнулся аж на три способа прошить что-либо во флеш память устройства, что обнадёживает и, возможно открывает лазейку для заливки туда полноценного GNU/Linux. Самонадеянно замечу, что это уже следующий шаг за банальным запуском чуть допиленного образа с SD карты.

Цель

— Установить на устройство ядро Linux. Желательно самое новое. Либо самое новое из тех, которое содержит все драйвера, специфические для устройства;
— Поставить GNU;
— Поставить окружение рабочего стола;
— Сделать резервную копию, чтобы устройство можно было вернуть в изначальное состояние, если что пойдёт не так;
— Хорошенько повеселиться со сложной задачей (сравнимо с установкой первых версий USB загрузчиков на Wii и прохождению NetHack или Dwarf Fortress).

Средства

Устройство GV-2B от неизвестного китайского производителя, на базе Rockchip 2918 (сокращённо RK29) (CPU ARM Cortex A8 1ГГц + GPU Vivante GC800 600МГц), с 4ГБ флеш памяти, 512МБ оперативной памяти и неплохим количеством разьёмов.
SD карта 16ГБ class 10.
PC с Arch Linux.
Клавиатура.
Монитор.
Шнур HDMI-DVI для подключения монитора.
Куча USB шнуров, переходников итп.

Предостережение и самобичевание

Наверняка многие из читателей сделали бы то, что описано в топике или хотя бы какую-то определённую часть, быстрее и лучше, но никаких упоминаний о таком подвиге я в просторах сети не нашёл. Топик содержит много практики и совсем немного теории, лишь самое необходимое, чтобы понять о чём идёт речь и что происходит (признаюсь честно, мне и самому теории в описанных областях явно не хватает). С академической точки зрения тянет на трёхчасовую лабораторную работу. Также хочу сказать, что впервые занимаюсь всем этим, если исключить подключение диска с предварительно установленным на настольком компьютере Ubuntu к PC104 x86-совместимому одноплатнику.

ongFiRE сделал сравнительную таблицу 39 одноплатных компьютеров в PDF!

В таблице присутствуют:
Raspberry Pi Model B, MK802, Mele A1000, Rhombus-Tech A10 EOMA-68, Gooseberry board, A13-OLinuXino, VIA APC, ,IA ARTiGO A1200, VIA ARTiGO A1150, BeagleBoard Rev. C4, BeagleBoard-xM, BeagleBone, PandaBoard, PandaBoard ES, Cotton Candy, CuBox, Hawkboard, IGEP v2, IGEP COM Proton, IGEP COM Module, Gumstix Overo series, Origen Board, ,Nimbus, Stratus, SheevaPlug dev kit (Basic), GuruPlug Standard, GuruPlug Display, DreamPlug, D2Plug, Trim-Slice series, Snowball, i.MX53 Quick Start Board, Pineriver H24/MiniX, Smallart UHOST, Genesi Efika MX Smarttop, Embest DevKit8600, Embest SBC8018, Embest SBC8530, Embest DevKit8500D

Автор рассказывает о перипетиях пивоваров, производителей СУБД, себя и кратко о том как правильно проектировать приложения. Мне показалась полезной поучительная часть статьи.

Приветствуем вас уважаемые Хабровчане!

Мы команда GlobaTel отныне будем стараться радовать вас информативными статьями в области хостинга и Дата-Центров, а так же иногда публиковать наши достижения сугубо с технической точки зрения.



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

Совсем недавно возникла задача создания программного обеспечения по генерации картографических тайлов. В качестве основы выбор пал на mapnik (альтернатив ему немного). Как оказалось, здесь на пути поджидало множество сложностей, непредвиденных ошибок, а более менее внятной документации по настройке всего «под ключ» найти не удалось. Повозившись какое-то время, мне удалось собрать множество граблей, которые могут возникнуть ну и довести дело до победного конца. Об этом и статья.

В этой статье мне бы хотелось рассказать о том, как приложения в Linux могут использовать систему Подключаемых Модулей Безопасности (Pluggable Authentication Modules) для прозрачной аутентификации пользователей. Мы немного покопаемся в истории развития механизмов аутентификации в Linux, разберемся с системой настроек PAM и разберем исходный код модуля аутентификации pam_p11, который позволяет проводить аутентификацию пользователей по смарт-картам.
В конце статьи мы рассмотрим на практике настройку и работу модуля аутентификации в сертифицированном по 3 классу защищенности СВТ и 2 уровню контроля отсутствия недекларированных возможностей дистрибутиве Astra Linux для аутентификации по USB-токенам Рутокен ЭЦП и Рутокен S. Учитывая то, что Рутокен S имеет сертификаты ФСТЭК по НДВ 3, а Рутокен ЭЦП по НДВ 4, это решение может применяться в информационных системах, обрабатывающих конфиденциальную информацию, вплоть до информации с грифом «С».

Linux Security Modules (LSM) — фреймворк, добавляющий в Linux поддержку различных моделей безопасности. LSM является частью ядра начиная с Linux версии 2.6. На данный момент в официальном ядре «обитают» модули безопасности SELinux, AppArmor, Tomoyo и Smack.

Работают модули параллельно с «родной» моделью безопасности Linux — избирательным управлением доступом (Discretionary Access Control, DAC). Проверки LSM вызываются на действия, разрешенные DAC.

Применять механизм LSM можно по-разному. В большинстве случаев это добавление мандатного управления доступом (как, например, в случае с SELinux). Кроме того, можно придумать собственную модель безопасности, реализовать ее в виде модуля и легко внедрить, используя фреймворк. Рассмотрим для примера реализацию модуля, который будет давать права на действия в системе при наличии особого USB-устройства.

Поглядим на схему и попытаемся разобраться, как работает хук LSM (на примере системного вызова open).

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

UKSM (Ultra Kernel Samepage Merging) — технология совмещения одинаковых страниц памяти в одну.

UKSM вдохновлен KSM(технология от RedHat), но практически полностью переписан.
У KSM есть несколько недостатков:

• Непрозрачность для пользователя и разработчика. Программа должна сообщать ядру, какие страницы объединить, этим пользуются редко
• Достаточно глупый алгоритм: сканирует память с постоянной скоростью. Зачем тратить CPU, если нет страниц, которые можно объединить?
• Достаточно медленный: максимальная скорость сканирования, которой удалось добиться при тестах ­— 260 МБ/с.

Организаторы IOCCC (Международный конкурс на самый непонятный код C) нажали кнопку «турбо». Если результаты прошлого конкурса опубликовали спустя четыре года после проведения, теперь прошло всего два месяца — и вот они.

Участвовать в конкурсе могут готовые программы размером меньше 4096 байт, при этом количество значимых символов, без учёта пробелов, знаков табуляции и знаков ; ( ), не должно превышать 2048. Задачей конкурса является «проверять компиляторы на стресс, демонстрировать тонкости языка программирования Си и важность соблюдения стиля программирования (делая обратное)».

Открою не Америку, но шкатулку Пандоры: в Java-коде много бойлерплейта. Типовые геттеры, сеттеры и конструкторы, методы ленивой инициализации, методы toString, hashCode, equals, обработчики исключений, которые никогда не выбрасываются, закрывалки потоков, блоки синхронизации. Проблема заключается даже не в том, чтобы написать всё это — современные среды разработки справляются с такими задачами нажатием нескольких клавиш. Сложность в поддержании бойлерплейта в актуальном состоянии по мере внесения модификаций в код. А в некоторых случаях (многопоточность, реализация методов hashCode и equals) и сам шаблонный код написать без ошибок — далеко не простая задача. Одним из решений проблемы является генерация кода, и в этой статье я расскажу про проект Lombok — библиотеку, которая не только может избавить вас от бойлерплейта, но и сделать это максимально прозрачно, с минимальной конфигурацией и, что немаловажно, с поддержкой на уровне среды разработки.

Размеры объектов в Java уже обсуждались на Хабре, например, здесь или здесь. Мне бы хотелось подробнее остановиться на размерах многомерных массивов — простая вещь, которая для меня стала неожиданной.

Оптимизируя вычислительный алгоритм по памяти, я наткнулся на то, что при определённых (вполне разумных) входных параметрах создаётся массив float[500][14761][2]. Сколько он может занимать в памяти (на HotSpot 1.6.0_26 32bit, если кому интересно)? Я примерно прикинул, что 500*14 761*2*sizeof(float) = 500*14 761*2*4 = 59 044 000 байт плюс какой-то оверхед. Решив проверить, как на самом деле, я воспользовался Eclipse Memory Analyzer (невероятно волшебная вещь, рекомендую!) и обнаружил, что «Retained Heap» для этого массива составляет 206 662 016 байт! Неплохой оверхед — 350%. Посмотрим, почему так получилось.

Предисловие

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

Тут другое дело. PHP не просто неудобен в использовании, плохо мне подходит, субоптимален или не соответствует моим религиозным убеждениям. Я могу рассказать вам много хороших вещей о языках, которых я стараюсь избегать, и много плохих вещей о языках, которые мне нравятся. Вперёд, спрашивайте! Получаются интересные обсуждения.

PHP — единственное исключение. Фактически каждая деталь PHP в какой-то мере поломана. Язык, структура, экосистема: всё плохо. И даже нельзя указать на одну убийственную вещь, настолько дефект систематичный. Каждый раз, когда я пытаюсь систематизировать недостатки PHP, я теряюсь в поиске в глубину обнаруживая всё больше и больше ужасных мелочей(отсюда фрактал).

PHP — препятствие, отрава моего ремесла. Я схожу с ума от того, насколько он сломан и насколько воспеваем каждым уполномоченным любителем нежелающим научиться чему-либо ещё. У него ничтожно мало оправдывающих положительных качеств и я бы хотел забыть, что он вообще существует.

Иногда мне приходится сталкиваться с заменой корневой файловой системы. Имея загрузочный диск и доступ к серверу, это не сложно. Однако, я хочу поделиться опытом замены корневой ФС удаленно, через ssh, без перезагрузки.

Причины для замены коневой ФС бывают разные:

• перевод / в LVM
• перевод / в mdraid
• замена типа файловой системы (ext3 => btrfs)
• уменьшение размера ФС (resize2fs)

Начнем с того, что

Зачастую новички сталкиваются с проблемой неслаженности своей музыкальной композиции: все инструменты по отдельности звучат хорошо, как надо, а в миксе получается невнятная «каша». А причина этого «недоразумения» в особенности строения нашего слухового аппарата, в так называемой слуховой маскировке.

Пара слов о слуховой маскировке

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

Есть проблема? Найди решение!

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

Эта статья нацелена на читателей, которые начинают или только хотят начать заниматься программированием модулей ядра Linux и сетевых приложений. А также может помочь разобраться с прозрачным проксированием HTTPS трафика.

Небольшое оглавление, чтобы Вы могли оценить, стоит ли читать дальше:

1. Как работает прокси сервер. Постановка задачи.
2. Клиент – серверное приложение с использованием неблокирующих сокетов.
3. Написание модуля ядра с использованием библиотеки Netfilter.
4. Взаимодействие с модулем ядра из пользовательского пространства (Netlink)

P.S. Для тех, кому только хочется посмотреть на прозрачный прокси-сервер для HTTP и HTTPS, достаточно настроить прозрачный прокси-сервер для HTTP, например, Squid с transparent портом 3128, и скачать архив с исходниками Shifter. Скомпилировать (make) и, после удачной компиляции, выполнить ./Start с правами root. При необходимости можно поправить настройки в shifter.h до компиляции.

Предположим, у вас есть большое приложение написанное на Java. Это может быть web-сервлет размещенный в контейнере или standalone-сервис. В процессе разработки (да и во время эксплуатации) возникает необходимость отслеживать процессы, протекающие в JVM: работу garbage collector, использование памяти, жизненный цикл потоков, а так же иные специфичные для вашего проекта показатели посредством MBean. Самый простой вариант — использовать профилировщик. Но увы, проблемы не случаются по расписанию, и невозможно заранее знать, когда нужно подключить профилировщик, а держать его постоянно включенным тоже не вариант. В таких случаях идеальное решение — непрерывный мониторинг. О нем и пойдет речь. Но для начала пара слов о классической профилировке.