Кстати, из интересного, тепло от 4*1080ti + 2*10 core Xeon в 1 юнитном корпусе Gigabyte отводится успешно. Своими глазами видел и поразился сему чуду инженерной мысли. Правда, корпус столь глубок, что из некоторых стоек морда на 5 см торчит)
Думал об этом. Но, не похоже на такой кейс, ибо, в таком случае во главе угла стояло бы количество карт на один хост, а автор к этому относился довольно свободно. Ибо, межхостовое соединение сопоставимых скоростей с даже PCIE x4 стоит очень дорого и тоже отнимает PCI лейны.
Мысль очень простая, — вы утверждаете, что хотите иметь 16 PCI лейнов на карту (вашими словами, 16 полосную автостраду по процессора для каждой карты). Это даёт пропускную способность в около 16 гигабайт в секунду на одну карту. Раз вам это надо, значит есть, где такой поток данных вне карты получить. Диск вам выдаст 1/32 этого потока. Значит, не диск. Ещё есть вариант 100G ethernet, но он тоже не упоминается.
Значит, данные будет генерировать процессор по некоторым алгоритмам. Если вы берете 4 карты, то на каждую идёт аж 3 ядра. Вопрос, как Вы собираетесь с 3х ядер генерировать такой поток?
Ясно, спасибо
И в итоге и джойн есть, и кликхаус тормозит (на джойне). Хотя, та же вертика, с которой, по сути, КХ скопирован по идеям, и которую по бенчмаркам (не использующим джойн) уделывает в разы, с джойном справляется неплохо, и даже имеет высокоэффективный merge join, который обгоняет hash.
Спасибо, интересно, но, как человек, как имевший опыт в написании кода под CUDA для монте-карло симуляции, так и участвовавший в создании сервера для работы этого кода в проде, так и не понял, откуда столь догматичная уверенность в том, что
1) слабый процессор вполне ок (а 12 ядер, это, увы, слабый процессор)
2) нехватка лейнов это вообще не ок
3) слабый SSD (даже не NVMe) это ок
Очевидно, что лейны нужны для передачи данных между камнем и картой. Очевидно и то, почему майнерам хватает одного лейна (у них камень лишь раздает задания и получает результаты), а геймерам надо все и сразу (текстуры протолкнуть в карту).
А вот в Вашем случае, не зная архитертуры, я вижу несколько вариантов, но все они противорячат Вашим требованиям
1) Ваш софт поднимает огромный объем данных с диска (или записывает после обработки), после чего гонет его в карту без преобразования на CPU, после чего карта делает быструю операцию, сопоставимую по скорости с подъемом данных -> лейны нужны ок, проц слабый ок, ваш SSD не ок. Нужен NVMe, а лучше много NVMe. Скорость SATA SSD на порядки ниже скорости пропихивания данных через лейны в карту. Ваша шина будет простаивать. Чтобы напихать четыре карты хотябы в половину пропускной способности, Вам надо около 30GB/s поток данных с диска или сети. Просто представьте на минутку себе такой поток. Я видел почти, но все же меньший поток на 4х процессорном сервере с батареей из датацентровых NVMe. Он обслуживал аналитическую СУБД, и обошелся владельцу в $70K. Да и то, подобный поток там возникал предельно редко, и, ограничь пиковый поток раза в 4, обшая производительность системы упала бы не более, чем на 5%.
2) Ваш софт делает тяжелое задание, по времени сильно большее, чем пропихивание данных в карту, и/или сохранение на диск после работы -> вам лейны не нужны. Берете майнерский риг с 1 PCI lane per GPU и вперед. Как никак, не надо думать, что такой конфиг это совсем убого. Это около 1GB/s на карту, то есть, перфоманс двух ваших дисков. Получаете предельно эффективное соотношение cost for GPUs/total cost.
3) Ваш софт делает небольшое поднятие данных с диска, значительное раздувание объема поднятых данных на CPU и быструю операцию на GPU. Тогда диск ок, лейны нужны, CPU не ок. Вы, скорее всего, не сможете 12-ядерным камнем накормить все карты и станут в очередь за заданием.
Вообщем, я отлично понимаю Вас, как человек, любящий железо и возню с ним, и не приемлющий конфигураций, которые рубят теоретический перфоманс на корню. Но, считаю, раз речь идет о бизнесе, при чем не об абстрактном создании «суперкомпьютера под столом» для абстрактного заказчика, то, как минимум, надо рассуждать не категориями
тогда как показывает практика, например, для игр, при использовании восьми линий, она теряет 5% производительности, а при использовании четырех — уже около 20-30% или больше.
а провести тесты, взять Excel и попробовать накидать калькулятор производительности вашего софта, учесть реальные потребности в потоках данных диск->проц, проц->карта, карта->проц, проц->диск.
Похоже, просто тормозящий прогресс, и тянущий за собой чемоданы говна, x86 наконец-то должен умереть и дать жить и развиваться другим, возможно, похоронив при этом интел (туда им и дорога). Лично мне это стало понятно ещё несколько лет назад, увидев скорость, с которой js бенчмарки проходит iPhone Х, в котором проц был уже несколько летней давности к моменту выхода.
А сейчас дело доводят до конца Apple с М1 и AWS со своими гравитонами.
А так то с процессорами общего назначения все хорошо. Linux скоро будет работать в каждой стиральной машине, ибо тупо проще взять low-end arm, чем что-то выдумывать. Подозреваю, что и в той же тесле их тоже достаточно. Врядли управляющий софт работает на чем-то экзотическом.
А есть принципиальная причина? Более, чем уверен, что если бы не было мощного глубоко запрятанного блокера, давно уже или в Яндексе реализовали б, или кто-то бы Альтинити задонатил за это.
Вот, все же, до сих пор не понимаю, почему раз в КХ все работает столь быстро, в нем столь убоги джойны. Broadcast join вообще отсутствует как таковой.
Почему все проприетарные конкуренты (BigQuery, Redshift, Vertica) с похожими принципами и подходами вопрос решили, а Clickhouse way — городить велосипеды из костылей с применением внешних in-memory кешей и смотрящего на них словаря просто, чтобы, например, посчитать
group by account_id, когда факты льются с кукой, а связка кука-> account может прийти после записи факта.
Вместо того, чтобы перещупывать бд картинок на песочнице Asirra, человек просто сохранил себе локально все картинки с petfinder с меткой кот/собака, спарся этот сайт.
Да, они по размеру не пиксель в пиксель с капчей, но для более сложного хеша это не проблема
Так а можно для тех, кто в танке? Зачем подобным оборудованием пользоваться в принципе, когда показатели целой полки в разы проигрывают одному nvme диску? Чем это лучше софтверного raid10 поверх nvme? Не выйдет, ли, что маржа энтерпрайз вендора НРЕ, делающего энтерпрайз решения для ультрабогатых клиентов перекроет выигрыш на дедупликации, сжатии, и прочих плюшках полки?
При правильном использовании облачных объектов, — нет, не сможет сгореть;)
К примеру, в спецификации S3 сразу написано, что данные хранятся в нескольких датацентрах. Есть ещё ряд продуктов, где такая репликация идёт по умолчанию.
Но, лично меня беспокоит, что там другая есть проблема, — сложность их инфраструктурного софта столь высока, что рано или поздно может софтверный баг привести к чему-то большому и необратимому
Интересно, произойдёт ли когда-то массовый сбой с потерей даже бекапированных данных в AWS, GCP, или Azure?
О локальных проблемах, когда AWS тупо отнял доступ к виртуальным дискам и их бекапам у клиента с премиум поддержкой, мотивировав это порчей данных, тут уже как-то писали (тогда клиент решил, что, видимо, чужие данные попали на его диск, и AWS предпочёл меньший зашквар с потерей данных большему с расглашением).
Сейчас началась антидатацентровая истерия во многих бизнесах после OVH, и публичные облака в очередной раз срубят бабло. Но интересно, к чему приведёт слепая вера людей в их непогрешимость.
Насколько знаю, инициация чарджбека, — это добрая воля банка-эмитента, а у клиента нет возможности инициировать его мимо банка, если банк отказал, что в СНГ делать любят (разве что, если ты какой-то платиновый клиент, то могут поднапрячься).
Так что, на пункте «зайти в банк» акт отмщения может и закончиться
Мысль очень простая, — вы утверждаете, что хотите иметь 16 PCI лейнов на карту (вашими словами, 16 полосную автостраду по процессора для каждой карты). Это даёт пропускную способность в около 16 гигабайт в секунду на одну карту. Раз вам это надо, значит есть, где такой поток данных вне карты получить. Диск вам выдаст 1/32 этого потока. Значит, не диск. Ещё есть вариант 100G ethernet, но он тоже не упоминается.
Значит, данные будет генерировать процессор по некоторым алгоритмам. Если вы берете 4 карты, то на каждую идёт аж 3 ядра. Вопрос, как Вы собираетесь с 3х ядер генерировать такой поток?
Так а вышло в итоге чужие данные дернуть? Или хоть как-то заабузить апи?
Ясно, спасибо
И в итоге и джойн есть, и кликхаус тормозит (на джойне). Хотя, та же вертика, с которой, по сути, КХ скопирован по идеям, и которую по бенчмаркам (не использующим джойн) уделывает в разы, с джойном справляется неплохо, и даже имеет высокоэффективный merge join, который обгоняет hash.
1) слабый процессор вполне ок (а 12 ядер, это, увы, слабый процессор)
2) нехватка лейнов это вообще не ок
3) слабый SSD (даже не NVMe) это ок
Очевидно, что лейны нужны для передачи данных между камнем и картой. Очевидно и то, почему майнерам хватает одного лейна (у них камень лишь раздает задания и получает результаты), а геймерам надо все и сразу (текстуры протолкнуть в карту).
А вот в Вашем случае, не зная архитертуры, я вижу несколько вариантов, но все они противорячат Вашим требованиям
1) Ваш софт поднимает огромный объем данных с диска (или записывает после обработки), после чего гонет его в карту без преобразования на CPU, после чего карта делает быструю операцию, сопоставимую по скорости с подъемом данных -> лейны нужны ок, проц слабый ок, ваш SSD не ок. Нужен NVMe, а лучше много NVMe. Скорость SATA SSD на порядки ниже скорости пропихивания данных через лейны в карту. Ваша шина будет простаивать. Чтобы напихать четыре карты хотябы в половину пропускной способности, Вам надо около 30GB/s поток данных с диска или сети. Просто представьте на минутку себе такой поток. Я видел почти, но все же меньший поток на 4х процессорном сервере с батареей из датацентровых NVMe. Он обслуживал аналитическую СУБД, и обошелся владельцу в $70K. Да и то, подобный поток там возникал предельно редко, и, ограничь пиковый поток раза в 4, обшая производительность системы упала бы не более, чем на 5%.
2) Ваш софт делает тяжелое задание, по времени сильно большее, чем пропихивание данных в карту, и/или сохранение на диск после работы -> вам лейны не нужны. Берете майнерский риг с 1 PCI lane per GPU и вперед. Как никак, не надо думать, что такой конфиг это совсем убого. Это около 1GB/s на карту, то есть, перфоманс двух ваших дисков. Получаете предельно эффективное соотношение cost for GPUs/total cost.
3) Ваш софт делает небольшое поднятие данных с диска, значительное раздувание объема поднятых данных на CPU и быструю операцию на GPU. Тогда диск ок, лейны нужны, CPU не ок. Вы, скорее всего, не сможете 12-ядерным камнем накормить все карты и станут в очередь за заданием.
Вообщем, я отлично понимаю Вас, как человек, любящий железо и возню с ним, и не приемлющий конфигураций, которые рубят теоретический перфоманс на корню. Но, считаю, раз речь идет о бизнесе, при чем не об абстрактном создании «суперкомпьютера под столом» для абстрактного заказчика, то, как минимум, надо рассуждать не категориями
а провести тесты, взять Excel и попробовать накидать калькулятор производительности вашего софта, учесть реальные потребности в потоках данных диск->проц, проц->карта, карта->проц, проц->диск.
Ну а стал бы играть, будучи тяжелобольным, было бы лучше? Выигрышем у человека в таком состоянии Шеффер гордился бы и считал бы честной победой?
Похоже, просто тормозящий прогресс, и тянущий за собой чемоданы говна, x86 наконец-то должен умереть и дать жить и развиваться другим, возможно, похоронив при этом интел (туда им и дорога). Лично мне это стало понятно ещё несколько лет назад, увидев скорость, с которой js бенчмарки проходит iPhone Х, в котором проц был уже несколько летней давности к моменту выхода.
А сейчас дело доводят до конца Apple с М1 и AWS со своими гравитонами.
А так то с процессорами общего назначения все хорошо. Linux скоро будет работать в каждой стиральной машине, ибо тупо проще взять low-end arm, чем что-то выдумывать. Подозреваю, что и в той же тесле их тоже достаточно. Врядли управляющий софт работает на чем-то экзотическом.
Понятно… Для предпродажной подготовки сгодится
Вот, все же, до сих пор не понимаю, почему раз в КХ все работает столь быстро, в нем столь убоги джойны. Broadcast join вообще отсутствует как таковой.
Почему все проприетарные конкуренты (BigQuery, Redshift, Vertica) с похожими принципами и подходами вопрос решили, а Clickhouse way — городить велосипеды из костылей с применением внешних in-memory кешей и смотрящего на них словаря просто, чтобы, например, посчитать
group by account_id, когда факты льются с кукой, а связка кука-> account может прийти после записи факта.
Интересно, почему MS, рубя бабло и обладая компетенцией в корп секторе, пытается скупать модно-молодежные темы? Диверсификация?
Вместо того, чтобы перещупывать бд картинок на песочнице Asirra, человек просто сохранил себе локально все картинки с petfinder с меткой кот/собака, спарся этот сайт.
Да, они по размеру не пиксель в пиксель с капчей, но для более сложного хеша это не проблема
Кажется, я читал уже когда-то о взломе капчи с котами и собаками. И там человек поступил проще — спарсил сайт-первоисточник
Так а можно для тех, кто в танке? Зачем подобным оборудованием пользоваться в принципе, когда показатели целой полки в разы проигрывают одному nvme диску? Чем это лучше софтверного raid10 поверх nvme? Не выйдет, ли, что маржа энтерпрайз вендора НРЕ, делающего энтерпрайз решения для ультрабогатых клиентов перекроет выигрыш на дедупликации, сжатии, и прочих плюшках полки?
При правильном использовании облачных объектов, — нет, не сможет сгореть;)
К примеру, в спецификации S3 сразу написано, что данные хранятся в нескольких датацентрах. Есть ещё ряд продуктов, где такая репликация идёт по умолчанию.
Но, лично меня беспокоит, что там другая есть проблема, — сложность их инфраструктурного софта столь высока, что рано или поздно может софтверный баг привести к чему-то большому и необратимому
Интересно, произойдёт ли когда-то массовый сбой с потерей даже бекапированных данных в AWS, GCP, или Azure?
О локальных проблемах, когда AWS тупо отнял доступ к виртуальным дискам и их бекапам у клиента с премиум поддержкой, мотивировав это порчей данных, тут уже как-то писали (тогда клиент решил, что, видимо, чужие данные попали на его диск, и AWS предпочёл меньший зашквар с потерей данных большему с расглашением).
Сейчас началась антидатацентровая истерия во многих бизнесах после OVH, и публичные облака в очередной раз срубят бабло. Но интересно, к чему приведёт слепая вера людей в их непогрешимость.
Типа под фишинг?
И как на тендере покупали, например, тот же таск-трекер или среду разработки?
Так что, на пункте «зайти в банк» акт отмщения может и закончиться