Дано:

1. Есть кластер. В кластере живёт несколько узлов. В узле живёт несколько веб-серверов. В веб-сервере живёт несколько аккаунтов. В аккаунте живёт несколько сайтов.
2. Для каждого сайта известна текущая нагрузка. Соответственно, известна нагрузка для каждого из аккаунтов.
3. Известно количество сайтов в каждом из аккаунтов.
4. Для каждого аккаунта сказано, на скольких минимум узлах (не веб-серверах) он должен присутствовать. Пусть это будет μ.
5. Для каждого аккаунта известно, какие веб-серверы обрабатывают его в данный момент.

Задача состоит в том, чтобы перераспределить аккаунты по веб-серверам так, чтобы

1. Аккаунты с максимальной нагрузкой присутствовали на максимальном числе узлов. Ну и соразмерно все остальные.
2. Каждый аккаунт представлен минимум на μ узлах.
3. В пределах одного узла каждый аккаунт представлен лишь один раз.
4. Текущая нагрузка наиболее равномерно распределена между всеми узлами (или с каким-то коэффициентом — не суть).
5. Сайты максимально равномерно распределены между всеми веб-серверами, чтобы минимизировать объём памяти каждого из процессов веб-серверов.
6. Сделать это всё так, чтобы изменения коснулись по возможности минимального количества веб-серверов, чтобы затем минимум их пришлось заставить перечитывать конфиг.
7. Делать это каким-то хитрым алгоритмом т.к. простой перебор на потенциальные десятки тысяч сайтов может отожрать немало проца и памяти…

Понятно, что идеально соблюсти все условия не получится. Соответственно, надо либо расставить приоритеты условиям, либо ввести коэффициент максимальной допустимой погрешности решения. Решение вырастает весьма объёмным даже для простого перебора. Мне страшно представить о часе, когда надо будет искать более изящные решения.

Реализованы функторы: Sized (заодно храним фактический размер записи), Splitted (правильнее было бы назвать Striped), Distributed (записи раскидываются по нескольким нижележащим хранилищам), COW (обеспечение почти полной атомарности для всяких сложных хранилищ, типа Splitted, за счёт copy-on-write).

Каким-то сумасшедшим performance пока похвастаться не могу (около 12000 килобайтных выборок в секунду, в случае использования хранилища FileSystem), реализация всё-таки ещё сырая.

Коллега на работе сказанул: «Google BigTable что ли сделал?». Я подумал, и решил, что нет, это Google FS :)

Сейчас развлекаюсь написанием универсального интерфейса к разным хранилищам (в первую очередь, это FS, memcached, memcachedb) с записями вида key+value. В качестве основы, создал универсальный интерфейс:

module type STORAGE =
        sig
                type t
                type storage_descr_t
 
                val init: storage_descr_t -> t init_result
 
                val get: t -> Key.t -> get_result Lwt.t
                val get_list: t -> Key.t list -> get_result Lwt.t list
 
                val delete: t -> Key.t -> delete_result Lwt.t
 
                val set: t -> Key.t -> ?value_size:value_size -> value -> set_result Lwt.t
                val add: t -> Key.t -> ?value_size:value_size -> value -> add_result Lwt.t
                val replace: t -> Key.t -> ?value_size:value_size -> value -> replace_result Lwt.t
        end

