суббота, 19 декабря 2015 г.

Strata + Hadoop 2015 Singapore

      В этом году мне довелось побывать Strata + Hadoop в Сингапуре и я должен сказать что я в шоке. В шоке от количества участников, от уровня докладчиков и самое главное - от уровня организации. Тебе на почту пришел QR, ты это письмо открыл на телефоне - показал свой айпаду которые рядами стоят у стоек регистрации - он прочитал этот  QR код и сразу распечатал тебе твой бейдж. Никаких тебе очередей и криков - "от A до S  сюда!", от "от S до Z сюда!"  Все очень четко и отлажено. Никаких тебе бумажных расписаний - просто скачиваешь приложение конференции - там тебе и расписание, и краткая информация по докладчикам. Тут же ты им можешь отзыв оставить. В общем после такого опыта мне европейские конференции кажутся митапами, и не более того.

РЖД молодцы

      У нас все любят ругать гос структуры, но ругать не строить. Языком молоть все мастера, а вот жопу поднять с дивана и что-то сделать - с этим обычно проблемы. Последние 5 лет я очень много езжу поездом, и я вижу весьма существенные изменения:

  • Сайт РЖД стал удобным. Действительно удобным, с весьма неплохим интерфейсом. Постепенно они выправили косяки юзабилити: запоминают куда я чаще всего езжу, не надо отдельно проходить электронную регистрацию, даже оплата теперь сделана по человечески. Не надо билет туда и билет обратно отдельно оплачивать.
  • Электронная регистрация заработала без сбоев: раньше ее только внедряли на фирменных поездах и не всегда все было гладко. Сейчас она действует и на обычных поездах. Просто приходишь с паспортом к поезду и все. Никаких тебе распечатываний в кассе.
  • Качество услуг в купе очень сильно улучшилось. Я имею ввиду телевизор, ужин/завтрак, всякие полезные мелочи. То что лет 5 назад можно было увидеть только в именных поездах типа "Лев Толстой" (Москва - Хельсинки), сейчас уже есть и в обычном поезде - Москва-Ульяновск. 
  • РЖД бонус - не могу сказать что там много халявы, но время от времени бесплатно проехаться можно. 
  • Качество вагонов очень выросло. Если раньше даже беря билеты в фирменный поезд можно было угодить в сарай, то в последний год я ничего такого близко не видел. 
  • Ну главное - система динамического ценообразования. Это просто огонь. Можно в купе  проехаться по цене плацкарта. 
Как человек работающий в большой компании я понимаю насколько сложно продираться сквозь бюрократические дебри корпоративной иерархии. Я уверен что в РЖД бюрократии еще на порядок больше чем у нас. Поэтому люди которые не смотря ни на что могут внедряют изменения в такой огромной и закостенелой компании - они просто молодцы. Респект вам.

вторник, 24 ноября 2015 г.

Темная сторона Aerospike

      Вот уже год как Aerospike работает у нас в продакшене. В связи с этим хотелось бы отметить несколько негативных моментов:

  • Не продуман downtime less upgrade. Чтобы убрать ноду из кластера нужно сказать ей dun. Это в свою очередь порождает процесс решардинга. Если у вас много данных это может быть весьма длинная история.  Потом нужно уверится что клиенты больше не ходят к этой ноде (зависит от вашего приложения). Потом upgrade/изменение настроек и снова добавление в кластер. И снова решардинг. 
  • Многие настройки нельзя менять на лету. То есть это означает необходимость рестарта. А про рестарт ниже.
  • Быстрый рестарт возможен только в Enterprise edition. Рестарт community edition - это весьма медленная операция. Ее длительность зависит от:
    • Настроек heartbeat (timeout, interval). Сразу после старта нода откажется принимать входящие подключения на 3000 порту пока она не присоеденится к кластеру
    • После присоединения к кластеру нода начнет читать либо реплицировать свою порцию данных с других нод кластера (для in memory namespace) либо читать данные с диска. Длительность этого процесса зависит от размера namespace
  • Некоторые настройки для изменения требуют full cluster restart. Это просто не серьезно для production-ready решения.
  • Не стабильное время ответа. В среднем Aerospike демонстрирует довольно хорошее время ответа (0.7-1ms), но время от времени случаются спайки до секунды. Вероятно это совпадает с запуском процесса expiration/eviction thread. А он запускается каждые nsup-period либо при переполнении раздела.
  • Smart клиент не такой уж и smart. Если используются Go client  то после изменения конфигурации кластера скорость работы с Aerospike резко падает. Потому что расположение данных меняется, и клиент начинает ходить за данными не на те ноды. Smart client не получает уведомлений от сервера о том что расположение данных изменилось. 
