Как и было обещано, мы выпускаем под LGPL нашу библиотеку эмуляции эмулятора терминала linux, которую мы используем для показа консолей виртуальных машин в облаке. Называется она, соответственно, pyte (PYthon Terminal Emulator).

По нашим собственным оценкам, покрытие «текстового» функционала console_codes приближается к 100% (от 80 до 90%, как подсказывают пессимисты из числа оппортунистов среди разработчиков).

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

Зато реализованы все остальные сложные функции, такие, как блокировка регионов экрана для записи, скроллинга, управление режимами переноса строк, правильная обработка атрибутов при различных видов удаления текста и т.д. — всё то, что нужно существующим приложениям, таким как nano, adom (на картинке фрагмент ESC-кодов и получающегося изображения как раз из ADOM'а), vim, emacs, mc, aptitude, dialog, yast2 и т.д. для полноценной отрисовки.

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

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

История создания

RIPE (европейский интернет-регистратор, организация, распределяющая IP-адреса) проводит два обучающих курса в Санкт-Петербурге.

RIPE NCC LIR Training Course

Проходит: 21.07.2011
Место проведения: Санкт-Петербург, в отеле Holiday Inn (адрес см ниже)
Темы:

• The Internet Registry (IR) System
• Exercise: RIPE and the RIPE NCC
• The Policy Development Process
• Exercise: First Day at Work as an LIR Contact
• The RIPE Database
• IPv4 Resources
• Exercise: Making Assignments
• Other Resources: AS Numbers & IPv6
• RIPE NCC Services
• Exercise: Slogan

RIPE NCC IPv6 Training Course

Проходит: 22.07.2011
Место проведения: Санкт-Петербург, в отеле Holiday Inn (там же, адрес ниже)
Темы:

• The Registry System
• IPv4?
• Exercise: Business Case
• IPv6 Basics
• Exercise: Addressing Plan
• Getting it
• Deploying
• Exercise: Deployment Challenges

Расписание и место

Новость одной строкой: теперь клиенты могут изменять параметры MOD из панели управления.

Давным-давно в нашем mod-server'е была реализована возможность управления параметрами выделения памяти. Это было реализовано на уровне самого сервера и параметров базы данных.

… Но этого не было в веб-интерфейсе. Самые настойчивые клиенты просили изменить настройки — и мы их меняли вручную. Глупо, да?

Наконец-таки, мы исправили ситуацию — настройки MOD-сервера стали доступны клиентам. Большая их часть применяется «на ходу» и не требует перезагрузки или приостановки обслуживания.

Принцип работы Memory-on-Demand

Новость одним абзацем: теперь у всех без исключения наших dedicated серверов (включая Xeon'ы и Atom'ы) есть возможность пользоваться IP-KVM'ом, встроенным в IPMI. Это:

• возможность смотреть консоль (включая графические режимы, биос и т.д.)
• Нажимать всякие хитрые кнопки (Ctrl-Alt-Del, Alt-SysRq, и т.д.) с виртуальной клавиатуры
• возможность подключать ISO как будто это USB-CD, подключенный к серверу
• Аналогично — образы дискет (этим ещё кто-то пользуется?)
• Включать/выключать питание сервера вне зависимости от мнения об этом операционной системы.

История

Бувально в тот момент, когда я (не очень успешно) вычитывал ошибки и опечатки в предыдущем посте, bobry предложил обсудить, как сделать в консоли историю (которая, Shift-PgUp).

Очевидным методом сделать что-то связанное с терминалами — посмотреть, как сделано у других и сделать так же. В процессе изучения этого мы обратили внимание на интересную особенность: некоторые программы, показывая содержимое, восстанавливают экран до запуска приложения (mc, vim, nano, less и т.д.). Кроме того, при их запуске исчезает (в xterm/gnome-terminal) скролл-бар.

Для изучения «каким образом» было решено остановиться на MC, как самом старинном (и не зависящем от ncurses) приложении.

Далее идёт роматичная история о том, как mc делает toggle_panel() с большим количеством цитат из исходного кода.

Заодно, читатель сможет посмотреть, как выглядит процесс «посмотри в исходниках».

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

Извините фальстарт, это не я, это андроидный смартбук.

Когда мы только запускали облако, первой проблемой было «как нам получить консоль». Штатный механизм XCP поразумевает, что консоль рисуется с помощью VNCTerm, а желающий её увидеть должен сначала пойти в XenAPI, получить там session-id консоли, пойти на порт консоли, передать session-id, получить RFB, завёрнутый в HTTP, развернуть HTTP, вынуть RFB (он же VNC), отдать её локальному рендереру VNC (VNC-клиенту или java-апплету с тем же функционалом). При этом консоль закрывалась (сессия рвалась) при каждой перезагрузке виртуальной машины. Она рвалась даже при миграции виртуальной машины. Другими словами, это была технология, которая подразумевала «глянул одним глазком, починил ssh/iptables и забыл». Неудобно, медленно, сложно. Выкатывать такое в продакт совсем не хотелось.

И я залез в дебри serial-howto, console-howto и ещё несколько ужасных документов, рассказывающих о том, как правильно нужно конфигуриовать прерывания на ISA плате у мультикарт, а так же специфику настройки linux-2.2 для работы с оными. Параллельно изучалось устройство консоли в зене (внимательный читатель мог даже заметить, когда именно я более-менее разобрался в этом вопросе — я писал на хабре краткий обзор того, что происходит с консолью).

После этого пришла мысль: нужно писать своё, потому что готового чужого хорошего нет.

Сначала мы хотели взять хотя бы готовые компоненты и сделать из них своё. Я помню до сих пор ту замечательную схему, в которой мы планировали сохранять в БД вывод anyterm'а, делать двойное туннелирование последовательного порта с использованием UDP… Выглядело это, мягко скажем, неприглядно.

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

Через некоторое время мы пришли к идее «нам нужен свой эмулятор терминала».
Задача казалась относительно простой, пока мы не прикоснулись к бездне, именуемой «escape-коды и типы терминалов...».

Пишущие машинки

Итак, в начале была пишущая машинка. В какой-то момент возникло желание совместить телеграф с пишущей машинкой. Так возник телетайп
Разумеется, инженерам, создававшим телетайп, не было никакого резона делать все с нуля. Они просто приделали коды к каждой клавише пишущей машинки. После некоторых боёв в стиле MS VS Netscape, был создан стандарт html5 на коды для оных машинок, то бишь телетайпов. Если мне память не изменяет, то это ASCII, где предусмотрены все комбинации клавиш, характерные для американской пишущей машинки. Включая код BELL, который, кстати, должен вовсе не делать BEEP, а делать «дзыньк», ибо у пишущих машинок был именно колокольчик, а не спикер.

Для виртуальных машин в облаке Селектел была добавлена консоль. Она доступна в панели управления во вкладке «консоль».

Вот ключевые отличия от примитивного «вот вам VNCterm, разбирайтесь сами»:

• текстовая консоль — малый трафик
• никаких плагинов (flash/java и т.д.) — работает средствами html/ajax.
• консоль можно смотреть одновременно с нескольких браузеров.
• консоль переживает перезагрузку и миграцию
• консоль можно увидеть на выключенной машине (ввод не работает по понятным причинам — но можно увидеть как машина выключалась).
• Копипейст — выделить мышкой и скопировать, вставка Shift-Ins или Cmd-V для маков.
• Переживает миграцию виртуальной машины без разрывов и неприятностей.
• Автоматическая регуляция скорости работы — при интерактивной работе скорость увеличивается, на простаивающей машине — снижается.
• Практически 100% поддержка linux_console — цвета, скроллинг и т.д. Проверены на работоспособность все основные программы — ncurses-based, mc, vim, emacs, nano, пачка консольных игрушек — adom, nethack, тетрис и т.д. Не поддерживается только экзотика вида «загрузить шрифты», «управление VESA-режимами и т.д.».
• Поддержка большинства комбинаций клавиш (зависит от браузера) — Ctrl-комбинации, Alt-комбинации, функциональные кнопки и т.д.
• Полная поддержка unicode (настолько, насколько его поддерживает ваш браузер), как минмум, псевдографика и русский язык работают без каких-либо проблем.

Чего не сделано:

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

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

Реальной работы — два часа в панельке, ещё несколько часов на проверку, что всё работает как положено. Но — не хватало времени и рук. Наконец, нашлось время, сделали.

Как это сделать?

Извините за долгое молчание — много работы, грядут большие обновления. А пока немного о не очень крупном, но весьма заметном для наших клиентов изменении.

Мы отказываемся от размещения модулей ядра на NFS. (И не только модулей, но клиенты заметят именно смену места хранения модулей).

Как это должно было работать

Виртуальные машины клиентов грузятся с использованием наших ядер (то есть код ядра хранится за пределами виртуальной машины). Ядрам нужны модули в процессе работы. /lib/modules подмонтирована по NFS, ядро само определяет из какого каталога грузить какие модули, нам легко их обновлять, клиенту легко получать доступ.

Как это оказалось

Во-первых, NFS-шары монтируются позже инициализации сети (это очевидно) и после монтирования всех остальных строчек в fstab. Ещё круче — в семействе debian/ubuntu они по-умолчанию монтируются асихнронно, так, что получается race condition с запуском rc.local.

Итог: pre-up скрипты на интерфейсах работают не так, как ожидалось, нестандартные файловые системы из fstab не монтируются как положено. Дополнительно, NFS не самый надёжный сервис (особенно с учётом бага #538000), другими словами, неудобно.

Как эту проблему решили

Модули теперь находятся на ISO'шке, подключенной ко всем виртуальным машинам в виде отдельного диска /dev/xvdp. Модули монтируются сразу же после монтирования рута ('/') и позволяют легко выполнять все последующие операции (pre-up скрипты, нестандартные файловые системы и т.д.).

Строчка монтирования (fstab) у всех выглядит одинаково:

/dev/xvdp /lib/modules iso9660 ro 0 0

Кстати, этот диск клиентами не оплачивается.

Один из вопросов, возникающих при создании сервиса (в данном случае не важно, облака или VDS) — это то, как создавать клиентские машины.

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


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

Как всё начиналось...

Когда облако только-только обретало первые черты, возникла задача автоматизации создания виртуальных машин. Разумеется, первым решением, лежащим на поверхности, было «взять и склонировать». Благо, все делов там — одна команда (xe vm-clone). Дальше была необходимость поправить настройки сети, имя хоста и пароль рута. Всей работы — на пол-дня. Ладно, два дня вместе с ловлей блох.

Сделали? Сделали. К счастью, эту версию не увидели даже бета-тестеры.

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

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

Причина? Ну, я думаю, вы догадываетесь. Пароль 323345 — это просто насмешка какая-то. И таких случаев было несколько.

Люди, которые считают, что злые хаккеры их не достанут, потому что «да кому я там нужен» совершенно правы. Никто специально не будет сидеть и подбирать вашу хитрую перестановку из qwerty и 123. Для этого давно созданы специализированные программы, которым, поверьте, глубочайшим образом всё равно, какой изощрённой мыслью вы руководствовались, делая пароль из пяти единиц и одной двойки, размещая двойку именно на третьей позиции (не догадаются же!). Не догадаются. Просто снесут брутфорсом с -цатой попытки. А нужны им не ваши персональные секреты — а ваши ресурсы. Для рассылки спама, перебора пароля к нужным сайтам, для работы в качестве открытого прокси. Для чего ломанная машина с хорошим инетом пригодится всегда найдётся…

Когда мы создавали облако, одной из сложных задач было написание биллинга. Мы решили пойти по пути максимального разделения компонент и ослабления связей (weak linking). Благодаря этому весь процесс делится на несколько независимых компонент: сбор информации о потреблении ресурсов компонентами виртуальной машины, хранение этой информации, списание средств со счёта клиентов, хранение истории списания средств (где-то рядом с историей пополнения и выписанными бумажными счет-фактурами и т.д.).

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

Вот тизер — недельный график суммарных списаний денег с клиентов:

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

Учёт интернет-трафика, наверное, самая простая тема из всех. Сколько байт на сетевой интерфейс пришло — такой и входящий трафик. Сколько байт ушло — такой и исходящий.

Необычным, наверное, является только то, что учитывается трафик не на третьем (сетевом) уровне, а на втором (канальном). Никакого сакрального смысла выбор уровня не несёт, просто в используемой технологии наиболее точный и простой учёт осуществляется именно по числу байт, переданных на канальном уровне. С технической точки зрения это учёт переданных байтов через VIF (виртуальный сетевой интерфейс машины). Единственным неприятным побочным эффектом является то, что всякий служебный трафик, такой как исходящие бродкасты, ARP и т.д. так же учитывается. Но, с учётом стоимости трафика (10^-6 рубля за килобайт) я с трудом себе представляю, как можно служебным трафиком намотать хотя бы на копейку.

А положительным аспектом (для нас, а в каком-то смысле и для клиента) является то, что если клиент поднимает тяжёлое приложение на втором уровне (l2tp, PPPoE, ATAoE), то оно посчитается так же, как и любой другой L3 протокол, без необходимости «довить» на клиента и принуждать его к прекращению использования неудобного для учёта протокола, не укладывающегося в модель «считать по IP».

Продолжаем цикл статей, посвящённых учёту ресурсов облака Селектел.

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

С диском связаны три ресурса, каждый из которых учитывается отдельно:

1. хранение дисков
2. объём прочитанного/записанного
3. и количество дисковых операций

Перед тем, как мы обсудим все три ресурса, нужно ещё объяснить одну интересную особенность устройства виртуальных машин — раздельность учёта ресурсов.

Устройство виртуальной машины

Процессорное время (то есть процессор) и оперативная память, о которых мы говорили ранее — это неотъемлемые ресурсы виртуальной машины. Если их нет — нет и самой виртуальной машины. Но можно (хотя и сложно) представить себе виртуальную машину без дисков и/или без сетевых интерфейсов. Кроме того, одни и те же диски можно подключать к разным виртуальным машинам. Таким образом возникает вопрос: а как учитывать диски, которые были сначала у одной машины, потом у другой, а сейчас вообще лежат не подключенными?

Наша ранняя модель учёта подразумевала, что все эти ресурсы относятся на счёт той виртуальной машины, к которой подключены. Но это вызывало массу неоднозначностей, и мы от этой модели отказались, вернувшись к модели, используемой в Xen Cloud Platform. На картинке упрощённая версия этой модели. Синим показано то, что принадлежит пользователю, зелёным — имена объектов, у которых осуществляется учёт.

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

Перед тем, как мы обсудим, как учитывается память, сначала посмотрим, как эта память виртуальной машине выделяется, и что такое вообще «память виртуальной машины».

Реальная память виртуальных машин

Гипервизор Xen, являющийся основой XCP, являющийся основой облака Селектел, контролирует несколько аспектов работы виртуальных машин. Из интересующих нас с точки зрения учёта — процессор и память. Процессор мы обсудили, теперь очередь оперативной памяти.

С точки зрения Xen'а выделение памяти домену (виртуальной машине) означает, что домен имеет право писать в указанную страницу памяти. Попытка домена записать в запрещённую для него страницу памяти вызовет исключительную ситуацию и с большой вероятностью прекращение работы домена, так что ядро гостевой системы тщательно следит за тем, чтобы не выйти за пределы разрешённой памяти (ровно так же, если программа попытается обратиться к несуществующей странице памяти, то ядро программу аварийно завершит или вызовет обработчик ошибок). В любом случае, виртуальной машине разрешено использовать только ту память, которую ей разрешили использовать. Таким образом, Xen всегда точно знает, сколько страниц памяти выделено той или иной виртуальной машине. (Да, минимальная градация учёта памяти — это 4кб кусочек памяти, называющийся «страница»). Я опущу раздел, связанный с трансляциями адресов, поскольку это одна из самых… м… затруднительных областей. Если вкратце — пририсуйте к обычной схеме трансляции виртуальной памяти на i386 ещё две таблицы дескрипторов — получится примерно оно.

Когда домен создаётся (то есть виртуальная машина стартует), программа под названием domain_builder говорит Xen'у, сколько страниц нужно выделить домену. Эту же информацию сообщают ядру гостевой системы, чтобы оно знало, сколько ей памяти выделено.

Внутри виртуальной машины запущен modd (memory on demand dæmon), который посредством xenstore (специфичный для зена метод взаимодействия между доменами) сообщает управляющему сервису о том, в каком состоянии находится память домена. В реальности это просто запись содержимого /proc/meminfo, не более. Сервер смотрит на настройки виртуальной машины и решает, сколько памяти нужно добавить или убрать. И отдаёт команду на изменение памяти.

И вот тут начинается самое интересное. В Xen'е существует понятие передача страниц памяти. Это, в буквальном смысле, означает «взять страницу памяти от одного домена и передать другому». Соответственно, когда отдаётся команда на отдачу/приём памяти, Xen забирает у гостевой системы память, или отдаёт ей эту память. В силу общей (полезной) параноидальности Xen'а, все отдаваемые из домена страницы предварительно обнуляются (чтобы случайно не отдать ценные данные посторонним соседям по виртуализации).

После запуска я получил много вопросов о том, как именно учитываются ресурсы в облаке. Некоторые интуитивно понимают, что такое «час процессорного времени» но есть и те, кто хочет подробного объяснения. Поскольку в общем анонсе подробные объяснения заняли бы много места, я вынес его в отдельный топик. Заодно, такой формат позволит более подробно описать, как Зен и виртуальные машины взаимодействуют. Уровень этого текста научно-популярный, то есть я не буду вдаваться в дебри кольцевых буферов, маскировки событий, «кредитного планировщика» и т.д., вместо этого я попробую рассказать относительно человеческим языком о том, как гипервизор управляет гостевыми машинами.


Что такое «процессорное время»? Сначала мы его хотели назвать более привычным «машинное время», благо, такой термин использовался во времена мейнфреймов, когда идея разделения машинного времени только-только зародилась, но вовремя остановились. Машинное время тех лет подразумевало все ресурсы, которые использовались машиной, а в нашем случае речь идёт именно о процессоре, так как каждый ограниченный ресурс учитывается раздельно.

Итак, что такое «процессорное время» и как может оказаться, что у одной виртуальной машины его насчитывается 4 часа в сутки, а у другой накручивает 30 «часов» за часов десять?

Облако Селектел работает под управлением Xen, точнее, Xen Cloud Platform, в котором гипервизором выступает Xen.

В Xen есть понятие «планировщик доменов». Оставляя в стороне разницу между доменом и виртуальной машиной (домен — запущенная конкретная виртуальная машина, когда виртуальная машина перезагружается, получается новый домен, когда виртуальная машина выключена, домена нет, а сама машина — есть), можно считать, что этот планировщик виртуальных машин. Те, кто знаком с работой современных ОС, наверное уже догадались, что планировщик доменов подозрительно похож на планировщик процессов в этих самых современных ОС.

Как выглядит работа виртуальной машины?

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

Примерно 47% заказанных клиентами виртуальных машин выключены владельцами. Величина меняется от 38% вечернее время до 58% в ночное.

При анализе статистики я разделил клиентов на две группы — одни реально используют машину в работе, другие — нет (вероятнее всего, это те, кто пришёл «посмотреть»).

Среди реально использующихся самая «дорогая» машина обошлась клиенту в 1138 рублей за месяц, распределение расходов было следующим:

Ресурс	количество	Сумма
Машинное время	158.94 часа	158.94 руб
Оперативная память	304.01 Гб *ч	152 руб
Диск: запросов на чтение	92.016 млн. шт.	276.04 руб.
Диск: запросов на запись	12.641 млн. шт.	37.92 руб.
Диск: прочитанный объём	2167.308 Гб	216.73 руб.
Диск: записанный объём	269.513 Гб	26.95 руб.
Хранение диска	22.110 Тб * час	110.55 руб.
Сеть: получено	54.187 Гб	10.83 руб.
Сеть: отправлено	148.426 Гб	148.42 руб.

Эта машина работает с настройками Debian Squeeze (32), автоматически регулируемая память от 256 до 2048 Мб, диск 30Гб. Судя по загрузке, которую я могу видеть снаружи, вполне себе так работает, процессор показывает загрузку, прыгающую от 10 до 60%, диски шуршат, сеть активна.

Самая дешёвая машина среди «активных» съела примерно 200 рублей (апроксимируем, так как эта машина работает только три недели).

Среди простаивающих машин цифры куда меньше (при примерно таких же настройках). Самая дешёвая машина (видимо, клиент потестил, выключил и решил оставить «на всякий случай») обошлась клиенту в 15 рублей — её выключили в первый день и с тех пор считается там только хранение дисков. Самая дорогая — в 170 рублей (клиент зачем-то сделал диск на 200Гб и периодически включает/выключает. Бэкапы?).

Обещанное этим летом облако Селектела, в котором оплачиваются только потреблённые ресурсы, наконец-то, готово.

На самом деле мы запустились ещё месяц назад, но решили не устраивать себе хабраэффект, а принимать клиентов по чуть-чуть. Благодаря этому мы смогли внимательно изучить возникающие затруднения и решать проблемы в очень индивидуальном порядке. Стратегия себя окупила, так как за время «полузапуска» нашлась одна неприятная опечатка в шаблоне у одной виртуальной машины, несколько мелких огрехов в интерфейсе. Заодно, спокойно, без предпусковой суматохи, были реализованы дополнительные функции управления виртуальными машинами.

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

                                                                              (на графике по оси абсцисс логарифмическая шкала)

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

Вопрос оказался интересным. Вот результаты тестов. В качестве теста использовался sysbench (он есть во многих дистрибутивах Линукса, в т.ч. в Ubuntu и Squeeze).

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

Хорошо видно, что атомы существенно проигрывают Core/Xeon процессорам, которые в один поток оказываются в полтора-два раза быстрее, чем атом с двумя ядрами и гипертредингом.

Ещё одно интересное наблюдение — на атоме 32-битный и 64-битный режим показывают себя одинаково, на всех остальных процессорах 64-битная архитектура заметно выигрывает у 32-битной.

В качестве эталонного теста использовался вызов nice -20 sysbench --test=cpu --cpu-max-prime=40000 --num-threads=X run (X — число потоков, от 1 до 16).

Благодаря тому, что Supermicro создала серверные платформы (19", 1U) на базе процессоров Intel Atom, мы смогли создать новый низкий тариф на арендуемые (dedicated) сервера.

Сервер на базе двухъядерного процессора Intel Atom D510 (1,66 ГГц), 2 гигабайта оперативной памяти, 500 гигабайт дискового пространства — за 1500 рублей в месяц.

Сервер с IPMI (и всеми полагающимися в связи с этим плюшками).

Причина, почему атомы в два раза дешевле ближайшей «старшей» платформы (Core 2 Duo, 3000р)?

• Они кушают меньше электричества
• Они меньше греются (меньше нагрузка на кондиционеры, опять же, меньше электричества).
• У них ниже стоимость, а значит, меньше затраты на аммортизацию.