January 30th, 2011

404

getty magic

Дочитал до части, где подробно описывается init+getty. Оно божественно просто и изящно.

init следит за pid'ами запущенных процессов - в интересующих нас вопросах это getty, слушающие на виртуальных консолях и последовательных портах.

когда приходит соединение и getty запускает login, он запускается не как fork-n-exec, а как чистый exec (с замещением вызвавшего процесса). Более того, login делает ровно то же самое - он запускает шелл через exec(), замещая им себя.

init молчит, так как pid жив. Как только pid умер (баш закрыли), init перезапускает getty, который в свою очередь запускает логин. Просто? Да. Изящно? Да!

И вот ещё чуть-чуть логики: на машине с fork-бомбой можно залогиниться с консоли, но нельзя ничего запустить. Почему? Потому что при логине не образуется НОВЫХ PID'ов, весь процесс проходит в одном PID'е. Так что залогиниться можно, но как только разлогинишься, init не сможет перезапустить getty.
404

Абстрактные размышления о модели ограничения iops'ов для Xen'ае

Существующая схема в XCP подразумевает использование cgroups и io-скедулеров. Но это слишком неудобно, как мне кажется.

Поскольку готовых удобных решений нет, давайте подумаем, как должны выглядеть готовые красивые решения?

Я исхожу из модели blktap(2), то есть виртуального блочного устройства, которое обслуживается в dom0 и присутствует в domU, по одному instance на каждую виртуалку.

Итак, что мы хотим ограничить? В самом абстрактном смысле - сделать так, чтобы io одного человека не мешало io другого, а в случае конфликта, выдавало бы каждому не менее X операций в секунду.

Этот наивный подход утыкается в проблему, которую я так и не смог решить, и которая, как мне кажется, так и не имеет решения: мы не можем сказать, сколько IOPS'ов у нас есть. Есть статистические замеры, есть худший и лучший случаи, но вот реального числа "будет не менее XX иопсов" у нас нет. Точнее, такое число есть, но оно очевидно неудовлетворительно и определяется случаем, когда все запросы с диску пробивают все кеши и попадают на один и тот же диск в худшем для него порядке. Такого случая исключить нельзя (хотя он очень маловероятен), таким образом, нижняя оценка производительности у нас оказывается чрезмерно заниженной. Все остальные оценки же не являются достоверными, так как мы всегда можем оказаться "чуть ниже прогноза".

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

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

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

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

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

Третья проблема чуть более практичная: каким образом мы формулируем ограничения? Это относительный приоритет, абсолютное число или абстрактное best-efforts в надежде, что наши усилия окажутся лучше, чем дефолтный io-скедулер?

Четвёртая проблема уже упоминалась, но всё равно требует отдельного внимания: любого рода скедулеры уровня хоста не будут учитывать наличие прочих хостов с равноконкурентным доступом к хранилищу; скедулер же уровня хранилища не сможет разделять виртуальные машины между друг другом (если мы стоим на модели lvmoiscsi). Другими словами, предлагаемое решение должно каким-то образом учитывать помехи от соседей как объективную реальность и действовать в своих пределах, не мешая соседям. При этом, опять же, нужно избегать стадного эффекта при работе алгоритма (все одновременно сделали бурст, потом одновременно же из-за затора тормознулись).

Выписываем проблемы ещё раз:
1) Как определить затор, желательно до его начала?
2) Как совместить burst с отсутствием задержек у окружающих?
3) По каким признакам накладывать ограничения?
4) Как учитывать конкурентный доступ к ресурсу со стороны неконтролируемых конкурентов при ограничении контролируемых?
404

(no subject)

Пожалуй, mindmap'ы всё-таки стоят внимания. Хотя мне очень не нравится, что они получаются такие развесистые и требующие большого скроллинга.
404

mind maps

Является ли ветка "я тупой лемминг" частью дерева рассуждений в mindmap'е?
404

mindmap

Споры как лучше - от руки или на компьютере, это всё равно, как споры "от руки писать или печатать на компьютере". mindmap это просто альтернативная форма записи текста.

Известные формы:

plaintext
таблица
список


Так вот, mindmap - это просто power of tree в применении к неструктурированным данным. Её можно писать как угодно, важно, что это просто другая форма записи. Её ближайшим аналогом являются вложенные списки, но они редко выживают на глубине выше 2-3, ибо глаза полностью запутываются, такие списки навязывают последовательное чтение для древовидной структуры, что не всегда оправданно.

mindmap всего лишь упрощает запись глубоко структурированных текстов, позволяя неограниченно увеличивать глубину (у меня тут mindmap по сборке xapi открыт, там глубина колеблется от 10 до 40, горизонтальный скроллер это мелочь).
404

Разбираюсь с xcp-ddk

Что меня убивает - каждая попытка - на минут 20 компиляции. Почти как с ядром линукса.

Сейчас борюсь с их опечаткой в SPEC-файле для type-conv. Кажется, оборол. Сейчас решаю проблему конфликта пакетов (кажется, я зря ставил родные RHEL'овские ocaml'ы), снёс всё, переставил из свежесобранного из build toolchain, жду результата...
404

(no subject)

... кстати, у йота-день, кажется, глюки с посчётом 24 часов и оно меня отрубило не через 24 часа, а часов через 30, а то и больше.