Назад | Перейти на главную страницу

Эквивалентно команде 'top' в кластере EMR?

У меня есть кластер EMR с тремя экземплярами, работающий на AWS, и он отвечает очень сейчас медленно.

При проверке панели мониторинга Hadoop на порту 8088 в моем браузере я вижу «Используемая память: 203,5 ГБ» и «Доступная память: 214 ГБ». Я предполагаю, что проблема здесь: вся оперативная память в настоящее время занята.

Как я могу узнать, какое приложение запущено и занимает всю оперативную память? Есть что-то вроде top команда для кластера? Когда я подключаюсь по SSH к главному узлу и проверяю top и free -g, вывод предполагает, что> 50% ОЗУ все еще доступно, и это противоречит выводам веб-отчета порта 8088.

Amazon уже предоставляет веб-интерфейс со статистикой по вашему кластеру EMR, просто перейдите по ссылке:

https://console.aws.amazon.com//elasticmapreduce/home

Выберите ссылку на кластер в разделе «Имя», чтобы открыть страницу сведений о кластере. Используйте каждую вкладку для просмотра соответствующей информации.

Например, вы можете найти сведения о вакансии для приложения Spark, перейдя в Application history а затем выбрав Application id и расширяя линейку. Подробнее: https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-cluster-application-history.html

Сначала немного подробностей о показателях:

Показатели «используемая память» и «доступная память» из YARN UI, о которых вы упомянули, указывают на использование памяти в процессах YARN, а не на хосты, используемые ResourceManager YARN.

Например. у вас есть 3 узла в кластере, с объемом более 64 ГБ каждый (bc 64 * 3 <214), например, 128 ГБ, однако YARN настроен на использование ~ 71 ГБ (214/3). (Я предполагаю, что цифры неверны, но это всего лишь пример). Для каждого узла все процессы на нем используют около 50% ОЗУ, однако ваше приложение использует почти всю ОЗУ, доступную для YARN в кластере.

Во-вторых: вполне нормально использовать как можно больше памяти кластера, если только ваш кластер не соответствует вашим потребностям, и вы не планируете увеличивать нагрузку без перенастройки кластера. Нужно только отслеживать фактические метрики хостов внизу, потому что для работы JVM также требуется свободная ОЗУ хоста для накладных расходов, хранилища вне кучи и т. Д.

В-третьих, предложения по вашему делу:

похоже, что ваши узлы не очень эффективно используются (загружены). Как правило, 80% использования - это то, чего вы хотите достичь для своей инфраструктуры (ОЗУ, ЦП и т. Д.). Итак, вы можете рассмотреть возможность перехода к меньшим узлам, но с их немного большим количеством. Меньшие узлы привели бы к меньшему количеству данных, большему параллелизму и, возможно, ускорению обработки за меньшие деньги.