Самой большой моей ошибкой в проектировании была идея использовать 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() есть везде, а не блокирующие сокеты криво реализованы разве что в винде.

Повторю, тестировалось именно проксирование. Известно, что при прямой отдаче и Apache, и Nginx использует ядрёный вызов sendfile(), который отдаёт содержимое файлика в сокет без лишних копирований. Это неинтересно. А вот проксирование — это совсем другое дело. В ядре пока что ещё нет прямых путей для копирования из сокета в сокет (есть полупрямой вариант splice() + pipe(), но как выяснилось он даже не на всех современных ядрах работает).

Итак…

На порту 8080 живёт Apache 2 ITK. У него в VirtualHost лежит bigfile размером ровно 20MB.

На порту 8081 живёт Nginx, который проксирует в Apache. Его конфиг:

worker_processes  16;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
worker_connections  1024;
}

http {
sendfile        on;
tcp_nodelay        on;
gzip  off;

server {
listen 12.34.56.78:8081;
server_name test1.com www.test1.com;
location / {
proxy_pass http://12.34.56.78:8080;
proxy_redirect http://test1.com:8080/ /;
proxy_set_header Host $host;
}
}
}

Результаты siege для Nginx:

debian2:~# siege -t30s -b -c 10 http://test1.com:8081/bigfile >/dev/null
** SIEGE 2.66
** Preparing 10 concurrent users for battle.
The server is now under siege…

Lifting the server siege…      done.
Transactions:                 372 hits
Availability:              100.00 %
Elapsed time:               29.66 secs
Data transferred:         6773.34 MB
Response time:                0.78 secs
Transaction rate:           12.54 trans/sec
Throughput:              228.37 MB/sec
Concurrency:                9.82
Successful transactions:         372
Failed transactions:               0
Longest transaction:            4.09
Shortest transaction:            0.07

228MB в секунду. Конкурентность 9.82. Доступность 100%. Самый медленный ответ: через 4 секунды.

Результаты oProxy (тоже 16 рабочих, чтобы было абсолютно честно):

debian2:~# siege -t30s -b -c 10 http://test1.com/bigfile >/dev/null
** SIEGE 2.66
** Preparing 10 concurrent users for battle.
The server is now under siege…

Lifting the server siege…      done.
Transactions:                 691 hits
Availability:              100.00 %
Elapsed time:               29.71 secs
Data transferred:        13820.00 MB
Response time:                0.38 secs
Transaction rate:           23.26 trans/sec
Throughput:              465.16 MB/sec
Concurrency:                8.94
Successful transactions:         691
Failed transactions:               0
Longest transaction:            9.18
Shortest transaction:            0.05

465MB в секунду (лучше более, чем в 2 раза). Конкурентность 9.18. Доступность 100%. Самый медленный ответ: через 9 секунд (хуже более, чем в 2 раза). Почувствуйте разницу ©

Мерим на маленьком файле. smallfile имеет размер 5 байт. Эмулируем атаку яростных 10 пользователей. Прочая конфигурация такая же. Результаты в Nginx:

debian2:~# siege -t30s -b -c 10 http://test1.com:8081/smallfile >/dev/null
** SIEGE 2.66
** Preparing 10 concurrent users for battle.
The server is now under siege…

Lifting the server siege…      done.
Transactions:               16952 hits
Availability:              100.00 %
Elapsed time:               30.47 secs
Data transferred:            0.08 MB
Response time:                0.02 secs
Transaction rate:          556.35 trans/sec
Throughput:                0.00 MB/sec
Concurrency:                9.97
Successful transactions:       16952
Failed transactions:               0
Longest transaction:            0.20
Shortest transaction:            0.00

Результаты в oProxy:

debian2:~# siege -t30s -b -c 10 http://test1.com/smallfile >/dev/null
** SIEGE 2.66
** Preparing 10 concurrent users for battle.
The server is now under siege…

Lifting the server siege…      done.
Transactions:                8718 hits
Availability:              100.00 %
Elapsed time:               29.57 secs
Data transferred:            0.04 MB
Response time:                0.03 secs
Transaction rate:          294.83 trans/sec
Throughput:                0.00 MB/sec
Concurrency:                9.27
Successful transactions:        8718
Failed transactions:               0
Longest transaction:            9.00
Shortest transaction:            0.00