Написал модуль FileSystem, реализующий такой интерфейс. Поскольку файлы могут быть (условно) бесконечного размера, это стало самой простой реализацией интерфейса. Но не всё в жизни так легко. Например, memcached имеет максимальный размер пары key+value где-то в районе 64KB. А хочется в нём хранить побольше. Да и файловые системы бывают дурные. Напрмер, не позволяют создавать файлы больше 512MB. Поэтому на основе FileSystem (ключевое слово import) был написан маленький модуль FileSystemSized, который помимо value пишет в файлик размер value. Штука, на первый взгляд, бесполезная. Но идём дальше. Создаём функтор Splitted, который принимает модуль с интерфейсом STORAGE и делает модули с тем же уже знакомым нам интерфейсом STORAGE. Этот функтор хитрый: он знает, какого максимум размера value может хранить переданный ему модуль. Если в одну запись не влазит — он бьёт value на кусочки, для каждого кусочка генерит свой уникальный ключ, и таким образом пишет. В первом кусочке он сохраняет реальный размер всего value. Вот зачем нам нужен был модуль FileSystemSized. На основе этого функтора получается чудесный модуль FileSystemSplitted. По образу и подобию можно сделать MemcachedSplitted. Или даже FileSystemSplitted_and_again_Splitted, только я не придумал зачем :)

Мыслим вперёд. Ключ у нас — строчка строгой длины, с равной вероятностью имеющая в первом/втором/третьем/… байте любое из значений 0..255. На основе первого байта ключа, мы можем раскидать пары key+value на 256 физических хранилищ (ну, или меньше, как захочется). Назовём такой функтор Distributed, и он тоже будет создавать модули с интерфейсом STORAGE. Получается изумительная картинка:

(* Создаём уже знакомый нам модуль для хранения больших значений
   в маленьких файлах.
*)
module FileSystemSplitted = Splitted(FileSystemSized)
 
(* Каждое значение хранится в одном файлике, но файлики раскидываются
   по разным директориям.
*)
module FileSystemDistributed = Distributed(FileSystemSized)
 
(* Каждое значение пилится на части, части раскидываются по разным директориям.
   С remote mount, получаем хранилище бесконечного размера для почти
   бесконечного количества значений.
*)
module FileSystemDistributedSplitted = Splitted(FileSystemDistributed)
 
(* Каждое значение хранится в одной директории, но там оно пилится на части.
   Директорий для хранения может быть несколько. Хранилище получается тоже
   бесконечным, но наполняется не так равномерно.
 *)
module FileSystemSplittedDistributed = Distributed(FileSystemSplitted)

Как видите, с помощью фактически одного интерфейса и двух функторов, получаем невероятное, лютое количество вариантов хранилища. Даже круче, чем в GlusterFS или GNU Hurd. А ведь мысль можно продолжить ещё дальше, дописав функторы Raid0 (писать значение в несколько хранилищ), Clustered (создаётся на основе списка хранилищ, умеющих только читать и списка хранилищ, умеющих изменять), Flock (за счёт некоторого performace degradation, делать exclusive lock на записи)… чем я и занимаюсь :) Замечу, что всё это в функционально чисто, без side-effects (они есть только на уровне хранилища) и безумно типобезопасно.

Как известно, JavaScript — язык c динамической (для классов с утиной) типизацией, с очень плохо развитой системой типов. Стандартный интерпретатор даже в браузерах Mozilla с расширениями разработчика отлавливает минимум ошибок. Практически все эти ошибки — синтаксические. В результате, писать надёжный код на JavaScript предельно сложно. Положение усугубляет фактическая невозможность запуска программы без использования браузера, т.е. нет никакой песочницы для тестов.

В этой статье я попытаюсь описать некоторые технологии, которые помогут знакомому с Ocaml человеку существенно сократить время написания безопасного, стабильного и более-менее компактного JS-кода. Впрочем, описываемые техники есть и для некоторых других языков с развитой системой типов (например, Haskell).

Ocamljs: компилятор Ocaml ⇒ JavaScript

Скачать: http://code.google.com/p/ocamljs/

Всё просто: вы пишете client-side код вашего сайта на Ocaml, а с помощью этого компилятора получаете готовый для использования в браузере JavaScript. Для обеспечения работы, непосредственно к вашему скрипту дописывается около 40KB дополнительного кода. Например. Ни к чему не обязывающий код:

type tree =
	| Leaf of int
	| Node of tree list
 
