Идея статьи родилась спонтанно из дискуссии в комментариях к статье «Кое-что об inode».
Дело в том, что внутренней спецификой работы наших сервисов является хранение огромадного числа мелких файлов. На данный момент у нас порядка сотен терабайт таких данных. И мы натолкнулись на некоторые очевидные и не очень грабельки и успешно по ним прошлись.
Поэтому делюсь нашим опытом, может кому и пригодится.
Я разработчик, альпинист и мне небезразлично все, что происходит вокруг. В этой статье я хочу рассказать о своих размышлениях по поводу командной работы, которые родились после моего восхождения на вершину Монблана в Альпах.
В наших проектах мы используем микросервисную архитектуру. При возникновении узких мест в производительности достаточно много времени тратится на мониторинг и разбор логов. При логировании таймингов отдельных операций в лог-файл, как правило, сложно понять что привело к вызову этих операций, отследить последовательность действий или смещение во времени одной операции относительно другой в разных сервисах.
Для минимизации ручного труда мы решили воспользоваться одним из инструментов трассировки. О том, как и для чего можно использовать трассировку и как это делали мы, и пойдет речь в этой статье.
Как-то в один момент я решил написать статью про поставку в виде контейнеров докер и deb-пакетов, но когда начал, меня почему-то понесло в далекие времена первых персональных компьютеров и даже калькуляторов. В общем, вместо сухих сравнений докера и deb получились вот такие вот размышления на тему эволюции, кои и представляю на Ваш суд.
В этой статье речь пойдет о том, как мы интегрировали разработанный Яндексом Томита-парсер в нашу систему, превратили его в динамическую библиотеку, подружили с Java, сделали многопоточной и решили с её помощью задачу классификации текста для оценки недвижимости.