Не поймите меня не правильно - Aerospike не так и плох. Просто вот такие есть у него недостатки. Но Aerospike очень активно развивается. Как сервер так и клиенты, поэтому некоторые проблемы решаются просто обновлением Aerospike и клиентских библиотек.

суббота, 26 сентября 2015 г.

Transparent Huge Pages

         Red Hat сделала "классную" фичу в ядре Linux называемую Transparent Huge Pages (THP).  Её суть в том что они пытаются научить приложения, не знающие ничего о huge pages работать с ними. Прозрачно подменяют обычные страницы памяти на huge pages. Все выглядит круто на бумаге, и даже в синтетических тестах - согласно их бенчмаркам THP на 10% ускоряют абстрактное приложение  http://www.slideshare.net/raghusiddarth/transparent-hugepages-in-rhel-6
        Но в реальной жизни получается несколько иначе. В некоторых случаях THP вызывает ничем не мотивированное увеличение потребления CPU в режиме ядра. Спасибо Oracle за то что они поделились своими наблюдениями - https://blogs.oracle.com/linux/entry/performance_issues_with_transparent_huge  К сожалению я еще не познал в достаточной мере кунг-фу linux perf, и надо сказать подобное поведение ядра поставило меня в тупик. 
          В общем всем советую добавить
echo never >> /sys/kernel/mm/redhat_transparent_hugepage/enabled

Elastic Search

      В последние пол года довольно много пришлось заниматься ElasticSearch. За это время многое о нем у знал, многое понял. Решил поделится со всеми своими открытиями.
      Первое и наверное самое главное. Обновления в ElasticSearch не real time. Под капотом там старые добрые lucene индексы, которые как были append-only так ими и остались. ElasticSearch очень крут тем что тебе не надо самому организовывать эту псевдо-реалтаймовость обновления индексов. Он сразу предоставляет тебе абстракции базы данных (get/update/delete), и дефолтное значение refresh_interval=1s некоторое время поддерживает данную иллюзию. Но во первых 1s время обновление это не реалтайм не разу, во вторых опыт показывает что при большой нагрузке эластик с таким refresh_interval очень плохо себя чувствует. Вы будете вынуждены либо группировать апдейты у себя в коде либо увеличивать refresh_interval.
   Второе: оптимальный размер jvm heap для эластика примерно половина доступной оперативки. Вторую половину оперативки он использует неявно, через кэши операционной системы.
    Третье: ElasticSearch очень чувствителен к сетевым проблемам. Как только случается сетевая задержка большая чем zen.discovery.timeout нода отваливается от кластера. Через  секунду она снова присоеденится к кластеру и начнет процесс восстановления. Будет скачивать с других нод шарды которые раньше на ней находились. Причем делает это ElasticSearch в несколько потоков чем очень не слабо нагружает кластер. Настолько не слабо что часто это приводит к тому что весь кластер складывается как карточный домик. Просто из-за того что сеть мигнула на одном из серверов. Возможно вам стоит ограничить количество шард которые ElasticSearch будет восстанавливать одновременно. Чем меньше параллельных потоков - тем меньше нагрузка на другие ноды. И тем больше время требуемое на присоединение ноды обратно. И обязательно посмотрите на zen.discovery.timeout - это значение должно соответствовать качеству вашей сети. 
        Четвертое: я бы очень НЕ рекомендовал вам использовать ноды с разной пропускной способностью в одном кластере. Эластик исходит из того что все ноды одинаковые и распределяет нагрузку соответствующим образом.  То есть размеры шард, их распределение по нодам. Как только самая слабая нода в кластере перестает справляться со своей нагрузкой - весь кластер встает колом. Если есть какая-то слабая нода - лучше либо вообще отцепить ее от кластера либо сделать ее вспомогательной нодой (не хранящей данные). 
             Пятое: важно выбрать правильный баланс между количеством реплик и затратами на обновление индекса и восстановлением кластера. Чем больше у вас реплик - тем большее время потребуется на восстановление кластера и тем больше ресурсов будут затрачивать обновление индексов.
             Шестое: Не питайте напрасных надежд - ElasticSearch это не база данных. Он не должен быть primary хранилищем данных. Смело ставьте action.write_consistency: one. Это очень сильно ускорит выполнение обновлений индекса.
             Седьмое: Ограничте размер threadpool.search.queue_size. Если кластеру плохо, то есть скорость обработки запросов  сильно меньше скорости их выполнения  какая бы ни была очередь - она наполняется моментально. Если эта очередь большая - она только отъесть оперативную память, которой и так не хватает в такие моменты. Мы прекрасно живем с threadpool.search.queue_size: 500 и примерно 30 000rps. 
        Восьмое: обратите внимание на  field data cache Его построение это очень затратная операция, если у вас интенсивно наполняется сбрасывается этот кэш - производительность будет очень страдать. Еще советую посмотреть на использование doc_value - возможно это избавит вас от многих проблем с памятью.
      Девятое: обратите внимание сколько аггрегаций делается в запросах к ElasticSearch. Аггрегации это довольно затратная операция, если есть способ уменьшить их количество - это сильно уменшит время выполнения запроса. 
           Десятое: про marvel наверное все знают, думаю нет смысла писать что это must have. Но кроме него есть еще один очень полезный плагин для ElasticSearch - HQ