let l : tree list = []
 
let _ =
	match l with
	| [] -> Dom.window#alert "empty list"
	| a :: [] -> ()
	| a :: b :: [] -> ()
	| _ -> Dom.window#alert "unexpected list"

Компилируем:

ocamljs -o test.js -I /usr/local/lib/ocaml/3.10.2/dom/ dom.cmjsa test.ml

Получаем вот такой код:

// .....
var oc$Dom$ = function () { var window$717 = window;
                            var document$718 = document;
                            return $(window$717, document$718); }();
var oc$1$ =
  function () {
    var l$63 = 0;
    if (l$63)
    {
      var match$71 = l$63[1];
      if (match$71)
      if (match$71[1]) (function () { var v$74 = oc$Dom$[0];
                                      return _m(v$74.alert, v$74, ["unexpected list"]); }()); else ;
      else ;
    }
    else (function () { var v$73 = oc$Dom$[0];
                        return _m(v$73.alert, v$73, ["empty list"]); }());
    return $(l$63);
  }();
var oc$Std_exit$ = (_(oc$Pervasives$[80], [0]), $());
return caml_named_value;
})();

JavaScript compressor

Как я уже сказал, код получается достаточно объёмным. Частично эту проблему решает gzip (при условии, что и сервер, и браузер имеют его поддержку). Однако, код можно существенно сократить за счёт оптимизации по размеру. Для этого есть ряд готовых online-утилит. Используемые техники:

• Удаление комментариев
• Удаление не несущих синтаксической нагрузки пробелов и переносов строк
• Назначение локальным переменным функций более коротких имён
• Вынесение длинных повторяющихся констант в переменную с коротким именем

Наилучшие результаты показывает Packer (http://dean.edwards.name/packer/), однако ocamljs компилирует не полностью корректный код — иногда забывает точки с запятой — поэтому Packer генерирует не работающий код. С учётом некорректности оригинального кода, наилучший результат показал Dojo ShrinkSafe (http://www.dojotoolkit.org/docs/shrinksafe). Рекомендую прогнать код через валидатор (http://jslint.com/), это в любом случае неплохая идея. Пример кода, получающегося с помощью Dojo ShrinkSafe:

// .....
var _213=function(){
var l$63=0;
if(l$63){
var _215=l$63[1];
if(_215){
if(_215[1]){
(function(){
var v$74=_210[0];
return _m(v$74.alert,v$74,["unexpected list"]);
}());
}else{
}
}else{
}
}else{
(function(){
var v$73=_210[0];
return _m(v$73.alert,v$73,["empty list"]);
}());
}
return $(l$63);
}();
var _218=(_(_106[80],[0]),$());
return _9d;
})();

Код получается практически не читаемым, зато размер сокращается в 2-4 раза.

Быстро сравнить различные компрессоры можно на сайте: http://compressorrater.thruhere.net/

O’Browser: виртуальная машина на JavaScript

Скачать: http://ocsigen.org/obrowser/

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

<script src="vm.js" type="text/javascript"></script>
<script type="text/javascript">
  /* <![CDATA[ */
    window.onload = function () {
      exec_caml ("tutorial.exe.uue") ;
    }
  /* ]]> */
</script>

Байт-код получается достаточно объёмным, да и сжатию поддаётся только за счёт слоя gzip. Впрочем, код самой виртуальной машины вполне поддаётся обработке JavaScript компрессоров. Валидность кода получается даже выше, чем у ocamljs. Декомпиляция байт-кода в нормальный JavaScript становится нерешаемой проблемой :)

Вот в отпуске побывал впервые в жизни… а некоторые так за всю жизнь ни разу там и не бывают как я подозреваю.

Не знаю полезно это или нет – отвлечься вот так от работы на почти целый месяц. Я пока не понял какой это возъимеет эффект на производительность труда. Зато во время отпуска я понял кое что о чём много раньше думал и никак не мог осознать.

