Архив автора

И еще один забавный случай про то, как мы наткнулись на баг, но теперь уже в самом memcached. Это даже, наверное, не баг, а особенность, не упомянутая в документации.

Всем известно, что у memcached есть текстовый протокол. Можно на tcp порт memcached (11211 по умолчанию) зайти телнетом и написать парочку команд. И есть в протоколе команда stats cachedump, которая не документирована, но которой пользуется утилита memcached-tool, входящая в поставку memcached.

Usage: memcached-tool <host[:port]> [mode]

(далее…)

В продолжении разговора о патче в php хочется еще рассказать о наших небольших патчах в pecl-memcached. Это pecl модуль, который реализует интерфейс libmemcached в php и добавляет handler сессий для хранения их в memcached.

Первый патч довольно простой, он добавляет нормальные сообщения об ошибках в код handler-а сессий. До этого патча невозможно было понять, то-ли сессии в мемкеше нет, то-ли отвалилась коннекция от мемкеша, то-ли что-то еще произошло. Во всех случаях код возвращал FAILURE и было непонятно, что на самом деле произошло. Аналогично, при сохранении сессии старый код просто увеличивал количество неудачных попыток и при достижении максимума выкидывал сервер из пула по непонятным снаружи причинам.
(далее…)

16 марта вышли новые версии php — 7.0.17 и 7.1.3. Это приятная новость для многих php разработчиков, но для нас она приятна еще и тем, что туда вошел наш патч, который чинит keep-alive соединения в php-fpm sapi.

Php-fpm появился сначала как отдельный патч для php 5.2, добавляющий менеджер fastcgi процессов, который позволяет организовать отдельные пулы, следит за временами выполнений рабочих процессов и много другое полезное. В ветке php 5.4 его приняли как официальный sapi и мы избавились от необходимости накладывать этот патч всякий раз, как выходит новая версия php с исправлением ошибок.

(далее…)

На нашем видео-пректе при отдаче видео с серверов возникает вопрос производительност дисковой подсистемы. Очевидно, что гигабитные сетевые интерфейсы обладают большей производительностью, чем, скажем, RAID0 из 2х дисков. И если бы видео-ролики обладали одинаковой популярностью, то диски являлись бы узким местом при отдаче контента.
Однако же, нам повезло и всегда есть небольшой набор роликов, которые делают 80% трафика, и длинный хвост с редкой посещаемостью. Этот небольшой набор оседает в кеше файловой системы и отдается практически без дисковой активности.
Например, если у нас на сервере лежит 100 гигабайт роликов, а памяти на сервере 24 гигабайта, то мы можен нарисовать такой график. По горизонтали у нас будут «файлы», отсортированные по популярности, по вертикали — трафик, порождаемый этими файлами. Суммарный трафик — площадь поверхности под графиком.

filesystemcache

С другой стороны, всегда стоит вопрос, сколько памяти на сервер лучше поставить и как померять hit/miss ratio. В этом посте мы рассмотрим, как это можно сделать.
(далее…)

У нас есть заказчики и партнеры в разных странах, и порой не все они могут комфортно изъясняться на английском языке. Мы в нашей работе используем trac для багтрекинга и документации. И поэтому мы написали и поддерживаем плагин для trac-а, который использует Google Translate и переводит тикеты и комментарии пользователей на язык, указанный в настройках пользователя.

Перевести
Перевод

Всем, кто сталкивается с подобными задачами, рекомендуем.

Страница плагина.

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

Начнем с того, что медиа-информацию (видео и аудио) необходимо хранить в цифровом виде, и хорошо бы еще и в сжатом. Этим занимаются кодеки (codec, coder-decoder). Они переводят медиа-информацию в цифровой поток и обратно.

codecs
(далее…)

В данном посте хотелось бы просуммировать наш опыт работы над крупными интернет-проектами и рассмотреть характер и объем работ системной и инфраструкторной поддержки проектов.

Работы можно отсортировать по «уровням» (с какой-то погрешностью). Высоким уровнем будет считаться уровень приложения и данных, низким уровнем будет аппаратная часть.

Диаграмма объема инфраструктурных и системных работ

(далее…)

Mike Haertel, автор GNU grep, написал в рассылку FreeBSD отличное письмо по поводу производительности grep-а.

Суть в том, что grep использует модифицированный алгоритм Boyer-Moore для поиска подстроки и ему не приходится проверять каждый байт.

Там же предлагалась идея использовать mmap для увеличения производительности, чтобы ядру не читать read-ом каждый байт, а передать контроль за этим в юзерспейс — самому grep-у.

