Перед выполнением задания ознакомьтесь с документацией по администрированию MongoDB.
Пользователь (разработчик) написал в канал поддержки, что у него уже 3 минуты происходит CRUD операция в MongoDB и её нужно прервать.
Вы как инженер поддержки решили произвести данную операцию:
- напишите список операций, которые вы будете производить для остановки запроса пользователя
- предложите вариант решения проблемы с долгими (зависающими) запросами в MongoDB
Необходимо выяснить причины длительного выполнения CRUD запроса, здесь помогут команды в mongo-shell (gte и lte можно экспериментально повыбирать, для получения вывода нужных операций):
db.current({"secs_running":{$gte: 5}})
db.inventory.find(
{ quantity: { $gte: 100, $lte: 200 } }
).explain("executionStats")
Также стоит зайти в систему мониторинга (free monitoring или сторонняя). Возможно имеет место утечка или банальная нехватка вычислительных ресурсов (соответсвенно либо расширять, либо оптимизаировать текущую БД).
Перед выполнением задания познакомьтесь с документацией по Redis latency troobleshooting.
Вы запустили инстанс Redis для использования совместно с сервисом, который использует механизм TTL. Причем отношение количества записанных key-value значений к количеству истёкших значений есть величина постоянная и увеличивается пропорционально количеству реплик сервиса.
При масштабировании сервиса до N реплик вы увидели, что:
- сначала рост отношения записанных значений к истекшим
- Redis блокирует операции записи
Как вы думаете, в чем может быть проблема?
Раз проблема имеет место только при масштабировании, то требуется смотреть в сторону конфигурации и сетевой доступности новых нод.
В связи с тем, что начался рост отношения записанных значения к истекшим, можно говорить о том, что данные начали перетираться из-за нехватки не достигнув TTL.
Это может говорить о нехватки памяти (по причине утечки например).
Не помешает также пройтись по чеклисту настроек Redis (особенно пункт 2):
- проверка Redis на наличие блокирующих slow команд
redis- cli SLOWLOG GET - проверка отключения huge_page на уровне ядра:
echo never > /sys/kernel/mm/transparent_hugepage/enabled && \ systemctl restart redis - проверка задержки на уровне VM:
redis-cli --intrinsic-latency 100
Вы подняли базу данных MySQL для использования в гис-системе. При росте количества записей, в таблицах базы, пользователи начали жаловаться на ошибки вида:
InterfaceError: (InterfaceError) 2013: Lost connection to MySQL server during query u'SELECT..... 'Как вы думаете, почему это начало происходить и как локализовать проблему? Какие пути решения данной проблемы вы можете предложить?
На мой взгляд, причин может быть несколько:
- Проблемы в сетевой доступности между клиентом и сервером. Если проблема массовая, то веротяно проблема на стороне сервера, а не клиента.
Стоит проверить сетевую доступность ping, возможно снять дамп трафика.
- Запрос подразумевает слишком обьемный ответ. Т.е. запрос не успевает завершиться до истечения таймера net_read_timeout. Возможно его стоит увеличить.
- Также есть параметры max_allowed_packet, connect_timeout, которые также могут помочь в решении проблемы. Данный кес может всплыть при очень плохой сетевой доступности клиента (высокие задержки, джиттер, потери).
Вы решили перевести гис-систему из задачи 3 на PostgreSQL, так как прочитали в документации, что эта СУБД работает с большим объемом данных лучше, чем MySQL.
После запуска пользователи начали жаловаться, что СУБД время от времени становится недоступной. В dmesg вы видите, что:
postmaster invoked oom-killer
Как вы думаете, что происходит?
Как бы вы решили данную проблему?
Модуль oom-killer для решения проблемы нехватки памяти для ядра системы. Соответсвенно, имеет место быть ее нехватка. В причинах стоит разобраться. Смотрим pg_top, top, htop. Смотрим систему мониторинга и проверяем имеет ли место утечка памяти. Проверяем отключены ли huge_pages. Возможно имеет смысл уменьшить параметр shared_buffers и work_mem в конфигурации postgres.conf, это сократит прожорливость процесса. Кроме того, для postgres 12.x возможно утечка памяти при work_mem=128MB.