diff --git a/src/homework/06-database/6.6/readme.md b/src/homework/06-database/6.6/readme.md index 8d7d602..6c3c1ad 100644 --- a/src/homework/06-database/6.6/readme.md +++ b/src/homework/06-database/6.6/readme.md @@ -1,92 +1,103 @@ -Выполнение [домашнего задания](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..... ' -> ``` -> -> Как вы думаете, почему это начало происходить и как локализовать проблему? -> -> Какие пути решения данной проблемы вы можете предложить? - -// todo - -### Задача 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` -> -> Как вы думаете, что происходит? -> -> Как бы вы решили данную проблему? - -// todo +Выполнение [домашнего задания](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. Увеличить количество оперативной памяти для машины. Данный способ, скорее всего, будет являться временным, + так как с увеличением количества данных будет увеличиваться и количество потребляемой оперативной памяти.