пятница, 24 апреля 2015 г.

Про талант и корону

    Жил был один очень талантливый программист. Прям честно скажу, когда он работал - то искры летели. И код получался до жути красивым. Но проблема в том что работал этот программист редко, потому что считал что он должен быть толи архитектором то ли CTO. Но поскольку ни тем ни другим его не делали, он быстро переставал работать. Пришлось его уволить.  А недавно общие знакомые переслали весточку о нем: http://www.artemandreenko.com/

Отсюда мораль: голый талант еще ничего не значит если он не мотивирован работать.

Go meetup в Badoo

   Вчера в офисе Badoo  прошел очередной Go meetup. Чувствуется что за те полтора года что меня не было в Москве уровень Go разработки вырос просто на порядок. Наконец-то есть интересные доклажы. В прошлые разы интерес вызывали разве что выступления Дмитрия Вьюкова, все остальное было капитанщиной.  Вот ссылки на презентации:


  1.  http://www.slideshare.net/BadooDev/ss-47345590
  2. http://www.slideshare.net/MaximDementyev/go-meetup-2015-0423
  3. http://www.slideshare.net/MikhailSalosin1/go-meetup-smotri-23042015

вторник, 14 апреля 2015 г.

суббота, 4 апреля 2015 г.

Lazada Tech Hub Moscow

    Собственно subj. Мы практически открылись, и у нас много вакансий. Если вы хотите писать на Go, и быть частью самой крутой e-commerce команды юго-восточной азии - приходите. У нас много интересных задач, мы любим нестандартные подходы. Мы не требуем предыдущего опыта на Go: достаточно желания изучить его. Из дополнительных плюшек: ДМС, мак буки и мак мониторы. Кроме Go  программистов есть вакансии:
    IOS программистов
    Android программистов
    Frontend программистов
Если заинтересовало - пишите на yuriy.vasiyarov at lazada.com
PS
Также есть вакансии технических менеджеров среднего и высшего уровня. Но по всем этим вакансиям очень высокие технические требования. Аджайл мастер 80-го уровня с амбициями CTO (или просто царь) нам не подойдет.