Если вдуматься, смысл этой оптимизации не очень большой. Все равно с диска считывается минимум 4 килобайта (размер физического сектора HDD), и вряд-ли Boyer-Moore сделает прыжок больше, чем на 4K.

Вторая причина в том, что каждая считанная страница памяти будет генерировать page fault. Это может быть даже дороже, чем системный вызов read().

Собственно, именно так и посчитали разработчики grep-а.

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

$ time grep groovy tmpfs/words > /dev/null

real 0m0.927s
user 0m0.600s
sys 0m0.311s
$ time grep -n groovy tmpfs/words > /dev/null

real 0m1.924s
user 0m1.606s
sys 0m0.307s
$

В Москве на Ходынке рабочие повредили кабель спецсвязи, из-за того, что он не был указан в документации в связи с высокой секретностью (http://lenta.ru/news/2010/08/16/liason/). Этот случай – очень хорошая иллюстрация опасности подхода «Security through obscurity» (безопасность путем сокрытия). Система, построенная на этом принципе может содержать уязвимости, но, разработчики или владельцы системы считают, что о них никто не узнает. Но на самом деле, об уязвимостях узнают, и в первую очередь отнюдь не разработчики этой системы.

В конце XIX века голландский криптограф Огюст Керкгоффс опубликовал свою книгу по криптографии и криптоанализу, в которой изложил требования к криптосистемам, одно из которых теперь известно как принцип Керкгоффса. Принцип Керкгоффса предлагает при разработке криптосистем придерживаться правила держать в засекреченном виде только небольшую часть системы, называемую кодом. А все остльные детали могут быть открытыми. Керкгоффс справедливо полагал, что чем меньше секретов содержит система, тем она безопаснее. Позднее Клод Шеннон перефразировал этот принцип как «враг может знать систему». Несмотря на аргументы, довольно часто, полагаясь на интуитивные ощущения, разработчики систем пытаются реализовать безопасность при помощи сокрытия как можно большего числа деталей.

Если хозяин квартиры хранит ключ от входной двери под дверным ковриком, он полагается на принцип Security through obscurity. Достаточно увидеть, как он достает ключ из под коврика, чтобы дверь оказалась полностью скомпрометированой. Не говоря уже о том, что потенциальный злоумышленник первым делом посмотрит под ковриком. Данный пример весьма очевиден, но более сложные случаи с точки зрения безопасности отличаются мало.

Алгоритм шифрования A5/1 (http://en.wikipedia.org/wiki/A5/1), применяемый в GSM сетях, изначально держался в секрете, однако в 1994 году некоторые детали реализации алгоритма утекли в широкие массы, а в 1999 году он был полностью раскрыт реверс-инженирингом телефонного аппарата. Алгоритм оказался настолько некриптоустойчив, что на данный момент GSM передачи можно перехватывать при помощи оборудования за $1500 (http://www.securitylab.ru/news/396052.php).

Компания Cisco Systems скрывала детали реализации своих протоколов маршрутизации, пока в мае 2004 года не были украдены исходные коды операционной системы, которая работает на их маршрутизаторах. В результате анализа кода было выявлено множество уязвимостей в протоколе EIGRP, что подвергло риску множество владельцов оборудования Cisco. (http://www.securitylab.ru/vulnerability/source/243482.php)

Случается люди кладут свою секретную информацию на веб-сервер, не защищая ее паролем и беспечно полагая, что об этом сервере никто не узнает, если они о нем никому не скажут (не будут создавать DNS имя, создатут секретную папку с секретным именем, поднимут веб-сервер на нестандартном порте и проч.). Сетевые сканеры (cheops-ng, firewalk, nmap) довольно быстро находят такие заначки, и их секретная информация быстро становится достоянием общественности. Аналогично, «секретные» URL оседают в истории броузеров, оказываются в HTTP referer, и, довольно быстро, Google и другие поисковые машины их индексируют.

Открытость системы, как правило увеличивает уровень ее безопасности. Согласно Эрик Реймонд сформулировал «закон Линуса», который гласит «при достаточном количестве глаз баги выплывают на поверхность» (given enough eyeballs, all bugs are shallow). Если система открыта, довольно много экспертов захотят на нее посмотреть и если в ней есть уязвимости, об этом будет известно довольно быстро, как правило до того, как ей будут пользоваться миллионы клиентов.

В процессе борьбы со спамом порой страдают невиновные. Системному администратору, который поставил свой SMTP сервер полезно помнить о вещах, которые помогут убедить других администраторов в том, что он рассылает не спам, а вполне легитимные письма.
(далее…)