Компания Facebook продолжает работу по повышению производительности кода PHP. В 2010 году они выпустили компилятор HipHop (HPHPc), который транслировал PHP в C++, жертвуя некоторыми редко используемыми функциями PHP вроде eval(), но повышая производительность.

С активной аудиторией в 1,1 млрд человек, Facebook крайне заинтересован в увеличении производительности веб-приложений. Поскольку многие программисты хорошо знакомы с PHP, компания решила не отказываться от этого «медленного» языка, а постараться максимально оптимизировать его. Кстати, так же делает и «Вконтакте» с недавно представленной технологией kPHP.

Впрочем, прежний подход по трансляции кода PHP в C++ пришлось оставить. Вместо этого выпущены виртуальная машина, окружение и JIT-компилятор для PHP под названием HipHop VM for PHP или просто HHVM. Здесь речь идёт о повышении производительности в пять-девять раз.
Читать дальше →

Вас смущает это число? Меня тоже.

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

Возможно, вы выделили слишком много оперативной памяти под кеш. Размер его можно значительно уменьшить путем отключения тяжеловесных, но редко посещаемых сайтов. Я вам помогу вычислить такие сайты.
Читать дальше →

   Случилась беда, один из имеющихся серверов периодически стал выпадать в "синий экран смерти", причем всегда с совершенно разными кодами ошибок. Чаще всего были ошибки 050, 02E..., но при таком разнообразии этих ошибок идентифицировать причину отказа не представлялось возможным. После многочисленных поисков, решили что возможно проблема в кривых драйверах, либо самой Windows 2003 Server. Поскольку все данные с сервера мы заблаговременно сохранили, то переустановка Windows 2003 для нас была не критична, что мы и начали делать. Но, как оказалось, даже при установке ОС, на разных этапах, выскакивал синий экран и установка на этом завершалась. Дальше наши изыскания были направлены в сторону "железа", первое что мы попытались это поменять SCSI-диски, благо их в сервере 5 штук объединенных в массив RAID5. Для этого мы создавали новые массивы из разных трех дисков, пытаясь исключить возможно неисправный, но и эти действия не привели к положительному результату. Ради интереса попробовали снять один из двух процессоров с материнской платы, который был во втором слоте, сервер при этом работал и на одном процессоре, но так же выпадал в ошибку, второй процессор снимать не стали, т.к. доступ к нему был не очень удобный. Следующим объектом проверки стал двуканальный SCSI-контроллер Intel SRCU42X, на нем установлена планка памяти на 128 мегабайт, поскольку подходящей памяти мы не нашли, решили поменять контроллер целиком.

 На одном из имеющихся серверов сняли контроллер, правда не такой, как в неисправном сервере, а  SRCU42L, у которого нет съемной планки памяти и только один канал.

   Замена контроллера вначале нас обрадовала, т.к. ОС установилась и мы решили, что проблема найдена, но через некоторое время сервер опять выдал ошибку.

 На материнской плате этого сервера так же есть встроенный SCSI-контроллер, но он был не задействован, ради эксперимента мы снимали PCI-SCSI-контроллер и формировали массив на нем, но и это не помогало. Еще пытались для всех трех контроллеров подбирать драйвера, но что мы только не подсовывали, положительного результата так и не получили.  Дальше уже вопрос стоял о замене материнской платы, либо корзины SCSI дисков и уже начали подыскивать где их можно приобрести.

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

   Вот на фото виновник неисправности - процессор Intel Xeon SL73P (3066DP/1M/533/1.525):

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

Все более популярной становится модель разработки веб-приложений, основанная на идее масштабирования с помощью процессов. Современное приложение представляет из себя набор выполняющихся процессов, не хранящих состояния, причем каждый изолирован друг от друга. Каждому такому процессу назначается свой локальный порт, что позволяет прозрачно экспортировать ваши сервисы для последующего их потребления кем-нибудь еще, возможно даже, что друг другом (например, один обслуживает http-запросы от пользователей, принимая url-адреса видео, а другой медленно, но верно, загружает их и конвертирует). Как правило, в большинстве случаев http-сервисы просто ставят за reverse proxy в nginx, но возможны варианты.

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

web:    mono ./awesome-app --port $PORT
api:    node ./api.js -p $PORT
worker: bundle exec rake resque:work QUEUE=*
habr:   bundle exec ./bin/thin -a localhost -p $PORT

Как видите, все довольно просто, в каждой строчке файла содержится по названию типа процесса и строка для его запуска. Так зачем оно нужно и что же там есть такого вкусного?

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

   Но собственно к делу, система состоит из баллона металлического штампосварного (БПХ - 80), объемом 80 литров в который закачен газ состоящий из хладона, азота, аргона и воздуха под давлением 6,4 МПа (65 кгс/см2). А весит эта бомба только без газа 58 килограмм. К баллону подсоединен модуль газового пожаротушения (МГПТ-65), который представляет собой электромагнитное запорное устройство, открывающее доступ газа из баллона в пожарные магистрали. На нем же установлен манометр, показывающий давление газа в баллоне.

   Модуль газового пожаротушения управляется прибором, который называется Прибор приемно-контрольный и управления автоматическими средствами пожаротушения и оповещателями С2000-ФСПТ. Собственно этот прибор через 8 специальных датчиков, установленных в серверной (4 на потолке и 4 под фальш-полом серверной) и контролирует безопасность серверной на предмет возгорания оборудования.

   Кроме того, прибор предназначен для:

- защиты зоны пожаротушения;

- управления автоматической установкой газового пожаротушения в автоматическом, либо ручном режиме;

- приема и обработки сигналов от извещателей;

- управления звуковыми и световыми оповещателями;

- управления инженерным оборудованием (например вентиляцией);

- приема команд и выдачи тревожных извещений;

- контроля исправности цепей управления оповещателей;

- прима извещений от различных датчиков;

- выдачи извещений "пожар", "неисправность", на пульт пожарной части.

 

    Датчики, которые подключены к прибору реагируют как на увеличение температуры в помещении, так и на наличие дыма. Прибор, кроме того, подключен к радио-передающему устройству РПД Астра-РИ, которое передает извещения по радиоканалу

 

на радиоприемное устройство РПУ Астра-РИ, установленное вне помещения серверной, где находится дежурный сторож.

 

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

 

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

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

  Надеемся, что наша система газового пожаротушения никогда не будет задействована.