А вот тут сливаем, почти в 2 раза. Аналогичная картина при увеличении конкурентных запросов. Но прокся при этом начинает показывать ещё более худшие результаты в Longext transaction. Буду над этим работать.

Update: нашёл в чём причина. В генах архитектуре. Завтра найду время, и перееду с socket passing на shared accept() и, возможно, epoll. Правда, при этом не совсем понятно, что делать с шедулингом нагрузки по рабочим. Рычаг теряю. Судя по логам, accept() на каждое соединение в среднем 3 миллисекунды тратит. Отсюда и цифра — 300 транзакций в секунду.

Из нового:

• Балансировка нагрузки. Универсальный модуль для любых видов соединений. Написано кривовато, но работает. Заведует всеми узлами мастер-процесс. Это несколько замедляет процесс (рабочим приходится больше общаться с мастером), зато позволяет контролировать балансировку в одном месте.
• Файлик: список сайтов. Пока каждый сайт можно только включить/выключить и прописать алиасы. Кроме того, на будущее есть поле “домашняя директория сайта”. В ближайшее время есть планы проксёй отдавать статичные файлы. Не понятно, что делать с .htaccess. Не хочется забивать, как это нынче делается в Nginx.
• Файлик: список узлов. Представляет из себя IP, мастер-пароль, список ролей.
• Роли. Что каждая машина умеет/должна делать. От этого зависит поведение балансировщика и некоторых скриптов. Предопределённые роли: worker_http (узел умеет обрабатывать HTTP-запросы), master (узел будет точкой входа, где висит балансировщик) и другие. Всё рассказывать раньше времени не буду :)
• Мониторинг. Наконец нашёл, где заюзать функционалы. На основе этого функционала (functional) написан мониторинг файлов. Как результат, прокся умеет автоматически подгружать изменённый список сайтов или узлов.
• Новый параметр у oproxyctl: show_nodes. Показывает известные узлы. Кто в дауне, сколько у каждого активных запросов, сколько всего обработано. Может оказаться полезным для выяснения проблемных узлов.
• Поддерживаем новый протокол, который я сам выдумал :) Служит для различных сервисных запросов к узлу. Поскольку позволяет совершать совершенно небезопасные вещи, авторизация происходит без передачи открытого пароля по сети.
• Новая утилита: clusterctl. Умеет 1) запустить на узлах с указанной ролью (или на всех, или на определённом IP) определённую команду и вернуть в STDOUT/STDERR что в итоге получилось 2) рассказывать список ролей текущей ноды 3) рассказывать список узлов, поддерживающих указанную роль. Служит для сервисных скриптов.
• Прокся умеет выставлять X-Forwarded-For, чтобы в конечном итоге в логи попадал нужный IP.
• Сервисные скрипты: apachectl (рестарт Апача на всех узлах), repquota и другие.
• Оптимизация, стабильность.

Допил коньяк. Опять потянуло на философию…

Заменил рекурсивный вызов на цикл, и уже двое суток работаем ровно и без падений; обработано около 2000000 реальных соединений к MySQL.

Кстати…

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

Активных пользователей в MySQL: 453

Из них, имеющих соединие каждые 5 минут за сутки (т.е. работающих круглосуточно): 46

Принято данных от пользователя (байты голого протокола):  9015309900

Передано байт:  121983229037

В сумме потрачено времени внутри MySQL: 138884 секунды (не забываем, что мускуль умеет жрать несколько процессоров)

Обработано запросов (в т.ч. авторизация и протокольная команда QUIT считаются запросами):  61044220

Это данные за сутки назад, включая бэкапный трафик (прибавляет ~15% ко всем циферкам).

  1. Забил на сложный ЯП-подобный конфиг. Нет на это времени, а не разворачивать идею до конца я не умею. In spirit of ispmgr.conf:

Param workers_count “4″
Param socket_reuseaddr “0″
Param log_statistics_period “300″

Listen mysql “0.0.0.0:3306″
Listen mysql “/tmp/mysql.sock”

MySQLBackend “/tmp/mysql-real.sock”
MySQLBackend “0.0.0.0:3307″

