Очевидно, вы упорствуете как в своем нежелании учиться читать, понимать и мыслить, так и в своей неприязни к новым знаниям. С вами скучно и занудно. Но у вас еще есть шанс, если вы отбросите лень и откроетесь новому.
DLag, вы снова и снова показываете вашу техническую некомпетентность.
Тренеруйтесь в чтении документации, консультируйтесь с старшими товарищами - все в ваших руках! Иначе с таким дремучим незнанием основ Unix и нежеланием повышать свой уровень знаний, вы подвергаете клиентов своей компании огромному риску.
broken позволил себе прямые оскорбления в мой адрес, пусть вас не удивляет, что это исключает теплое отношение к нему с моей стороны.
А отношение нашей компании к клиентам - это равноправное партнерство, мы предоставляем услугу - они платят за это деньги, и обе стороны уважительно относятся друг к другу. Если возникает конфликт, то нужно спокойно разобраться в ситуации и решить его без эксцессов. Оскорбления и клевета в стоимость наших услуг не входят.
Возможно, в вашей компании является правилом принимать все оскорбления со стороны клиента, напоминая себе, что клиент платит деньги. Но это значит, что у вас нечетко сформулировано направление бизнеса и вам нужно решить, на чем лучше концентрироваться - на услугах BDSM или все-таки услугах хостинга. Кроме этого, если руководство вашей компании требует от сотрудников работать с клиентом, который их целенаправленно оскорбляет, оно сознательно нарушает КЗОТ в отношении своих сотрудников и подлежит административной ответственности.
DLag, в вашей слабой технической компетентности я уже убедился. Разумеется, для меня не стало сюрпризом, что текст вы "ниасилили" :)
Вот по поводу ваших неладов с логическим выводом вы меня ставите в тупик. Человек не может состоять в современном обществе без элементарных бытовых знаний логики. Вы же ко всему прочему оказываете услуги в достаточно сложной области, где умение пользоваться логикой просто необходимо для нормальной работы. Как вам удается совмещать явное игнорирование логики с вашей работой?
Очередная ваша ложь: я не говорил, что будет тормозить на 1 Гб и нужно взять 2 Гб, я сказал что не уверен, что вам поможет 1 Гб, так как предсказать это невозможно. Я вам предлагал легкий способ проверить - вы почему-то не захотели.
Не хочу гадать, чем у вас был занят сервер, но очевидно, что памяти ему все-таки не хватало. У вас кроме форумов там и сайты размещались, и раздача файлов шла, и nginx кучу временных файлов создавал. Возможно, базы все-таки больше - я почему-то помню 1 или 2 Гб.
Причин могут быть десятки, но результат один - 512 Мб физической памяти было мало и диск вы грузили больше, чем соседи вместе взятые. В OpenVZ эту нехватку памяти восполняет операционная система, забирая ее у ваших соседей. Но это уже вопрос вашей удачи и того, насколько хостера данная ситуация устраивает.
Мне не трудно парировать ваши параноидальные выдумки и ложь. И, хотя мне неприятно ваше общество, есть в этом и хорошая сторона - помогает держать себя в тонусе ;)
Диски у нас хорошие и быстрые - это ваша ложь, у ксен больших требований к скорости нет - это пересказываемые вами выдумки.
broken, не льстите себе - мне поминать хама и лжеца желания нет, это заслуга DLag, обращайтесь к нему.
Про особенность OpenVZ повторю. Не для вас, конечно - бесполезно делиться знанием с человеком, воинствующим в своем невежестве. Но только чтобы вы другим не морочили голову вашими интерпретациями.
У OpenVZ есть одна особенность - очень гибкое распределение памяти между виртуальными серверами. Одно из основных преимуществ. Во многих случаях приносит огромную пользу, особенно в корпоративных системах. Но в хостинге это часто приводит к неприятным побочным эффектам, когда для виртуальных серверов даже с одинаковыми тарифами физическая оперативная память распределяется не одинаково и может сильно отличаться. Вплоть до того, что фактическое использование физической памяти VPS с минимальным тарифом может быть больше в десятки раз, чем у VPS с максимальным тарифом.
Например, для минимизации обращений к диску операционная система использует дисковый кэш в физической оперативной памяти. В дисковом кэше хранятся копии данных диска, к которым часто обращаются приложения. Объем этой памяти и то, какие данные в ней нужно хранить, ОС решает самостоятельно, преследуя в качестве цели максимизацию суммарной производительности системы. На практике это решается выделением максимально возможного дискового кэша для VPS, которые больше всего работают с данными на диске (большие базы данных, большое число файлов или файлы большого объема). Дисковый кэш для других серверов будет практически недоступен, а малоактивные программы будет вытеснены в свап.
Таким образом, ОС максимизирует суммарную производительность системы путем максимизации производительности самых нагруженных VPS, пусть и ценой потери производительности у VPS с меньшей нагрузкой.
Если на сервере находятся несколько десятков малонагруженных VPS и несколько VPS с большой нагрузкой, ситуация скаладывается примерно так: VPSы с большой нагрузкой отлично работают даже на минимальных тарифах; а так как малонагруженных VPS очень много и ресурсы отъедаются у них по чуть-чуть, то падение их производительности не так бросается в глаза - ну будет страница вместо 0.01 сек генерироваться 1 секунду. Словом, все как в пословице: с миру по нитке - нищему рубашка.
Ситуация ухудшается, когда число VPSов с большой нагрузкой на сервере увеличивается или нагрузка одного из VPS становится настолько высоким, что операционной системе приходится чаще и агрессивней перераспределять оперативную память. Ухудшение работы других VPS становится очевидным. Иногда клиенты обвиняют из-за этого хостера в оверселлинге, хотя совершенно безосновательно - хостер ничего не оверселлит, это ОС гибко распределяет ресурсы.
Случай broken - отличная иллюстрация этой особенности. Для того, чтобы запустить два форума в сумме на 5000 уников в сутки, можно взять какой-нибудь из самых слабых тарифов на OpenVZ - с, порядка, 256 Мб памяти. Этого вполне хватает, чтобы запустить nginx, mysqld и несколько десятков экземпляров apache с акселератором. А дисковый кэш под файлы сайта и базы данных, объемом около 0.5-1 Гб, выделит сама ОС, позаимствовав память у соседних VPS. Если бы он взял обычный выделенный сервер с памятью в 256 Мб или VDS на Xen с таким же объемом, то скорость работы форума была бы намного медленнее, так как дополнительной памяти по дисковый буфер там взяться неоткуда, а чтение данных напрямую с диска замедлит работу на порядки, какие бы быстрые не были эти диски. Для того, чтобы добиться такой же скорости на выделенном сервере, объем оперативной памяти пришлось бы увеличивать примерно до 1 Гб.
Повторю лишь снова - на дилетантский взгляд "большой оверхед". На практике - незаметно, т.к. кроме диска важен объем памяти и скорость процессора. 7% диска на суммарной производительности веб-приложений превращаются в доли процента. А если у вас задача уже уперлась в диск, плюс или минус 7% существенно ситуацию не изменят.
А рост 7% по экспоненте - с чего вы такую чушь выдумали?
Смысла проводить с OpenVZ не вижу, я и по теории могу представить, что там оверхед минимальный. Но при росте конкурентных запросов оверхед на механику превысит на порядки оверхед на виртуализацию и при интенсивной работе с диском скорость будет практически одинаковой что у нативной ОС, что у Xen, что у Virtuozzo - могут быть лишь небольшие нюансы из-за работы дискового шедулера. Если хотите убедиться, тестируйте сами - я, как уже вам известно, вашим гувернером быть вовсе не стремлюсь :) Если вы высказали чушь, трудитесь доказать ее самостоятельно, а не требуйте от других ее опровергнуть.
Ужасно - это ваша обычная риторическая фигура, которыми вы ужасно злоупотребляете :) Погоняйте на реальных тестах, проверьте одинаковые ли у вас устройства в VM экспортируются. Возможно, у вас в качестве бэкенда блочного девайса используется файл, который держится в кэше хостовой ОС - из-за этого диск в виртуальной машине будет работать даже быстрее чем реальный диск. Посмотрите, вы где-то ошиблись.
У нас клиенты HVM для FreeBSD используют, и со скоростью у них все в полном порядке. Когда пару лет назад мы услугу тестировали, оверхед на диске был незначительный, те же самые проценты.
DLag, тщательно вчитывайться и развивать внимательность - в этом успех понимания при чтении. В топике страдает один клиент не от 7%, а от того, что у него нехватка памяти и disk io больше половины от disk io всего сервера, но ему все не хватает. Тут на чем хочешь застрадаешь. Сотни других клиентов работают с удовольствием.
1, 2. Прелестный образец спутанного мышления :). Ваш unixbench - все тестам тест, а мой unixbench плюс тест архивированием - для вас тест не в тему. Как вы думаете, имеет смысл после этого относиться к вашим словам всерьез?
3. На дилетантский взгляд "дохрена". На практике - незаметно, т.к. кроме диска важен объем памяти и скорость процессора. 7% диска на суммарной производительности веб-приложений превращаются в доли процента. А если у вас задача уже уперлась в диск, плюс или минус 7% существенно ситуацию не изменят.
А как получается таких вычислять? В OpenVZ подсчет disk io для контейнеров сейчас есть?
Впрочем, с этим полностью согласен.
cvss добавил 15.12.2009 в 14:58
Перечитайте пост и поймете о чем тест. Я для вас не гувернер, чтобы учить читать, разжевывать смысл и повторять несколько раз одно и то же. Ну и вы вольны тестировать все, что угодно, я же в этом вас не ограничиваю.
DLag, у вас вызовет неудовольствие любой тест, который не покажет желанный для вас результат и вы создадите тысячу дурацких придирок :) . С этим как раз согласуется то, что вы проигнорировали результат любимого вами unixbench, но, в конце концов, мне ваше отношение к тесту безразлично, тест я делал не для вас.
