В этой статье представлены три небольшие истории, которые произошли в нашей практике: в разное время и в разных проектах. Объединяет их то, что они связаны с сетевой подсистемой Linux (Reverse Path Filter, TIME_WAIT, multicast) и иллюстрируют, как глубоко зачастую приходится анализировать инцидент, с которым сталкиваешься впервые, чтобы решить возникшую проблему… и, конечно, какую радость можно испытать в результате полученного решения.Читать полностью »
В процессе эксплуатации систем с SELinux я выделил несколько интересных кейсов, решения которых вряд-ли описаны в Интернете. Сегодня я решил поделиться с вами своими наблюдениями в надежде, что число сторонников SELinux еще немного возрастет :)
Главная героиня нашего сегодняшнего интервью редко нуждается в представлении. Света Смирнова, инженер технической поддержки Percona, является экспертом по диагностике неполадок и оптимизации производительности MySQL, активным членом российского и международного Open Source сообщества, регулярным спикером на крупных профильных мероприятиях, автором одной из наиболее актуальных книг по MySQL — «MySQL Troubleshooting». На предстоящем летнем PG Day'17 Russia Света проведет интенсивный учебный курс по отладке производительности MySQL и прочитает лекцию, посвященную отладке репликации.
Накануне PG Day, мы побеседовали со Светой о тонкостях процесса репортинга и устранения багов в MySQL, последних тенденциях и трендах в мире популярных форков, истории внедрения функциональности поддержки JSON и подготовили подборку материалов, блогов и книг, полезных для всех специалистов, работающих с MySQL.
Эксклюзивно для PG Day, специальный раздел учебного курса будет посвящён Performance Schema. С её помощью можно отлаживать хранимые процедуры, отслеживать, где используется оперативная память сервера MySQL, просматривать текущие переменные отдельно для каждого соединения, отлаживать запросы, диагностировать блокировки и многое другое. Света расскажет, как настраивать Performance Schema и правильно выбирать входящие в нее инструменты для ваших задач.
Одним из самых популярных докладов конференции PG Day в 2015 году стал рассказ Владимира Бородина и Ильдуса Курбангалиева о ситуациях, когда посгресовым базам становится плохо, надо их диагностировать и искать узкие места. Все примеры в докладе взяты из реальной практики Яндекса, сопровождаются иллюстрациями и подробным рассказом о поиске «боттлнека». Не смотря на то, что проблемы рассматривались в разрезе 9.4 и 9.5 версий базы данных, общая ценность и практическая применимость советов Владимира и Ильдуса остается неизменной. Рады предложить вам транскрипцию этого доклада.
Вступление Ильи Космодемьянского: сейчас у нас будет рассказ о том, как жить, если очень хочется иметь Oracle, а его нет. На самом деле, это полезный доклад, потому что одна из проблем, которую мы сейчас имеем – это проблема средств диагностики. Средства диагностики местами не достают, местами, вместо привычных средств диагностики нужно использовать довольно сложные тулзы, которые вообще предназначены для разработчиков Linux, а не для DBA. У DBA зубы начинают болеть, когда они смотрят на эти скрипты. И вот ребята из Яндекса и PG Pro расскажут о методах диагностики Postgres, которые они применяют, как ими пользоваться и немного расскажут о том, как они собираются улучшить этот мир.
Мы наконец допинали функционал мониторинга elasticsearch до публичного релиза. Суммарно мы переделывали его три раза, так как результат нас не устраивал и не показывал проблемы, которые мы огребали на нашем кластере ES.
Под катом история про наш production кластер, наши проблемы и наш новый мониторинг ES.
Основным хранилищем метрик у нас является cassandra, мы используем её уже более трех лет. Для всех предыдущих проблем мы успешно находили решение, используя встроенные средства диагностики кассандры.
В кассандре достаточно информативное логгирование (особенно на уровне DEBUG, который можно включить на лету), подробные метрики, доступные через JMX и богатый набор утилит (nodetool, sstable*).
Но недавно мы столкнулись с одной достаточно интересной проблемой, и нам пришлось серьезно поломать голову, почитать исходный код кассандры, чтобы разобраться, что происходит.
