Файловая система proc (в дальнейшем просто procfs) является виртуальной файловой системой, которая предоставляет информацию о процессах. Она — “прекрасный” пример интерфейсов следующих парадигме “все является файлом”. Procfs была разработана очень давно: во времена, когда серверы в среднем обслуживали несколько десятков процессов, когда открыть файл и вычитать информацию о процессе не было проблемой. Однако время не стоит на месте, и сейчас серверы обслуживают сотни тысяч, а то и больше процессов одновременно. В таком контексте идея “открыть файл для каждого процесса, чтобы вычитать интересующие данные” уже не выглядит такой привлекательной, и первое что приходит на ум чтобы ускорить чтение — это получение информации о группе процессов за одну итерацию. В этой статье мы попробуем найти элементы procfs которые можно оптимизировать.

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

Как вы думаете насколько реально зайти на машину по ssh, обновить систему, загрузить новое ядро и при этом оставаться в той же ssh сессии. Сейчас есть модное движения по обновлению ядра на лету (ksplice, KernelCare, ReadyKernel, etc), но у этого способа есть много ограничений. Во-первых, он не позволяет применять изменения, которые меняют структуру данных. Во-вторых, объекты в памяти могут уже содержать неверные данные, которые могут вызвать проблемы в дальнейшем. Здесь будет описан более «честный» способ обновить ядро. На самом деле, сам способ уже давно известен [1], а ценность этой статьи в том, что мы разберем все в деталях на реальном примере, поймем, насколько это просто или сложно, и чего стоит ждать от подобных экспериментов.

Сегодня мы хотели рассказать вам о том, как наши ребята за три часа повысили производительность кластера для тестирования ПО в 4 раза, просто «пораскинув мозгами».



Upd. Этот пост это — НЕ МАСШТАБНОЕ ТЕСТИРОВАНИЕ — это реальная история из практики с забавными моментами. Мы повысили плотность ВМок в 4 раза, если вы ожидаете увидеть сравнительное тестирование, графики и анализ производительности, вам не сюда. Тут сегодня скорее душевное чтиво.

Уже много лет компания Virtuozzo (бывшее подразделение компании Parallels) разрабатывает серверное ПО для виртуализации на основе открытых проектов. Самые известные opensource разработки компании: OpenVZ, CRIU, P.Haul, Ploop, VCMMD.

Пока патентные войны остаются скрытой угрозой для экосистемы OpenStack, давайте поговорим о технологии, позволяющей разворачивать OpenStack практически в один клик. Название этого проекта многократно встречалось в постах нашего блога, но не было ни одного текста, посвященного именно Fuel. Между тем — именно этот проект существенно упростил процедуру развертывания OpenStack и сделал менее трудоемким процесс дальнейшего управления облаком. Безусловно, можно действовать по старинке. Использование Fuel не является обязательным для работы с OpenStack. Однако мы считаем, что если театр начинается с вешалки, то OpenStack начинается с Fuel. По крайней мере — Mirantis OpenStack (MOS).

Я хочу рассказать как тестируется один из продуктов компании Parallels Inc., в которой я работаю,
— Parallels Cloud Server. Думаю некоторым хабрачитателям этот продукт уже знаком по статьям Parallels рассекретила Cloud Server, FastVPS: Как мы меняли платформы виртуализации и Собери сам: как мы сделали хранилище Amazon-style для небольших хостеров. Если нет, то рекомендую статьи выше к прочтению.

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

Если у меня получилось вас заинтересовать — добро пожаловать под кат.