Меня всегда мучал вопрос – как объяснить людям никогда не занимавшимся такого рода трудом, каким занимаюсь я то что вот происходит у меня и у таких как я в голове когда мы работаем. Как НЕ программисту представить себе работу программиста и понять наконец чего же происходит и как вообще с этим быть.

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

Ну вобщем хватит предъистории. Как работает программист.

Работа программиста – это СОН.

Звучит нелепо, правда?

Если вы хотите представить что именно делает программист во время работы, то легче всего это представить именно так. Он спит!

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

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

Если взять к примеру задачу нахождения пути выхода из лабиринта. Программист в решении этой задачи не перст который ведёт воображаемую маленькую заблудившуюся девочку незнакомой тропой к выходу. Он и не эта девочка тоже. И не стены лабиринта. Он не выход который надо найти. Он всё это вместе разом.

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

Я не фигурально выражаюсь. Это БУКВАЛЬНО снится. Программист при решении задачи виртуально живёт в создаваемом мире химер, похожих каким-то образом на условия решаемой задачи.

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

Большинство людей процесс засыпания воспринимают как определённый ритуал. У кого-то он довольно короткий, а у кого-то довольно сложный и длинный. У кого что. Кому-то надо непременно почитать перед сном, кто-то не засыпает если тридцать приседаний не выполнит перед тем как лечь. Так или иначе отход ко сну у каждого происходит по своему и это не просто ЧИК – и заснул. Хотя бывает у некоторых и так.

Вот тоже самое и в работе программиста. Процесс начала работы это тоже самое. Программист не может просто сесть и начать работать точно также как вот вы не можете сказать себе “СПИ УЖЕ СКОРЕЙ!” и отключиться. И общего какого-то способа тоже нет, как нет его в ритуале засыпания.

Кто-то вот считает баранов, которые будучи вызваны к жизни этим вот самым процессом счёта вынуждены потом как-то дальше жить у нас здесь в Новой Зеландии. А кто-то фантазирует. Кто-то следит за своим дыханием, а кто-то просто прилепит чаю с ромашкой и готов.

Это ведь ещё и меняется со временем. Сегодня вот вы легли спать и всё – уже сладкие грёзы. А завтра ворочаетесь час, два, три и ну никак. Тоже самое и в работе программиста. буквально тоже самое.

Ну и что делать всвязи с этим?

Ну скажем так. Если вы НЕ программист и вы каким-то образом заинтересованы впрямую или косвено в том чтобы он производил-таки продукт своего труда, то вам надлежит понять вот это всё хоть в какой-то более-менее мере.

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

Представили?

Вот это именно так выглядит для нас – программистов. БУКВАЛЬНО ТАК.

Это вам со стороны кажется что вы просто подошли и спросили который час.

А давайте я вас подойду и спрошу в три часа ночи который час?
Чего страшного-то? Ну и что такого что вы только что заснули?
Я просто спрошу, вы ответите и спите дальше. Чего такого-то?

Так легче понять я думаю будет. На таком примере.

Вот вы представляйте что от вашего сна зависит ВСЁ! Всё при всё. Вот от того как вы сегодня поспите зависит будет завтра чего дома жрать или нет. Зависит будет ваша дочть замужем или нет. Вырастет ваш сын неудачником или добьётся чего-то в жизни. Всё это зависит от того как продуктивно вы сегодня поспите.

Представили?

И вот вы собираетесь начать этот сон. Этот вот самый сон от которого ВСЁ зависит и вы это отчётливо осознаёте.

Скажите вот теперь. Как насчёт спать и одновременно немножко, краем глаза разговаривать, чуть чуть помогать сыну решать арифметику, немножко подглядывать в телевизор и чуть чуть так совсем немного съездить в магазин? Не на долго…

Как спится, сладко?

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

Вы бы так смогли КАЖДЫЙ ДЕНЬ?

