###### tags: `netology` `devops` # Домашнее задание к занятию "6.6. Troubleshooting" ## Задача 1. MongoDB Пользователь (разработчик) написал в канал поддержки, что у него уже 3 минуты происходит CRUD операция в MongoDB и её нужно прервать. - *напишите список операций, которые вы будете производить для остановки запроса пользователя* - Допустим, что средства профлирования уже были включены. - Теперь мы можем найти список запросов, выполняющихся больше 3-х минут: `db.currentOp({"secs_running":{$gte: 180}})`. - Найдем интересующий нас запрос. - Остановим его командой: `db.killOp(opid)`. - предложите вариант решения проблемы с долгими (зависающими) запросами в MongoDB - С помощью профилировщика, как в пункте выше можно найти все запросы, попадающие под наши критерии медленных. - С помощью `explain(‘executionStats’)` построить план запроса. - Наиболее вероятная причина низкой скорости - выборка по большому числу записей, чтобы их сократить нужно построить индекс. ## Задача 2. Redis Вы запустили инстанс Redis для использования совместно с сервисом, который использует механизм TTL. Причем отношение количества записанных key-value значений к количеству истёкших значений есть величина постоянная и увеличивается пропорционально количеству реплик сервиса. При масштабировании сервиса до N реплик вы увидели, что: - *сначала рост отношения записанных значений к истекшим* - *Redis блокирует операции записи* Как вы думаете, в чем может быть проблема? --- Рост "новых" пар ключ-значение по отношению к тем, которые должны быть очищены говорит о том, что растет размер хранилища, а значит ресурс памяти заканчивается. Блокировка на запись, скорее свего, говорит о том, то выделенная память закончилась. ## Задача 3. MySQL Вы подняли базу данных MySQL для использования в гис-системе. При росте количества записей, в таблицах базы, пользователи начали жаловаться на ошибки вида: ```sql= InterfaceError: (InterfaceError) 2013: Lost connection to MySQL server during query u'SELECT..... ' ``` Как вы думаете, почему это начало происходить и как локализовать проблему? Какие пути решения данной проблемы вы можете предложить? --- Чаще всего данная ситуация возникает, когда происходит выборка очень большого количества данных, что очевидно, т.к. проблема стала возникать не сразу, а при росте количества записей! Документация рекомендует нам увеличить настройку `net_read_timeout` с дефолтных 30 до 60 секунд, но делать это стоит только после того, как закончились пути оптимиация запроса с помощью индексов и других средств БД. ## Задача 4. PostgreSQL Вы решили перевезти гис-систему из задачи 3 на PostgreSQL, так как прочитали в документации, что эта СУБД работает с большим объемом данных лучше, чем MySQL. После запуска пользователи начали жаловаться, что СУБД время от времени становится недоступной. В dmesg вы видите, что: ```bash= postmaster invoked oom-killer ``` Как вы думаете, что происходит? Как бы вы решили данную проблему? --- Данная ошибка говорит о том, что закончилась выделенная память. Скорее всего, объем данных все еще велик. Если нужен именно этот объем данных, то можно попробовать выгружать не все данные целиком, а пачками (batch) меньшего размера.