Цена железа в первой модели:
3 x CPU Xeon 2620 v2 (28000 руб) = 84000 руб.
12 x RAM Kingston DDR3 16Gb (10500 руб) = 126000 руб.
3 x SSD Intel DC3700 (22700 руб) = 68100 руб.
1 x Платформа Supermicro 6027TR-HTRF (210000 руб) = 210000 руб.
6 x HDD HGST Ultrastar 1Tb (5000 руб) = 30000 руб.
Полная стоимость железа: 512810 руб.
Полная стоимость железа и софта: 1452300 руб. по курсу ЦБ на сегодня.
Слишком маленькая наценка за софт, недостаточно энтерпрайзно.
Как именно обрабатывать событие в обработчике Thread.UncaughtExceptionHandler – вопрос второй, можно конечно и в лог писать а потом эти логи парсить. Если конечно есть уверенность в том, что OOM точно не поломает логгинг.
Речь здесь скорее про то, что а) для ловли/логгирования таких ошибок удобно использовать Thread.UncaughtExceptionHandler б) при планировании мониторинга нужно предусматривать кейсы, когда приложение полуживое, но находится в состоянии Out of Memory.
Есть один неочевидный и коварный аспект Out of Memory ошибок, который может натворить много бед в продакшене и о котором стоит сказать. Суть в том, что в зависимости от реализации приложение в полумертвом OOM-состоянии может нормально отвечать на запросы внешнего мониторинга (например, отдавать страницу 200 ОК или возвращать утвердительный ответ о работоспособности иным способом, например по JMS), при этом де-факто уже не являясь работоспособным.
Поэтому если речь идет о mission-critical задачах, может быть уместно устанавливать дефолтный эксепшн хендлер (см. Thread.setDefaultUncaughtExceptionHandler()) и вызывать System.exit() как только прилетает упоминание OutOfMemoryError.
Zlib жмет 20 Мбайт в секунду при 100% утилизации ядра.
Более современные LZ4 и Snappy (этот последний — от Google) при чуть более низком коэффициенте компрессии жмут 300-400 Мбайт на одном ядре, то бишь работают в 15-20 раз быстрее. Так что если стоит цель сэкономить CPU — на мой взгляд логичнее вместо zlib использовать их (при условии что и сервер, и клиент — ваша кодовая база, а в вашем случае это так).
Поясню. Криптографические хеши sha256 и MD5 (как и древний некриптографический CRC32), которые вы используете для решения этих задач, имеют потолок производительности 300-500 Мбайт/с на одном ядре. То есть если читать и хешировать данные с SSD, то потребление CPU будет где-то в районе 100%.
При этом у вас описаны следующие цели:
Яндекс.Диск использует дайджесты sha256 и MD5 для проверки целостности файлов, обнаружения изменившихся фрагментов и дедупликации файлов на бекенде.
Эти задачи применения криптографических хеш-функций не требуют. Для их решения логичнее использовать быстрые некриптографические хеши (например вышеназванный xxhash, по ссылке есть небольшое сравнение).
Скорость получения дайджеста файла увеличена примерно в два раза.
Воспользуйтесь каким-нибудь современным и быстрым алгоритмом хеширования (вроде xxhash) вместо медленных sha256 и md5, и у вас будет повод написать о том, что скорость выросла не в 2, а в 20-30 раз.
В октябре 2014 года компания Microsoft объявила о партнерстве с Docker, в рамках которого будет представлена реализация контейнерной виртуализации для будущей версии ОС Windows Server
Было бы интересно прочесть статью от маркетинга о том, почему «не шмогла», ведь в Linux-контейнерах происходит то же самое. Удивительно и странно наблюдать сейчас как Docker (не имея никаких ракетных технологий) съедает за рубежом рынок, который должен мог бы быть съеден OpenVZ несколько лет назад.
Это можно сделать даже несколькими разными способами: поставить флаг OFPPC_NO_PACKET_IN на конкретный порт, либо поставить table-miss правило с пустым экшном (drop). Вообще многие кошмары, фобии и предрассудки относительно openflow отпадают сами собой при внимательном ознакомлении с их спецификацией. Другое дело, что не всякий свитч (особенно физический) поддерживает те или иные аспекты этой спецификации.
В заключении могу сказать, что цены на виртуальные серверы с SSD дисками в последнее время падают из-за снижения стоимости самих дисков, однако, если Вам требуется большое количество места, то хранение информации на SSD будет не дешевым удовольствием. Однако, я почти уверен, что в будущем нас ждет отказ от медленных SATA дисков.
Реальность такова, что HDD не только никуда не денется, но и большинство перечисленных хостеров под лычкой SSD продают гибридное хранилище. Поэтому оптимизм слегка преждевременный :)
Окупаемость интернет-проекта больше 2-3-х лет не может быть. За это время оборудование уже устареет и не будет приносить прибыль. Сервера — не трубопрокатные станки.
За два года серверы пылью покрыться не успеют :) А серьезно – ключевые технологии просто не обновляются так часто. Те же процессорные сокеты LGA2011 и LGA1366 вышли с интервалом в 4 года. При этом я уверен, что половина российских хостеров до сих пор продает хостинг на процах LGA1366. Так что здесь правильнее говорить о 4-5 годах. Это не говоря о том, что под активным клиентом никто оборудование не апгрейдит, и работать оно может столько, сколько живет клиент.
Дальше, по кредитам и ценам. Покупая оборудование в США на трехлетний кредит со ставкой ну пусть 6% вы в итоге выплачиваете
1*1,06^3 = 1,19 от стоимости оборудования в США
Делая то же самое в России при процентной ставке 15%
1,5*1,15^3 = 2,28 от стоимости оборудования в США
Так что не все то, что кажется нерентабельным демпингом в России, на самом деле нерентабельно в США.
А когда пользовательская база вырастет что? Поднять цены?
Ну, цены поднимать конечно никто не будет, но в целом когда у тебя есть 100к активных пользователей хостинга — продать им что-нибудь в нагрузку не проблема. Защита от DDoS, managed серверы, домены… Вариантов много. Но в реале я думаю они не парятся на этот счет и нормально окупаются даже при текущих ценах. Надо бы посчитать конечно.
150к записей в таблице пользователей не означает, что все из них активны и имеют инстансы. В каком-то из их недавних документов проскакивала цифра в 90к одновременно включенных инстансов всего.
Там не такой уж жесткий демпинг, это все вполне окупаемо. Не стоит забывать, что оборудование и деньги в штатах существенно дешевле. Плюс когда имеешь много денег (а они судя по всему имеют), можно работать не на сиюминутную прибыль а на рост пользовательской базы и стоимости компании.
Все не совсем так. DO первым вышел с массовым и дешевым решением на SSD. Никто не заставлял их демпинговать, это был осознанный маневр обмена ARPU на массовость и виральность. Как вино, расчет был сделан абсолютно верно. Ну а Linode были вынуждены делать не хуже и не дороже, потому что иначе бы проиграли.
3 x CPU Xeon 2620 v2 (28000 руб) = 84000 руб.
12 x RAM Kingston DDR3 16Gb (10500 руб) = 126000 руб.
3 x SSD Intel DC3700 (22700 руб) = 68100 руб.
1 x Платформа Supermicro 6027TR-HTRF (210000 руб) = 210000 руб.
6 x HDD HGST Ultrastar 1Tb (5000 руб) = 30000 руб.
Полная стоимость железа: 512810 руб.
Полная стоимость железа и софта: 1452300 руб. по курсу ЦБ на сегодня.
Слишком маленькая наценка за софт, недостаточно энтерпрайзно.
Речь здесь скорее про то, что а) для ловли/логгирования таких ошибок удобно использовать Thread.UncaughtExceptionHandler б) при планировании мониторинга нужно предусматривать кейсы, когда приложение полуживое, но находится в состоянии Out of Memory.
Поэтому если речь идет о mission-critical задачах, может быть уместно устанавливать дефолтный эксепшн хендлер (см. Thread.setDefaultUncaughtExceptionHandler()) и вызывать System.exit() как только прилетает упоминание OutOfMemoryError.
Более современные LZ4 и Snappy (этот последний — от Google) при чуть более низком коэффициенте компрессии жмут 300-400 Мбайт на одном ядре, то бишь работают в 15-20 раз быстрее. Так что если стоит цель сэкономить CPU — на мой взгляд логичнее вместо zlib использовать их (при условии что и сервер, и клиент — ваша кодовая база, а в вашем случае это так).
При этом у вас описаны следующие цели:
Эти задачи применения криптографических хеш-функций не требуют. Для их решения логичнее использовать быстрые некриптографические хеши (например вышеназванный xxhash, по ссылке есть небольшое сравнение).
Воспользуйтесь каким-нибудь современным и быстрым алгоритмом хеширования (вроде xxhash) вместо медленных sha256 и md5, и у вас будет повод написать о том, что скорость выросла не в 2, а в 20-30 раз.
Было бы интересно прочесть статью от маркетинга о том, почему «не шмогла», ведь в Linux-контейнерах происходит то же самое. Удивительно и странно наблюдать сейчас как Docker (не имея никаких ракетных технологий) съедает за рубежом рынок, который должен мог бы быть съеден OpenVZ несколько лет назад.
Реальность такова, что HDD не только никуда не денется, но и большинство перечисленных хостеров под лычкой SSD продают гибридное хранилище. Поэтому оптимизм слегка преждевременный :)
Все же странно в конце 2014 видеть опенстек в публичных решениях, учитывая то, что весь рынок уже успел пощупать и поплеваться с него.
За два года серверы пылью покрыться не успеют :) А серьезно – ключевые технологии просто не обновляются так часто. Те же процессорные сокеты LGA2011 и LGA1366 вышли с интервалом в 4 года. При этом я уверен, что половина российских хостеров до сих пор продает хостинг на процах LGA1366. Так что здесь правильнее говорить о 4-5 годах. Это не говоря о том, что под активным клиентом никто оборудование не апгрейдит, и работать оно может столько, сколько живет клиент.
Дальше, по кредитам и ценам. Покупая оборудование в США на трехлетний кредит со ставкой ну пусть 6% вы в итоге выплачиваете
1*1,06^3 = 1,19 от стоимости оборудования в США
Делая то же самое в России при процентной ставке 15%
1,5*1,15^3 = 2,28 от стоимости оборудования в США
Так что не все то, что кажется нерентабельным демпингом в России, на самом деле нерентабельно в США.
Ну, цены поднимать конечно никто не будет, но в целом когда у тебя есть 100к активных пользователей хостинга — продать им что-нибудь в нагрузку не проблема. Защита от DDoS, managed серверы, домены… Вариантов много. Но в реале я думаю они не парятся на этот счет и нормально окупаются даже при текущих ценах. Надо бы посчитать конечно.