Beam smp что это

Почему процесс жрет много процессорного времени, зависая в select?

Почему процесс жрет много процессорного времени, зависая в select? Конкретно процесс beam.smp висит:

Process 2005 attached — interrupt to quit select(0, NULL, NULL, NULL, NULL

2005 rabbitmq 20 0 2125m 56m 2576 S 56.6 0.7 169:21.78 beam.smp

56,6% — это загрузка процессора.

При том маршрутизации очередей в RabbitMQ не так много.

По памяти не так и много:

Некий erlang’овский rpmd-daemon отвисает на таких системных выховах:

Process 1017 attached — interrupt to quit select(7, [3 5], NULL, NULL, ) = 0 (Timeout) gettimeofday(, NULL) = 0 select(7, [3 5], NULL, NULL, ) = 0 (Timeout) gettimeofday(, NULL) = 0 select(7, [3 5], NULL, NULL, ) = 0 (Timeout)

Но редко и ресурсов не кушает почти.

А вот beam.smp в самом верху top’a.

В чем может быть проблема?

Работа ELMA365 с антивирусным ПО

В статье приводится описание ключевых аспектов настройки файерволла и правильного размещения приложения и СУБД, которые обеспечивают максимальную производительность и безопасность работы системы ELMA365.

ELMA365 является микросервисным решением, использующим технологии Golang, NodeJS, Angular, PostgreSQL, MongoDB, RabbitMQ, Redis, Docker, Kubernetes и S3 MinIO протокола для хранения файлов. Расположение приложения и СУБД в DMZ (Demilitarized Zone — демилитаризованная зона) и контроль трафика с помощью файерволла обеспечат безопасность работы системы ELMA365.

elma365-with-antivirus

Антивирусы могут замедлять работу приложения ELMA365, так как производят проверку трафика между контейнерами и базой данных, а также сканируют файлы и кэшируют информацию в памяти. Проверка читаемых файлов СУБД не предполагает наличия вредоносного кода, поэтому эта процедура не приносит пользы и замедляет работу приложения.

Приложение ELMA365 и СУБД взаимодействуют посредством определённых портов. Проверка трафика через эти порты может также замедлять работу, так как приложение активно взаимодействует с СУБД. При этом антивирус проверяет каждое сообщение, отправленное между приложением и СУБД, не пересылая его напрямую.

Рекомендуется устанавливать антивирус на обратном прокси на границе DMZ. Это позволит избежать автоматической проверки трафика между приложением и СУБД, а также максимально ускорить и обезопасить работу системы.

Если несмотря на приведённые рекомендации вам необходимо установить антивирус, в исключения для версий KinD и Microk8s портов 443 и 80 для взаимодействия с пользователем нужно добавить следующие внутренние порты:

для взаимодействия с БД: 5432, 27017, 6379, 5672, 9000;
для взаимодействия с сервисами: 33349, 10248, 25000, 10249, 9099, 10251, 10252, 10256, 19001, 1338, 6010, 33955, 10250, 10255, 10257, 10259, 16443.

Также в исключения необходимо внести директории /opt/elma365/ и /var/lib/docker/overlay2/ , а также следующие БД и процессы:

Базы данных приложения ELMA365:

/opt/bitnami/postgresql/bin/postgres;
/opt/bitnami/mongodb/bin/mongod;
/opt/bitnami/mongodb/bin/mongo;
redis-server;
/opt/bitnami/redis/bin/redis-server;
/opt/bitnami/erlang/lib/erlang/erts-12.3.1/bin/beam.smp;
/opt/bitnami/rabbitmq/sbin/rabbitmq-server;
minio;
/opt/bitnami/minio/bin/minio server.

Процессы приложения ELMA365:

/bin/sh;
/coredns;
/hostpath-provisioner;
/nginx-ingress-controller;
/opt/bitnami/erlang/lib/erlang/erts-12.3.1/bin/epmd;
/sbin/dinit;
/snap/microk8s/3410/bin/containerd;
/snap/microk8s/3410/bin/containerd-shim-runc-v1;
/snap/microk8s/3410/kubelite;
/srv/elma365ctl-server;
/usr/bin/dumb-init;
/usr/bin/kube-controllers;
/usr/libexec/git-core/git-daemon;
/usr/local/bin/node;
/usr/local/bin/runsvdir;
calico-node;
git daemon;
gpg-agent;
nginx: cache manager process;
nginx: master process;
nginx: worker process;
runsv;
sh;
внутренние процессы ELMA365.

Для получения списка внутренних процессов обратитесь в техподдержку ELMA365.

Couchbase 4.5.1: What is beam.smp and why it is consuming too much memory

We are having a single node Couchbase [4.5.1-2844 Community Edition (build-2844)]. For some reason, we are seeing high memory usage on the server. When we log into the server and view the stats we can see that memcached and beam.smp service is using the memory. I need to know, what is the use of beam.smp process, and why it is consuming high memory. Screenshot for the same is attached to the question. Also I have followed the following links to debug the issues: https://forums.couchbase.com/t/beam-smp-memory-usage/11843/2 https://issues.couchbase.com/browse/MB-20521 enter image description here

asked Feb 7, 2019 at 13:06
101 1 1 gold badge 1 1 silver badge 3 3 bronze badges

1 Answer 1

beam.smp is the Erlang vitual machine used by CouchDB (as CouchBase) for serving and indexing your DB. So it’s where the magic happens.

answered Jul 15, 2019 at 9:46
111 2 2 bronze badges

The Overflow Blog

Hot Network Questions

Subscribe to RSS

Question feed

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

RabbitMQ (beam.smp) and high CPU/memory load issue

I have a debian box running tasks with celery and rabbitmq for about a year. Recently I noticed tasks were not being processed so I logged into the system and noticed that celery could not connect to rabbitmq. I restarted rabbitmq-server and even though celery was not complaining anymore it was not executing new tasks now. The odd thing was that rabbitmq was devouring cpu and memory resources like crazy. Restarting server would not solve the problem. After spending couple hours looking for solution online to no avail I decided to rebuild the server. I rebuilt new server with Debian 7.5, rabbitmq 2.8.4, celery 3.1.13 (Cipater). For about an hour or so everything worked beautifully again until celery started complaining again that it can’t connect to rabbitmq!

[2014-08-06 05:17:21,036: ERROR/MainProcess] consumer: Cannot connect to amqp://guest:**@127.0.0.1:5672//: [Errno 111] Connection refused. Trying again in 6.00 seconds.

I restarted rabbitmq service rabbitmq-server start and same issue gain: rabbitmq started again swelling up constantly pounding on cpu and slowly taking over all ram and swap:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21823 rabbitmq 20 0 908m 488m 3900 S 731.2 49.4 9:44.74 beam.smp

Here’s the result on rabbitmqctl status :

Status of node 'rabbit@li370-61' . [, , , , , , ]>, >, , , , , , , , , , ]>, , , , , , , , ]>, ,]>, ,

