Это может быть в случае, если у вашего NVMe-диска есть достаточно много конденсаторов или батарейка и sync контроллер диска делает тогда, когда хочет сам, а не когда его заставляет ось.
Либо если это диск с высокой параллельностью - такое тоже возможно.
Среди десктопов самое лучшее что я пока видел - это интелы 545s и 760p.
Все самсунги в этом тесте - мальчики для битья (evo вообще утиль, pro - ещё куда ни шло).
Говорят старые сэндфорсы в таком режиме прям огонь как валили, но я сам не проверял.
По-сути этот тест показывает работу диска в режиме транзакций - критично для журналов ceph, для некоторых сценариев работы с СУБД.
Ну и, да, он очень хорошо показывает почему серверные диски стоят столько, сколько они стоят и почему для серверов десктопные диски выбирать не надо, даже несмотря на то что они - вроде как честные ssd.
(мы нежно любим Intel P3520 и S3510 для production-систем, для тестовых систем ставим intel 760p на китайских райзерах)
Наверное, я лично знаю только облачную инфраструктуру и если приложение работает на такой инфраструктуре его называют так же облачным. Есть еще какие то варианты интерпретации?
Судя по дискуссии - есть. Облако - это инфраструктура. Но под "облаком" подразумевают очень разное. От самых первых попыток виртуализации до гиперконвергентных систем и оркестрации. Можно долго ломать копья, а потом выяснится, что сравнивали xen с кубером.
SOA - это архитектура, не совсем понятно как оно относится к облаку и инфраструктуре, SOA можно строить и на обычных железных серверах, хоть в одной стойке, хоть в нескольких ДЦ, только это не будет облаком, все же это будет SOA
Очевидно. Там буква А на конце не для красоты)
SOA (сервисно-ориентированная архитектура) позволяет, при правильной реализации, упростить процесс горизонтального масштабирования систем. Горизонтальное масштабирование в длинных периодах делается железно, в коротких - облаками.
Ну и, ещё момент, когда у нас SOA с оркестрацией - можно легко утилизировать имеющееся железо путем переброски мощностей между сервисами, что улучшает TCO.
Именно поэтому так активно и растёт девопс (кроме того что это же круто и гугл так делает (тм) ) - можно лучше утилизировать гудящие железки в стойках и меньше падать.
Кстати, по опыту очень многих моих знакомых команд, на long-run SOA может очень больно выстрелить в ногу на 50+ сервисах. Очень. С космической стоимостью поддержки и развития.
Это был пример, я не знаю какую задачу в рамках вордпреса кроме self-hosted может помочь решить облако. О более приближенный вариант, на каждую задачу парсера подымать в автомате по инстансу и при завершении убивать инстанс, если есть задача парсить 1000 сайтов, то можно поднять 1000 инстансов спарсить все за пару минут и убрать их. Экономия будет колоссальная, если задачу надо выполнять быстро.
Ещё можно быстро переезжать между хостерами и удобно бэкапиться.
Никто не говорил что это дешево =)) SOA действительно вредна, если она не нужна, то лучше даже не начинать, когда проекту понадобится, перейти из монолита на SOA намного проще чем наоборот.
Вопрос - а где эта точка? Я пока не слышал ни одного кейса, когда успешный продукт с SOA уходил в монолиты. Обратное происходит, но весьма неспешно и далеко не у всех.
И опять же: TCO - король. Если делать приложуху с SOA на входе в 1.5-2 раза дороже, но гипотетически через 4 года нас это будет ограничивать, то бог бы с ним. Давайте хоть заработаем для начала: "In the long run we are all dead"
А кто говорил что облако это дешево? Или кто говорил что облако это отказоустойчиво? Облако это из уровня HL и быстрой масштабируемости, удобства управления и развертывания. Когда можно запустить тысячи машин, объединить их в кластер Hadoop произвести нужные вычисления и потушить все машины и все это за минуты и в автоматическом режиме.
Всё тут происходящее - это потому что никто не договорился в самом начале о том что же такое это облако.
sgrumi топит за SOA; есть такой подход и у него есть свои плюсы и минусы; SOA хорошо существует в среде из большого количества контейнеров и позволяет (при выполнении ещё ряда доп требований) расширяться и сужаться под нагрузку (и _никто_ не сказал что делать со стейтфулами, все делают костыли из говна и палок, ага)
Aisamiery вообще говорит о хадупе. На searchengines? Серьёзно?
Большинство здесь использует софт из говна и палок, который не спасёт ничего. Какая SOA, о чем вы? Ссуровые монолитные парни на php4 (или близком по качеству уровне кода)
И сейчас вот ещё скажу - для подавляющего большинства проектов SOA и kubernetes-based облака вредны и дороги. Да и нахрен не нужны, если честно.
Потому что получится не очень красивая и очень дорогая в эксплуатации и поддержке игрушка.
Чтобы оба пункта работали, облачная платформа должна быть на отказоустойчивых технологиях, прежде всего по стораджу. Локальный сторадж тут никак не будет работать.
Расскажите как решаете вопросы с иопсами и латентностью для томов под субд и, особенно тонкий вопрос - их журналы?
У нас на железе замена sata ssd на nvme даёт прирост по 90 перцентилю почти на порядок, например. Даёт именно из-за улучшения латенси.
Что предлагаете вы? Или назад в каменный век?)
Как решаете проблему шумных по иопсам соседей?
Калькулятор на сайте добивает. У меня только под мастером только одного приложения 84гб памяти сейчас, не считая пачки апп-серверов. Как это всё вбить в ваш калькулятор?
Что за странные мегагерцы коих можно купить астрономические числа? Как они мапятся на реальную производительность ядер уровня, скажем, e3-1270v6?
по нашей практике производительность CPU на РСУБД 20x XEN vCore (Dual E5-2640v4) примерно равны 8x XEN vCore (E3-1270v6): при сравнимом количестве запросов (эквивалентные планы и примерно равный объём данных) е3 дают _лучшее в два раза_ время ответов, Cpu pinning нет, оверселла по ядрам, памяти внутри ноды также нет, средняя нагрузка внутри ноды не более 0.9 по ядрам; диски под данные выделенные и никто их не расходует. Детали могу в привате рассказать.
Так что надо хорошо понимать что у вас за нагрузки и нужную степень параллелизма и немножко о структуре использования данных приложением.
И всякое NUMA ещё, да. CPU Pinning нужен?
вот да, про amd действительно стоило уточнить. Приношу извинения. Как то вылетело из головы что "это" еще существует. А то так можно и до атомов дойти..
Эпики/TR интересны. Там где можно хорошо распараллелиться и основная нагрузка в io - почему нет? С учетом адово медленных ядер в большинстве текущих scalable-то эпики выглядят весьма и весьма конкурентноспособными.
А аналогов e3 пока в массовом сегменте нет.
До атомов можно и нужно доходить, если с умом. Те же современные Avoton C3xxx в синтетике показывают просто удивительные цифры производительности в php на одно ядро, сравнимые с очень частотными e3 последних поколений (можно потестить в новых виртуалках scaleway в амстердаме).
Всё никак не дойдут руки запустить туда живой нагрузки и посмотреть как оно взлетит по 90 процентилю.
Если всё окажется действительно как надо, то эти самые атомы - весьма интересная заявка на определенную нишу, с учетом плотности размещения и энергопотребления.
---------- Добавлено 20.10.2018 в 02:03 ----------
Вот последний тестовый образец за 100 у.е
А если не секрет - где вы (и какие) мамки вы берете под 2011?
Процессоры там прекрасные и под всякие офисные помойки больше и не надо, но вопрос с материнскими платами заставляет грустить.
кто возьмет EX61-NVMe - поделитесь какой там диск будет стоять?)
Это не тот объем даже для базы, когда надо SSD. Надо пару нулей добавить, что бы у HDD возникли проблемы.
Ушатать 6gb базу на hdd? легко
Сделайте выборку с тем, чтобы она использовала filesort и много временных таблиц)
Локальный NVMe на ПК:
Почему-то у меня данные совсем другие.
Это может быть в случае, если у вашего NVMe-диска есть достаточно много конденсаторов или батарейка и sync контроллер диска делает тогда, когда хочет сам, а не когда его заставляет ось.
Либо если это диск с высокой параллельностью - такое тоже возможно.
Среди десктопов самое лучшее что я пока видел - это интелы 545s и 760p.
Все самсунги в этом тесте - мальчики для битья (evo вообще утиль, pro - ещё куда ни шло).
Говорят старые сэндфорсы в таком режиме прям огонь как валили, но я сам не проверял.
По-сути этот тест показывает работу диска в режиме транзакций - критично для журналов ceph, для некоторых сценариев работы с СУБД.
Ну и, да, он очень хорошо показывает почему серверные диски стоят столько, сколько они стоят и почему для серверов десктопные диски выбирать не надо, даже несмотря на то что они - вроде как честные ssd.
(мы нежно любим Intel P3520 и S3510 для production-систем, для тестовых систем ставим intel 760p на китайских райзерах)
Самую боль, конечно же :)
randwrite мелкими блоками в один поток и ещё в режиме транзакций:
fio --filename=[PUT_YOURS] --direct=1 --sync=1 --rw=randwrite --bs=4k --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=journal-test -ioengine=libaio
Более высокие показатели дисковой производительности можно получить, заказав услугу «Премиум Storage» для выбранных контейнеров - Tier II: disk.io - до 400 Mb/s; iops - до 20 000 o/s. Стоимость: 0,03 руб/час
А что с latency - медиана, 90p, 99p, стандартное отклонение? И как меряете иопсы: размер блока, глубина очереди?
Судя по дискуссии - есть. Облако - это инфраструктура. Но под "облаком" подразумевают очень разное. От самых первых попыток виртуализации до гиперконвергентных систем и оркестрации. Можно долго ломать копья, а потом выяснится, что сравнивали xen с кубером.
Очевидно. Там буква А на конце не для красоты)
SOA (сервисно-ориентированная архитектура) позволяет, при правильной реализации, упростить процесс горизонтального масштабирования систем. Горизонтальное масштабирование в длинных периодах делается железно, в коротких - облаками.
Ну и, ещё момент, когда у нас SOA с оркестрацией - можно легко утилизировать имеющееся железо путем переброски мощностей между сервисами, что улучшает TCO.
Именно поэтому так активно и растёт девопс (кроме того что это же круто и гугл так делает (тм) ) - можно лучше утилизировать гудящие железки в стойках и меньше падать.
Кстати, по опыту очень многих моих знакомых команд, на long-run SOA может очень больно выстрелить в ногу на 50+ сервисах. Очень. С космической стоимостью поддержки и развития.
Ещё можно быстро переезжать между хостерами и удобно бэкапиться.
Никто не говорил что это дешево =)) SOA действительно вредна, если она не нужна, то лучше даже не начинать, когда проекту понадобится, перейти из монолита на SOA намного проще чем наоборот.
Вопрос - а где эта точка? Я пока не слышал ни одного кейса, когда успешный продукт с SOA уходил в монолиты. Обратное происходит, но весьма неспешно и далеко не у всех.
И опять же: TCO - король. Если делать приложуху с SOA на входе в 1.5-2 раза дороже, но гипотетически через 4 года нас это будет ограничивать, то бог бы с ним. Давайте хоть заработаем для начала: "In the long run we are all dead"
А кто говорил что облако это дешево? Или кто говорил что облако это отказоустойчиво? Облако это из уровня HL и быстрой масштабируемости, удобства управления и развертывания. Когда можно запустить тысячи машин, объединить их в кластер Hadoop произвести нужные вычисления и потушить все машины и все это за минуты и в автоматическом режиме.
Всё тут происходящее - это потому что никто не договорился в самом начале о том что же такое это облако.
sgrumi топит за SOA; есть такой подход и у него есть свои плюсы и минусы; SOA хорошо существует в среде из большого количества контейнеров и позволяет (при выполнении ещё ряда доп требований) расширяться и сужаться под нагрузку (и _никто_ не сказал что делать со стейтфулами, все делают костыли из говна и палок, ага)
Aisamiery вообще говорит о хадупе. На searchengines? Серьёзно?
Большинство здесь использует софт из говна и палок, который не спасёт ничего. Какая SOA, о чем вы? Ссуровые монолитные парни на php4 (или близком по качеству уровне кода)
И сейчас вот ещё скажу - для подавляющего большинства проектов SOA и kubernetes-based облака вредны и дороги. Да и нахрен не нужны, если честно.
Потому что получится не очень красивая и очень дорогая в эксплуатации и поддержке игрушка.
Чтобы оба пункта работали, облачная платформа должна быть на отказоустойчивых технологиях, прежде всего по стораджу. Локальный сторадж тут никак не будет работать.
Расскажите как решаете вопросы с иопсами и латентностью для томов под субд и, особенно тонкий вопрос - их журналы?
У нас на железе замена sata ssd на nvme даёт прирост по 90 перцентилю почти на порядок, например. Даёт именно из-за улучшения латенси.
Что предлагаете вы? Или назад в каменный век?)
Как решаете проблему шумных по иопсам соседей?
Калькулятор на сайте добивает. У меня только под мастером только одного приложения 84гб памяти сейчас, не считая пачки апп-серверов. Как это всё вбить в ваш калькулятор?
Что за странные мегагерцы коих можно купить астрономические числа? Как они мапятся на реальную производительность ядер уровня, скажем, e3-1270v6?
Можно в приват.
Для тестов и вычислений hetzner самое оно, как для использования для коммерческих проектов hetzner б не порекомендовал.
Вот я тоже так считаю, НО.
За последние пять лет работы самый стабильный датацентр - это именно FSN Хецнера.
Нужно максимум проца
по нашей практике производительность CPU на РСУБД 20x XEN vCore (Dual E5-2640v4) примерно равны 8x XEN vCore (E3-1270v6): при сравнимом количестве запросов (эквивалентные планы и примерно равный объём данных) е3 дают _лучшее в два раза_ время ответов, Cpu pinning нет, оверселла по ядрам, памяти внутри ноды также нет, средняя нагрузка внутри ноды не более 0.9 по ядрам; диски под данные выделенные и никто их не расходует. Детали могу в привате рассказать.
Так что надо хорошо понимать что у вас за нагрузки и нужную степень параллелизма и немножко о структуре использования данных приложением.
И всякое NUMA ещё, да. CPU Pinning нужен?
вот да, про amd действительно стоило уточнить. Приношу извинения. Как то вылетело из головы что "это" еще существует. А то так можно и до атомов дойти..
Эпики/TR интересны. Там где можно хорошо распараллелиться и основная нагрузка в io - почему нет? С учетом адово медленных ядер в большинстве текущих scalable-то эпики выглядят весьма и весьма конкурентноспособными.
А аналогов e3 пока в массовом сегменте нет.
До атомов можно и нужно доходить, если с умом. Те же современные Avoton C3xxx в синтетике показывают просто удивительные цифры производительности в php на одно ядро, сравнимые с очень частотными e3 последних поколений (можно потестить в новых виртуалках scaleway в амстердаме).
Всё никак не дойдут руки запустить туда живой нагрузки и посмотреть как оно взлетит по 90 процентилю.
Если всё окажется действительно как надо, то эти самые атомы - весьма интересная заявка на определенную нишу, с учетом плотности размещения и энергопотребления.
---------- Добавлено 20.10.2018 в 02:03 ----------
Вот последний тестовый образец за 100 у.е
А если не секрет - где вы (и какие) мамки вы берете под 2011?
Процессоры там прекрасные и под всякие офисные помойки больше и не надо, но вопрос с материнскими платами заставляет грустить.