Ну тоесть каждый день вот вы ложитесь спать ЗНАЯ что от вашего сна зависит всё при всё при всё и даже больше. И вот в процессе вашего сна происходит вот это всё – напоминания, запоминания, помогания, звонки, разговоры посторонние под ухом и всё такое. И так каждую ночь. Как вам такая жизнь?

Хотите?

Призодите работать программистом в нашу контору. Получите в полной мере!

Хотя не всё так трагично. Конечно есть люди которые способны кимарить просто постоянно. Водители такие бывают что чуть-ли не на каждом сфетофоре способны чуток вздремнуть. Ну вы знаете – им чуть бибикнуть приходится чтобы вернуть к жизни. Наверняка вы знакомы с такой ситуацией.

Ну так вот и программисты тоже такие бывают. Они всегда находятся в состоянии близком ко сну. Чуть не мешает никто – сразу “брык” и в сон. Не глубоко, только на чуть чуть. Особо серьёзных никаких химер не успеешь понагрезить, но чуть-чуть немножко слабо-туманных вполне успеешь. Вот в такой сон.

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

Ну потому что отвлекают постоянно. Потому что БУДЯТ же бля постоянно! Потому что люди не понимают что ты же спишь и что их ебучая менеджерская “организационная” активность она на самом деле только мешает работать. Большинство людей НЕ программистов этого не понимают.

Я надеюсь что осознав аналогию работы программиста со сном может быть люди лучше поймут как надо обходиться с программистами и откуда вообще берутся хорошие программы. Поймут наконец что вот этот ебучий ЖЖ – это то что пишу и читаю ПЕРЕД СНОМ. Вот также как вы. Вы не можете спать пока неначитаетесь или пока телевизор не насмотритесь. Не можете ведь?

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

Хотите хороших программ?

Хотите чтобы ваш муж-программист был успешен и заработал все деньги?

Хотите чтобы ваши подчинённые программисты наконец-то сделали всё как надо?

Тогда вот вам простой рецепт:

НЕ БУДИТЕ СЛИШКОМ ЧАСТО ПРОГРАММИСТА!

Но сначала немного технических деталей. В снапшотах ZFS есть неоспоримые преимущества перед снапшотами LVM:

1. В LVM надо заранее выделять место под снапшот (по сути, создавать ещё один logical volume). Если размер изменений в основном разделе превысили это место, снапшот становится неактивным. Его нельзя ни подмонтировать, ни растянуть. Только удалить. Но место под снапшоты можно налету увеличивать, это сомнительный, но плюс.
2. В LVM в каждом снапшоте хранится разница с основным разделом, а не с предыдущим разделом. В итоге, если мы сделали снапшот backup1, затем залили в FS файлик 30MB, затем сделали снапшот backup2, затем залили ещё один файлик на 30MB, то в backup1 будет занято 60MB, а в backup2 30MB. Логично было бы делать снапшот от снапшота, тогда разница накапливалась по-человечьи. Но LVM такое извращение не поддерживается.

Но есть и преимущества:

1. Снапшот является RW. Честно говоря, так и не придумал, зачем оно может понадобиться.
2. LVM живёт в kernel space, в отличие от порта ZFS на Linux zfs-fuse.
3. ZFS предоставляет и не нужный мне слой навороченной FS.

Итак, надо периодически делать снапшот раздела, хранить определённое количество часовых и суточных копий. Для этого написал shell-скриптик lvm-home-snapshot. Вот он:

#!/bin/sh
 
name=$1
size=$2
vgname=$3
lvname=$4
copies=$5
 
time=`date +'%Y-%m-%d--%H-%M-%S'`
sname="backup-$time-$name"
 
/sbin/lvcreate -p r -L$size -s -n $sname /dev/$vgname/$lvname
 
