Вы не поверите, но RAID5/6 — это частный случай erasure coding, для произвольных порогов существуют схемы типа кодов Рида-Соломона-Коши, и сводятся они к составлению и решению системы линейных уравнений в конечных полях, т.е. в сущности то же решение, только чуть по другому сформулированное
Вариантов много, исследования на месте не стоят. Пирамидальное избыточное кодирование для хранения (почти как в ceph) плюс асинхронный BFT протокол заточенный под хранилище (а не SMR) вполне может и взлететь… https://www.csee.umbc.edu/~hbzhang/files/beat.pdf
Т.е. количество OSD тоже совсем небольшое, порядка 10?
В общем-то вопрос был к тому, что видел много FUDа, что ceph rbd не годится для баз данных, и ceph плохо работает на совсем маленьких кластерах, но ваш пример похоже показывает совершенно обратную картину.
О какой равномерной загрузке может идти речь, если большинство задач в спринте занимают полспринта и больше? При таких условиях за два-три дня как раз и будет приходить вал задач. Да, это лучше, чем если бы задачи делались три месяца, а потом у тестировщиков неделя на валидацию, но проблема не решается — вместо огромного аврала раз в несколько месяцев регулярные авралы раз в две недели. В компании где я работаю это как-то обходится тем, что разработчики берут задачи из следующего спринта, в результате в начале каждого спринта длинные задачи уже наполовину выполнены и нагрузку на тестировщиков действительно получается размазать, но даже так случаются факапы. Плюс при этом сами спринты размазываются и становятся сложнее предсказуемыми (а ведь это одна из главных фишек скрама). Поэтому и интересно — может есть решение лучше?
Насчёт второго пункта и рекомендации использовать agile — а чем это собственно поможет? Допустим есть спринт две недели, есть куча задач, которые занимают скажем неделю и больше. Разработчики делают эти задачи, тестировщики в лучшем случае занимаются какими то exploratory задачами, в худшем просто курят бамбук. И за два дня до закрытия спринта и вваливается дохрена задач от разработчиков на валидацию — и привет аврал.
Возможно тупой вопрос, но — не было мысли о том, что спектры перемещений дорожного полотна под воздействием проезжающих машин и теоретическая АЧХ собственных колебаний этого самого полотна так похожи, потому что именно с этими частотами ему проще всего колебаться? Как пример из электроники — если взять фильтр с какой-то АЧХ и подать на вход ему белый шум, то спектр выходного сигнала будет повторять эту самую АЧХ. Ни в коей мере не пытаюсь принизить проделанную работу, правда интересно.
Ну я в курсе про закон Амдала, и на десктопе у меня реальных 20 ядер (спасибо списанным процам и алиэкспрессу), но только это немного мимо, как уже отписали выше. Если при написании программы/сервиса/whatever была заложена масштабируемость, то при росте числа ядер/узлов доля времени "медленного" кода как минимум не будет расти, а как максимум будет падать. При этом время на разработку на плюсах будет в разы больше, чем на том же питоне, а человекочасы масштабировать гораздо сложнее. Более того, даже в чисто плюсовых проектах регулярный паттерн — два уровня кодовой базы, в нижнем все вылизывается под максимальную производительность (и там вдумчивая работа с памятью, минимизация syscalls и т.п.), а в верхнем пишется в стиле лишь бы побыстрее, и чтобы потом в этом легко разобраться было. При этом основное время выполняется как раз низкоуровневый код, а если это становится не так, то находится очердной "горячий" участок и выделяются очередные низкоуровневые примитивы. И вот этот высокоуровневый код на самом деле часто гораздо удобнее и проще было бы писать на чем-то более высокоуровневом, чем C++. Питон я только для примера привел, скорее как крайность.
Если задача — запускать в нужном порядке по определенным условиям число-молотилки или какие-нибудь IO (реализованные опять же на C) — то 2 порядка замедления питона погоды не сделают. Наглядный пример — Keras, который является очень удобной оберткой над в том числе Tensorflow, половина которого опять же на питоне (вторая половина как раз на C/C++), и в питоновском коде программы от силы 10% времени проводят. И тут хоть в 100 раз этот питон ускорить — ощутимого эффекта не будет. Зато продуктивность с этим самым питоном за счет высокоуровневых конструкций и быстрой обратной связи (не надо ждать компиляции, проще организовать автотесты) на порядок выше.
Если же я пишу сложную управляющую логику с очень разнообразными действиями, не сводящимися к «повторить вычисления A, B, C миллион раз», то лучше взять на вооружение всю мощь типизированного C++.
А может быть тогда имеет смысл взять что-то еще более высокоуровневое, чем C++? Что-то не требуещее компиляции по несколько минут (более-менее сложного кода), имеющее кучу удобных библиотек, позволяющее легко писать тесты? Не то, чтобы я был противником C++ — сам пишу на нем уже лет 15, но вот для своих личных экспериментов последние пару лет реально тянет писать например на связке Python + C.
"на сервере с Intel Xeon Gold сборка выполняется за 9 минут 12 секунд"
Вы его в один поток что ли собираете? Просто например даже на стареньком E5-2660v2 сборка в 20 потоков занимает чуть меньше двух минут.
Вы не поверите, но RAID5/6 — это частный случай erasure coding, для произвольных порогов существуют схемы типа кодов Рида-Соломона-Коши, и сводятся они к составлению и решению системы линейных уравнений в конечных полях, т.е. в сущности то же решение, только чуть по другому сформулированное
Вариантов много, исследования на месте не стоят. Пирамидальное избыточное кодирование для хранения (почти как в ceph) плюс асинхронный BFT протокол заточенный под хранилище (а не SMR) вполне может и взлететь… https://www.csee.umbc.edu/~hbzhang/files/beat.pdf
Понял, спасибо
Т.е. количество OSD тоже совсем небольшое, порядка 10?
В общем-то вопрос был к тому, что видел много FUDа, что ceph rbd не годится для баз данных, и ceph плохо работает на совсем маленьких кластерах, но ваш пример похоже показывает совершенно обратную картину.
Т.е. данные постгреса лежали на томе RBD? И если не секрет — какой размер кластера и что за сетка между нодами?
Странно, но мне это как раз знакомо.
О какой равномерной загрузке может идти речь, если большинство задач в спринте занимают полспринта и больше? При таких условиях за два-три дня как раз и будет приходить вал задач. Да, это лучше, чем если бы задачи делались три месяца, а потом у тестировщиков неделя на валидацию, но проблема не решается — вместо огромного аврала раз в несколько месяцев регулярные авралы раз в две недели. В компании где я работаю это как-то обходится тем, что разработчики берут задачи из следующего спринта, в результате в начале каждого спринта длинные задачи уже наполовину выполнены и нагрузку на тестировщиков действительно получается размазать, но даже так случаются факапы. Плюс при этом сами спринты размазываются и становятся сложнее предсказуемыми (а ведь это одна из главных фишек скрама). Поэтому и интересно — может есть решение лучше?
Насчёт второго пункта и рекомендации использовать agile — а чем это собственно поможет? Допустим есть спринт две недели, есть куча задач, которые занимают скажем неделю и больше. Разработчики делают эти задачи, тестировщики в лучшем случае занимаются какими то exploratory задачами, в худшем просто курят бамбук. И за два дня до закрытия спринта и вваливается дохрена задач от разработчиков на валидацию — и привет аврал.
Вам повезло. Я вот был в проекте, где написание модульных тестов было запрещено. Прямым указом. Место работы я в итоге сменил...
Ну кстати шанс как раз есть — юнит тесты мало того что писать надо, но ещё и код делать тестируемым, а с анализатором нужно просто запустить его.
Только мне показалось, что цены у них немного охреневшие? 15 баксов за инстанс, который в том же digital ocean или linode стоит 5.
И, что интересно, в boost intrusive такая уже есть
Например тут можно посмотреть: https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization
Или Numba, если нужны суровые числодробилки и не пугает необходимость ставить LLVM не ниже четвертой версии
Ну я в курсе про закон Амдала, и на десктопе у меня реальных 20 ядер (спасибо списанным процам и алиэкспрессу), но только это немного мимо, как уже отписали выше. Если при написании программы/сервиса/whatever была заложена масштабируемость, то при росте числа ядер/узлов доля времени "медленного" кода как минимум не будет расти, а как максимум будет падать. При этом время на разработку на плюсах будет в разы больше, чем на том же питоне, а человекочасы масштабировать гораздо сложнее. Более того, даже в чисто плюсовых проектах регулярный паттерн — два уровня кодовой базы, в нижнем все вылизывается под максимальную производительность (и там вдумчивая работа с памятью, минимизация syscalls и т.п.), а в верхнем пишется в стиле лишь бы побыстрее, и чтобы потом в этом легко разобраться было. При этом основное время выполняется как раз низкоуровневый код, а если это становится не так, то находится очердной "горячий" участок и выделяются очередные низкоуровневые примитивы. И вот этот высокоуровневый код на самом деле часто гораздо удобнее и проще было бы писать на чем-то более высокоуровневом, чем C++. Питон я только для примера привел, скорее как крайность.
Если задача — запускать в нужном порядке по определенным условиям число-молотилки или какие-нибудь IO (реализованные опять же на C) — то 2 порядка замедления питона погоды не сделают. Наглядный пример — Keras, который является очень удобной оберткой над в том числе Tensorflow, половина которого опять же на питоне (вторая половина как раз на C/C++), и в питоновском коде программы от силы 10% времени проводят. И тут хоть в 100 раз этот питон ускорить — ощутимого эффекта не будет. Зато продуктивность с этим самым питоном за счет высокоуровневых конструкций и быстрой обратной связи (не надо ждать компиляции, проще организовать автотесты) на порядок выше.
А может быть тогда имеет смысл взять что-то еще более высокоуровневое, чем C++? Что-то не требуещее компиляции по несколько минут (более-менее сложного кода), имеющее кучу удобных библиотек, позволяющее легко писать тесты? Не то, чтобы я был противником C++ — сам пишу на нем уже лет 15, но вот для своих личных экспериментов последние пару лет реально тянет писать например на связке Python + C.
"на сервере с Intel Xeon Gold сборка выполняется за 9 минут 12 секунд"
Вы его в один поток что ли собираете? Просто например даже на стареньком E5-2660v2 сборка в 20 потоков занимает чуть меньше двух минут.
Да, следующая часть и правда интересна