Some entries from /var/log/rabbitmq:

=WARNING REPORT==== 8-Aug-2014::00:11:35 === Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: =WARNING REPORT==== 8-Aug-2014::00:11:35 === Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: =WARNING REPORT==== 8-Aug-2014::00:11:35 === Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: =WARNING REPORT==== 8-Aug-2014::00:11:35 === Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: =WARNING REPORT==== 8-Aug-2014::00:11:36 === Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: =INFO REPORT==== 8-Aug-2014::00:11:36 === vm_memory_high_watermark set. Memory used:422283840 allowed:414559436 =WARNING REPORT==== 8-Aug-2014::00:11:36 === memory resource limit alarm set on node 'rabbit@li370-61'. ********************************************************** *** Publishers will be blocked until this alarm clears *** ********************************************************** =INFO REPORT==== 8-Aug-2014::00:11:43 === started TCP Listener on [::]:5672 =INFO REPORT==== 8-Aug-2014::00:11:44 === vm_memory_high_watermark clear. Memory used:290424384 allowed:414559436 =WARNING REPORT==== 8-Aug-2014::00:11:44 === memory resource limit alarm cleared on node 'rabbit@li370-61' =INFO REPORT==== 8-Aug-2014::00:11:59 === vm_memory_high_watermark set. Memory used:414584504 allowed:414559436 =WARNING REPORT==== 8-Aug-2014::00:11:59 === memory resource limit alarm set on node 'rabbit@li370-61'. ********************************************************** *** Publishers will be blocked until this alarm clears *** ********************************************************** =INFO REPORT==== 8-Aug-2014::00:12:00 === vm_memory_high_watermark clear. Memory used:411143496 allowed:414559436 =WARNING REPORT==== 8-Aug-2014::00:12:00 === memory resource limit alarm cleared on node 'rabbit@li370-61' =INFO REPORT==== 8-Aug-2014::00:12:01 === vm_memory_high_watermark set. Memory used:415563120 allowed:414559436 =WARNING REPORT==== 8-Aug-2014::00:12:01 === memory resource limit alarm set on node 'rabbit@li370-61'. ********************************************************** *** Publishers will be blocked until this alarm clears *** ********************************************************** =INFO REPORT==== 8-Aug-2014::00:12:07 === Server startup complete; 0 plugins started. =ERROR REPORT==== 8-Aug-2014::00:15:32 === ** Generic server rabbit_disk_monitor terminating ** Last message in was update ** When Server state == ,false> ** Reason for termination == ** =INFO REPORT==== 8-Aug-2014::00:15:37 === Disk free limit set to 50MB =ERROR REPORT==== 8-Aug-2014::00:16:03 === ** Generic server rabbit_disk_monitor terminating ** Last message in was update ** When Server state == ,false> ** Reason for termination == ** =INFO REPORT==== 8-Aug-2014::00:16:05 === Disk free limit set to 50MB

UPDATE: Seems like problem was solved when installed newest version of rabbitmq (3.3.4-1) from rabbitmq.com repository. Originally I had one installed (2.8.4) from Debian repositories. So far rabbitmq-server is working smoothly. I will update this post if issue comes back. UPDATE: Unfortunately after about 24 hours the issue reappeared where rabbitmq shut down and restarting the process would make it consume resources until it shuts down again within minutes.