Эту интересную новость я узнал из письма, упавшего мне на почтовый ящик сегодня ночью. Мне вообще было интересно знать, куда движется Twitter последнее время. Учитывая развитие блоггинговых возможностей у конкурентов (Facebook, Google Plus), было бы опрометчиво, на мой взгляд, со стороны руководства Twitter стоять на месте. Трудно рассматривать Posterous в качестве конкурента Twitter, хотя бы по нишевости контента, посещаемости и другим характеристикам. Как следствие, сомневаюсь что это обычное поглощение (как было, например, у Facebook и Friendfeed. В результате покупки Facebook фактически умертвил сервис, о чём я писал тут и упоминал тут). Скорее всего, это именно “приобретение” квалифицированного персонала и работающего функционала для развития основного проекта (похоже, это такие “модные” веяния в менеджменте IT-компаний последнеевремя). Безусловно, что Twitter имеет несколько иную направленность, нежели Facebook или Google Plus. Однако же, кое-чем их функционал всё-таки перекликается. Плюс, я не исключаю возможность того, что руководство Twitter, подгоняемое волной развития и роста популярности социальных сетей, может усилить социальную составляющую своего сервиса. Хотя, учитывая появление в сети таких проектов, как Diaspora или даже DuckDuckGo, стоит отметить, что эта самая волна многим уже порядком надоела, и, видимо, за максимумом постепенно последует спад. Короче, посмотрим.
Утилитка Spawn-FCGI, предназначенная для запуска процессов в FastCGI-режиме и являющаяся частью проекта Lighthttpd, уже давненько используется многими без самого Lighty. Связано это с её чрезвычайной полезностью, стабильностью и быстротой работы. Три года назад разработчики Lighthttpd даже вынесли её в отдельный проект. Не смотря на растущую популярность PHP-FPM, Spawn-FCGI находит своих “клиентов”. Причем, не только среди запускающих посредством неё PHP-процессы. Недавно мне понадобилось поднять именно Spawn-FCGI для PHP на Debian-сервере. Проблемка в том, что пакет, поставляющий утилиту, не содержит в себе так необходимого для нормального управления init-скрипта. Об этом, кстати, есть баг-репорт. Неприятность затрагивает Debian и, как следствие, Ubuntu и, возможно, её производные. Поскребя по интернету, я нашел-таки скриптик от народных умельцев. Кое-чего в нём для меня не хватало, так что я устранил этот недостаток. Ниже — скрипт с отсебятинкой, работает на Squeeze и не жалуется.
#! /bin/sh## spawn-fcgi Startup script for the nginx HTTP Server## chkconfig: - 84 15# description: Loading php-cgi using spawn-cgi# HTML files and CGI.#### BEGIN INIT INFO# Provides: spawn-fcgi# Required-Start: $all# Required-Stop: $all# Default-Start: 2 3 4 5# Default-Stop: 0 1 6# Short-Description: Start and stop php-cgi using spawn-fcgi# Description: Start and stop php-cgi using spawn-fcgi### END INIT INFO# Author: Ryan Norbauer# Modified: Geoffrey Grosenbach http://topfunky.com# Modified: David Krmpotic http://davidhq.com# Modified: Kun Xi http://kunxi.org# Modified: http://drumcoder.co.uk/# Modified: http://olezhek.net/SCRIPTNAME=$(basename$0)DAEMON=/usr/bin/spawn-fcgi
FCGIHOST=127.0.0.1
FCGIPORT=9000
FCGIUSER=www-data
FCGIGROUP=www-data
FCGIAPP=/usr/bin/php-cgi
FCGICHILDREN=5
PIDFILE=/var/run/$SCRIPTNAME.pid
DESC="Spawn-FCGI"# You can change settings for this script by editing /etc/default/$SCRIPTNAME[-r /etc/default/$SCRIPTNAME]&&. /etc/default/$SCRIPTNAME# Gracefully exit if the package has been removed.test-x$DAEMON||exit 0
test-x$FCGIAPP||exit 0
start(){# $DAEMON -a $FCGIHOST -p $FCGIPORT -u $FCGIUSER -g $FCGIGROUP -f $FCGIAPP -P $PIDFILE -C $FCGICHILDREN 2> /dev/null || echo -en "\n already running"$DAEMON-a$FCGIHOST-p$FCGIPORT-u$FCGIUSER-g$FCGIGROUP-P$PIDFILE-C$FCGICHILDREN--$FCGIAPP 2> /dev/null ||echo-en"\n already running"}
stop(){kill-QUIT`cat$PIDFILE`||echo-en"\n not running"}
restart(){kill-HUP`cat$PIDFILE`||echo-en"\n can't reload"}case"$1"in
start)echo-n"Starting $DESC: "
start
;;
stop)echo-n"Stopping $DESC: "
stop
;;
restart|reload)echo-n"Restarting $DESC: "
stop
# One second might not be time enough for a daemon to stop,# if this happens, d_start will fail (and dpkg will break if# the package is being upgraded). Change the timeout if needed# be, or change d_stop to have start-stop-daemon use --retry.# Notice that using --retry slows down the shutdown process somewhat.sleep 1
start
;;*)echo"Usage: $SCRIPTNAME {start|stop|restart|reload}">&2
exit 3
;;esacexit$?
Скопировать текст в файл, файл поместить в директорию /etc/init.d/, накинуть прав на выполнение:
# chmod +x /etc/init.d/<your filename>
Прописать в автозагрузку:
# update-rc.d <your filename> defaults
Готово. Само собой, для работы скрипта требуется наличие Spawn-FCGI и CGI-интерфейса, процессы которого будут плодиться. В данном случае, я использовал php-fastcgi. Как я упоминал выше, Spawn-FCGI, в общем-то, без разницы, какие CGI-процессы плодить. Это может быть и CGI для Python, например. Кстати, предпоследняя версия этого скрипта как раз была предназначена для запуска CGI для Mercurial — а это Python. Для того, чтобы этот скрипт запускал что-то другое, достаточно поменять значение переменной FCGIAPP на нужное, скопировать скрипт под другим именем и опять прописать в автозагрузку. Скрипт изменен таким образом, чтобы дополнительные настройки для него можно было менять, не редактируя сам скрипт — через файл /etc/default/<your file name>.
Поскольку об этой мелочи я постоянно забываю, я решил написать про неё в блог. Речь идет о Java-плагине для браузеров в Ubuntu/Mint. Этот плагин можно установить при помощи aptitude:
sudo aptitude install sun-java6-plugin
Однако, этого недостаточно, чтобы плагин был обнаружен и “воспринят” браузером. Для этого нужно создать символьные ссылки на библиотеку плагина для нужных браузеров. Причём, от дистрибутива к дистрибутиву путь, по которому размещён этот файл, изменяется. Поэтому, перед тем как раскидывать линки, лучше уточнить путь к файлу libnpjp2.so. В Linux Mint 11/Ubuntu Natty amd64 библиотека плагиина размещается по пути /usr/lib64/jvm/java-6-sun/jre/lib/amd64/. В Linux Mint 12/Ubuntu Oneiric этот путь уже эквивалентен /usr/lib/jvm/java-6-sun/jre/lib/. Eсли платформа не amd64, а x86, то путь тоже поменяется. Само собой, что нужно, чтобы браузеры и библиотека были скомпилированы под одну платформу. Для Opera директория с плагинами обычно размещается по пути /usr/lib/opera/plugins, для Firefox — /usr/lib/mozilla/plugins. Туда и нужно линковать. Выглядеть это будет примерно так:
cd /usr/lib/opera/plugins &&sudo ln-s /usr/lib64/jvm/java-6-sun/jre/lib/amd64/libnpjp2.so
cd /usr/lib/firefox/plugins &&sudo ln-s /usr/lib64/jvm/java-6-sun/jre/lib/amd64/libnpjp2.so
Real deal от Google, по идее, “подхватывает” этот плагин автоматически. Отмечу, что я использовал для примера выше путь к libnpjp2.so для Mint 11/Ubuntu Natty.
После создания символьных ссылок следует перезапустить браузеры, чтобы они подключили плагин. У Opera, на месте, где должен загружаться апплет, может появиться сообщение, что плагин не обнаружен. Чтобы заработало, нужно просто покликать по этой области. Chrome у меня пожаловался на то, что плагин устарел. Возможно, это было связано с тем, что уже есть седьмая версия Java. В любом случае, единственную альтернативу запуску апплета, которую сейчас может предложить Chrome — установку Java из самораспаковывающегося архива либо из rpm-пакета — для deb-систем нет смысла использовать.
Сегодня обнаружил пренеприятную вещь. Если в WP, будучи авторизованным, производить какие-либо действия, через некоторое время сайт перестаёт отзываться и выпадает в осадок на непродолжительное время. После этого всё опять начинает работать, как ни в чём не бывало, до следующего такого же события. Я полез в логи в поисках источника проблемы. В /var/log/syslog я нашел исчерпывающую информацию:
Dec 22 20:39:41 < хост убран > suhosin[19857]: ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '< ip убран >', file 'wp-admin/admin.php', line 109)
Оказалось, что это полезняшка-Suhosin прибивает скрипт wp-admin/admin.php по причине того, что последний по непонятной причине начинает жрать очень уж много памяти. Гораздо больше, чем задано в настройках PHP. Начав копаться в движке, я обнаружил, что разработчики весьма щедро одарили свой движок памятью (wp-includes/default-constants.php:27):
Подобная запись присутствовала в WP и раньше. Тогда значение просто было жёстко прописано в те же 256Мб. В конфиге php у меня установлено максимальное значение в 128Мб. Именно по этой причине Suhosin и валил выполняющийся скрипт.
На данный момент я не очень представляю, чего же такого делает admin.php, что требует больше 128 мегабайт памяти. Особенно учитывая, что это происходит во время отправки комментария. Не смотря на то, что скрипту требуется память, я решил не раздвигать установленные в 128Мб рамки. Скорее наоборот, я решил придавить Wordpress этими 128 мегабайтами. Как видно из кода выше, это совсем нетрудно сделать — достаточно определить константу WP_MAX_MEMORY_LIMIT в wp-config.php:
define('WP_MAX_MEMORY_LIMIT','128M');
Тогда вышеупомянутый код в wp-includes/default-constants.php не будет выполняться. Конечно, это полурешение. Более того, я ожидаю, что, если скрипту понадобится больше 128Мб, он также будет убиваться, но уже интерпретатором PHP. Однако, я все же посмотрю, как оно будет работать.
У Amazon есть много вариантов использования их вычислительного облака. И это относится не только к широкой линейке тарифов. Можно сказать, что количество тарифов можно умножить на два, поскольку инстансы бывают двух типов — on-demand и reserved. Их отличие только в стоимости. Первый удобно заказывать, когда необходимо взять вычислительную мощность на время, меньшее чем 1 год. В других случаях действительно выгоднее брать reserved-тип либо комбинировать оба. В принципе, ничто не мешает гонять on-demand instance годами, но финансовые потери в такой ситуации будут существенны, да и глупо это.
[ ... ]
