Выполнение [домашнего задания](https://github.com/netology-code/virt-homeworks/blob/master/06-db-06-troobleshooting/README.md)
по теме "6.6. Troubleshooting".

## Q/A

### Задача 1

> Перед выполнением задания ознакомьтесь с документацией по [администрированию MongoDB](https://docs.mongodb.com/manual/administration/).
> 
> Пользователь (разработчик) написал в канал поддержки, что у него уже 3 минуты происходит CRUD операция в MongoDB и её
> нужно прервать.
> 
> Вы как инженер поддержки решили произвести данную операцию:
> - напишите список операций, которые вы будете производить для остановки запроса пользователя
> - предложите вариант решения проблемы с долгими (зависающими) запросами в MongoDB

Первым шагом будет найти операцию, которую необходимо остановить. Для этого необходимо выполнить запрос на получение всех операций
в определённой БД, которые выполняются дольше 3 минут (180 секунд):

```javascript
db.currentOp(
   {
     "active" : true,
     "secs_running" : { "$gt" : 180 },
     "ns" : /^db1\./
   }
)
```

В полученном массиве нужно найти нужную операцию и взять её `opid`. Затем полученный параметр подставить в команду:

```javascript
db.killOp(opid)
```

Самый оптимальный вариант решения проблемы: добавить ограничение на длительность выполняемого запроса. 
Это можно настроить непосредственно для каждого запроса/операции, указав либо ключ `maxTimeMS`, либо вызвав метод `maxTimeMS()`,
в зависимости от контекста. А затем уже необходимо настраивать мониторинг, чтобы понять, почему конкретно операции выполняются долго.

### Задача 2

> Перед выполнением задания познакомьтесь с документацией по [Redis latency troobleshooting](https://redis.io/topics/latency).
> 
> Вы запустили инстанс Redis для использования совместно с сервисом, который использует механизм TTL.
> Причем отношение количества записанных key-value значений к количеству истёкших значений есть величина постоянная и
> увеличивается пропорционально количеству реплик сервиса.
> 
> При масштабировании сервиса до N реплик вы увидели, что:
> - сначала рост отношения записанных значений к истекшим
> - Redis блокирует операции записи
> 
> Как вы думаете, в чем может быть проблема?

Данная ситуация, скорее всего связана с проблемой, описанной в параграфе `Latency generated by expires` [документации redis](https://redis.io/docs/reference/optimization/latency/#latency-generated-by-expires).
Если кратко, то большое количество ключей, чьё время жизни истекает в одно время могут привести к тому,
что redis заблокирует доступ для произведения очистки.

По умолчанию redis настроен на удаление 200 истёкших ключей в секунду. При этом алгоритм адаптивный и будет зацикливаться, если обнаружит,
что более 25% процентов ключей уже истекли. Изначальное значение можно увеличить через конфигурацию `ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP`.

### Задача 3

> Перед выполнением задания познакомьтесь с документацией по [Common Mysql errors](https://dev.mysql.com/doc/refman/8.0/en/common-errors.html).
> 
> Вы подняли базу данных MySQL для использования в гис-системе. При росте количества записей, в таблицах базы,
> пользователи начали жаловаться на ошибки вида:
> ```python
> InterfaceError: (InterfaceError) 2013: Lost connection to MySQL server during query u'SELECT..... '
> ```
> 
> Как вы думаете, почему это начало происходить и как локализовать проблему?
> 
> Какие пути решения данной проблемы вы можете предложить?

Данная проблема, скорее всего, происходит по причине, что по запросу выбирается очень большое количество строк (исчисляется миллионами).
Варианты решения проблемы:
- Переписать запрос на выборку результатов, добавив какие-либо ограничения (например, `limit`);
- Увеличить значение `net_read_timeout` со значения по умолчанию до 60 секунд или больше.

Для более точной локализации проблемы можно использовать журнал ошибок, путь до которого задаётся конфигурацией `log_error`.

### Задача 4

> Перед выполнением задания ознакомьтесь со статьей [Common PostgreSQL errors](https://www.percona.com/blog/2020/06/05/10-common-postgresql-errors/) из блога Percona.
> 
> Вы решили перевести гис-систему из задачи 3 на PostgreSQL, так как прочитали в документации, что эта СУБД работает с
> большим объемом данных лучше, чем MySQL.
> 
> После запуска пользователи начали жаловаться, что СУБД время от времени становится недоступной. В dmesg вы видите, что:
> 
> `postmaster invoked oom-killer`
> 
> Как вы думаете, что происходит?
> 
> Как бы вы решили данную проблему?

Данная проблема возникает из-за недостатка оперативной памяти. `OOM Killer` - это компонент ядра Linux, призванный решать проблему недостатка памяти.
Таким образом, если настроен `OOM Killer`, то он будет "убивать" процессы, если ОС недостаточно RAM (включая swap).

В таком случае есть несколько вариантов решения:
1. Ограничить количество потребляемой оперативной памяти инстансом БД. Например, следуя следующим [рекомендациям](https://www.enterprisedb.com/postgres-tutorials/how-tune-postgresql-memory).
2. Увеличить количество оперативной памяти для машины. Данный способ, скорее всего, будет являться временным,
  так как с увеличением количества данных будет увеличиваться и количество потребляемой оперативной памяти.
