Контролируемое скачивание 2

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

Я буду исходить из того, что вы читали первую часть триллера. Если нет, почитайте сейчас, потому что иначе ничего не поймете. А если читали, то все равно пробегитесь еще разок, потому что давно это было :-).

Напомню вкратце, на какой схеме я остановился в прошлый раз.

• клиент обращается за скачиванием в Django-приложение, работающее под Apache'ем
• приложение возвращает в Apache умный итератор, из которого файл выдается пользователю
• умный итератор умеет ограничивать скорость, придерживая выдачу кусочков файла
• умный итератор учитывает количество отданных байт, записывая его в БД

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

А потом, как и положено по законам драматургии, пришли пользователи :-). Точнее, даже не столько пользователи, сколько нашему менеджеру проекта пришла в голову идея сымитировать небольшую нагрузку и скачать файл в 40 потоков на широком канале. Сервер встал. Загрузка сервера сильно взлетела и продолжала постоянно расти, и при этом сервер не обслуживал ни обычные веб-запросы, ни собственно скачивание. Клиентская качалка не получала никаких данных, ждала таймаут и пересоединялась, пересоединялась, пересоединялась... О чем и был заведен соответствующий баг.

Мыканье слепого котенка

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

Попытка 1: во всем виноват mod_python!

Такое поведение сервера — огромная загрузка и ничего полезного — часто означает, что он только и делает, что свапится. "Ну конечно!" — подумал я, ведь все же знают, что mod_python, который рекомендуется для работы с Django, обладает этим самым минусом: кушает вместе с Апачем сравнительно много памяти. Значит, достаточно просто перевести сервер с Апача на lighttpd и завести Django-приложение через FastCGI, и проблема будет решена! Сказано — сделано. Никаких багов после перевода приложения на другую схему развертывания не возникло, но и не решило это ничего: сервер вел себя абсолютно также...

Попытка 2: утекание коннектов

Поняв, что "нахаляву" проблема не решилась, я стал тестировать приложение в домашних условиях и в какой-то момент поймал странную картину: через несколько секунд начала многопоточного скачивания на сервере образовывалось большое количество процессов Postgres'а — около 70 (по нормальному хватает минимальных 4, включая служебные). После небольшого расследования на поверхность был извлечен совершенно реальный баг. Django всегда закрывает соединение с БД сразу после завершения обработки запроса. Но для контроля скачивания я возвращаю из джанговской функции свой итератор, который начинает выполняться уже после того, как он из Django передан наверх, и соединение с БД к тому моменту уже закрыто и забыто. Но вот в процессе итераций я записываю статистику скачивания как раз в БД, для чего тут же снова автоматически открывается один новый коннект. А закрывать его автоматически уже некому. Вот они и плодились, занимая память.

Попытка 3: во всем виноват flup!

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

Тут надо дорассказать, что в Неком Музыкальном Сервисе все скачивание организовано через корзину: туда альбом сначала кладется, оттуда уже скачивается, и при успешном завершении скачивания из нее удаляется.

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

FastCGI-сервер с Django-приложением организуется с помощью библиотечки flup, задача которой — забрать у Django-приложения итератор с данными и выдать их веб-серверу через собственно FastCGI протокол. Так вот оказалось, что когда клиентский браузер обрывает соединение, lighttpd тоже обрывает соединение с flup и уходит заниматься другими запросами. А вот flup... Он-то совершенно игнорирует тот факт, что данные от него никто не принимает, и продолжает их исправно забирать у приложения и куда-то отдавать. И таким образом через какое-то время приложение думает, что скачивание прошло вполне успешно.

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

Через некоторое время с помощью магии "open source", электронной почты, английского языка и доброй воли автора flup Аллана Садди баг в flup был починен, и я с новыми надеждами запустил сервис в новое тестирование.

Попытка 4: nginx

Ага, вы правильно поняли — ни черта не изменилось :-). Находясь в легком отчаянии от полного непонимания, что вообще происходит (а ведь должно же работать!), я внял совету нашего менеджера проекта попробовать запустить сервис через веб-сервер nginx, который по слухам ещё меньше и быстрее lighttpd должен быть.

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

Какого же было мое удивление, когда в связке с nginx возникли приблизительно те же проблемы, что только что были починены на стороне flup. Только теперь уже сам nginx, агрессивно забирал содержимое из FastCGI-соединения, не заботясь о том, с какой скоростью принимает их клиент (и принимает ли вообще). В результате, из-за того, что nginx быстренько забирал у приложения все данные, альбом регистрировался успешно скачанным и изымался из корзины задолго до того, как клиент его скачивал. И с этого момента все новые запросы клиентского download-менеджера к другим кускам файла падали с ошибками, так как файла уже не существовало.

Правда на этот раз магия "open-source" мне не помогла. Игорь Сысоев — автор nginx — ответил в рассылке в том духе, что это старая мохнатая проблема, и если бы ее было просто починить, то давно уже починил бы... Так я вернулся к lighttpd.