lst=`/sbin/lvdisplay | egrep '^ +LV Name' | egrep "/dev/$vgname/backup-.*-$name"|awk '{print $3}'`
snapshots_cnt=`echo $lst|wc -w`
if [ $snapshots_cnt -gt $copies ]; then
	to_delete=`(for i in $lst; do echo $i; done) | head $(($copies-$snapshots_cnt))`
	for i in $to_delete; do /sbin/lvremove -f $i; done
fi

Как хорошо видно, принимает 5 параметров: имя снапшота, размер, имя группы разделов, имя раздела, количество хранимых копий. Пример использования:

lvm-home-snapshot hourly 768M home john 3

Создаст снапшот “/dev/home/backup-2009-06-19–14-45-01-hourly” раздела /dev/home/john размером 768MB. Если накопилось более трёх снапшотов с именем hourly — наиболее старые будут удалены. Итого, в крон написал:

0 14        * * *    /root/bin/lvm-home-snapshot day 2G home john 4
0 0-4,15-23    * * *    /root/bin/lvm-home-snapshot hour 256M home john 8
15,30,45 *    * * *    /root/bin/lvm-home-snapshot hourquot 128M home john 3

Итак снапшоты создаются, всё чудно. Но надо как-то минимизировать вероятность перезаполнения снапшотов. Для этого был написан ещё один скрипт, который заодно удаляет INACTIVE (переполнившиеся) снапшоты:

#!/usr/bin/perl
 
use warnings;
use strict;
 
my ($name, $vgname, $maxpct, $addpct) = @ARGV;
 
open my $proc, "/sbin/lvdisplay|";
 
my ($d, $s, $u);
while (<$proc>) {
	chomp;
	if (/^ +LV Name +(.*)/) { $d=$1 }
	elsif (/^ +COW-table size +(\d+)\S* +(.*)/) { $s=int $1; $u=$2 }
	elsif (/^ +Allocated to snapshot +(\d+)/) {
		my $pct = $1;
		next if $d !~ m|^/dev/$vgname/backup-.*-$name$| || $pct<$maxpct;
 
		my $newsize = int $s*($addpct/100+1);
		`/sbin/lvextend -L$newsize$u $d`;
	}
	elsif (m|^ +(/dev/$vgname/backup-.*-$name) \[INACTIVE\]|) {
		`/sbin/lvremove -f $1`;
	}
}
close $proc

Принимает параметры: имя снапшота, имя группы разделов, максимальный процент занятости (при превышении снапшот увеличивается), на сколько процентов от текущего увеличить. Пример использования:

lvm-home-snapshot-extend hourly home 15 30

Все снапшоты с именем hourly в группе разделов home, занятые более чем на 15%, будут увеличены на 30%. В крон добавил строчки:

* *        * * *    /root/bin/lvm-home-snapshot-extend hourquot home 15 30
* *        * * *    /root/bin/lvm-home-snapshot-extend hour home 25 30
* *        * * *    /root/bin/lvm-home-snapshot-extend day home 35 20

Не слишком эффективно, но меня устраивает. Да и лень как-то дальше развивать.

include Set.Make(struct type t = (int * int) * int let compare = compare end)
 
let (@) g f x = g (f x) and id x = x and sw f x y = f y x and zip x y = (x, y)
 
let fold9 f = let rec loop i = if i>8 then id else loop (i+1) @ f i in loop 0
 
let fold81 f = fold9 (fold9 @ (@) f @ zip)
 
let mark ((i,j),x as e) : t -> t =
  add e @ fold9 (fun k -> remove ((i/3*3 + k/3, j/3*3 + k mod 3), x) @
    remove ((i,j),k) @ remove ((i,k),x) @ remove ((k,j),x))
 
let search =
  let g p f s = fold (f @ sw mark s) (filter ((=) p @ fst) s) in
  fold81 g
 
let read () =
  let f p = Scanf.scanf "%d " (fun x -> if x>0 then mark (p,x-1) else id) in
  fold81 f (fold81 (fold9 @ ((@) add @ zip)) empty)
 