/*
Listen mysql “0.0.0.0:3307″
Listen mysql “/tmp/mysql-my.sock”

MySQLBackend “/tmp/mysql.sock”
*/

2. MySQL backend failover. По умолчанию, все соединения идут на 1-й бэкенд. Если к нему подсоединиться не удалось, прозрачно пробуем следующие. Балансировку делать пока не стал т.к. в репликации master-master она только больше проблем создаст. Возможно, её имеет смысл сделать только для балансировки select-запросов. Но это будет позже, с тестированием под нагрузкой.

3.  Если log_statistics_period в конфиге больше нуля — раз в это количество секунд сбрасывать статистику в /usr/local/ispmgr/var/oproxy-stats.log

4. Залечил совершенно замечательную ошибку, из-за которой потенциально, через несколько дней работы мог случиться stack overflow. Но на данный момент, выражалась только в memory leak.

5. Запустил в тест на рабочей хостинг-машине. Несколько часов полёт нормальный.

2. Порт под FreeBSD. Это удивительно, но под фрюхой прокся вываливалась с исключениями о deadlock’ах в мутексах. И это правильно, там алгоритмически иначе быть не может. Почему этого не происходило под Linux — фиг знает. А ведь и там вываливалась иногда с этим, но не в этих местах кода…

3. Полная поддержка KeepAlive. Сводится к тому, что прокси теперь не жалуется в логи, если в процессе ожидания команды от клиента случился таймаут. И вообще, логи оставлены практически только для ошибок.

4.  Исправлено несколько разного рода ошибок.

В общем, ничего интересного. Дальше в планах написание балансировщика для mysql_proxy и конфиг. Конфиг — это большая тема. Там должен быть элемент ЯП. И что этот язык должен уметь, ещё надо подумать.

time perl -MDBI -e ‘$dsn = “DBI:mysql:database=mysql;host=127.0.0.1;port=5501″;$dbh = DBI->connect($dsn, “user”, “анунеподглядывай”);for(0..100000){$s = $dbh->selectall_arrayref(”select repeat(100000000000000000, 10)”);}’

Во время выполнения, oProxy ел около 31% CPU, MySQL 25% Perl 50%. Ещё есть куда расти.

Как этого добился:

1. Прежде всего выяснил, что очень большие задержки происходят при чтении из сокета. Исследование показало, что я всегда перед этим делаю двойную запись в сокет (отдельно заголовок пакета, и отдельно содержимое), как следствие включается дополнительное ожидание данных ядром от программы, а удалённая сторона некоторое время ничего не получает и не отвечает. Слил всё в один write, ситуация улучилась раза в 4. Но всё равно плохо.

2.  Далее обнаружил, что иногда из-за особенностей протокола MySQL, данные опять отправляются несколькими исходящими пакетами подряд (пакет-заголовок датасета, описание поля, описание поля …, пакет конец описаний, данные, данные, …, конец данных). Всё-таки поставил Ocaml 3.11 и включил для сокета опцию Unix.TCP_NODELAY. Стало ещё лучше, но всё равно не то.

2.5. (в этом месте выясняется, что 80% времени программа проводит в обработке той кучи дебага, что есть в коде. Логи были стремительно сокращены :)

3.  Часовое разглядывание вывода tcpdump’а привело к интересному результату: оказывается, последовательности своих пакетов, MySQL склеивает в одно целое и отправляет одним TCP пакетом. Только сейчас в описании протокола вижу ключевую фразу: The description is of logical packets. Не стал мудрствовать лукаво, тоже начал склеивать последовательности, сократив таким образом количество write’ов в сокет до возможного минимума. С этим пунктом, TCP_NODELAY начинает иметь смысл только при отправке больших массивов данных, поэтому временно упразднён и всё возвращено обратно на Ocaml 3.10.2.

Что умеет: собственно, проксировать (80% готово, см. ниже). Считать трафик, затраченное время и количество запросов. Поддерживает протоколы MySQL >= 4.1 (версия протокола 10?). Теоретически поддерживает и более младшие версии, но не тестировал.

Чего пока не умеет: проксировать наборы данных в ответах клиенту. На реализацию потребуется не более полутора часов.