Попытка 5: новый баг в lighty

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

После настойчивого тестирования и сравнения двух этих ситуаций я раскопал удивительный баг, на этот раз — в lighttpd. Засада оказалась — вы не поверите — в цифре кода статуса HTTP-ответа, выдаваемого моим приложением. Первый кусочек файла запрашивался самым обычным GET'ом, и получал в ответ самый обычный 200 OK, и с ним все было хорошо. А вот другие кусочки запрашивались с указанием диапазона нужных байтов, и в ответ получали другой код — 206 Partial content. И вот с ними-то lighttpd и глючил: если он получает из FastCGI сервера ответ со статусом 206, то отказывается принимать туловище дальше, а просто закрывает соединение. Вот так. И никакая "чрезмерная нагрузка" тут ни при чем.

Поискав (безуспешно) ответ на "почему" и "что делать", я снова обратился к магии "open source" и... да, полез искать правды в Сишный код lighty.

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

case 206: /* write_queue is already prepared */
        con->file_finished = 1;

        break;

Очень подозрительно, не правда ли? Я так и не знаю, зачем нужно было это условие, но после того, как я закомментировал этот "file_finished", а после еще научил mod_fastcgi.c, что "положительный ответ" в HTTP это не 200, а диапазон [200 - 299], баг ушел. И новые не пришли.

Попытка 6: долой БД!

Впрочем, Самый Главный Баг тоже никуда не делся. И следующая идея, которая была отработана до дна — это то, что записывание в БД статистики о состоянии скачивания каждым процессом на каждой итерации происходит сотни раз в секунду и должно тормозить. Сначала я попытался заменить запись строчек в БД на запись в некую общую область памяти на сервере, в качестве которой выступал memcached. А потом была еще опробована идея записывать эту статистику в файлы на диске.

В общем, ни одно из этих изменений не повлияло значительно на картину происходящего. То есть PostgreSQL с многопроцессным доступом вполне справлялся. Но в качестве исторического казуса стоит отметить, что именно решение с файлами осталось и работает по сю пору :-).

Попытки закончились

Я погрешу против истины, если скажу, что совсем ничего не исправилось... Нет, после правки утечек соединений с БД и скачиваний в никуда сервер стал кое-что качать. Но все равно, с реальной нагрузкой он совершенно не справлялся: 4 или 5 человек легко ставили его на колени.

Примерно на этом моменте, когда все сторонние эффекты были отброшены, у меня стало формироваться четкое представление о том, почему именно все так плохо.

Все, на самом деле, удивительно просто. Каждый Django-процесс — это Apache + mod_python + интерпретатор Питона + Django + мой код = 25 - 30 МБ. Под lighttpd с FastCGI чуть меньше — 18 - 22 МБ. А это значит, что для того, чтобы держать одновременно 100 пользователей (реальная необходимость) нужно от 2 до 3 ГБ свободной памяти без учета памяти на все остальное. А памяти тогда в сервере было 500 МБ... Вот вам и сваппинг. Причем добивание сервера памятью под завязку тоже не спасло бы, потому что помимо скачивания есть еще и закачивание, и весь остальной веб, так что там реально получалось куда больше 4 ГБ. Да и 100 пользователей были минимальным количеством, предполагалось и побольше.

Что самое печальное, все хорошие идеи на тот момент практически закончились. Был один запасной вариант вообще отказаться от всей идеи контролируемого скачивания как такового и оставить на сервере работать FTP-демон, который замечательно справляется со своими задачами. Больше того, у этого демона (proftpd) есть, вроде бы, какая-то возможность выполнять SQL, а значит, что теоретически его можно было бы даже заставить отмечать успешное скачивание, залезая напрямую в базу.

И еще в голове у меня крутилась совершенно дикая идея, которую я не рассказывал никому во избежание навлечь мрак полного отчаяния в и так-то невеселые времена (проект, между тем, задерживался уже месяца на два). А именно, написать свой веб-сервер на C++, вдохновившись успешно работающим proftpd, каждый процесс которого занимает по 1,5 МБ вместо 25.

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

Как ни странно, я все же решил попробовать написать свой веб-сервер :-). В конце концов, недели мне точно должно было хватить, чтобы понять, срастется оно или нет. И я приступил с расспросами к Google на предмет того, "как там пишутся демоны на C++", на котором я ничего не писал уже несколько лет.

"Медуза"

Но провидению было угодно, чтобы нагуглил я совсем не то, что искал. Рыская вокруг результатов со словами "fork", "daemon", "web server" и всего такого я вдруг заметил знакомое слово "Python" и наткнулся на страничку, которая, ни много ни мало, открыла мне совершенно незнакомую доселе парадигму массового обслуживания запросов и стала поворотной вехой во всей этой истории.

Эта страничка — ныне уже не вполне актуальное описание питоновской библиотеки "Medusa", которая как раз и предназначена для создания серверов, обслуживающих большое количество клиентов. А неактуально оно по той причине, что ядро библиотечки этой, как оказалось, уже давно включено в стандартную библиотеку Питона в виде неприметных модулей asyncore и asynchat.

