homework 6.6: add tasks 3-4

This commit is contained in:
2022-06-14 10:11:44 +07:00
parent a7c5bd2e6d
commit 93dcd900fd

View File

@@ -1,92 +1,103 @@
Выполнение [домашнего задания](https://github.com/netology-code/virt-homeworks/blob/master/06-db-06-troobleshooting/README.md) Выполнение [домашнего задания](https://github.com/netology-code/virt-homeworks/blob/master/06-db-06-troobleshooting/README.md)
по теме "6.6. Troubleshooting". по теме "6.6. Troubleshooting".
## Q/A ## Q/A
### Задача 1 ### Задача 1
> Перед выполнением задания ознакомьтесь с документацией по [администрированию MongoDB](https://docs.mongodb.com/manual/administration/). > Перед выполнением задания ознакомьтесь с документацией по [администрированию MongoDB](https://docs.mongodb.com/manual/administration/).
> >
> Пользователь (разработчик) написал в канал поддержки, что у него уже 3 минуты происходит CRUD операция в MongoDB и её > Пользователь (разработчик) написал в канал поддержки, что у него уже 3 минуты происходит CRUD операция в MongoDB и её
> нужно прервать. > нужно прервать.
> >
> Вы как инженер поддержки решили произвести данную операцию: > Вы как инженер поддержки решили произвести данную операцию:
> - напишите список операций, которые вы будете производить для остановки запроса пользователя > - напишите список операций, которые вы будете производить для остановки запроса пользователя
> - предложите вариант решения проблемы с долгими (зависающими) запросами в MongoDB > - предложите вариант решения проблемы с долгими (зависающими) запросами в MongoDB
Первым шагом будет найти операцию, которую необходимо остановить. Для этого необходимо выполнить запрос на получение всех операций Первым шагом будет найти операцию, которую необходимо остановить. Для этого необходимо выполнить запрос на получение всех операций
в определённой БД, которые выполняются дольше 3 минут (180 секунд): в определённой БД, которые выполняются дольше 3 минут (180 секунд):
```javascript ```javascript
db.currentOp( db.currentOp(
{ {
"active" : true, "active" : true,
"secs_running" : { "$gt" : 180 }, "secs_running" : { "$gt" : 180 },
"ns" : /^db1\./ "ns" : /^db1\./
} }
) )
``` ```
В полученном массиве нужно найти нужную операцию и взять её `opid`. Затем полученный параметр подставить в команду: В полученном массиве нужно найти нужную операцию и взять её `opid`. Затем полученный параметр подставить в команду:
```javascript ```javascript
db.killOp(opid) db.killOp(opid)
``` ```
Самый оптимальный вариант решения проблемы: добавить ограничение на длительность выполняемого запроса. Самый оптимальный вариант решения проблемы: добавить ограничение на длительность выполняемого запроса.
Это можно настроить непосредственно для каждого запроса/операции, указав либо ключ `maxTimeMS`, либо вызвав метод `maxTimeMS()`, Это можно настроить непосредственно для каждого запроса/операции, указав либо ключ `maxTimeMS`, либо вызвав метод `maxTimeMS()`,
в зависимости от контекста. А затем уже необходимо настраивать мониторинг, чтобы понять, почему конкретно операции выполняются долго. в зависимости от контекста. А затем уже необходимо настраивать мониторинг, чтобы понять, почему конкретно операции выполняются долго.
### Задача 2 ### Задача 2
> Перед выполнением задания познакомьтесь с документацией по [Redis latency troobleshooting](https://redis.io/topics/latency). > Перед выполнением задания познакомьтесь с документацией по [Redis latency troobleshooting](https://redis.io/topics/latency).
> >
> Вы запустили инстанс Redis для использования совместно с сервисом, который использует механизм TTL. > Вы запустили инстанс Redis для использования совместно с сервисом, который использует механизм TTL.
> Причем отношение количества записанных key-value значений к количеству истёкших значений есть величина постоянная и > Причем отношение количества записанных key-value значений к количеству истёкших значений есть величина постоянная и
> увеличивается пропорционально количеству реплик сервиса. > увеличивается пропорционально количеству реплик сервиса.
> >
> При масштабировании сервиса до N реплик вы увидели, что: > При масштабировании сервиса до N реплик вы увидели, что:
> - сначала рост отношения записанных значений к истекшим > - сначала рост отношения записанных значений к истекшим
> - Redis блокирует операции записи > - Redis блокирует операции записи
> >
> Как вы думаете, в чем может быть проблема? > Как вы думаете, в чем может быть проблема?
Данная ситуация, скорее всего связана с проблемой, описанной в параграфе `Latency generated by expires` [документации redis](https://redis.io/docs/reference/optimization/latency/#latency-generated-by-expires). Данная ситуация, скорее всего связана с проблемой, описанной в параграфе `Latency generated by expires` [документации redis](https://redis.io/docs/reference/optimization/latency/#latency-generated-by-expires).
Если кратко, то большое количество ключей, чьё время жизни истекает в одно время могут привести к тому, Если кратко, то большое количество ключей, чьё время жизни истекает в одно время могут привести к тому,
что redis заблокирует доступ для произведения очистки. что redis заблокирует доступ для произведения очистки.
По умолчанию redis настроен на удаление 200 истёкших ключей в секунду. При этом алгоритм адаптивный и будет зацикливаться, если обнаружит, По умолчанию redis настроен на удаление 200 истёкших ключей в секунду. При этом алгоритм адаптивный и будет зацикливаться, если обнаружит,
что более 25% процентов ключей уже истекли. Изначальное значение можно увеличить через конфигурацию `ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP`. что более 25% процентов ключей уже истекли. Изначальное значение можно увеличить через конфигурацию `ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP`.
### Задача 3 ### Задача 3
> Перед выполнением задания познакомьтесь с документацией по [Common Mysql errors](https://dev.mysql.com/doc/refman/8.0/en/common-errors.html). > Перед выполнением задания познакомьтесь с документацией по [Common Mysql errors](https://dev.mysql.com/doc/refman/8.0/en/common-errors.html).
> >
> Вы подняли базу данных MySQL для использования в гис-системе. При росте количества записей, в таблицах базы, > Вы подняли базу данных MySQL для использования в гис-системе. При росте количества записей, в таблицах базы,
> пользователи начали жаловаться на ошибки вида: > пользователи начали жаловаться на ошибки вида:
> ```python > ```python
> InterfaceError: (InterfaceError) 2013: Lost connection to MySQL server during query u'SELECT..... ' > InterfaceError: (InterfaceError) 2013: Lost connection to MySQL server during query u'SELECT..... '
> ``` > ```
> >
> Как вы думаете, почему это начало происходить и как локализовать проблему? > Как вы думаете, почему это начало происходить и как локализовать проблему?
> >
> Какие пути решения данной проблемы вы можете предложить? > Какие пути решения данной проблемы вы можете предложить?
// todo Данная проблема, скорее всего, происходит по причине, что по запросу выбирается очень большое количество строк (исчисляется миллионами).
Варианты решения проблемы:
### Задача 4 - Переписать запрос на выборку результатов, добавив какие-либо ограничения (например, `limit`);
- Увеличить значение `net_read_timeout` со значения по умолчанию до 60 секунд или больше.
> Перед выполнением задания ознакомьтесь со статьей [Common PostgreSQL errors](https://www.percona.com/blog/2020/06/05/10-common-postgresql-errors/) из блога Percona.
> Для более точной локализации проблемы можно использовать журнал ошибок, путь до которого задаётся конфигурацией `log_error`.
> Вы решили перевести гис-систему из задачи 3 на PostgreSQL, так как прочитали в документации, что эта СУБД работает с
> большим объемом данных лучше, чем MySQL. ### Задача 4
>
> После запуска пользователи начали жаловаться, что СУБД время от времени становится недоступной. В dmesg вы видите, что: > Перед выполнением задания ознакомьтесь со статьей [Common PostgreSQL errors](https://www.percona.com/blog/2020/06/05/10-common-postgresql-errors/) из блога Percona.
> >
> `postmaster invoked oom-killer` > Вы решили перевести гис-систему из задачи 3 на PostgreSQL, так как прочитали в документации, что эта СУБД работает с
> > большим объемом данных лучше, чем MySQL.
> Как вы думаете, что происходит? >
> > После запуска пользователи начали жаловаться, что СУБД время от времени становится недоступной. В dmesg вы видите, что:
> Как бы вы решили данную проблему? >
> `postmaster invoked oom-killer`
// todo >
> Как вы думаете, что происходит?
>
> Как бы вы решили данную проблему?
Данная проблема возникает из-за недостатка оперативной памяти. `OOM Killer` - это компонент ядра Linux, призванный решать проблему недостатка памяти.
Таким образом, если настроен `OOM Killer`, то он будет "убивать" процессы, если ОС недостаточно RAM (включая swap).
В таком случае есть несколько вариантов решения:
1. Ограничить количество потребляемой оперативной памяти инстансом БД. Например, следуя следующим [рекомендациям](https://www.enterprisedb.com/postgres-tutorials/how-tune-postgresql-memory).
2. Увеличить количество оперативной памяти для машины. Данный способ, скорее всего, будет являться временным,
так как с увеличением количества данных будет увеличиваться и количество потребляемой оперативной памяти.