Изначально сам Huawei предложил попробовать сервера в инфраструктуре нашего предприятия. Мы использовали на тот момент другие их решения. В это же время искали сервера под Кассандру. Звезды сошлись. На энергопотребление не смотрели. А на цену, очень даже.
Когда я был молодым разрабом, навалили мне 5 менеджеров супер важных задач. И каждый требовал, чтоб я решил его задачу через 2 недели. Когда я сказал, что это просто физически не возможно и что они не правильно оценивают объем каждой задачи, мне было сказано, что я просто не знаком с Тайм Менеджментом и они меня научат. Мне было поручено расписать этапы разработки по каждой из этих 5-ти задач. На это было потрачено пару дней. Получилось, что мне потребуется на их решение 6 месяцев. Что сделали менеджеры? Они стерли сроки из моего списка и отдали на оценку другим разрабам (я об этом не знал). Что они получили? Вдвое большие оценки! Сейчас, как мне кажется, единственный правильный вариант, после всех оценок, это выставление приоритетов каждой задаче. Причем, выставлять их должны не разрабы, а бизнес-заказчики. Пусть бизнес решает, что нужно в первую очередь. По опыту, скажу, что до решения низкоприоритетных задач, часто даже дело не доходит. Оно становится не нужным, ошибочным, не актуальным.
Уже несколько лет используем Huawei TaiShan 256GB RAM, 128 ARM ядер и несколько быстрых SSD. В кластере из 3-х серверов отлично живет Apache Cassandra, выполняя миллионы запросов в минуту к некоторым кейспейсам. Сервера при этом особо не напрягаются и до предела их производительности еще очень далеко. По моему мнению, такие многопоточные штуки, как в данном случае, Cassndra, очень хорошо живут на куче дешевых ядер. Пробовал и Java микросервисы на таком железе запускать. Тоже очень хорошо работают, при таком количестве ядер, за них очень невысокая конкуренция.
Но сейчас с Huawei общеизвестная проблема, не хотят они с нами работать.
Думаю, проще его представить как событие, которое длится от и до. Это как полоска в диаграмме Ганта. У каждой такой полоски, есть контекст, в котором хранится, например, название сервиса, тип http-запроса, код http-ответа, была ли ошибка при обработке Можно и свои тэги добавлять, например, идентификатор пользователя, а потом, в WEB-интерфейса Jaeger указать фильтр по этому тэгу и посмотреть, что тормознуло у этого клиента.
Ну а в коде, да, это структура данных. Прицепленная некоторым образом к текущему потоку обработки запроса.
OpenTracing и в частности Jaeger, так и работает. Можно дописать свои инъекторы, которые пропихивают заголовки и в нестандартные протоколы. Причем, поверх штатных библиотек Jaeger есть и более вкусные. Так, для Java + Spring Boot есть стартер opentracing-spring-jaeger-cloud-starter, который умеет эти заголовки прокидывать не только в HTTP но и в очереди, например.
Мне статья не понравилась. Вначале, очевидные вещи о CISC и RISC. Для кого они? Менеджеру, это не нужно, а любой ИТ-шник это знает с первого курса ВУЗ-а. Т.е. плохая рекламная статья.
Я не против ARM, и тех, кто продвигает сервера на их основе. Даже наоборот, скоро запущу несколько серверов в бой, будут работать в кластерах параллельно с x86 серверами, очень хочется сравнить по показателям производительности/цены. Хочется посмотреть как будет жить на них Java, на большем количестве ядер. На сколько хорош RHEL, bare metal и kvm. Да, забудем про ESX, нет его пока.
Cassandra имеет схему данных, значительно легче масштабируется, в отличии от классических реляционных СУБД, вроде Oracle DB, MySql, Postgre. Имеет язык запросов CQL, похожий на SQL. И обладает, я бы сказал, управляемым ACID и CAP, Вы сами можете выдирать, что для Вас важно, конфигурируя кластер, указывая Replication Factor и Consistency level. И по моему мнению, мало задач, с которыми она бы не справилась, Вы просто не умеете ее готовить:)
Да, есть задачи, для которых классические реляционные БД подходят лучше, но так ведь никто и не заставляет нас в современном мире ограничиваться чем-то одним, почему нельзя использовать и то и то сразу?
Сервера мониторили? Во что упираются сервера кассандры, память, диск, паузы GC? Если не во что не упираются, значит вы ее просто не догрузили. Пишите в Кассандру не в 5 а в 50 потоков через 1 коннект.
Сравнение не честное, т.к. про HBase Вы все знаете, а Кассандра, для Вас, черный ящик.
key_cache_size_in_mb — задайте несколько гигов. Он куда более важен для производительности на чтение, чем row_cache, строки и так будут в кеше операционки. И 8 дисков, для данного теста, Кассандре не нужны, она свалит все на один. Много дисков понадобится для множества кейспейсов и таблиц. Писать с CL=ALL, это еще можно понять, но читать смысла нет, достаточно LOCAL_QUORUM.
Сейчас GTK имеет более свежую версию, чем поддерживается gotk3 (3.6-3.16), например у меня — 3.18 и так просто, как в статье скомпилировать сам gotk3 и приложение не получится, используем:
для установки:
go install -tags gtk_3_18 github.com/gotk3/gotk3/gtk
для сборки приложения:
go build -v -tags gtk_3_18 -gcflags "-N -l"
Можно попробовать развернуть кубернетес через Rancher, мне показалось это проще, сразу получите все что нужно, и легкое добавление хостов через web-интерфейс и настроенный из коробки и fluentd и grafana и web-дашборд.
Но если хотите в деталях понять как это все работает, лучше, хоть раз, поставить руками мастера, ноды, попробовать их по обновлять, по выгонять, по добавлять в кластер, перед тем как внедрить это все на бой.
Да, понимаю. Я о том, что новые возможности, это конечно хорошо! Но что делать со старыми ограничениями? Понятно, что ключи, на то они и ключи, чтоб быть уникальными (в пределах хоста), но хотелось бы иметь возможность добавлять им уникальности не только добавлением пробелов (например, jmx-endpoint использовать как параметр ключа). Это ограничение приводит к тому, что, использовать JMX, для мониторинга базовых параметров JVM, например, когда на сервере несколько десятков микросервисов, очень не удобно. Свои MBean-ны внутри микросервисов можно называть уникально и мониторить их свойства без проблем.
Почти все, конечно можно обойти, благо, например, мониторить память и процессор можно и «снаружи» JVM через итемы самого Zabbix-agent-а.
Эх, разрабы заббикса как не предполагали, что на одном сервере могут работать несколько джава-приложений, так и не предполагают. Попробуйте промониторить, скажем память нескольких jvm через jmx. Получите дублирование ключей итемов. Приходится использовать хак с пробелами в названии ключей.
Ну тут все понятно, чтобы метод был законным, нужно, что бы был закон, в котором написано, что так информацию распространять можно. И для того, что бы удостовериться, что граждане не передают законным образом сведения, составляющие гос. тайну, соответствующие органы должны иметь возможность контроля. Никто же не собирается из наших сообщений вырезать слова и мысли, значит и с цензурой все хорошо. Так что, ничего не нарушается.
Согласен. Для проектов на JAX-RS использую maven-javadoc-plugin вместе с swagger-doclet, Он генерирует swagger-документацию по JavaDoc. Помимо обычных аннотаций используются специфические дополнительные аннотации, которые не мешают читать код, но помогают уточнить документацию. Дополнительный бонус — приучает писать полноценные комментарии :)
QT это не обязательно C++, есть разные байндинги, в том числе и для GO.
https://github.com/gotk3/gotk3
https://github.com/therecipe/qt
Изначально сам Huawei предложил попробовать сервера в инфраструктуре нашего предприятия. Мы использовали на тот момент другие их решения. В это же время искали сервера под Кассандру. Звезды сошлись.
На энергопотребление не смотрели. А на цену, очень даже.
Когда я был молодым разрабом, навалили мне 5 менеджеров супер важных задач. И каждый требовал, чтоб я решил его задачу через 2 недели. Когда я сказал, что это просто физически не возможно и что они не правильно оценивают объем каждой задачи, мне было сказано, что я просто не знаком с Тайм Менеджментом и они меня научат. Мне было поручено расписать этапы разработки по каждой из этих 5-ти задач. На это было потрачено пару дней. Получилось, что мне потребуется на их решение 6 месяцев. Что сделали менеджеры? Они стерли сроки из моего списка и отдали на оценку другим разрабам (я об этом не знал). Что они получили? Вдвое большие оценки!
Сейчас, как мне кажется, единственный правильный вариант, после всех оценок, это выставление приоритетов каждой задаче. Причем, выставлять их должны не разрабы, а бизнес-заказчики. Пусть бизнес решает, что нужно в первую очередь. По опыту, скажу, что до решения низкоприоритетных задач, часто даже дело не доходит. Оно становится не нужным, ошибочным, не актуальным.
Уже несколько лет используем Huawei TaiShan 256GB RAM, 128 ARM ядер и несколько быстрых SSD. В кластере из 3-х серверов отлично живет Apache Cassandra, выполняя миллионы запросов в минуту к некоторым кейспейсам. Сервера при этом особо не напрягаются и до предела их производительности еще очень далеко.
По моему мнению, такие многопоточные штуки, как в данном случае, Cassndra, очень хорошо живут на куче дешевых ядер.
Пробовал и Java микросервисы на таком железе запускать. Тоже очень хорошо работают, при таком количестве ядер, за них очень невысокая конкуренция.
Но сейчас с Huawei общеизвестная проблема, не хотят они с нами работать.
За что же Digma DiScooter Urban Sky самоваром-то обозвали? :)
Ну а в коде, да, это структура данных. Прицепленная некоторым образом к текущему потоку обработки запроса.
Мне статья не понравилась. Вначале, очевидные вещи о CISC и RISC. Для кого они? Менеджеру, это не нужно, а любой ИТ-шник это знает с первого курса ВУЗ-а. Т.е. плохая рекламная статья.
Я не против ARM, и тех, кто продвигает сервера на их основе. Даже наоборот, скоро запущу несколько серверов в бой, будут работать в кластерах параллельно с x86 серверами, очень хочется сравнить по показателям производительности/цены. Хочется посмотреть как будет жить на них Java, на большем количестве ядер. На сколько хорош RHEL, bare metal и kvm. Да, забудем про ESX, нет его пока.
Да, есть задачи, для которых классические реляционные БД подходят лучше, но так ведь никто и не заставляет нас в современном мире ограничиваться чем-то одним, почему нельзя использовать и то и то сразу?
Сравнение не честное, т.к. про HBase Вы все знаете, а Кассандра, для Вас, черный ящик.
key_cache_size_in_mb — задайте несколько гигов. Он куда более важен для производительности на чтение, чем row_cache, строки и так будут в кеше операционки. И 8 дисков, для данного теста, Кассандре не нужны, она свалит все на один. Много дисков понадобится для множества кейспейсов и таблиц. Писать с CL=ALL, это еще можно понять, но читать смысла нет, достаточно LOCAL_QUORUM.
Самое серьезное ограничение, на мой взгляд, когда процессов, на которые наложены ограничения cgroups много, проще будет перезагрузить сервер)
для установки:
go install -tags gtk_3_18 github.com/gotk3/gotk3/gtk
для сборки приложения:
go build -v -tags gtk_3_18 -gcflags "-N -l"
Это есть в issue проекта
Но если хотите в деталях понять как это все работает, лучше, хоть раз, поставить руками мастера, ноды, попробовать их по обновлять, по выгонять, по добавлять в кластер, перед тем как внедрить это все на бой.
Почти все, конечно можно обойти, благо, например, мониторить память и процессор можно и «снаружи» JVM через итемы самого Zabbix-agent-а.
Эх, разрабы заббикса как не предполагали, что на одном сервере могут работать несколько джава-приложений, так и не предполагают. Попробуйте промониторить, скажем память нескольких jvm через jmx. Получите дублирование ключей итемов. Приходится использовать хак с пробелами в названии ключей.