let print s () =
  let pr ((i,j),x) = Printf.printf "%d%c" (x+1) (if j=8 then '\n' else ' ') in
  iter pr s; print_newline ();;
 
search print (read ()) ()

Вы посмотрите эту красоту, это же [почти] совершенство! А если учесть, что 272 байта — это чтение задачи с STDIN и вывод результата, размер кода сокращается до менее чем 600 байт.

Впрочем, Perl традиционно отличился своей минималистической магической мешаниной:

use integer;@A=split//,<>;sub R{for$i(0..80){next if$A[$i];my%t=map{$_/9
==$i/9||$_%9==$i%9||$_/27==$i/27&&$_%9/3==$i%9/3?$A[$_]:0=>1}0..80;R($A[
$i]=$_)for grep{!$t{$_}}1..9;return$A[$i]=0}die@A}R

Ну и специалисты по PHP тоже выразились: http://www.weberdev.com/get_example-4243.html

1. Показать всякую текущую статистику (устаревшее show_workers, show_nodes и т.д.)
2. Управлять списками наблюдения.

Второй пункт интереснее. Немного предыстории. Часто бывает, что у клиентов на shared-хостинге случился перерасход ресурсов и они хотят знать, откуда эта нагрузка растёт. Резонное желание. Но беда в том, что ни я, “заведующий всем” © на хостинге, ни тем более техподдержка не может точно ответить на такой вопрос. Просто неоткуда брать данные. Чтобы разрешить эту проблему и были созданы списки наблюдения. Допустим, по MySQL-пользователю evlampiy случилось превышение нагрузки на MySQL. Пишем:

start save time, sent, query from mysql where user = “evlampiy” into file “/home/evlampiy/mysql_load.txt”

Всё, с этого момента прокся начнёт сохранять в указанный файлик все запросы к MySQL, пришедшие от пользователя evlampiy. Будет записано время выполнения запроса, количество посланных клиенту байт и сам запрос. Как только выяснили происхождение нагрузок, пишем:

stop save time, sent, query from mysql where user = “evlampiy” into file “/home/evlampiy/mysql_load.txt”

Запись прекратилась. Можно и понавороченней:

start save current_time, time/60, sent/1024/1024, host, uri from http where host = “john.5070.info” and ((uri = “/” and time < 0.5) or (uri = “/news/” and time > 0.01)) into file “/tmp/crazy_requests.txt”; stop save host from http into file “/tmp/all_http.txt”

Разумеется, можно посмотреть текущий список наблюдения:

show queries

На моей машине оверхед на один запрос со списком наблюдения длиной 5 получился 70 микросекунд, что примерно соответствует 2.3% на одно наблюдение при отдаче напрямую и 1.7% при проксировании.

Самой большой моей ошибкой в проектировании была идея использовать POSIX треды. Всё замечательно, но только до тех пор, пока активных соединений не становится больше сотни. Дело в том, что такие треды, по сути, являются почти что отдельными процессами: у них свой стек, их обрабатывает шедулер ядра и т.д. Единственное отличие — у них в пределах одного процесса единое адресное пространство. Так вот, всё это вызывало такие проблемы, как переполнение стека, нелинейность масштабирования и пр. В качестве альтернатиы рассматривалось два варианта:

1. Библиотека Equeue. Знаменита тем, что предоставляет низкий уровень к управлению очередями обработки дескрипторов. Это и минус — работать с ней не слишком комфортно: “есть только очередь и события, всё остальное на ваше усмотрение”.
2. Библиотека Lwt. По сути, то же самое, но выполнено совсем, совсем с другого бока. В интерфейсе предоставляется модель монад и псевдопотоков (отсюда название: LightWeight Threads). Быдлокодеру, навроде меня, достаточно лишь описать зависимости между состояниями: что делать, когда я получу данные из вон того сокета, и куда их записать потом.

