mirror of
https://github.com/Dannecron/netology-devops.git
synced 2025-12-25 15:22:37 +03:00
homework 6.6: add tasks 3-4
This commit is contained in:
@@ -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. Увеличить количество оперативной памяти для машины. Данный способ, скорее всего, будет являться временным,
|
||||
так как с увеличением количества данных будет увеличиваться и количество потребляемой оперативной памяти.
|
||||
|
||||
Reference in New Issue
Block a user