Вышла (https://github.com/leo-yuriev/ReOpenLDAP/releases/tag/v1.1.6) новая версия ReOpenLDAP (https://github.com/leo-yuriev/ReOpenLDAP) — форка проекта OpenLDAP (http://www.openldap.org/), с устранением массы ошибок и ряда доработок для стабильной работы репликации. С выпуском 1.1.6 проект ReOpenLDAP отметил три года с момента своего основания (публичный форк появился чуть позже). Всё это время ReOpenLDAP работает 24x7 в инфраструктуре ПАО МегаФон, обеспечивая высоконагруженную обработку запросов в multi-master кластере с full-mesh репликацией.
Версия 1.1.6 аккумулирует работу 8 месяцев этого года и включает:
более сотни коммитов (https://github.com/leo-yuriev/ReOpenLDAP/compare/v1.1.5...v1... в том числе более 50 исправлений ошибок; поддержку musl-libc (https://www.musl-libc.org), а также ряд доработок для совместимости и упрощения сборки; Continuous Integration на инфраструктуре Travis-CI (https://travis-ci.org/leo-yuriev/ReOpenLDAP) и Circle-CI (https://circleci.com/gh/leo-yuriev/ReOpenLDAP).
С этим релизом ветка 1.1 получает статус архивно-стабильной. В ней будут исправляться ошибки, но какая-либо разработка будет прекращена. В свою очередь, работы в ветке 1.2 начнутся с переработки API в сопутствующих ldap-библиотеках с утратой совместимости с предыдущим версиями. Это позволит, с одной стороны, получить более прозрачное и удобное API, которое будет провоцировать меньше ошибок. С другой стороны, переработка API необходима для устранения неоднозначностей и адекватной работы статических анализаторов кода (Coverity, PVS-Studio и др.).
Вторым изменением в ветке 1.2 будет переход на актуальную версию (https://github.com/leo-yuriev/libmdbx/blob/master/README.md) движка хранения libmdbx. Которая, среди прочего, поддерживает управление геометрией и бесплатную авто-компактификацию с освобождением места на диске. С точки зрения пользователя, это позволит автоматически и безболезненно как увеличивать, так и уменьшать размер БД, в том числе без остановки сервера или деградации услуг.
К сожалению, новые возможности не даются бесплатно. Для возможности их реализации в libmdbx (https://github.com/leo-yuriev/libmdbx) был существенно переработан (и ещё не зафиксирован) внутренний формат БД, с потерей совместимости с предыдущими версиями.Пользуюсь случаем хочется ответить на частый вопрос "Почему нет пакетов?": ReOpenLDAP ориентирован на достаточно специализированные сценарии применения, для которых не представляется возможным создать универсальную конфигурацию и собрать соответствующий пакет. Во всех известных (авторам) случаях используются адаптированны под собственные нужды конфигурации (опции configure, включая подключаемые модули и оверлеи), в частности используются монолитные сборки с LTO (https://en.wikipedia.org/wiki/Interprocedural_optimization).
Планируемые (и большей частью уже реализованные) доработки libmdbx также приведут к утрате совместимости по формату БД. Всё это вместе давало повод не формировать пакеты, так как последующие обновления нарушили бы совместимость и только огорчили пользователей. Авторы не владеют информацией (не имеют полноценного видения) о том, в какой именно конфигурации должен быть собран ReOpenLDAP для пакетирования. Поэтому мы (прежде всего) ждем встречной активности от тех, кто уже использует проект или планирует это сделать (состав компонентов и библиотек принципиально не изменится, поэтому всячески приветствуются pull-request-ы с пакетированием).
URL: https://github.com/leo-yuriev/ReOpenLDAP/releases/tag/v1.1.6
Новость: http://www.opennet.ru/opennews/art.shtml?num=47015
Чем оно отличается от OpenLDAP? С апстримом синхронизируется или нет?
Да, "синхронизируется".
Хотя "апстрим" кошмарен, если разобраться )Рекомендую глянуть wiki, там более-менее всё рассказано = https://github.com/leo-yuriev/ReOpenLDAP/wiki
Более подробный вариант = http://0x1.tv/ReOpenLDAP_%E2%80%94_%D1&#...
Упс, безопасный вариант второй ссылки = http://bit.ly/2fD7sCL
>> OSSDEVCONF-2016
> Упс, безопасный вариант второй ссылки = http://bit.ly/2fD7sCLКстати, приезжайте в этом году :)
И ещё кстати: заметил сборку reopenldap-2.4.44 для эльбруса, не расскажете? (начиная с того, что нынче с версионированием)
>>> OSSDEVCONF-2016
>> Упс, безопасный вариант второй ссылки = http://bit.ly/2fD7sCL
> Кстати, приезжайте в этом году :)Постараюсь :)
Но увы обещать не могу (
Тут вот надо-бы в Брюссель ехать на https://ldapcon.org/2017/reopenldap/, а некогда (> И ещё кстати: заметил сборку reopenldap-2.4.44 для эльбруса, не расскажете? (начиная с
> того, что нынче с версионированием)Если кратко, то это не я, а ребята из РедСофт.
Версионирование было изменено больше года назад, начиная с https://github.com/leo-yuriev/ReOpenLDAP/releases/tag/ReOpen...
А ближайшее к 2.4.44 - это внутренняя версия = https://github.com/leo-yuriev/ReOpenLDAP/releases/tag/PS...
Причем сейчас эту версию точно уже не стоит использовать, тем более чтобы портировать и т.д.
Возможно они взяли именно эту или чуть более позднюю версию как drop-in replacement OpenLDAP, чтобы не заморачиваться с объединением liblber.so+libldap.so=>libreldap.so
> Если кратко, то это не я, а ребята из РедСофт.клевета. мы под Эльбрус ReOpenLdap не собирали.
>> Если кратко, то это не я, а ребята из РедСофт.
> клевета. мы под Эльбрус ReOpenLdap не собирали.Пардон, у меня "под подозрением" были только вы ;)
Точнее я был уверен...Больше идей нет, пакетов не видел, и патчей тоже.
Причем там были мелкие гадости, которые поправил кажется весной.
Чел собирал с libc-muls, кажется для ARM и там что-то повылазило (git log --oneline | grep musl).
Поэтому для Эльбруса оно в лоб не собралось-бы.Но если будут вести - маякните pls.
> Поэтому для Эльбруса оно в лоб не собралось-бы.
> Но если будут вести - маякните pls.Записал в тудушку спросить при встрече.
> В свою очередь, работы в ветке 1.2 начнутся с переработки API в сопутствующих ldap-библиотеках с утратой совместимости с предыдущим версиями.Речь вот об этой наркомании? :
int ldap_search_ext(
LDAP *ld,
char *base,
int scope,
char *filter,
char *attrs[],
int attrsonly,
LDAPControl **serverctrls,
LDAPControl **clientctrls,
struct timeval *timeout,
int sizelimit,
int *msgidp );
>[оверквотинг удален]
> char *base,
> int scope,
> char *filter,
> char *attrs[],
> int attrsonly,
> LDAPControl **serverctrls,
> LDAPControl **clientctrls,
> struct timeval *timeout,
> int sizelimit,
> int *msgidp );Нет.
В этом API просто много параметров и пугающие LDAPControl**, но он логичен и корректен.
Есть другие, где опциональным параметром передается указатель на уже выделенную память, которая будет использована повторно. Если же этот параметр NULL, то память выделяется внутри.
Такая семантика сильно заморачивает Coverity, из-за чего идет лавина false-positives.
Кроме этого, такое API часто провоцирует ошибки приводящие к утечкам памяти, либо к использованию уже освобожденных участков.Есть еще достаточно нелогичностей и костылей.
Вы видели первую версию API ldap_search(), без _ext* ? Вот это называется "логично и корректно", а то что я привел - уже писали долбаные наркоманы, попытавшиеся запихнуть множество из того, что раньше настраивалось через десяток вызовов ldap_set_option() opaque-хэндла в параметры одного вызова поиска.Вся сокетная подсистема на этом стиле живёт, весь ioctl, netlink, и много кто ещё (sqlite, mysql, ...). И только авторы openldap-а Дартаньяны, и знают как надо библиотечное api проектировать для Си.
А то что там в коде можно найти ещё более лютый ппц - я ни минуты не сомневаюсь.
> Вы видели первую версию API ldap_search(), без _ext* ? Вот это называется
> "логично и корректно", а то что я привел - уже писали
> долбаные наркоманы, попытавшиеся запихнуть множество из того, что раньше настраивалось
> через десяток вызовов ldap_set_option() opaque-хэндла в параметры одного вызова поиска.
> Вся сокетная подсистема на этом стиле живёт, весь ioctl, netlink, и много
> кто ещё (sqlite, mysql, ...). И только авторы openldap-а Дартаньяны, и
> знают как надо библиотечное api проектировать для Си.
> А то что там в коде можно найти ещё более лютый ппц
> - я ни минуты не сомневаюсь.ldap_search() просто вызывает ldap_search_ex() подставляя кучу NULL.
Использовать отдельные функции для установки каких-то unusual опций или параметров не всегда удобно.
Точнее говоря, это требует создание, поддержки и удаления некоторого контекста.
Тогда ldap_search() превратиться минимум в три вызова: ldap_search_request_create(), ldap_search_request_execute(), ldap_search_request_destroy(). Плюс еще десяток функций на установку всяческих опций и контроллов.В результате функция с несколькими параметрами превратиться в десяток-два функций и прочих конструкций. Притом что "на самом деле" ldap_search() формирует и выполняет один запрос, и примерно никакие лишние/дополнительные стейты ему не нужны.
Сравнение с API уровня ioctl() и т.д. совершенно не корректно. Во-первых, тут важнее совместимость, т.е. к уже существующему простейшему API добавляют какие-то опции. Во-вторых, в этих API уже есть естественно существующий и необходимый контекст/стейт. В-третьих, тем не менее, такое управление опциями через несколько ioctl() создает огромный оверхед на системных вызовах, с которым как-то пытаются бороться (например в glibc).
С другой стороны, ldap_search_ex() легко оборачивается в кружева на С++. Которые позволяют легко, удобно, безопасно, bla-bla-bla пользоваться API.
Итого, как ни странно, но ldap_search_ex() - один из самых разумных методов обсуждаемого
API.
Если OpenLDAP не подошел может быть было лучше эти посмотреть:
* http://directory.apache.org/
* http://directory.fedoraproject.org/
?
FDS вряд ли им подойдет, т.к. неторопливый на их нагрузках (сказывается использование bdb)
> FDS вряд ли им подойдет, т.к. неторопливый на их нагрузках (сказывается использование
> bdb)Да, примерно так, но хуже.
На пробах нагрузку держал только OpenLDAP, все остальные на один-два порядка меньше.
Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012, и еще каких-то форточек), но результат был стабильно жуткий.
Поставить OpenLDAP+HDB|MDB репликой к 389DS|FDS мульти-мастеру?
1. Управляемость.
2. Нагрузочная способность.
3. Профит.
(4. Нюансы: не поддерживает навороченных хэшей (в 389DS всё на плагинах) и иных плюшек.)
> Поставить OpenLDAP+HDB|MDB репликой к 389DS|FDS мульти-мастеру?Увы, это все нереально.
389DS не справляется с требуемой нагрузкой.
Если было-бы справлялся, то никакой реплики на OpenLDAP не надо.
В этом случае и ReOpenLDAP не случился-бы.
Это первое.Далее, после починки репликации в ReOpenLDAP, у меня есть сомнения что multi-master репликация в 389DS (и где-либо еще) работает на 100%. Там очень-очень не просто, особенно с учетом всех плагинов и схем (к слову, в AD у M$ тоже масса проблем и залежи костылей - думаю, не более 10 человек в MS полностью знают как оно "на самом деле" работает).
Но это еще не все.
https://pro-ldap.ru/tr/rfc/rfc4533.html - очень талантливый документ, можно легко сделать десяток реализаций в полном соответствии с ним, так что ни одна пара не сможет взаимодействовать. Поэтому примерно у всех LDAP-ов репликация/синхронизация работает только с сама-с-собой.
> 389DS не справляется с требуемой нагрузкой.Да, и в моём случае корень проблемы даже не столько в BDB как таковой (на чтении она всё равно в памяти, а массивная запись в LDAP — ???), сколько в механизме репликации (плагины changelog5, retro-changelog). Которые пишут в журнал т.ч. kerberos-аттрибуты типа "время последней авторизации этого аккаунта". В *OpenLDAP такой проблемы нет, по очевидной причине.
> Далее, после починки репликации в ReOpenLDAP, у меня есть сомнения что multi-master
> репликация в 389DS (и где-либо еще) работает на 100%. Там очень-оченьДа. Принимая соглашение multi-master, мы соглашаемся: 1. С (окончательной) потерей атомарности. 2. С возможностью навернуть репликацию, испортив журнал (и ещё 100500 увёрток мелким текстом). Прямо как у юристов. Но (иногда) с ней таки лучше. Если не делать, как M$-коллеги "а можно 50 m-m? можно! (утрирую, но не сильно)".
> Но это еще не все.
> https://pro-ldap.ru/tr/rfc/rfc4533.html - очень талантливый документ, можно легко сделать
> десяток реализаций в полном соответствии с ним, так что ни одна
> пара не сможет взаимодействовать. Поэтому примерно у всех LDAP-ов репликация/синхронизация
> работает только с сама-с-собой.Вот для этого как раз и поставляются 100500 плагинов для 389. Включая (уродский) retro-changelog, на который (я) ругаюсь как раз по причине неадекватной нагрузки на запись. Но: позволяющий создавать/поддерживать всякие интерфейсы к чужим системам. См. реализацию ёж&уж (bind9-ldap).
* В OpenLDAP система плагинов — вообще кошмар полный. Ошибка в (любом) плагине рушит демона. By design. Зато в пустом OpenLDAP никто не путается под ногами, что (в моём окружении) даёт x2…x3 даже на BDB.
> Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012,
> и еще каких-то форточек), но результат был стабильно жуткий.В одном федеральном органе такой AD держался на сильно специальном контракте по поддержке -- интересно, что там сейчас...
>> Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012,
>> и еще каких-то форточек), но результат был стабильно жуткий.
> В одном федеральном органе такой AD держался на сильно специальном контракте по
> поддержке -- интересно, что там сейчас...Не знаю про какой Вы там федеральный орган, но я лично участвовал во внедрении OpenLdap как полноценная замена виндовой AD в крупной компании
Результаты были вполне хорошие но вот с управляемостью все на самописных скриптах кастылях и тому подобном оставляла желать лучшего
Да и специалистов как то особо и не нашлось кто отвечал бы чисто за это направление.
На сколько я знаю сейчас там этот OpenLdap стоит как дополнительный под какие то там задачи
> Не знаю про какой Вы там федеральный орган, но я лично участвовал
> во внедрении OpenLdap как полноценная замена виндовой AD в крупной компанииВообще LDAP -- не замена AD (который надмножество покорёженного LDAP), это самбу смотреть надо; например, http://altlinux.org/SambaDC (кстати, у нас недавно завелось и на эльбрусе).
> Если OpenLDAP не подошел может быть было лучше эти посмотреть:
> * http://directory.apache.org/
> * http://directory.fedoraproject.org/
> ?У OpenDJ или 389DS будет шанс обогнать ReOpenLDAP по скорости только при замене движка хранения на libmdbx.
Но OpenDJ -- это ява и тамошние ценители седеют просто глядя на код LMDB/libmdbx, даже через JNI.
А 389DS очень сильно заражен Berkeley DB. Дрянная днк BDB там прослеживается в половине проекта и для возможности подключения другого backend-а нужно проделать большую работу = вычистить хвосты BDB и сформировать достаточный внутренний API для plugable подсистемы хранения.
т.е. проблема именно в неприятии java?
а значит ApacheDS пролетает из-за этого же?
> т.е. проблема именно в неприятии java?
> а значит ApacheDS пролетает из-за этого же?Что значит "неприятие Java"? Неприятие кем? Пролетает где?
Безотносительно ApacheDS/OpenDJ и ReOpenLDAP, я могу повторить свою позицию = то что можно сделать в Java быстро, то в C/C++ (и даже в Rust) можно сделать еще быстрее (и часто намного быстрее, он и трудозатратнее).
Однако, к выбору OpenLDAP (что было давным-давно) это мое "мнение" никак не относится, вообще совсем. OpenLDAP был выбран примерно по двум причинам:
1) На пробах только OpenLDAP показал приемлемую производительность, все остальные безнадежно отставали.
2) OpenLDAP представлялся заслуживающим доверия (много пользователей, много версий, много установок). Одно интервью Ховарда чего стоит = https://www.opennet.ru/opennews/art.shtml?num=14723
Это не проблема, это реалии жизни. Потому, что большая часть того,
что пишется на java, являет собой кучу гуано.
а на счет этого
http://directory.apache.org/mavibot/
движка что скажете?
С Mavibot в работе я не сталкивался.Судя по описанию его устройство очень близко к libmdbx и LMDB. Очень похоже что это "inspired by LMDB" также как BoltDB и т.д.
Однако, комбинация B-tree, MVCC и COW не обязана дать гарантированный результат (производительность). Там очень много подводных камней и "фишек". Например реклайминг в LIFO-порядке и авто-компактификация.
Поэтому я не удивлюсь если Mavibot показывает на порядок более низкие результаты чем LMDB, не говоря о libmdbx (есть есть LIFO, авто-компактификация и другие фичи).
Банчмарков самого Mavibot я не нашел = https://www.google.ru/search?q=apache+mavibot+benchmark
Свежих бенчмарков Apache Directory Service тоже, по-прежнему есть только https://www.slideshare.net/ldapcon/benchmarks-on-ldap-direct...
Причем в этих текстах OpenLDAP выглядит несколько хуже чем в наших, а на слайдах есть странности:
1) В тесте скорости загрузки OpenLDAP идет аж четвертым, а потом уделывает всех в остальных тестах, включая write (обновления) - такого быть не может, и я не разу не видел.
2) Непонятная разница между 32-битной и 64-битной версиями (подозреваю что собрано с разными опциями, assert-ы, отладочное логирование и т.п).
3) Иногда hdb-бакенд обгоняет mdb - никогда такого не видел.
Последние несколько лет сильно за темой не слежу, так что эта новость первая, которую вижу по данной тематике. Складывается впечатление, что по теме застой. Так что отсутствие свежих бенчмарков показательно.
> Последние несколько лет сильно за темой не слежу, так что эта новость
> первая, которую вижу по данной тематике. Складывается впечатление, что по теме
> застой. Так что отсутствие свежих бенчмарков показательно.Я бы не сказал что застой, точнее он только в OpenLDAP (причины в моем понимании уже озвучивал). Остальные проекты более-менее двигаются.
А вот с бенчмарками история интересная. Пруф-ссылок не накидаю (не копил), но несколько раз повторялась примерно такая история:
- какой-нибудь "условный Sun" делает бенчмарк и публикует результаты "Мы спереди планеты всей..., покупайте у нас...";
- Ховард из Symas повторяет бенч с участием OpenLDAP (иногда что-нибудь подкручивая) и наглядно всех делает;
- на выходе "условный Sun" теряет лицо, а OpenLDAP получает use-case, а иногда и несколько патчей.В ответ на это, часть "условных Sun-ы" постепенно добавило в лицензии добавили пункт запрещающий публиковать результаты тестов, особенно сравнительных. Гениальное решение.
Другая часть "условных Sun-ов" поступила мудрее - они стали просто немного допиливать и ребрендить OpenLDAP, как с помощью Symas, так и без.
>хочется ответить на частый вопрос "Почему нет пакетов?"хорошо, а почему нет ебилдов?
Потому-что нам они не нужны, а вы их не сделали.
Welcome = https://github.com/leo-yuriev/ReOpenLDAP/issues/35 :)
В чем преимущества по сравнению с 389 Directtory Server (RedHat Directory Server)?
> В чем преимущества по сравнению с 389 Directtory Server (RedHat Directory Server)?Повторю еще раз = скорость.
Чтобы у 389DS были шансы сравниться с OpenLDAP или ReOpenLDAP нужно вместо Berkeley DB использовать https://github.com/leo-yuriev/libmdbx или хотя-бы какой-нибудь WiredTiger.
Причем я полностью согласен, что 389DS сейчас имеет гораздо более красивый и надежный код. Но вот backend хранения - из прошлого века.
А вы пробовали с Red Hat на эту тему поговорить (разумеется с бенчмарками и прочими пруфами)?
> А вы пробовали с Red Hat на эту тему поговорить (разумеется с
> бенчмарками и прочими пруфами)?Говорить по-сути не о чем.
Проблема в другом, и уже давно как бревно в глазу.У RedHat в 389DS нет какой-либо инфраструктуры (даже зачатков) для подключения движков/бакендов хранения. Все гвоздями прибито к BDB (Berkeley DB), точнее даже не прибито, а приварено.
Думаю, что они рады-бы поменять устаревшее BDB-гobнo (уже извините) на что угодно, хоть на LevelDB. Одни проблемы с лицензией чего стоят...
Однако, для этого нужно на полгода-год остановить всю разработку и заниматься только этим, т.е. делать инфраструктуру подключения storage backend.
Соответственно, до появления этой инфраструктуры и API нет смыслы обсуждать подключение новых подсистем хранения, тем более замену.
Более того, если был-бы подобный API, то (наверное) я бы не удержался и сделал вариант 389DS на https://github.com/leo-yuriev/libmdbx ;)
Бурханыч еще и в сторону LDAP развивает Интернет?
> Бурханыч еще и в сторону LDAP развивает Интернет?Слоупок я, дошло о чем спрашивали ;)
Может и развивает, но мне об этом ничего не известно.
Если говорить о ReOpenLDAP, то эта работа была сделана исключительно для решения проблем возникших (достаточно неожиданно) при внедрении одного из решений Петер-Сервис внутри МегаФона.
С сентября 2016 проект не аффинирован с какой-либо коммерческой структурой (не считая публичных сервисов: github, travis-ci и т.п.).
может быть, если бы вы в своих репозиториях в гитхабе использовали другой язык, удалось привлечь внимание большего количества разарботчиков?
Да, конечно, это очевидно.Но "не все так однозначно". Собственно главная проблема унаследована от OpenLDAP.
Исходный код кошмарен с точки зрения читаемости и подводных камней. Эффективно с ним работать может только авторы, точнее сам Ховард и может-быть кто-то еще.
Всем остальным приходиться тратить массу времени на понимание написанного, особенно всех взаимосвязей и side effects.
Поэтому, на самом деле, вне зависимости от языка и прочих ритуалов привлечения внимания, в ReOpenLDAP не будет много больше разработчиков чем в исходном OpenLDAP.
А почему не LibreLDAP/LibreOpenLDAP? Зачем ломать стереотпы
Исходная цель ReOpenLDAP была попроще = навести минимальный порядок и поправить баги мешающие (мягко говоря) эксплуатации.Ну и Libre тогда только у офиса была, стереотипов еще не было )
Если такие прямо несусветные запросы к производительности, почему не взяли просто in memory rdbms?
fix: не rdbms конечно, а dbms
> fix: не rdbms конечно, а dbmsНачиналось с другого, совсем.
Просматривался вариант реализовать одну из подсистем с участием LDAP-сервера.
Кроме этого, в "принципе не помешал-бы" некий работающий LDAP-blackbox.
Протестировали производительнось, прошел только OpenLDAP.
Проблемы всплыли много позже, и тогда меня позвали починить...Собственно, что я перессказываю - там выше есть ссылка на запись доклада.
А где-то там у Стаса рядом есть запись и доклада с 2015.Но если абстрагироваться от истории, то inmemory+wal конечно подходит.
Но тогда Костин tarantool был ещё не так крут/готов, а главное - OpenLDAP работал в тестах и никто не ожидал "напильника" в два года.
Есть полно промышленных решений особенно на почитаемой вами жабе которые не надо было ждать :D итого архитектора на мыло, трудозатраты не оценили путём, два года ваяли велосипед
> Есть полно промышленных решений особенно на почитаемой вами жабе которые не надо
> было ждать :D итого архитектора на мыло, трудозатраты не оценили путём,
> два года ваяли велосипедУ вас есть неточность - на java НЕТ промышленных (и не промышленных) решений которые могут заменить или как-то конкурировать с ReOpenLDAP. Даже без репликации они уступают в 5-10 раз (точнее сказать сложно: разное железо, схемы, характер запросов и т.д.) при условии работы in-memory. А как только требуется фиксация на диске, то java неожиданно заносит и все тонет в IOPS.
Далее, если разобраться, то все "промышленные решения на яве", на деле оказываются чуть менее чем XY-ней, примерно везде где нужна производительность (а не "кони в вакууме" или "фабрики фабрик для фабрик молотков"). А все исключения из этого наблюдения устойчиво попадают в шаблон: сверху на яве рисуются кнопочки и "IB-розочки", а снизу через JNI все делает C/C++.
Причем на 20% в этом виновата сама Java, с "парой чемоданов батареек" в виде виртуальной машины, сборки мусора и т.п.
И на 80% - экосистема, где здравый смысл принесен в жертву религии шарообразных абстракций, паттернов и некого стиля.Вот только уточню: в огромной массе других случаев java - отличный язык и технология, в том числе более дешевый.
Чуть наброшу по теме Java.Все ошибаются, и нисколько я не исключение. Поэтому, если (вдруг) все-таки есть какие-то java-решения на замену ReOpenLDAP, то я вам советую/прошу предложить их в billing.ru. Может даже поучаствовать во внедрении.
Жабу там беззаветно любят, если не ошибаюсь - уже лет 15.
Однако, все-же есть риски что не примут (пошлют). Ибо уже года 3 (могу ошибаться) срывают сроки релизов из-за того, что "промышленные решения на java" работают чуть медленнее чем надо (а чертовы мегагерцы перестали расти).Причем, там же можно будет выяснить (лицом к лицу) актуальность общеизвестных и как-бы основных причин (руки из попы, люди-снежинки, танцорам что-то мешает) плохих java-показателей. Ну и показать "как надо".
Короче, всячески рекомендую.
"Ибо уже года 3 (могу ошибаться) срывают сроки релизов из-за того"По личному опыту - в телекомах ЗП ровно вдвое ниже, чем у нормального бизнеса.
Соответственно, то что кто-то там сидит и три года за еду срывает сроки, ничего не доказывает."фабрики фабрик для фабрик молотков"
На плюсах никто не мешает такую же ахинею городить. А вот о твоей компетенции выводы уже можно делать. Ещё напиши про сборщик мусора, как он часами ужасный stop the world делает 8)))
По "прошу предложить"
Где ТЗ? Чтобы было о чём говорить.
В целом по теме. Известно что однопоточная прожка на анси си, на 30-50 % быстрее однопоточной на жабе. На плюсах практически одинаково. А вот полная утилизация хотя бы 12ядерного проца на сишечках это уже приключение. Хотя на жабе это под силу и весьма среднему прогеру.
> По личному опыту...[...]
Я там ответил, но получилось в новой ветке (видимо промазал по ссылке).
В способности тру-жабистов нагрузить в полку все 100500 ядер системы даже обычным "Hello world!" никто и не сомневается.
> По личному опыту - в телекомах ЗП ровно вдвое ниже, чем у нормального бизнеса.Не заметил.
> Соответственно, то что кто-то там сидит и три года за еду срывает сроки, ничего не доказывает.
На самом деле платят и ищут профи.
Просто предложите свои услуги, если не слабо:
- https://hh.ru/vacancy/20985959
- https://hh.ru/vacancy/20965714Мои компетенции можно по-обсуждать публично:
- http://www.highload.ru/2017/abstracts/2837.html
- http://www.highload.ru/2017/abstracts/2838.html
- В Калуге на http://bit.ly/2w9xWTq
- В Брюсселе на https://ldapcon.org/2017/Приходите. Welcome.
На всякий, еще раз замечу:
- Java отличный язык, особенно когда C/C++ не подходит (non reasonable) или их не осилили/загoвнoкодили.
- разработка на Java всегда будет менее трудозатратной (дешевле) чем аналогичное C/C++.
- правильно сделанная программа на Java всегда будет медленнее и прожорливее аналога на C/C++.
Ох, судя по описанию java-вакансии в Петер-Сервисе еще не все пальцы отгорели от засовывания highload в розетки типа ElasticSearch и Cassandra :)И причины появления http://www.scylladb.com не вразумили, жаль.
> На самом деле платят и ищут профи.По вакансии не скажешь, что ищут профи. "Ожидания" уровня простого жабакодера. з/п не указана. Ещё и Питер.
"правильно сделанная программа на Java всегда будет медленнее и прожорливее аналога на C/C++."
Ты опять неправ. Про утилизацию железа уже писал. Из личных наблюдений сишные Постгрес, Монго, Оракле на например 12-ядернике дальше 1-2 ядер НИКОГДА не вылазят. Мои жабные поделки - легко, иногда даже без доп телодвижений (те же Collections из core многопоточны из коробки).
Кстати, из общения с продуктами Positive Technologies. SIEM полный шлак по сравнению со ВСЕМИ рассмотренными конкурентами. Сканер сети шлак, а цена космос. Только менеджеры говорливые, обещают что "вот-вот всё станет круто". Так что предлагаю авторитетом не давить ;)
>> На самом деле платят и ищут профи.
> По вакансии не скажешь, что ищут профи. "Ожидания" уровня простого жабакодера. з/п
> не указана. Ещё и Питер.Ну я уже понял что вы у нас коренной уникум из defaultcity и "за еду" в Питер не поедете.
Может покажите что-нибудь для острастки, на github например?>> "правильно сделанная программа на Java всегда будет медленнее и прожорливее аналога на
>> C/C++."
> Ты опять неправ. Про утилизацию железа уже писал. Из личных наблюдений сишные
> Постгрес, Монго, Оракле на например 12-ядернике дальше 1-2 ядер НИКОГДА не
> вылазят. Мои жабные поделки - легко, иногда даже без доп телодвижений
> (те же Collections из core многопоточны из коробки).Я не хочу спорить с вами о вещах, которые вы не понимаете.
Точнее, видимо, не понимаете до конца как они работают.Говоря пафосно, пытаться обогнать C/C++ на Java - это примерно как превысить скорость света :)
С одной стороны, в яве не ничего, чего нельзя-было бы сделать на С/C++ (но на Java может быть _дешевле_).
С другой стороны, в ява неизбежны накладные расходы при организации структур данных.
Конечно можно все сделать на массивах из primitive types или в unsafe (который "внезапно" до-сих пор не выкинули), но тогда зачем вообще тут Java?> Кстати, из общения с продуктами Positive Technologies. SIEM полный шлак по сравнению
> со ВСЕМИ рассмотренными конкурентами. Сканер сети шлак, а цена космос. Только
> менеджеры говорливые, обещают что "вот-вот всё станет круто". Так что предлагаю
> авторитетом не давить ;)Это как-раз "не кстати" и не имеет отношения к теме, а просто показывает отсутствие у вас экспертизы и других аргументов. Рекомендую начать с изучения причин попадания Positive Technologies в "магический квадрант".
Тем не менее - я вам не скажу за "всю Одессу", особенно за продукты с ложкой такого java-кошмара как ElasticSearch... Но если же есть что-то сказать, то приходите на https://www.phdays.ru и/или http://www.securitylab.ru
А вот с моими "поделиями" все просто = берете линейку и меряете.
Давайте начнем с этих мелочей и до "Позитива" доберемся чуть позже (и для релевантности после релизов с каким-нибудь моим участием).
Какие кадры на hl встречаются, ржу не могу... Увы, си днище, потому что нормальные прогеры пишут сразу в машинных кодах. И субд и распределенные системы. А си ваше тормозит и глючит, особенно с -O3, знаем, плавали.
> Какие кадры на hl встречаются, ржу не могу... Увы, си днище, потому
> что нормальные прогеры пишут сразу в машинных кодах. И субд и
> распределенные системы. А си ваше тормозит и глючит, особенно с -O3,
> знаем, плавали.Да, понимаю.
Но вы держитесь, нас всех когда-нибудь вылечат ;)
Короче, шанс еще есть, держитесь!
Гражданин, в твоем кривом мозгу не созрело что JAVA изначально тоже писана на C? И собирается с теми-же -O ключами?
"де$илы, $ля" (с)
>JAVA изначально тоже писана на CИ посмотри сколько ДЫРИЩ в каждой версии. Жду не дождусь когда жабку перепишут на rust-е, а си и на этой задаче пойдёт в помойку ;)
Ну а rust видимо из "святым духом" программировался из сферического вакуума простанства и времени… (facepalm)
> Ну а rust видимо из "святым духом" программировался из сферического вакуума простанства
> и времени… (facepalm)Такой сверхироничный ламер, просто диву даюсь. Раст это компилятор, пусть его хоть на брейнфаке пишут, глюки сишечки в него никак не переползут. В отличие от виртуальной машины JVM (это даже если раст на сях пишут, в чём не уверен).
Я жабу не люблю, но насколько я знаю, за счёт вирт. машины можно делать runtime-оптимизации недоступные сишке и отчего жаба будет быстрее в определённых случаях.
Так что про скорость света это может быть несколько ошибочно.
> Я жабу не люблю, но насколько я знаю, за счёт вирт. машины
> можно делать runtime-оптимизации недоступные сишке и отчего жаба будет быстрее в
> определённых случаях.
> Так что про скорость света это может быть несколько ошибочно.JIT и интроспекция действительно позволяют делать некоторую оптимизацию, но вот кол-во случаев когда это получается и дает результат не так много:
1. Всяческое "совсем" позднее связывание (включая подгрузку каких-то классов на ходу), что в случае java перетекает в следующий подпункт;
2. Генерация кода самой программой;
3. Если выясняется что какой-то метод вызывается очень часто, в том числе когда часть или все параметры зафиксированы;В C/C++ штатного JIT конечно нет, но при необходимости есть несколько вариантов (NativeJIT, LLVM, даже jithabr).
Подпункты же 1 и 3 примерно не актуальны, т.е. дают выигрыш в экосистем java, а в C/C++ и без них нормально.
Поэтому, в качестве итога = за счет упомянутых оптимизаций java может обогнать только плохой (плохо спроектированный или бездумный) код C/C++. Но в этом может быть и прелесть явы: можно упopото вить веревки из паттернов и абстракций, потом вжух и в продакшин, и оно будет работать (только медленнее C/C++).
>скорость света, скорость света, скорость светаГуру из Positive Technologies видимо не знает, что в теоретической физике уже лет 100 как вполне допускается передвижение быстрее С. ;) wormhole называется. Что самое смешное, аналогия вполне в тему - движение тушки в пространстве это цепочка си - ассемблер - машинные инструкции. Си тут ДАЛЕКО не "скорость света".
А на мейнфреймах с Z/OS некоторые операции жабы исполняются сразу процом. Вполне себе такой wormhole. Си в пролёте... ;)
Тоже слышал про сжатие пространства и отрицательную энергию.
Но трицательный IQ вижу впервые, это прохая реклама для жабы.
Кстати, ещё очевидный тезис, не раз его озвучивал. JVM проектируют и программят зубры, навроде Шипилева. А прожки пишут простые Васи-погромисты. Половина из них чуть лучше среднего, а половина так и хуже среднего. Только не надо блабла, что сишнике все сплошь с IQ 150++Поэтому равнять оптимизации Васи-погромиста и оптимизации Шипилёва - признак небольшого ума. Итого прога на жабе из под обычного прогера-жабиста может легко обогнать прогу на си обычного прогера-сишника. Шах и мат, братишки! Надоело очевидное рассказывать...
Оставьте вы Леху в покое, его уже и так допекли разные грамотеи.Знаете яву - отлично, знаете как процы работают - еще лучше.
Так продемонстрируйте сами что-нибудь, своё и не бесполезное.
Нет готового - сделайте, а не страдайте тут маразмом.К примеру, вот возьмите и реализуйте на java это = https://github.com/leo-yuriev/t1ha
Некоторые "идиоты" (включая меня) утверждают, что это толком не возможно (будет в 4-6 раз медленнее) - покажите обратное.Если (вдруг) не получится, то можно сделать пользу = пробросить вызовы через "Critial Natives" = https://bugs.openjdk.java.net/browse/JDK-7013347
Попробуйте сделать bench, посмотрите в v-tune и т.д.
Море возможностей...
> К примеру, вот возьмите и реализуйте на java это = https://github.com/leo-yuriev/t1ha
> Некоторые "идиоты" (включая меня) утверждают, что это толком не возможно (будет в
> 4-6 раз медленнее) - покажите обратное.Знатно потролилил убогого ) Хотя это и реализуется, и почти без падения производительности, но через JNI и опять с выходом на C :)
> Знатно потролилил убогого ) Хотя это и реализуется, и почти без падения
> производительности, но через JNI и опять с выходом на C :)Не, это было лишнее.
Удалил.
> Знатно потролилил убогого ) Хотя это и реализуется, и почти без падения
> производительности, но через JNI и опять с выходом на C :)В java нет uint64_t, поэтому умножение u64xu64->u128 придется делать через %$#, например так = https://github.com/leo-yuriev/t1ha/blob/25f790b6723fa0035f2b...
В результате вместо одного (но "широкого") умножения будет аж 4, плюс сдвиги и сложения.
java.math.BigInteger - да можно, но оверхед достаточно показательный.
>его уже и так допекли разные грамотеи.The Future will Positive
which are not uses specific hardware tricksэто ты про себя? :) хау мач вотч, мгимо финишд?
По хэш функции. Опять сишники сваливаются в микробенчмарки. Не интересно абсолютно.
>The Future will Positive
>which are not uses specific hardware tricksНу так предложите автору исправления. Посмейтесь вместе с носителем языка и покажите как должно быть.
Ткните носом, с аргументацией (правила из учебника).>это ты про себя? :) хау мач вотч, мгимо финишд?
По делу есть-что аргументировать, кроме продолжения "сам дурак"?
>По хэш функции. Опять сишники сваливаются в микробенчмарки. Не интересно абсолютно.
Возьмите линейку, измерьте и покажите: вот такая-то задача, вот её код, вот код "линейки", вот и тут Java быстрее C++ на столько-то.
Либо отыщите готовые результаты. Ведь их же должно быть валом?PS: Вас культурно и многократно выпороли, а вы продолжаете что-то изображать.
Если не заниматься тактодрчерством, а брать практические задачи, например FTSдвижок, графовую субд с мощным движком (где можно за небольшое время написать свой траверсер или выбрать из кучи стандартных) то могучих сишников как ветром сдувает. Покажите аналог jboss-а под си. Мне и мерять ничего не надо, кровавый ынтырпрайз лепится на жабе и точка.
> Если не заниматься тактодрчерством, а брать практические задачи, например FTSдвижок, графовую субд с мощным движком (где можно за небольшое время написать свой траверсер или выбрать из кучи стандартных) то могучих сишников как ветром сдувает. Покажите аналог jboss-а под си. Мне и мерять ничего не надо, кровавый ынтырпрайз лепится на жабе и точка.Все практические задачи состоят из простых действий, каждое из которых корректнее измерять в тактах. А вся оптимизация заключается в экономии этих тактов, чем собственно и занимается упомянутый вами Шипилев в рабочее время.
Полнотекстовый поиск (FTS), семантический анализ, графовые БД, RDF и все прочие практические задачи (с "нелинейными" манипуляциями структурами данных "на указателях") в C/C++ всегда будут быстрее. Поэтому Sphinx от Андрюхи рвет какой-нибудь ElasticSearch почти также как ScyllaDb унижает Cassandra.
Однако, на Java делать подобные аппликухи-залипухи в 42 раза проще/дешевле, включая всякие POCи, плагинчики и прочие XY-инчики. К сожалению, это и более выгодно - рынок пока еще ведется на "безопасность и надежность" Java в обработке данных. Поэтому генерируется очень много "мега-проектов", которые индустрия не успевает вовремя переварить и слить (по-сути ими забита канализация).
Короче, попробуйте загрузить в ElasticSearch пару десятков миллионов чего-нибудь больше "Hello Word"... Увидите как яву укачивает и тошнит везде где нетривиальные задачи сочетаются с нагрузкой. Иногда может показаться что оно работает быстро - пока не будет повторено на C/C++ (как ScyllaDB); и как-бы надежно - но до нехватки памяти, места на диске и т.п., а потом абсракции сталкиваются с реалиями; и как-бы безопаснее чем C/C++...
А вот со всяческой оркестрацией и "архитектурной гибкостью" у Java наоборот очень хорошо. Чуть менее чем все паттерны там очень хорошо/обильно и давно смазаны вазелином. Адаптеры, фасады и всяческие другие виды прокладок позволяют решать месячные проблемы бизнес-архитекторов и прочих "аналитегов". Поэтому "кровавый ынтерпрайз" неотделим от java, и от обоих инженеров тошнит примерно одинаково.
Вот поэтому "кровавый ынтерпрайз", когда дело доходит до нагрузки и производительности - либо загибается и умирает, либо эволюционирует и прозревает в отношении jboss и прочей явоты.
Тем не менее, я еще раз повторю: Java прекрасна и очень-очень к месту, там где требуемая производительность позволяет транжирить такты CPU и мегабайты RAM.
>Sphinx рвет ElasticSearch
>ScyllaDb унижает CassandraТы наверное из далекого будущего пишешь, ScyllaDb появилось на 10 лет позже Каси и до сих пор не реализован весь функционал этого drop-in (хыхы) replacement. Инсталляций 3.5 на всю планету.
Sphynx через 50 лет, видимо, тоже будет рулить. Тебе лучше знать.
Лучше расскажи, почему в вашем Positive Technology SIEM слепили на богомерзком ElasticSearch? При этом имея storage в виде mongo которое сишное и имеет встроенный FTS (по моему опыту более тормозной upto 1000x и убогий) У них же такие эксперты-сишники работают :)
> Если не заниматься тактодрчерством, а брать практические задачи...то мне на той неделе одни люди говорили о том, как собираются жабу менять на сишечку примерно в масштабах ЦОДа.
Вас и впрямь выпороли. Причины [смутного] беспокойства тоже отчасти понятны, я бы тоже беспокоился при таком поведении оракла в стеклянном доме...
> JVM проектируют и программят зубры,Зубры, мкаки, хомячки и прочие насекомые - много вас таких.
Хм, ява вместо брусчатки. Коллега что-ли?
RTFM.Запросы поиска/чтения в ReOpenLDAP и libmdbx масштабируются линейно по ядрам CPU.
Спасибо за интересный проект.
Такой вопрос.
Хочу использовать libmdbx как хранилище в golang, я нашёл биндинг к LMDB https://github.com/bmatsuo/lmdb-go но наверное для libmdbx его нужно адаптировать, если да то насколько сильно?
До этого думал использовать boltdb (для реалтайм хранилища/горячего кэша), но судя по описанию в биндинге даже стандартный LMDB в сочетании с го дают большую скорость чем родной болт.
> Спасибо за интересный проект.
> Такой вопрос.
> Хочу использовать libmdbx как хранилище в golang, я нашёл биндинг к LMDB
> https://github.com/bmatsuo/lmdb-go но наверное для libmdbx его нужно адаптировать, если
> да то насколько сильно?
> До этого думал использовать boltdb (для реалтайм хранилища/горячего кэша), но судя по
> описанию в биндинге даже стандартный LMDB в сочетании с го дают
> большую скорость чем родной болт.Да, нужно адаптировать.
Но думаю изменения будут небольшие и в основном механические.Однако, вынужден предупредить - формат БД и API в master и devel еще не зафиксированы.
Революций в API не будет, но какие-то доработки в байндингах точно потребуются.
А формат БД и внутренности будут меняться достаточно серьезно.Старую стабильную версию из stable/0.0 использовать не рекомендую. В свое время (для МегаФона) одним из требований была совместимость по формату БД. Поэтому многие принципиальные фичи были невозможны.
Дополню: Совместимость текстового формата dump/restore будет поддерживаться, в том числе с LMDB (если вдруг это не так - то это баг).
Спасибо за ответ.