Чего не будет уметь: балансировать нагрузку. Изначально планировал часть select’ов направлять на реплицирующий сервер. Увы, из-за особенностей протокола MySQL и авторизации в частности, это не представляется реализуемым. Во всяком случае, идея меня пока так и не посетила. Возможно, что-то даст изучение исходников существующих балансеров, если конечно есть с открытым кодом.

UPDATE: Дело оказалось в другом. Когда далёкая сторона рвёт пайп, процесс ловит не исключение, а сигнал SIGPIPE. Который, соответственно, и надо было отловить. Но это уже исключительно моя глупость. Достаточно было воспользоваться gdb. Теперь уже точно всё чудесно:

2008-11-21 15:04:49 [21685] Worker: Exception: Exception got while putstring(): Failure(”Broken pipe”)
2008-11-21 15:04:49 [21685] Worker: Exception: Exception in protocol_http: End_of_file

Добавил подсчёт времени ответа. Считается от момента начала отправки запроса серверу и до появления первого токена (версии протокола) . Пригодится для оценки нагрузки. (циферки: принято/отправлено/суммарное время ответа/количество запросов, среднее время ответа):

2008-11-21 01:15:53 [9458] Master: www-128.ibm.com: 1492/2231/1.151/4 avg response time: 0.288
2008-11-21 01:15:53 [9458] Master: www.google.com: 1529/7240/1.275/4 avg response time: 0.319
2008-11-21 01:15:53 [9458] Master: tldp.org: 2183/32055/2.462/10 avg response time: 0.246
2008-11-21 01:15:53 [9458] Master: do.davebsd.com: 892/61312/3.156/16 avg response time: 0.197
2008-11-21 01:15:53 [9458] Master: 62.105.135.103: 492/4796/0.488/2 avg response time: 0.244
2008-11-21 01:15:53 [9458] Master: john.5070.info: 48972/56860/29.940/25 avg response time: 1.198
2008-11-21 01:15:53 [9458] Master: angara.net: 17093/783047/21.354/64 avg response time: 0.334
2008-11-21 01:15:53 [9458] Master: opennet.ru: 404/18673/3.246/2 avg response time: 1.623
2008-11-21 01:15:53 [9458] Master: weather.noaa.gov: 432/41257/11.670/12 avg response time: 0.973
2008-11-21 01:15:53 [9458] Master: linux.org.ru: 406/359/0.271/2 avg response time: 0.135
2008-11-21 01:15:53 [9458] Master: www.opennet.ru: 827/838/0.091/4 avg response time: 0.023
2008-11-21 01:15:53 [9458] Master: www.linux.org.ru: 3414/21411/1.079/12 avg response time: 0.090

Думаю, на этом можно с HTTP заканчивать и начинать MySQL. Будет продолжать активно тестироваться — я через это дело в интернет хожу.

Померил более достоверными средствами производительность. Окружение: запросы на http://ya.ru, контент которого закэширован моей домашней прокси (Squid). Запросы идут через wlan. Флуд-атака 40-а конкурентными пользователями. Организовал с помощью siege. Строчка запуска: siege -t 30s -b -c 40 http://ya.ru >/dev/null

Результаты 30-секундной атаки:

Через oProxy:

Transactions:                1767 hits
Availability:              100.00 %
Elapsed time:               30.08 secs
Data transferred:            6.24 MB
Response time:                0.67 secs
Transaction rate:           58.74 trans/sec
Throughput:                0.21 MB/sec
Concurrency:               39.27
Successful transactions:        1767
Failed transactions:               0
Longest transaction:            4.14
Shortest transaction:            0.21

Напрямую:

Transactions:                1390 hits
Availability:              100.00 %
Elapsed time:               29.83 secs
Data transferred:            4.91 MB
Response time:                0.83 secs
Transaction rate:           46.60 trans/sec
Throughput:                0.16 MB/sec
Concurrency:               38.78
Successful transactions:        1390
Failed transactions:               0
Longest transaction:            3.65
Shortest transaction:            0.10

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

Кстати, заняло это проксирование 0.22 секунды процессорного времени (в предыдущем измерении допустил ошибку). Т.е. около 0.00012 секунды на запрос.