Выбор пал на Lwt. А вот тут следует сказать несколько восторженных слов о типизации Хиндли — Милнера, используемой, в том числе, в Ocaml. Как я уже сказал, потоки POSIX при разработке выглядят практически как отдельные процессы. Создал поток, и забыл о нём, а он варится сам по себе. В Lwt же надо отдельно позаботиться о последствиях каждой операции IO. Прежде всего, я заменил все вызовы Unix.socket (создание сокета) — благо в коде почти все они были в моей обёртке и реально вызов встречался только в 2-3 местах — на Lwt_unix.socket. И понеслось. Типовычислялка компилятора сразу указала мне, где я, дурень, пытаюсь подсунуть в нормальную сокетную функцию параметр с каким-то странным типом Lwt_unix.file_descr. Следующая неделя прошла за чрезвычайно интеллектуальной работой. Компилятор говорил мне, что нужно сделать чтобы впасть в нирвану, а я всячески пытался её достичь. Таким образом, буквально через несколько дней негритянской работы, передо мной предстал код, который мало того, что не содержал ни одного вызова к стандартным функциям IO, так ещё и компилился.

Каково же было моё удивление, когда с первым запуском оно ещё и заработало! После недели тупой работы, перехода с философии “одно соединение == один самостоятельный псевдопроцесс” на “одно соединение == один конечный автомат”, после исправления тучи кода исключительно по указаниям компилятора! Кривенько, но заработало, результат я увидел. Последующая неделя ушла на исправление совсем новых багов, багов ещё со старой версии и дописывания новых приятных мелочей.

Итого, имеем. Кластер с определённым количеством клиентов (пока меньше, чем на одной машине в среднем, но уже существенно). Прокся заведует как балансировкой нагрузки между HTTP-узлами, так и между MySQL. Т.е. гоняются вполне реальные данные настоящих сайтов. На одно соединение (не запрос) HTTP в среднем уходит чуть меньше миллисекунды CPU (это и проксирование динамики, и отдача статики с помощью системного sendfile). На соединение MySQL уходит несколько больше — около 5 миллисекунд, хотя алгоритм там наоборот в целом проще. Связываю это с

• sendfile() там не применишь, все проксируемые данные копируются в userspace
• Имею богатый опыт разглядывания скриптов клиентов. А это совсем другая, удивительная, не поддающаяся научному изучению культура. У них принято сказать SELECT * на большую табличку, затем сложным алгоритмом с циклами тройной вложенности вычленить из многомегабайтного результата 2 строки, затем их отправить обратно в мускуль с целью join’а в непристойной позе с другой табличкой.

Памяти жрёт в рабочем режиме при текущих нагрузках стабильно 12-15MB (один мастер, 4 рабочих).

Планы (или мечты?) на будущее:

• Пропатчить Lwt на предмет использования epoll() вместо select(). Чтобы в будущем не было мучительно больно обрабатывать 10000 одновременных соединений. Если, конечно, до этого дойдёт.
• Написать некую глюкалу, которая сильно поможет в поиске причин высоких нагрузок как на сайтах, так и в БД. Пока мне это видится чем-то вроде: oproxyreport “select response_time-start_time, uri from http where host=’ispsystem.com’ and uri begins with ‘/ru/’ save to ‘/tmp/load.log’”. Если будет реализовано — сразу можно будет написать интерфейсик в ISPmanager, чтобы клиенты могли сами это делать.

Я всё сказал.

p.s. Нет, не всё :) С переходом на Lwt, обнаружилась ещё одна приятная особенность: портабельность. Например, во FreeBSD 7.1. поломали те самые POSIX треды, из-за чего мне пришлось отказаться от альфа-тестирования прокси на ней в своё время. Lwt же ни от чего не зависит. Select() есть везде, а не блокирующие сокеты криво реализованы разве что в винде.