Насчет винды не знаю, но софтварный рейд в линуксе (тот же mdadm) работает без проблем и довольно шустро.
Смысла в аппаратном контроллере для nvme немного:
— Немного выиграть в производительности на интенсивном i/o
— Потратить 100к на контроллер
— Через 3-4 года покупать, останавливать сервер и менять батарейку
— Получить нафиг не нужные и даже вредные для enterprise ssd фичи аппаратного raid-контроллера вроде батарейки и write back, read ahead итп.
Реальная причина может быть одна: если не хватает портов/линий pci-e на материнке, но на современных платформах как правило проблем нет.
Вот вы написали праведный коммент, который морально поддерживает большинство, но он далек от истины.
Правила заполнения графы «Причина смерти» строго регламентированы: «Согласно МКБ-10, первоначальная причина смерти – это болезнь (травма), вызвавшая цепь болезненных процессов, непосредственно приведших к смерти. То есть, если в стационар поступает больной с острым инфарктом миокарда при наличии коронавируса с незначительными поражениями в легких, в качестве основной причины смерти будет указан инфаркт миокарда».
И это логично и правильно. Пока не установлена однозначная причинно-следственная связь между патологией и ковидом, последний не может указываться в качестве причины смерти.
Ну и мне все равно не понятно, какой вообще смысл манипулировать этой самой статистикой? Ради экономии откровенных копеек?
Более того, у нас все тела с ковидом обязательно вскрываются для установления точной причины смерти. В западных развитых странах — нет.
У каждого испытуемого есть свой номер, для которого заранее известно, будет ли использовано плацебо или нет. Номера раздаются в начале испытаний случайно. Врачи не знают, что скрывается за номером. Флакончики одинаковые. Те, кто изначально генерировал список, не участвуют непосредственно в проведении испытаний.
Это какой-то дамп потока сознания, а не сравнение. После мега-обобщений в духе «лютая казуальщина» (автор вообще знает определение термина? и почему он считает что это плохо?) и «очень нишевый продукт», у меня сложилось мнение, что автор абсолютно не разбирается в вопросе.
> Ну вот cpuboss пишет про 2660/2699 typical power consumption:
85.31W vs 117.81W
не знаю что они пишут, но я смотрю сенсоры на реальной машине под нагрузкой с LA 60-70 =)
> Частота-то может и не устраивает, но вот ценник в 75 тысяч против 270 заманчив ;)
2699v4 нет смысла брать (у него цена неадекватная), т.к. уже два поколения процессоров вышло и за 160-180 тысяч сейчас можно получить больше потоков (48) с большей базовой частотой (2.4). А за 250 тысяч можно получить базовую частоту 3.2 и 32 потока. Но TDP там 205 ватт =(
> И да, что один сервер будет потреблять полкиловата — да, такое случается, я с этим не спорил.
Я просто ответил на утверждение:
> Сервера 500 давно уже не потребляют. Сотню-две (3 — в упор)
Прошу прощения, не хочу показаться назойливым, но вот вы пишете:
Насколько я знаю, профессиональное серверное железо есть у нас
А что такое «профессиональное железо»? У меня создается ощущение, что вы как-то не очень ловко жонглируете терминами «серверное железо», «профессиональное железо» и «корпоративного класса».
В итоге мне становится не понятно, чем вы хвастаетесь: то ли тем, что не ставите десктопное железо в стойки, то ли тем, что покупаете брендированные платформы (хотя стоимость платформы ~7-10% от всей внутренней требухи)? =)
Ну и на вопрос про диски/процессоры вы все-таки не ответили )) Если это коммерческая тайна, то нет проблем, так и скажите, но по ссылке платформа для процессоров E5-v3/v4, а это на 2-3 поколения отстает от текущего у Интела.
Коллеги, вот вы пишете «выбрали железо понадежнее», «у нас железо корпоративного класса», намекаете, что мало кто вообще ставит серверное железо, кроме вас (хотя это далеко не так).
А расскажите подробнее о том, какое это такое железо вы ставите? Хотя бы текущие конфиги: процессор, диски, память. Даже железо «корпоративного класса» бывает очень разным. Можно ставить и морально устаревшее, оно тоже 5 лет еще пробегает. У нас есть горстки и интелов и самсунгов dc-серий… которые отлично подходят для подпирания столов, стеллажей и другой мебели. Бывают и у них неудачные партии.
дружно идут мучаться в общем apache со старой версией php и общей mysql базе на не самом мощном железе.
Скорее всего потому что это во-первых, не правда: у многих хостеров доступны последние версии php и железо будет лучше, чем на подавляющем большинстве платформ для размещения vds. А во-вторых это может быть проще и дешевле.
Swoole позволяет использовать микросервисную архитектуру в php проектах
Следует ли из этого, что по мнению автора, без Swoole нельзя создать микросервис на php? Небольшой сервис, использующий php-fpm не будет считаться «микросервисом»?
Микросервисы позволяют: ускорить запросы, инкапсулировать логику, упростить код и избавится от дублирования зависимостей.
Это вообще невероятно спорное утверждение, ничем не подкрепленное. На мой взгляд оно развнозначно словам «Замороженные пельмени позволяют: ускорить запросы, инкапсулировать логику [...]»
В итоге по-факту вы просто описываете кейс с применением swoole для создания долгоживущего приложения на php. При этом практически не затронута сама тема микросервисов и построения соотв. архитектуры.
При чем здесь вы и ваша библиотека. Речь идет о предлагаемых для 8 версии изменениях, в которых прямо указано:
> This change to the semantics of non-strict comparisons is backwards incompatible. Worse, it constitutes a silent change in core language semantics. Code that worked one way in PHP 7.4 will work differently in PHP 8.0
Проблемы вас ждут из-за того, что в любом более-менее живом проекте ваш код — не единственный. Даже если допустить, что вы везде используете strict_types=1 и пишете исключительно корректный с точки зрения типов код, то ручаться за авторов всех библиотек, которые вы испольузете — невозможно.
Поскольку проблема будет возникать в рантайме и статически отследить такие регрессии будет практически невозможно, то велик шанс столкнуться с огромным количеством багов и неявного поведения ПО. Да, все можно исправить со-временем, но вопрос в том, кто за это время будет платить.
Возможно ли уточнить, каких именно показателей не позволяет достичь ceph (желательно в цифрах)? В чем заключается киллер-фича вашего решения кроме того, что оно позволяет обеспечить однородность?
Возможно в докладе есть ответ на мой вопрос, но все же: насколько понимаю, вы написали свое решение для распределенного хранения данных. А почему вы не использовали, например, ceph?
Смысла в аппаратном контроллере для nvme немного:
— Немного выиграть в производительности на интенсивном i/o
— Потратить 100к на контроллер
— Через 3-4 года покупать, останавливать сервер и менять батарейку
— Получить нафиг не нужные и даже вредные для enterprise ssd фичи аппаратного raid-контроллера вроде батарейки и write back, read ahead итп.
Реальная причина может быть одна: если не хватает портов/линий pci-e на материнке, но на современных платформах как правило проблем нет.
Правила заполнения графы «Причина смерти» строго регламентированы: «Согласно МКБ-10, первоначальная причина смерти – это болезнь (травма), вызвавшая цепь болезненных процессов, непосредственно приведших к смерти. То есть, если в стационар поступает больной с острым инфарктом миокарда при наличии коронавируса с незначительными поражениями в легких, в качестве основной причины смерти будет указан инфаркт миокарда».
И это логично и правильно. Пока не установлена однозначная причинно-следственная связь между патологией и ковидом, последний не может указываться в качестве причины смерти.
Ну и мне все равно не понятно, какой вообще смысл манипулировать этой самой статистикой? Ради экономии откровенных копеек?
Более того, у нас все тела с ковидом обязательно вскрываются для установления точной причины смерти. В западных развитых странах — нет.
Исследования были осенью, когда набирали добровольцев и вкалывали им частично плацебо. Там для каждого своя доза была готова персональная.
Сейчас идет уже просто вакцинация без номеров и плацебо. Новых добровольцев для испытаний не набирают. Они все свои уколы еще в прошлом году получили.
85.31W vs 117.81W
не знаю что они пишут, но я смотрю сенсоры на реальной машине под нагрузкой с LA 60-70 =)
> Частота-то может и не устраивает, но вот ценник в 75 тысяч против 270 заманчив ;)
2699v4 нет смысла брать (у него цена неадекватная), т.к. уже два поколения процессоров вышло и за 160-180 тысяч сейчас можно получить больше потоков (48) с большей базовой частотой (2.4). А за 250 тысяч можно получить базовую частоту 3.2 и 32 потока. Но TDP там 205 ватт =(
> И да, что один сервер будет потреблять полкиловата — да, такое случается, я с этим не спорил.
Я просто ответил на утверждение:
> Сервера 500 давно уже не потребляют. Сотню-две (3 — в упор)
Серверы разные нужны, серверы разные важны =)
Если базовая частота 2ггц устраивает =)
Сейчас проверил 2699v4 на турбобусте — 195 ватт при TDP 145W
Посмотрите TDP для современных процессоров Intel. Он там указан без турбобуста ark.intel.com/content/www/us/en/ark/products/series/192283/2nd-generation-intel-xeon-scalable-processors.html
Прошу прощения, не хочу показаться назойливым, но вот вы пишете:
А что такое «профессиональное железо»? У меня создается ощущение, что вы как-то не очень ловко жонглируете терминами «серверное железо», «профессиональное железо» и «корпоративного класса».
В итоге мне становится не понятно, чем вы хвастаетесь: то ли тем, что не ставите десктопное железо в стойки, то ли тем, что покупаете брендированные платформы (хотя стоимость платформы ~7-10% от всей внутренней требухи)? =)
Ну и на вопрос про диски/процессоры вы все-таки не ответили )) Если это коммерческая тайна, то нет проблем, так и скажите, но по ссылке платформа для процессоров E5-v3/v4, а это на 2-3 поколения отстает от текущего у Интела.
А расскажите подробнее о том, какое это такое железо вы ставите? Хотя бы текущие конфиги: процессор, диски, память. Даже железо «корпоративного класса» бывает очень разным. Можно ставить и морально устаревшее, оно тоже 5 лет еще пробегает. У нас есть горстки и интелов и самсунгов dc-серий… которые отлично подходят для подпирания столов, стеллажей и другой мебели. Бывают и у них неудачные партии.
Скорее всего потому что это во-первых, не правда: у многих хостеров доступны последние версии php и железо будет лучше, чем на подавляющем большинстве платформ для размещения vds. А во-вторых это может быть проще и дешевле.
Следует ли из этого, что по мнению автора, без Swoole нельзя создать микросервис на php? Небольшой сервис, использующий php-fpm не будет считаться «микросервисом»?
Это вообще невероятно спорное утверждение, ничем не подкрепленное. На мой взгляд оно развнозначно словам «Замороженные пельмени позволяют: ускорить запросы, инкапсулировать логику [...]»
В итоге по-факту вы просто описываете кейс с применением swoole для создания долгоживущего приложения на php. При этом практически не затронута сама тема микросервисов и построения соотв. архитектуры.
> This change to the semantics of non-strict comparisons is backwards incompatible. Worse, it constitutes a silent change in core language semantics. Code that worked one way in PHP 7.4 will work differently in PHP 8.0
Поскольку проблема будет возникать в рантайме и статически отследить такие регрессии будет практически невозможно, то велик шанс столкнуться с огромным количеством багов и неявного поведения ПО. Да, все можно исправить со-временем, но вопрос в том, кто за это время будет платить.
Возможно ли уточнить, каких именно показателей не позволяет достичь ceph (желательно в цифрах)? В чем заключается киллер-фича вашего решения кроме того, что оно позволяет обеспечить однородность?