Прогнать unixbench можно и без бюджета ;), хотя ценность его как теста очень низка - уж очень он синтетический, оторван от реальной жизни.
Но чтобы закрыть тему "тормозов диска у Xen" и показать с цифрами, что тормозов нет, вот результаты unixbench на одной и той же машине, на одном и том же разделе диска. Native - на физической машине с разрешенным одним ядром и 256 Мб ОЗУ, и Xen PV - на виртуальной машине в режиме PV с одним ядром и 256 Мб ОЗУ.
Жирным текстом выделены итоговые числа - чем больше, тем лучше. Видно, что на физическом железе, и в виртуальной машине, числа почти равны, в виртуальной машине даже немного больше. Казалось бы, нарушение закона сохранения энергии, но объясняется просто - небольшую часть нагрузки (доли процента) принимается на себя подсистема ввода-вывода, которая находится снаружи виртуальной машины и выполняется на другом ядре.
А можно посмотреть на результат нормальной, реальной задачи. Упаковка в tar исходников ядра линукса - задача с интенсивным чтением диска. Суммарный размер - около 320 Мб, больше 24 тыс. файлов. Перед упаковкой дисковый кэш сбрасывался через vm.drop_caches.
Разница во времени - чуть меньше 7%, достаточно обычный оверхед на виртуализацию.
Наши ошибки мы признаем. Если они приводят к нарушению SLA, мы всегда предоставляем компенсацию. Последний раз масштабная проблема была в сентябре - авария на одном из узлов SAN, устранение которой потребовало несколько часов. Авария затронула более 50 виртуальных серверов, хотя многие аварию даже не заметили. Всем была начислена компенсация в виде 1 месяца бесплатного хостинга.
В случае с broken, постоянная проблема была именно у него - по действующему тарифному плану ресурсов не хватало, а переходить на следующий тариф и платить больше владелец не хотел. Разумный человек из всей этой истории увидит то, что нам просто не повезло иметь дело с broken, с этим единственным клиентом, который теперь в иррациональной ненависти флудит при упоминании TrueVDS и не брезгует ложью, личными оскорблениями и разговорами самого с собой под маской виртуала.
broken, опускаться на ваш уровень до взаимных оскорблений не хочу, а продолжать вежливо разговаривать с вами не теряя собственного достоинства уже не вижу возможности. Поэтому впредь постараюсь вас игнорировать. Вам предлагаю начать тратить свое время на что-нибудь полезное и позитивное, и воздерживаться от участия в этой теме и комментирования сообщений, связанных со мной или TrueVDS.
На технические вопросы от других участников форума отвечаю и продолжу отвечать с удовольствием. Могу рассказать и про ребилды RAID, если это кого-нибудь и в самом деле интересует.
Понимаю, что на поставленные вопросы вам отвечать не удобно и вы их обходите стороной или противоречите сами себе. Но не стоит переходите на оскорбления, здесь не детский сад.
У меня еще возникло предположение, почему вы столько много энергии тратите на ненависть к нам. Это отличное предупреждением новому хостеру о том, что его ожидает, если вдруг на ноде появятся еще тяжелые клиенты и ваш VDS начнет тормозить :).
Зачем что-то приписывать мне? Вы сами мне в сентябре писали: "на пару дней переносил на второй свой впс(1969)". Этот же номер присутсвует в переписке uborshica.
Выбирайте сами, когда вы солгали - тогда или сейчас.
Я приведу факты:
1. В суппорт TrueVDS приходит тикет по поводу тормозов диска на втором заказе, принадлежащем broken.
2. Вскоре после тикета, это же самое сообщение здесь на форуме пишет uborshica.
3. broken и uborshica мило беседуют на форуме как незнакомые люди.
У меня напрашивается вывод - у broken раздвоение личности :). А какая у вас версия?
broken, вы, наверное,еще долго будете черной тенью кружить возле любого упоминания TrueVDS. И, хотя это приносит дискомфорт, к этому можно отнестить с пониманием - понятно, что на всех не угодишь. Яркий источник негативных отзывов, проблема которого заключалась лишь в желании получить ресурсов больше, чем за них заплачено - тоже вполне нормальное явление ;).
Но то, зачем вы здесь завели виртуала uborshica и стали переписываться сами с собой, я уже понять не могу. Чтобы не было слишком одиноко в священной войне?
Чаще всего, узким местом оказываются контроллеры дисковых массивов, может быть у вас модель оказалась неудачная. Но там кроме него есть много компонентов цепочки, каждый из которых может сильно повлиять на производительность в целом. Не возьмусь угадывать, что в вашем случае могло быть не так.
Я тоже видел, было приятно встретить грамотный подход 🍻
У нас латентность сети к iSCSI-storage - 0.06 мс, латентность SSD - 0.4 мс. По сравнению с прямым доступом, конечно, есть задержка, но по сравнению латентностью HDD - будь то SATA или SAS - она мизерная. Через SAN SSD на реальных задачах в 30 раз быстрее, локально - в 35-40 раз.
Да, все верно.
Не совсем так. L1 и так при любом переключении контекста почти полностью очищается. L2, L3 - да, их можно вымыть и замедлить соседа процентов на 5-10. Хотя в реальности это встречается не часто, на этот случай мы даем всем виртуальным машинам на 7% больше процессора, чем указано в спецификации.
cvss добавил 23.10.2009 в 18:20
Ясно, вы представляете только в теории и где-то ошибаетесь. На практике - все нормально, ничего не убивается.
Скорость не убивается. Если бы убивалась, конечно, смысла не было бы.
А как вы пришли к такому мнению? Вероятно, где-то в выводе ошибка.
О том, для чего нужен SAN, у нас написано в описании системы. Про SAN вообще, в популярной форме хорошо написано на Википедии: на английском и на русском. В разделе Benefits (Преимущества) описаны и другие полезные функции, которые она дает.
Все работает через интерфейсы и поддерживается софтварно. Переформулируйте, пожалуйста, вопрос яснее.
