https://opennet.ru/openforum/vsluhforumID3/101142.html Представлен (http://fedoramagazine.org/fedora-21-for-aarch64/) релиз дистрибутива Fedora 21 (http://www.opennet.ru/opennews/art.shtml?num=41221) для серверных систем с 64-разрядной архитектурой ARMv8/AArch64 (https://ru.wikipedia.org/wiki/ARM_%28%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0%29#ARMv8_.D0.B8_.D0.BD.D0.B0.D0.B1.D0.BE.D1.80_.D0.BA.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4_ARM_64_.D0.B1.D0.B8.D1.82). Сборки для Aarch64 содержат все возможности, доступные в базовом наборе пакетов Fedora 21 Base и в варианте дистрибутив для серверных систем Fedora 21 Server. Из репозиториев для Aarch64 доступно более 15 тысяч пакетов. Среди поддерживаемых платформ отмечены (https://fedoraproject.org/wiki/Architectures/AArch64/F21/Installation) платы Applied Micro X-Gene (Mustang)<br>и Advanced Micro Devices Opteron A1100 (Seattle), а также эмулятор (https://fedoraproject.org/wiki/Architectures/AArch64/Install_with_QEMU) на основе QEMU.<br><br>URL: http://fedoramagazine.org/fedora-21-for-aarch64/<br>Новость: http://www https://opennet.ru/openforum/vsluhforumID3/101142.html#48 Tue, 13 Jan 2015 18:06:11 GMT смотря что вы вкладываете в базовую платформу? CPU? <br> https://opennet.ru/openforum/vsluhforumID3/101142.html#47 Tue, 13 Jan 2015 15:44:29 GMT &gt; Когда такое же запихали в Xeon - после тестов оказалось что мертвому припарка. Тот же аппаратный CRC32 проигрывает по скорости вычислению через таблицу. Так и с остальными.<br><br>Ну у Xeon свои особенности, там общая ПСП о-го-го и кэша до фига. Тут, думаю, есть смысл, иначе бы не стали делать.<br><br>&gt; Понятно. lzo не всегда хорошо сжимает. <br><br>На практике вместо поблочного сжатия в HBase иногда лучше сжимать/разжимать некоторые данные при обработке, если критично именно сжатие и куски достаточно большие (тогда хоть lzma используй). Иногда получается даже эффективнее, т.к. при встроенном сжатии в кэше данные хранятся несжатыми. Но для всех остальных случаев lzo - самое то.<br><br>&gt; насколько я помню архитектуру этого безобразия - там нода обработки и нода хранения в общем случае разные ноды. после чего нужно как-то передавать данные для обработки. Из-за чего даже делали хак в виде hardlinks что бы эмулировать копирование по сети.<br><br>В общем случае - да, но это неправильное использование и не должно происходить. Данные из https://opennet.ru/openforum/vsluhforumID3/101142.html#46 Tue, 13 Jan 2015 15:38:28 GMT &gt;&gt; О том, что Cray возвращается от кластеров на преимущественно COTS hardware<br>&gt; Для вас новость - что для сети крей и не переставал использовать свое железо ?<br><br>Возможно, написал недостаточно кристально ясно -- но вроде же очевидно, что не про интерконнект, а про базовую платформу. По крайней мере Вам. :)<br> https://opennet.ru/openforum/vsluhforumID3/101142.html#45 Tue, 13 Jan 2015 15:15:04 GMT &gt;&gt;&gt;&gt; Странный у вас кластер.<br>&gt;&gt;&gt; Hadoop/HBase <br>&gt;&gt; K-Cluster <br>&gt; Коллеги, но это изрядно разные типы кластеров, несмотря на очевидное "сползание" HPC-технологий <br>&gt; в ДЦ.<br><br>отнють.<br>http://www.opensfs.org/wp-content/uploads/2013/04/LUG2013_Hadoop-Lustre_OmkarKulkarni.pdf<br>http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/intel-hpc-distribution-for-apache-hadoop-including-lustre.pdf<br><br>и тп.<br><br>Люстрой можно оптимизировать Hadoop а вот сделать из Hadoop posix fs - весьма сложно. Хотя реально.<br> https://opennet.ru/openforum/vsluhforumID3/101142.html#44 Tue, 13 Jan 2015 15:13:06 GMT &gt;&gt; Криптоакселератор - он в целом как мертвому припарка - хорошо что есть, но нужен весьма и весьма специфических нагрузках.<br>&gt; Он там довольно универсальный, с акселерацией SHA и zlib например, это много <br>&gt; где в обычных задачах может всплыть. Понятное дело, это далеко не <br>&gt; то же самое, что плата акселератора для спец. задач - просто <br>&gt; специальные инструкции процессора позволяют ускорять определенный код. Не все ж specint <br>&gt; считать, нужно и реальный код запускать.<br><br>Когда такое же запихали в Xeon - после тестов оказалось что мертвому припарка. Тот же аппаратный CRC32 проигрывает по скорости вычислению через таблицу. Так и с остальными.<br><br>&gt;&gt; Я думал gzip используют что бы уйти от этих самых узких мест <br>&gt; gzip слишком уж все кладет. lzo дает очень хорошее сжатие и не <br>&gt; грузит проц, а gzip просто забесплатно сожрет +10 ядер на той <br>&gt; же нагрузке. А эффективности сжатия и ввода-вывода почти не добавит. Кроме <br>&gt; того, на практике в HBase можно дизайнить таблицы так, чтобы получать <br>&gt; эффект от fastd https://opennet.ru/openforum/vsluhforumID3/101142.html#43 Tue, 13 Jan 2015 15:03:27 GMT &gt;&gt; Да ну? а мои логи говорят об обратном...<br>&gt; О том, что Cray возвращается от кластеров на преимущественно COTS hardware к <br>&gt; своим уникальным железкам? Вот это новость, рассказывайте!<br><br>Для вас новость - что для сети крей и не переставал использовать свое железо ? сначала SeaStar а потом Aries? Power7 и все дела. Сейчас еще добавился Nvidia Tesla в каком-то custom виде, и тп. Даже материнки у Крея всегда были странные и не стандартные - требующие "специальной" сборки ядра.<br> https://opennet.ru/openforum/vsluhforumID3/101142.html#42 Tue, 13 Jan 2015 14:05:44 GMT &gt;&gt;&gt; Странный у вас кластер.<br>&gt;&gt; Hadoop/HBase<br>&gt; K-Cluster<br><br>Коллеги, но это изрядно разные типы кластеров, несмотря на очевидное "сползание" HPC-технологий в ДЦ.<br> https://opennet.ru/openforum/vsluhforumID3/101142.html#41 Tue, 13 Jan 2015 14:04:10 GMT &gt; Криптоакселератор - он в целом как мертвому припарка - хорошо что есть, но нужен весьма и весьма специфических нагрузках.<br><br>Он там довольно универсальный, с акселерацией SHA и zlib например, это много где в обычных задачах может всплыть. Понятное дело, это далеко не то же самое, что плата акселератора для спец. задач - просто специальные инструкции процессора позволяют ускорять определенный код. Не все ж specint считать, нужно и реальный код запускать.<br><br>&gt; Я думал gzip используют что бы уйти от этих самых узких мест<br><br>gzip слишком уж все кладет. lzo дает очень хорошее сжатие и не грузит проц, а gzip просто забесплатно сожрет +10 ядер на той же нагрузке. А эффективности сжатия и ввода-вывода почти не добавит. Кроме того, на практике в HBase можно дизайнить таблицы так, чтобы получать эффект от fastdiff (префиксного сжатия), после него дожать что lzo, что gzip - одна фигня.<br><br>&gt; Hadoop в общем виде не умеет RDMA по сети<br><br>В общем виде ему и не нужно, при правильном проектировании он обеспечивает локальность https://opennet.ru/openforum/vsluhforumID3/101142.html#40 Tue, 13 Jan 2015 14:03:32 GMT &gt; Да ну? а мои логи говорят об обратном...<br><br>О том, что Cray возвращается от кластеров на преимущественно COTS hardware к своим уникальным железкам? Вот это новость, рассказывайте!<br>