И вот про эту самую "новую парадигму" я хочу написать подробней. Заранее извиняюсь за отнятое время перед теми, кому она давно уже не нова. Поделюсь с теми, кто так же темен, как я :-).

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

• Многопроцессный, когда сервер для обработки запросов плодит копии (fork'ается), каждая из которых изолирована в памяти и независима от соседних процессов. Это наиболее популярный метод в юникс-средах, потому что fork сравнительно дешев, а треды не везде реализованы хорошо и тормозят. Кроме того, в том же Линуксе, если я правильно помню, именно изолированные процессы необходимы для работы PHP.

  Основной проблеме этого способа было посвящено все предыдущее повествовавание: память расходуется много и пропорционально количеству запросов.

• Многотредный, когда запросы обслуживаются несколькими тредами внутри одного или нескольких процессов. Этот метод популярен в Windows-средах, потому что создание новых процессов сравнительно дорого, а вот треды в Windows сделаны очень неплохо.

  Впрочем, для приложений на Питоне это не рекомендуется в любом случае из-за Global Interpreter Lock.

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

Но раз это один процесс, то пока он обслуживает один сокет (отправляет или принимает данные) остальные сокеты не обслуживает никто. И поэтому, по идее, достаточно одного медленного соединения, чтобы все тормозило в ожидании его. Но этого не происходит, потому что у всех современных ОС есть так называемый "неблокирующий" режим работы сокетов:

• При записи в неблокирующий сокет процесс отдает ОС указатель на сокет, указатель на данные и говорит: "давай, отправляй". И дальше TCP/IP-стек ОС будет заниматься отправкой под управлением ядра совершенно самостоятельно, а управление в процесс возвращается мгновенно. Чтобы узнать, когда данные отправлены (или не отправлены), процесс может периодически проверять состояние сокета, когда оно снова изменится на "готов к записи".

• Аналогично при чтении процесс периодически просматривает состояние сокета, в ожидании того, когда ОС сообщит, что там появились данные. После этого отдает ОС указатель на пустой буфер, говорит: "сваливай всё сюда". И может опять идти заниматься своими делами.

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

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

То есть, если сервер занимается, например, выдачей статических файлов, и для каждого кусочка файла ему надо только считать в память очередной буфер и перекинуть его в сокет — это очень быстро, и такой подход здесь идеально подходит. А вот если серверу для формирования кусочка контента надо долго напряженно копаться в БД или, скажем, зазиповывать архив или обрезать изображение размером 5000 на 3000 точек, то все остальные сокеты действительно будут долго ждать одного, и все будет тормозить. В этом случае надо искать способы разбить долгую задачу на несколько кусочков или передать ее на выполнение в другой процесс или тред.

Download server

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

Но самое, самое-то главное, что при наличии библиотек я могу написать это на Питоне, а значит — использовать Django! А значит в этом отдельном сервере скачивания смогу использовать всю свою уже имеющуюся логику авторизации, проверки прав, поиска файлов альбома. Плюс, там же будут работать мои и Django'вские middleware-фильтры. Короче говоря, я уже имею всю нужную инфраструктуру. Осталось написать только раздачу в сокеты.

Библиотечка asyncore оказалась довольно таки удобной. Все, что потребовалось от меня — это повесить свои функции на события "handle_read", "handle_write", "handle_close", которые библиотека сама запускает, когда сокеты готовы принимать и отдавать данные, и когда закрываются. В эти обработчики я свалил всю свою логику по откусыванию кусочков от файла и ограничению скорости. И даже разбор HTTP-запроса мне не пришлось писать самостоятельно, потому что с Медузой очень удачно поставляется пример HTTP-сервера, из которого я стащил все то немногое, что надо сделать перед тем, как сформировать Django'вский HttpRequest.

Кстати, после того, как я познакомился с Meduse/asyncore, я, опять же впервые для себя, наткнулся у Pythy на описание библиотечки Twisted, которая, похоже, умеет делать то же самое, но более развита. Это так? Где почитать?

В итоге, сервер где-то за неделю был написан и отлажен. И работал, выдерживая и по 100, и по 200 пользователей с неограниченным трафиком. При этом CPU загружался не больше, чем на 50-60% процентов в пике.

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

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

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

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

  

  Сама страничка, кстати, рисуется все теми же Django'вскими шаблонами.

Тем не менее, все мы боялись того, что реальная нагрузка будет каким-нибудь образом отличаться от тестовой, и работать все это не будет. Но все наши страхи оказались напрасными :-). Сервис запущен, download server обслуживает всех, кто к нему обращается, причем процессор нагружает процентов на 30 независимо от того, 80 на нем пользователей или 180. Скушал около 35 МБ памяти и она там колышется в небольших пределах в зависимости от количества народу. Работает неделями без перезагрузки.

Красота!

Вот вам и сочинение "Как я провел лето" :-)